Le plafond de raisonnement sous contraintes — 55-60% et pas au-delà

En bref

Imaginez un architecte talentueux qui dessine de magnifiques bâtiments mais ne maîtrise pas les lois de la physique : ses plans sont esthétiques, parfois brillants, mais quand l’ingénieur structure les vérifie, près d’une fois sur deux les calculs ne tiennent pas. Les fondations ne portent pas la charge. Les portées sont trop longues. Les contraintes physiques sont violées. Les grands modèles de langage actuels se trouvent dans cette situation face aux problèmes d’optimisation sous contraintes : ils produisent des solutions plausibles, mais qui échouent à respecter les règles du domaine. Les LLM — y compris les modèles dits « de raisonnement » — plafonnent à 55-60 % de satisfaction des contraintes sur les tâches d’optimisation sous contraintes physiques, quelle que soit leur taille ou leur architecture. Le fine-tuning supervisé (SFT) améliore la mise en forme des réponses mais ne franchit pas ce seuil. Seul l’apprentissage par renforcement, via une méthode appelée GRPO, produit des gains mesurables sur la faisabilité. Ce résultat délimite une frontière concrète : les LLM actuels ne peuvent pas remplacer un solveur formel sur des problèmes où chaque contrainte doit être respectée.

Le test : optimisation de flux électriques

Pour mesurer si un LLM sait raisonner sous contraintes, il faut un problème où les contraintes ne sont pas optionnelles — où une solution qui les viole est simplement invalide. L’Optimal Power Flow (OPF) constitue ce type de banc d’essai.

L’OPF est un problème fondamental des réseaux électriques. Étant donné un réseau de nœuds (centrales, consommateurs, lignes) et une demande en puissance, le problème consiste à trouver la combinaison de production qui minimise le coût tout en respectant des contraintes physiques strictes : les lois de Kirchhoff (conservation du courant et de la tension à chaque nœud), les limites de puissance de chaque générateur, et les capacités de transport de chaque ligne. Ces contraintes ne sont pas des préférences — elles traduisent la physique du réseau. Une solution qui les ignore produirait une panne ou un incendie.

Ce que l’OPF rend difficile pour un LLM est précisément ce qui le rend intéressant : il ne suffit pas de produire une réponse « à peu près correcte ». Chaque contrainte doit être vérifiable. Un solveur formel comme Ipopt (Interior Point OPTimizer) — un optimiseur mathématique open-source conçu pour les problèmes non-linéaires — garantit une solution faisable ou déclare l’infaisabilité. Il n’hallucine pas.

Bernier, Ghamizi, Dogoulis et Cordy (Université du Luxembourg / LIST, 2026) ont construit un benchmark autour de l’OPF pour évaluer plusieurs LLM frontier sur leur capacité à raisonner et optimiser sous ces contraintes physiques. Le taux de satisfaction des contraintes est la métrique centrale : quelle proportion des contraintes physiques du problème la solution produite respecte-t-elle ?

En clair : l’OPF n’est pas un benchmark de “trouver la meilleure réponse” — c’est un benchmark de “trouver une réponse qui ne casse rien”. Un solveur classique répond toujours juste, ou refuse de répondre. Un LLM, lui, répond toujours — y compris quand sa réponse est physiquement infaisable. C’est précisément ce que mesure le test.

Le plafond — 55-60 % et pas au-delà

Le résultat central de Bernier et al. (arXiv:2603.23004) est net : sur la quasi-totalité des tâches nécessitant une optimisation réelle sous contraintes, les modèles stagnent autour de 55-60 % de satisfaction des contraintes. Ce plafond est indépendant de l’architecture du modèle, de sa taille, et de son régime d’entraînement.

Ce qui rend ce résultat notable, c’est son universalité. Les modèles dits « de raisonnement » — ceux qui génèrent une longue chaîne de pensée intermédiaire (chain-of-thought) avant de répondre — n’obtiennent pas de scores systématiquement supérieurs à leurs équivalents sans raisonnement étendu. Générer davantage de tokens intermédiaires ne résout pas le problème de faisabilité.

