Quand l’IA code à votre place, vous travaillez 19% plus lentement

Des agents logiciels comme Devin, Claude Code et GitHub Copilot Workspace prennent désormais une description de tâche, lisent une base de code, écrivent le code qui y répond, exécutent des tests jusqu’à ce qu’ils réussissent, et ouvrent une pull request — sans qu’un développeur ne tape une seule ligne. Devin, conçu par Cognition AI, opère dans des environnements cloud isolés. Sur sa base d’utilisateurs en production, 67% des pull requests qu’il ouvre de manière autonome sont fusionnées. Claude Code lit un dépôt entier, planifie des modifications sur plusieurs fichiers, exécute la suite de tests et itère sans instruction entre chaque étape. Ces outils sont en usage en production, pas en aperçu de recherche.

Ce qui les distingue des outils de génération de code antérieurs, c’est la boucle de rétroaction. Un moteur de suggestion génère du texte et s’arrête ; un agent autonome génère du code, l’exécute, lit ce qui revient, et réessaie. L’échafaudage sous-jacent est le même pour tous les outils : un grand modèle de langage lit le contexte — base de code, description de problème, journal d’erreurs — génère un plan, l’exécute via des outils comme des commandes shell, des modifications de fichiers et des opérations git, lit le résultat, et révise. La boucle continue jusqu’à ce que l’agent réussisse ou épuise son budget de ressources.

La boucle qui a remplacé l’éditeur

Le niveau d’autonomie des outils disponibles s’étend sur trois niveaux. À l’extrémité assistée, GitHub Copilot suggère les prochaines lignes pendant qu’un développeur tape. Un niveau au-dessus, les éditeurs multi-fichiers comme Cursor réécrivent sur une base de code sous la direction d’un développeur, effectuant les modifications que le développeur spécifie. À l’extrémité autonome, Devin et des systèmes comparables opèrent indépendamment pendant de longues périodes, prenant des décisions séquentielles sur quoi lire, quoi modifier et quoi tester, ne se manifestant que pour les approbations que le système ne peut pas gérer seul.

Le cadre d’évaluation qui mesure les progrès de ces outils est SWE-bench, créé par des chercheurs de Princeton et Stanford. Il teste les agents sur de vrais rapports de bogues provenant de dépôts Python open source — Django, Flask, scikit-learn — et mesure le pourcentage qu’un agent peut résoudre correctement. Le score publié le plus élevé actuel sur le sous-ensemble vérifié, 96%, appartient à Claude Opus 5. Ce chiffre représente une capacité réelle : la capacité de diagnostiquer un vrai bug logiciel, d’écrire un correctif et de vérifier qu’il passe les propres tests du projet.

Ce que le benchmark cache

Le score de 96% comporte un astérisque important. SWE-bench Verified s’appuie sur 500 tâches soigneusement sélectionnées. Lorsque des chercheurs ont appliqué une variante résistante à la contamination — SWE-bench Pro, conçue avec des problèmes qui ne pouvaient pas apparaître dans les données d’entraînement d’un modèle — un modèle antérieur qui avait obtenu plus de 80% sur Verified est tombé sous 50% sur Pro. Une partie de la performance des benchmarks reflète la familiarité avec l’ensemble d’évaluation, pas une capacité généralisée de résolution de problèmes. L’écart est un défi de recherche connu, pas une critique d’un outil spécifique.

Une étude distincte a trouvé quelque chose de plus difficile à expliquer. METR, une organisation de recherche en sécurité de l’IA, a mené un essai contrôlé randomisé avec des développeurs open source expérimentés travaillant sur leurs propres dépôts. Les développeurs utilisant les outils d’IA de codage actuels étaient 19% plus lents que ceux qui travaillaient sans eux — malgré une estimation indépendante qu’ils étaient 20% plus rapides. Les causes étaient spécifiques : le temps passé à re-prompter lorsque l’agent produisait des résultats incorrects, le temps passé à vérifier les sorties avant de fusionner, et la charge cognitive de passer de la direction d’un agent au suivi de ce que l’agent avait fait. Un benchmark teste si un agent peut résoudre un bug bien spécifié en isolation. Un essai randomisé teste si un développeur travaille plus vite sur une journée réelle. Ils mesurent des choses différentes.

Pourquoi 93% d’adoption n’a produit qu’un gain de débit de 10%

L’autonomie du code fonctionne mieux sur des tâches bornées et bien spécifiées : un bug reproductible avec des entrées et sorties claires, une fonction avec une spécification précise, une suite de tests pour un module avec un comportement défini. À mesure que la portée s’étend à des tâches qui nécessitent des connaissances architecturales implicites, des conventions d’équipe non documentées ou des décisions sur l’orientation du produit, la fiabilité chute — non pas parce que les modèles manquent de capacité, mais parce que le contexte que ces décisions exigent ne tient pas dans le système et ne peut pas être dérivé des seuls fichiers de la base de code.

Le changement pratique réside dans ce que le travail exige. Les développeurs travaillant avec des agents autonomes passent plus de temps à écrire des spécifications suffisamment précises pour qu’un agent les exécute : descriptions de problèmes détaillées, contrats de test clairs, critères d’acceptation explicites. Ils passent plus de temps à revoir du code qu’ils n’ont pas écrit, ce qui demande un type d’attention différent de l’écriture de code — chercher des erreurs logiques, des failles de sécurité et des dérives architecturales que l’agent ne signalera pas lui-même. Une enquête de 2026 auprès de 121 000 développeurs a révélé que 93% utilisent régulièrement des outils de codage IA ; le débit des pull requests a augmenté d’environ 10% dans le même groupe. Le goulot d’étranglement est passé de l’écriture du code à sa revue.

La prochaine étape en développement actif est celle d’agents qui gèrent leurs propres files de tâches : recevoir une spécification de projet, la décomposer en sous-tâches, déléguer entre des modèles spécialisés, et ne remonter que les décisions qui exigent un jugement humain. Plusieurs frameworks open source pour l’orchestration de codage multi-agents ont été livrés en 2026. L’adoption en entreprise dans les environnements de production reste limitée. Gartner prévoit qu’une part significative des projets logiciels agentiques commencés cette année seront abandonnés avant 2028, une fois que les équipes découvriront l’écart entre ce qu’une démo contrôlée montre et ce qu’un déploiement fiable à grande échelle exige.

Étiquettes: intelligence artificielle, Programmation, AI coding agents, autonomie du code, développement logiciel