Détérioration de performances sous contraintes : les règles structurelles exposent la fragilité des agents LLM dans la génération de code backend, d'après une étude. L'IA est loin de remplacer les développeurs

Détérioration de performances sous contraintes : les règles structurelles exposent la fragilité des agents LLM dans la génération de code backend, d’après une étude. L’IA est loin de remplacer les développeurs.

L’on donne à un agent de codage IA une spécification claire : créer une API REST avec ces 19 endpoints. L'agent s'exécute dans un environnement vierge, choisit sa propre structure et produit un résultat qui satisfait 86 % des assertions. Puis l’on ajoute une seule phrase : « Utilise Clean Architecture, PostgreSQL et SQLAlchemy. » Le même agent, le même modèle, la même spécification, et le taux de réussite chute à 46 %. Cet écart a un nom. Un article publié en 2026 par EURECOM et l’université de Basilicate le désigne sous le nom « déclin des performances sous contraintes. » Il vient rappeler à quel point l’intelligence artificielle est loin de remplacer de façon totale les développeurs informatiques humains.

Ampleur de la baisse due à l'ajout de contraintes

Les agents de codage IA performants perdent en moyenne 30 points de pourcentage de taux de réussite aux tests de validation lorsque des contraintes structurelles sont ajoutées à un cahier des charges fonctionnel. L'équipe d'EURECOM a mesuré ce phénomène sur les 8 configurations performantes de son étude, définies comme celles obtenant un score supérieur à 50 % sur la base de référence sans contraintes. La baisse observée entre le niveau L0 (cadre web uniquement) et le niveau L3 (architecture + base de données + ORM) est systématique.

Cette méthodologie permet d'établir clairement les liens de causalité. L'équipe a défini une seule spécification OpenAPI, l'API RealWorld Conduit comprenant 19 opérations CRUD, puis a appliqué des contraintes à quatre niveaux : L0 (framework uniquement), L1 (une contrainte supplémentaire), L2 (deux), L3 (architecture + base de données + ORM). Chaque variante s'exécute dans 8 frameworks sur 80 tâches, avec 291 assertions comportementales par tâche. Les agents s'exécutent dans Docker, le code est évalué par des tests HTTP de bout en bout ainsi que par des vérificateurs statiques qui vérifient si les contraintes d'architecture, de base de données et d'ORM ont bien été respectées. L'évaluation totale a consommé environ 5 milliards de jetons.

L'écart entre le taux de réussite des assertions et le taux de réussite au premier essai (pass@1) est un résultat qui ne tient pas sur un graphique. OpenHands + MiniMax-M2.5 a atteint 78,6 % d'A% sur les tâches L3 les plus difficiles, mais seulement 8,3 % de pass@1. Près de quatre exécutions sur cinq ont échoué à un moment ou à un autre au cours de la suite de 291 assertions. L'article soulève un point méthodologique important pour quiconque évalue des agents de codage : le taux de réussite à la première tentative (pass@1) est bruité, car une seule assertion échouée réduit à néant l'ensemble de l'exécution ; le taux de réussite (A%) reflète donc les progrès partiels de manière plus stable. Mais l'écart entre les deux indique que même lorsqu'un agent semble compétent en moyenne, la probabilité d'une exécution sans faille dans des conditions de production réelles est inférieure à 10 %.


Ce sont les contraintes des bases de données qui causent la plupart des problèmes

La majeure partie de cette baisse de 30 points est due à des contraintes liées à la base de données, et non à l'architecture ou aux règles ORM. L'étude utilise un plan d'expérience par paires appariées pour isoler l'effet marginal de chaque contrainte, en comparant des paires de tâches qui ne diffèrent que par une seule contrainte, toutes les autres variables étant maintenues constantes.