Le benchmark ConstraintBench (Xu et al., arXiv:2602.22465, 2026) confirme ce diagnostic sur un périmètre plus large. Ce benchmark évalue six modèles frontier sur 200 tâches couvrant dix domaines de recherche opérationnelle — planification de production, routage de véhicules, affectation de ressources, ordonnancement — avec des solutions vérifiées par le solveur Gurobi (un solveur commercial de référence pour les problèmes d’optimisation mixte-entière). Les modèles ne répondent pas en générant du code : ils doivent produire des décisions directes, vérifiées contrainte par contrainte.

Les résultats de ConstraintBench précisent le tableau :

• Le meilleur modèle atteint 65,0 % de faisabilité — légèrement au-dessus du plafond OPF, mais toujours loin d’un solveur.
• Quand un modèle produit une solution faisable, cette solution atteint 89-96 % de l’optimum Gurobi — c’est-à-dire que l’optimalité n’est pas le problème principal.
• Aucun modèle ne dépasse 30,5 % sur le critère joint (faisabilité + optimalité à 0,1 % du référent solveur).
• La difficulté varie fortement selon le domaine : 83,3 % de faisabilité sur des problèmes de mix de production, contre 0,8 % sur des problèmes d’affectation d’équipages.

La conclusion de ConstraintBench est claire : la faisabilité est le goulot d’étranglement primaire, pas l’optimalité. Lorsque les modèles parviennent à produire une solution qui respecte les contraintes, elle est généralement proche de l’optimum. Le problème est d’y arriver.

Les modes d’échec sont systématiques et non aléatoires. Les études identifient plusieurs patterns récurrents : sous-estimation des contraintes de durée (erreur de parsing structurel, pas ponctuelle), hallucination d’entités absentes du problème, et découplage entre faisabilité et optimalité — sur certains domaines, les modèles atteignent une haute faisabilité mais zéro optimalité, car la recherche exhaustive de type branch-and-bound nécessaire à l’optimalité est incompatible avec la génération autorégressive token par token.

En clair : le plafond 55-60 % n’est pas un échec aléatoire qu’on pourrait corriger par plus de données. C’est un mur structurel. Quand un LLM produit une solution faisable, elle est presque optimale (89-96 %) — le problème n’est pas la qualité, c’est la fiabilité. Quatre fois sur dix, la solution proposée viole une contrainte physique.

SFT apprend le format, pas le raisonnement

La réaction naturelle face à ce plafond est d’entraîner davantage les modèles sur des exemples de résolution. C’est ce que fait le Supervised Fine-Tuning (SFT) : le modèle apprend à reproduire des solutions correctes à partir d’un corpus étiqueté.

Bernier et al. ont testé cette approche extensivement. Leur résultat est sans ambiguïté : le SFT améliore la mise en forme des réponses mais échoue à améliorer la faisabilité physique. Le taux de satisfaction des contraintes reste au même plateau après fine-tuning. Le modèle apprend à présenter ses réponses dans le bon format — il structure mieux sa sortie, il nomme correctement les variables — mais il ne résout pas mieux le problème sous-jacent. En particulier, il ne transfère pas vers des topologies de réseau nouvelles (changements structurels non vus pendant l’entraînement).

Ce résultat s’inscrit dans une observation plus générale de la littérature 2025-2026. Guo et al. (arXiv:2602.01058) montrent que le SFT optimisé en isolation peut verrouiller les modèles dans des modes imitatifs rigides : le modèle apprend à reproduire les patterns de la distribution d’entraînement plutôt qu’à généraliser le raisonnement. La formulation des auteurs est directe — « SFT can lead to pattern matching that occasionally suppresses pre-trained reasoning logic or fails on out-of-distribution tasks » — le SFT peut induire du pattern matching qui écrase parfois la logique de raisonnement pré-entraînée, ou qui échoue sur des tâches hors distribution.

La distinction est importante pour comprendre pourquoi SFT ne suffit pas ici. L’OPF n’est pas un problème de reconnaissance de pattern. Une topologie de réseau légèrement différente change la structure du problème. Un modèle qui a mémorisé des solutions sur des topologies connues ne dispose pas des outils pour raisonner sur une topologie inédite — parce que le SFT ne lui a pas appris à raisonner, il lui a appris à imiter.

