Pourquoi les agents IA de codage échouent sur les fonctionnalités complexes

Les agents de codage IA sont omniprésents en 2026. Ils rédigent des pull requests, corrigent des bugs et génèrent des tests. Les mainteneurs acceptent 83,8% des pull requests générées par Claude Code dans les projets open source, dont plus de la moitié sont fusionnées sans modification humaine. Les gros titres suggèrent que nous approchons du génie logiciel autonome.

Mais un nouveau benchmark raconte une histoire très différente. FeatureBench, publié en février 2026 par des chercheurs de l'Académie chinoise des sciences et de Huawei, a testé les principaux agents IA sur le développement de fonctionnalités complexes multi-fichiers. Les résultats sont édifiants : Claude Opus 4.5, qui résout 74,4% des tâches SWE-bench, ne réussit que 11,0% des tâches FeatureBench. Même la meilleure configuration — Codex avec GPT-5.1 — ne gère que 12,5%.

Le fossé entre corriger un simple bug et construire une vraie fonctionnalité est énorme. Comprendre pourquoi est essentiel pour tout développeur travaillant avec des outils IA aujourd'hui.

Ce que FeatureBench mesure réellement

La plupart des benchmarks de codage, y compris le célèbre SWE-bench, testent les agents sur des corrections de bugs isolées. Une tâche SWE-bench typique implique de modifier environ 33 lignes de code et de passer environ 9 points de test. Ce sont de vrais problèmes issus de vrais dépôts, mais ils ne représentent qu'une fraction du développement logiciel.

FeatureBench change la donne en testant le développement au niveau des fonctionnalités — le type de travail qui couvre plusieurs commits, touche de nombreux fichiers et nécessite de comprendre comment les différentes parties d'une base de code sont connectées. Une tâche FeatureBench typique exige :

• Environ 790 lignes de nouveau code
• Des modifications sur 15 fichiers ou plus
• La réussite de 60 points de test ou plus
• La compréhension de dépendances inter-fichiers complexes

Le benchmark comprend 200 tâches extraites de 24 dépôts Python open source, couvrant tout, des ajouts progressifs de fonctionnalités à la construction de fonctionnalités depuis zéro.

Trois raisons pour lesquelles les agents échouent sur les fonctionnalités complexes

Les chercheurs de FeatureBench ont identifié trois schémas d'échec fondamentaux qui expliquent la chute dramatique des performances.

1. Cécité aux dépendances inter-fichiers

Quand une fonctionnalité couvre plusieurs fichiers, les agents doivent suivre les imports, les signatures de fonctions, les hiérarchies de classes et l'état partagé dans toute la base de code. Les agents actuels échouent fréquemment. Le type d'erreur le plus courant est NameError — l'agent référence une fonction ou une classe existant dans un autre fichier mais utilise le mauvais nom, les mauvais arguments, ou oublie de l'importer.

Les corrections de bugs simples révèlent rarement cette faiblesse car elles impliquent typiquement des changements dans un seul fichier ou un petit groupe de fichiers liés.

2. Le problème de la paresse

Les chercheurs ont découvert que les LLM actuels présentent une tendance à la "paresse" — ils devinent les interfaces au lieu de lire les fichiers pour récupérer les prototypes exacts. Quand un agent doit appeler une fonction définie ailleurs dans la base de code, il invente souvent une signature plausible au lieu de naviguer vers le code source réel pour la vérifier.

Cela fonctionne étonnamment bien pour les patterns courants et les bibliothèques connues, mais échoue de façon catastrophique dans les grandes bases de code personnalisées où les signatures de fonctions sont uniques et non évidentes.

3. Échelle et planification à long terme

Construire une fonctionnalité nécessite de la planification : quels fichiers créer, lesquels modifier, dans quel ordre effectuer les changements, et comment vérifier que tout fonctionne ensemble. Les agents actuels peinent avec ce type de planification à long terme. Ils tendent à plonger directement dans l'implémentation plutôt que d'explorer d'abord la base de code, comprendre les patterns existants et créer un plan cohérent.

Corriger un bug est une opération tactique. Construire une fonctionnalité est une opération stratégique. Les agents sont tactiquement compétents mais stratégiquement faibles.

Les preuves issues de l'open source

Les résultats de FeatureBench concordent avec des recherches plus larges sur l'adoption des agents IA dans les projets open source. Une étude MSR de 2026 analysant des centaines de pull requests générées par IA a trouvé des patterns clairs :

• Les tâches de documentation atteignent un taux d'acceptation de 82,1%
• Les nouvelles fonctionnalités chutent à 66,1%
• Les changements structurels comme les refactorisations obtiennent les taux de succès les plus bas et les temps de résolution les plus longs

Le schéma est constant : plus la tâche est complexe et transversale, plus l'agent risque d'échouer ou de nécessiter une intervention humaine significative.

Ce que cela signifie pour les développeurs

Ces données ne signifient pas que les agents de codage IA sont inutiles — bien au contraire. Le taux d'acceptation de 83,8% sur les PR Claude Code est réel et impressionnant. Mais cela signifie que les développeurs doivent calibrer leurs attentes.

Où les agents apportent de la valeur aujourd'hui

• Corrections de bugs avec des étapes de reproduction claires
• Génération de tests pour le code existant
• Documentation et commentaires de code
• Refactorisation de routine dans un seul fichier
• Code standardisé et patterns répétitifs

Où la supervision humaine reste critique

• Développement multi-fichiers couvrant la base de code
• Décisions architecturales sur la conception du système
• Préoccupations transversales comme l'authentification, le cache ou la journalisation
• Travail d'intégration connectant plusieurs systèmes
• Optimisation des performances nécessitant une compréhension profonde du système

Le workflow émergent

Les équipes les plus productives en 2026 ne remplacent pas les développeurs par des agents. Elles utilisent un workflow hybride : les humains gèrent l'architecture, la planification et l'intégration complexe tandis qu'ils délèguent des sous-tâches bien définies aux agents. Le rôle du développeur passe de l'écriture de chaque ligne à la décomposition des fonctionnalités en unités adaptées aux agents et la revue des résultats.

La voie à suivre

FeatureBench pointe des domaines spécifiques où les agents doivent progresser :

1. Meilleure exploration du code — les agents doivent systématiquement lire et comprendre les bases de code avant de tenter des modifications
2. Gestion du contexte long — maintenir une compréhension cohérente sur des dizaines de fichiers lors d'une même tâche
3. Développement piloté par les tests — utiliser les tests exécutables comme retour d'information pendant l'implémentation
4. Planification avant codage — créer et suivre des plans d'implémentation pour les fonctionnalités multi-étapes

Ce sont des problèmes résolubles. Le fossé entre 11% et 74% n'est pas permanent — c'est une feuille de route. Mais pour l'instant, le message est clair : les agents de codage IA sont des assistants puissants, pas des ingénieurs autonomes. Les développeurs qui comprennent cette distinction construiront de meilleurs logiciels plus rapidement que ceux qui attendent des agents qu'ils fassent tout.

Le benchmark ne ment pas. Le taux d'acceptation de 83,8% sur les tâches simples non plus. Les deux chiffres sont vrais en même temps — et c'est précisément pourquoi comprendre ce fossé est important.