Le chiffre relatif à l'ORM peut sembler trompeur à première vue, et l'article explique pourquoi. L'effet marginal d'un ORM est mesuré par rapport à une base de référence qui inclut déjà une base de données ; il reflète donc le coût lié à l'utilisation forcée d'un ORM à la place du SQL brut, et non le coût de l'interaction avec la couche de données en soi. Lorsque l'équipe a effectué une analyse des défaillances sur les 222 exécutions ayant échoué sur les deux modèles, les défauts au niveau de la couche de données (composition incorrecte des requêtes et erreurs d'exécution ORM) représentaient environ 45 % de toutes les erreurs logiques. La base de données est la partie la plus difficile, que l'on utilise ou non un ORM par-dessus.

Les erreurs logiques ont dominé les échecs avec environ 71 % sur les deux modèles analysés, le reste se répartissant entre les échecs de démarrage du serveur (12 à 21 %), les implémentations incomplètes et une poignée d'agents bloqués dans des boucles. Les agents ne rencontraient pas d'échec au démarrage. Ils démarraient des serveurs qui traitaient des requêtes mal formées, des en-têtes d'authentification avec des majuscules et minuscules incorrectes, et des modèles ORM dont le modèle se souvenait à moitié à partir des données d'entraînement. Qwen3-Coder-Next, en particulier, a montré que 22,6 % de ses erreurs logiques étaient dues à une mauvaise configuration de l'authentification, principalement un analyse syntaxique incorrecte du préfixe du jeton.


Le framework web choisi comme référence peut faire varier le taux de réussite des tests de 33 points avant même que d'autres contraintes ne soient ajoutées.

Express, Koa et Flask constituent clairement le trio de tête. Ils partagent une interface API minimaliste et explicite, où l'agent doit définir directement le routage, l'injection de dépendances et la validation. FastAPI pénalise l'agent pour les aspects que les utilisateurs apprécient généralement : la validation basée sur les indications de type, les conventions d'injection de dépendances et la détection automatique exigent de l'agent qu'il se souvienne des idiomes du framework acquis lors de la pré-formation plutôt que de les définir explicitement. Django paie un prix similaire pour privilégier les conventions plutôt que la configuration. Hono est à la traîne car l'environnement de test fonctionne sur Node.js, où Hono a besoin d'un adaptateur de compatibilité sous-représenté dans les données d'entraînement.

Le schéma est le même que celui dont parle Anthropic dans ses conseils sur l'ingénierie contextuelle : les agents échouent non pas lorsque la tâche est difficile, mais lorsque le contexte pertinent est implicite. Ce que les guides d'ingénierie contextuelle d'Anthropic omettent de mentionner, c'est que le terme « implicite » inclut les conventions de framework ancrées dans la mémoire musculaire des développeurs. Pour un développeur Django, INSTALLED_APPS est une évidence. Pour un agent générant du code à partir de zéro, c'est l'une des milliers de valeurs par défaut du framework qu'il doit deviner.


Prendre en compte toutes ces contraintes est ce qui s’appelle mettre sur pied un logiciel fonctionnel, prêt à être déployé en production et maintenable. C’est le rôle d’un ingénieur logiciel humain qui ne se limite pas à de la complétion de code dans laquelle les agents IA sont excellents.

« L'intelligence artificielle peut coder, mais elle n'est pas capable de construire un logiciel fonctionnel et prêt à être mis en production, sans intervention humaine », déclare Matias Heikkilä. Dans une récente analyse sur les agents d'IA de codage, il affirme que de nombreux entrepreneurs recherchent activement des personnes pouvant faire fonctionner le code généré par l'IA.

Il a déclaré avoir lui-même déjà reçu plusieurs de ces demandes. Selon Matias Heikkilä, ces offres d'emploi d'un nouveau genre démontrent que l'IA est peut-être douée pour le prototypage ou la création de démos, mais elle ne peut actuellement pas créer de logiciel, c'est-à-dire faire de l'ingénierie logicielle.

Selon une étude publiée par Uplevel en septembre 2024, l'utilisation de GitHub Copilot a entraîné une augmentation de 41 % des bogues. Les personnes qui ont utilisé GitHub Copilot n'ont pas été soulagées de l'épuisement professionnel, ce qui indique l'efficacité limitée de l'outil dans la réduction du stress lié au travail. Les développeurs passent désormais plus de temps à examiner le code généré par l'IA, ce qui pourrait contrebalancer tout gain de temps.

Son analyse a suscité un grand débat dans la communauté, de nombreux commentaires soutenant cette thèse. Les entreprises telles que Microsoft et Amazon investissent massivement dans l'IA générative et force leurs employés à adopter cette technologie en interne pour l'écriture de code. Cependant, plusieurs se plaignent des limites critiques des agents d'IA de codage, affirmant que ces outils augmentent la charge de travail au lieu de la réduire.

« Je suis abonné à un LLM de pointe, mais ces derniers temps, je ne l'utilise qu'environ 25 % du temps. À un certain niveau, les problèmes d'architecture logicielle que je résous, en m'appuyant sur des décennies de compréhension de la conception maintenable, performante et vérifiable des structures de données, des types et des algorithmes, sont des choses que les LLM ne peuvent même pas commencer à appréhender », a écrit un commentateur.

Des humains sont embauchés pour nettoyer le code écrit par l'IA

Avec l'essor d'outils d'IA tels que ChatGPT, il est désormais possible de décrire un programme en langage naturel (français par exemple) et de demander au modèle d'IA de le traduire en code fonctionnel. Andrej Karpathy, ancien chercheur d'OpenAI, a donné un nom à cette pratique : le « vibe coding ». Cette pratique gagne rapidement du terrain dans les milieux technologiques. Et Google a même déclaré que 25 % de son code est généré par l'IA.


Le vibe coding attire l'attention parce qu'elle pourrait abaisser la barrière à l'entrée de la création de logiciels. Mais des questions subsistent quant à la capacité de cette approche à produire de manière fiable un code adapté aux applications du monde réel. Les études montrent que l'IA est loin d'être à la hauteur.

C'est là que des entreprises comme Harsh Kumar interviennent. Harsh Kumar explique que ses clients lui mettent souvent à disposition des applications ou sites Web générés par une IA et qui se sont avérés instables ou totalement inutilisables. Son rôle : réparer la casse ou remettre de l’ordre dans le code généré par l’IA afin d’aboutir à un produit logiciel fonctionnel. Cette entreprise basée en Inde a déclaré qu'elle a un nombre important de clients.

Harsh Kumar entre ainsi dans la nouvelle catégorie de titre d’emploi dénommée spécialiste en nettoyage de code généré par l’IA. L’humain revient donc au secours de l’IA que les entreprises tentent de vendre comme une révolution et sur laquelle certains dirigeants s'appuient pour réduire leurs effectifs.

À l'heure actuelle, la plupart des projets d'IA échouent. Selon le MIT, le taux d'échec de 95 %. Malgré la ruée vers l'intégration de nouveaux modèles d'IA puissants, environ 5 % des programmes pilotes d'IA parviennent à accélérer rapidement leurs revenus ; la grande majorité stagne, n'ayant que peu ou pas d'impact mesurable sur le compte de résultat. Ce constat amer fait écho à des études récentes selon lesquelles les capacités de l'IA sont surestimées.

Source : Etude

Et vous ?

Les chiffres mis en avant par cette étude sont-ils pertinents ? Sont-ils cohérents avec la réalité dont vous êtes au fait avec les agents de codage IA ? Partagez vos expériences en tant que développeur de logiciels

Voir aussi :

L'IA peut-elle remplacer des développeurs professionnels ? Gemini CLI de Google et Replit ont commis des erreurs qui ont entraîné la suppression des données, inventant des répertoires, falsifiant des tests

L'IA n'est pas prête à remplacer les développeurs humains pour le débogage, selon des chercheurs de Microsoft. Elle ne peut pas déboguer les logiciels de manière fiable même si elle a accès à des outils

Les assistants d'IA de codage font-ils vraiment gagner du temps aux développeurs ? Une étude suggère que ces outils n'augmentent pas la vitesse de codage, mais augmentent significativement le taux de bogues