Ce mécanisme explique également les résultats de ProOPF (arXiv:2602.03070, 2026), un benchmark professionnel sur 12 000 instances OPF. Les LLM frontier atteignent plus de 90 % sur les benchmarks existants — mais tombent sous 30 % sur ProOPF-B, une évaluation annotée par des experts sur des problèmes réalistes. Le fossé entre performance sur benchmarks standards et performance sur problèmes professionnels reflète exactement le même phénomène : généralisation apparente, faisabilité réelle limitée.

GRPO : la seule méthode qui brise le plafond

Si le SFT ne franchit pas le plafond, la question est : qu’est-ce qui le franchit ?

Bernier et al. ont entraîné des variantes de leurs modèles avec GRPO (Group Relative Policy Optimization), une méthode d’apprentissage par renforcement (RL). Les auteurs rapportent des gains significatifs sur certaines topologies de réseau — gains que le SFT seul ne produisait pas.

GRPO a été introduit par DeepSeek AI dans DeepSeekMath (Shao et al., arXiv:2402.03300, 2024) pour le raisonnement mathématique. Son principe diffère du fine-tuning supervisé sur un point décisif : au lieu d’apprendre à imiter des solutions correctes, le modèle apprend à optimiser un signal de récompense. Ce signal évalue directement la qualité de la solution produite — ici, la validité structurelle et la faisabilité physique.

La mécanique de GRPO mérite d’être explicitée. Dans le RL classique avec feedback humain (RLHF), l’entraînement nécessite un modèle critique séparé (un « critic ») pour évaluer les sorties du modèle principal. GRPO supprime ce besoin : pour chaque problème, le modèle génère un groupe de réponses (d’où le mot « Group »), et la récompense de chaque réponse est calculée relativement à la moyenne du groupe. Les réponses meilleures que la moyenne sont renforcées, les moins bonnes sont pénalisées. Il n’y a pas de modèle critique externe — le groupe lui-même sert de référence.

Cette architecture a un avantage pratique : elle est moins coûteuse à entraîner que le RLHF complet. Elle a surtout un avantage pour les problèmes sous contraintes : la récompense peut être définie directement sur des critères vérifiables — est-ce que les lois de Kirchhoff sont respectées ? est-ce que les limites de puissance sont dans les bornes ? — plutôt que sur un jugement humain subjectif.

En clair : SFT apprend au modèle à imiter (« voici comment on présente une solution »), GRPO apprend au modèle à réussir (« voici une fonction qui dit si ta solution est valide, optimise-la »). Sur des problèmes où la réussite est mesurable mécaniquement (lois physiques, tests unitaires), GRPO franchit le plafond. Sur des problèmes où la “réussite” est subjective, le bénéfice s’estompe.

Les résultats de GRPO sur les benchmarks mathématiques donnent un ordre de grandeur de l’effet. Sur le benchmark MATH, DeepSeekMath passe de 46,8 % (version Instruct, entraînée par SFT) à 51,7 % avec GRPO — soit un gain de cinq points sur une tâche de raisonnement pur. Sur GSM8K, le gain est de 82,9 % à 88,2 %. Ces chiffres sont issus du papier fondateur (arXiv:2402.03300) et sont vérifiés.

Dans le domaine des contraintes physiques, les gains rapportés par Bernier et al. sont qualitatifs dans les sources accessibles — « améliorations modestes mais significatives » — sans chiffre précis extrait du corps de l’article. L’essentiel est la direction : GRPO produit une amélioration de la faisabilité là où SFT restait plat.

Une extension récente, Scaf-GRPO (arXiv:2510.19807, 2025), introduit une guidance structurée (scaffolding) pendant l’entraînement RL, et rapporte un gain de +44,3 % sur le benchmark AIME24 de raisonnement mathématique par rapport à GRPO vanilla. Ces développements suggèrent que la conception de la récompense et la structure du signal RL sont des leviers actifs — mais leur application systématique aux problèmes d’optimisation sous contraintes physiques reste un terrain de recherche ouvert.

Ce que ça implique pour les praticiens

Ces résultats ont des implications concrètes pour quiconque envisage d’utiliser des LLM dans des workflows nécessitant de l’optimisation sous contraintes.

Les LLM ne remplacent pas les solveurs formels. Un solveur comme Gurobi ou Ipopt garantit la faisabilité ou déclare l’infaisabilité. Un LLM, même performant, produit des solutions qui violent les contraintes dans 35-45 % des cas sur des problèmes réels. Sur des problèmes où une contrainte violée a des conséquences opérationnelles — réseau électrique, planification d’équipages, routage avec fenêtres temporelles strictes — ce taux d’échec est inacceptable.

La distinction génération de code / raisonnement direct est cruciale. OR-LLM-Agent (Zhang et al., arXiv:2503.10009, 2025) — un agent basé sur DeepSeek-R1 et GPT-o3-mini — atteint 85 % de précision sur 83 problèmes réels de recherche opérationnelle. Mais il ne résout pas les contraintes directement : il décompose le problème, génère du code Gurobi, et délègue l’optimisation au solveur. C’est un pattern architecturalement différent — le LLM agit comme un traducteur problème → code, pas comme un optimiseur. Cette approche fonctionne, mais elle contourne le problème de raisonnement plutôt qu’elle ne le résout.

Le SFT sur des exemples de domaine améliore la présentation, pas la robustesse. Si votre pipeline inclut un fine-tuning supervisé pour adapter un LLM à des problèmes d’optimisation, attendez-vous à ce que le modèle produise des sorties mieux formatées — mais ne comptez pas sur une amélioration de la satisfaction des contraintes sur des problèmes hors distribution. Pour cela, il faut un signal de récompense explicite (RL) ou un solveur en aval qui valide et corrige.

GRPO ouvre une voie, mais avec des limites à clarifier. Les gains rapportés sur l’OPF sont prometteurs, mais leur amplitude exacte et leur généralisation à d’autres domaines ne sont pas encore établis dans la littérature accessible. La conception de la récompense — quelle granularité, par contrainte ou par topologie — reste une question ouverte. Avant d’envisager un entraînement RL pour un cas d’usage spécifique, il faut pouvoir définir une récompense vérifiable automatiquement : c’est faisable sur des problèmes à contraintes formelles, plus difficile sur des problèmes où la faisabilité elle-même est ambiguë.

La difficulté varie selon le domaine. ConstraintBench montre une amplitude de 0,8 % à 83,3 % selon le type de problème. Le mix de production (tâche relativement bien contrainte et structurée) est beaucoup plus accessible que l’affectation d’équipages (combinatoire NP-difficile avec contraintes imbriquées). Avant de déployer un LLM sur une tâche d’optimisation, évaluer précisément sur des instances représentatives — les benchmarks généraux ne prédisent pas la performance sur des topologies spécifiques.

Architecture recommandée selon le profil contraint

Ce qu’il faut retenir

• Les LLM plafonnent à 55-60 % de satisfaction des contraintes sur les tâches d’optimisation sous contraintes physiques (OPF, recherche opérationnelle), indépendamment de la taille du modèle et de l’architecture. Ce plafond est documenté par au moins deux benchmarks indépendants (Bernier et al. 2026, ConstraintBench 2026).

• Le SFT améliore le format des réponses mais ne franchit pas ce plafond. Les modèles fine-tunés de manière supervisée restent au même niveau de faisabilité et ne transfèrent pas sur des topologies nouvelles — parce qu’ils imitent des patterns plutôt qu’ils n’apprennent à raisonner sous contraintes.

• GRPO (Group Relative Policy Optimization), une méthode RL sans modèle critique séparé, est la seule approche rapportant des gains mesurables sur la faisabilité dans ce domaine. Le mécanisme : récompenser directement les propriétés physiques vérifiables (validité structurelle, respect des bornes) rather than reproduire des solutions exemple.

• Le goulot d’étranglement réel est la faisabilité, pas l’optimalité : quand un modèle produit une solution faisable, elle est généralement proche de l’optimum (89-96 % selon ConstraintBench). Le problème est de produire une solution faisable en premier lieu.

• En pratique : pour des workflows exigeant une optimisation fiable sous contraintes dures, les LLM actuels opèrent mieux comme générateurs de code délégant à un solveur formel que comme optimiseurs directs.