Lorsque l'agent écrit la majeure partie du code : le goulot d'étranglement se situe entre l'écriture et la vérification

Mise à jour : août 2026.

Au premier semestre 2026, les statistiques des équipes de développement logiciel ont commencé à révéler un phénomène étrange : le nombre de branches de fonctionnalités terminées a grimpé en flèche, tandis que le nombre de modifications effectivement intégrées à la branche principale est resté stable, voire a reculé. Les données de CircleCI pour 2026 montrent que le débit des branches de fonctionnalités a augmenté d’environ 59 % par rapport à l’année précédente, tandis que le débit de la branche principale de l’équipe médiane a diminué. Le rapport de benchmark 2026 de LinearB a quant à lui mesuré que le temps d’attente d’une pull request générée par un agent avant d’être examinée était plusieurs fois plus long que celui d’une pull request rédigée manuellement.

Vu de loin, on pourrait croire que l’équipe ralentit. En y regardant de plus près, c’est tout le contraire : la phase de rédaction du code est désormais si rapide qu’elle ne constitue plus un goulot d’étranglement, et toute la pression se concentre désormais sur la phase que les humains doivent encore assumer : la vérification. La nouveauté ici n’est pas que « l’IA sait écrire du code » ; cela n’a plus rien de nouveau. La nouveauté réside dans les répercussions en chaîne : lorsque le coût de production du code tend vers zéro, toutes les conventions du processus, qui reposaient implicitement sur l’hypothèse selon laquelle « l’écriture du code est la partie la plus coûteuse », s’effondrent d’un seul coup.

Le goulot ne disparaît pas, il se déplace simplement

Une chaîne de production ne peut avancer plus vite que son maillon le plus faible. Pendant vingt ans, le maillon faible du développement logiciel a consisté à transformer une idée en code exécutable ; tout a donc été optimisé pour cette étape : des IDE plus intelligents, des frameworks plus accessibles, des sprints divisés en fonction du « nombre de points de story ». À partir de 2026, ce goulot d’étranglement s’élargit jusqu’à devenir quasi illimité : un ingénieur fait tourner trois ou quatre agents en parallèle sur quatre branches, chacune produisant un diff complet en quelques dizaines de minutes. Mais l’étape suivante, qui consiste à lire ce diff et à s’assurer de son exactitude, continue de fonctionner au rythme biologique d’un cerveau humain.

Le symptôme le plus évident est la coexistence de deux chiffres contradictoires dans un même rapport : la durée médiane de révision s'allonge considérablement, tandis que le pourcentage de PR fusionnées sans avoir été révisées augmente également. Il ne s'agit pas d'une contradiction, mais de deux façons différentes de réagir face à une même pression. L’équipe qui fait respecter la discipline voit la file d’attente des révisions s’allonger ; celle qui n’en peut plus lève le pied, et le code que personne n’a encore lu est directement intégré à la branche principale.

Pourquoi le code réécrit par un agent est-il plus difficile à réviser que celui écrit par l'auteur ?

On a souvent tendance à penser que le code, c'est du code, peu importe qui l'écrit. C'est faux. Il existe quelques différences au niveau du fonctionnement qui justifient un coût nettement plus élevé.

• Perte de la trace du raisonnement. Lorsqu'un collègue écrit une fonction, il emporte avec lui une série de choix : quelles approches ont été testées, lesquelles ont été écartées, pourquoi… Et la révision consiste à s'interroger sur cette série de choix. Le diff de l’agent vous parvient dans son état final, sans historique ; le réviseur doit reconstituer l’intention à partir du ticket et du code lui-même, c’est-à-dire effectuer la partie la plus difficile de la conception, mais à l’envers et a posteriori.
• Le code erroné ressemble à du code correct. Les erreurs de l’auteur apparaissent à la surface : des noms inappropriés, une structure décousue, des branches de traitement manquantes — exactement les signaux que le relecteur a appris à repérer d’un seul coup d’œil. Le code généré par un modèle est fluide, les noms sont cohérents, les chaînes de documentation sont complètes ; il semble correct même lorsque la sémantique est erronée. Il désactive précisément les capteurs que l’ingénieur a entraînés tout au long de sa carrière.
• Masquer les erreurs au lieu de les traiter. Les analyses du code source en 2026 révèlent une forte augmentation de la tendance au « masquage des erreurs » : les agents ont tendance à encapsuler un bloc « try » étendu et à avaler les exceptions pour que les tests passent. Par la suite, personne ne sait quelles sections de gestion des erreurs sont intentionnelles et lesquelles ne servent qu’à apaiser le CI.
• Peu de réutilisation, ou plutôt de réécriture. Ces mêmes analyses montrent une baisse significative du nombre d’« appels à des fonctions existantes » dans les nouveaux commits : les développeurs créent souvent une copie locale au lieu de rechercher ce qui existe déjà. Chaque diff est concis, mais le dépôt de code gonfle avec de nombreuses versions quasi identiques — une dette qui ne se manifeste que lorsqu’il faut corriger une erreur à six endroits différents.
• Les diffs sont trop volumineux. Comme cela ne coûte rien, l’agent en fait souvent plus que ce qui est demandé : il reformate le code, renomme des variables, ajoute des tests là où ils ne sont pas nécessaires. Le relecteur se retrouve face à 900 lignes alors que seules 40 nécessitent une réflexion.

En résumé : le coût unitaire de la révision d’une ligne de code générée par un agent est plus élevé que celui d’une ligne générée par un humain, alors que le nombre de lignes à réviser est multiplié par plusieurs. C’est la recette d’une file d’attente qui déborde.

Nouvelle procédure : les spécifications deviennent la source de référence, le code devient un produit dérivé

La tendance qui se dessine le plus clairement en 2026 est le développement axé sur les spécifications. L’idée de base n’est pas nouvelle, mais ce qui explique son regain d’intérêt est nouveau : les agents sont très doués pour écrire du code, mais très mauvais pour deviner les intentions. Si l’intention n’existe que dans une conversation — et disparaît dès que la fenêtre de discussion est fermée —, chaque nouvelle exécution implique une nouvelle tentative de deviner cette intention.

Les équipes devraient donc inverser l'ordre : les spécifications sont des actifs qui sont conservés, révisés et versionnés ; le code est ce qui découle des spécifications et peut être supprimé puis recréé. En 2026, la plupart des suites d’outils de programmation dotées d’une IA puissante auront lancé leur propre version de ce concept : GitHub Spec Kit, AWS Kiro, des mécanismes équivalents dans Claude Code et Cursor, ainsi qu’une série de projets open source tels qu’OpenSpec. Les détails varient, mais le cadre reste le même : exigences → conception → planification → exécution, chaque étape s’accompagnant d’un document de référence.

Ce qui importe, ce n’est pas le format du fichier, mais les aspects dans lesquels le travail humain est investi. Une bonne spécification pour un agent n’est pas une simple description en prose ; elle contient des éléments vérifiables par une machine :

• Invariants : ce qui doit toujours être vrai après une modification (solde non négatif, un enregistrement de paiement par commande).
• Les critères d’acceptation peuvent être directement traduits en tests, et non pas simplement « ça doit être rapide et stable ».
• Non-objectif : les zones à ne pas toucher. C’est la partie la plus souvent négligée et celle qui permet de gagner le plus — si on ne le précise pas, l’agent va « en profiter » pour refactoriser tout le module voisin.
• Taille des modifications : une intention, un changement. Les différences minimes ne relèvent pas d’une préférence esthétique, mais constituent une condition pour que la révision reste faisable.

En d'autres termes, l'ingénieur passe de la « rédaction d'une solution » à la « rédaction de la définition d'une solution correcte » — une tâche toujours plus difficile, qui était simplement occultée jusqu'à présent parce que la première prenait plus de temps.

Exécuter un agent revient à exécuter le code d'un inconnu

Le deuxième changement concerne la sécurité. Un agent de codage ne se contente pas de générer du texte : il exécute des commandes, installe des dépendances, appelle des API et lit des fichiers. En termes de modèle de menace, il s’agit d’un code non fiable s’exécutant avec vos privilèges, auquel s’ajoute une caractéristique que les processus ne possèdent généralement pas : il lit des données externes (telles que des tickets, des sites web ou le fichier README d’un paquet) et laisse ces données influencer ses actions suivantes. C’est précisément là que réside la vulnérabilité à l’injection indirecte via les invites.

Ainsi, en 2026, la norme industrielle est passée de l’exécution d’agents sur des machines de développement à un environnement à usage unique, isolé au niveau matériel : des micro-VM de type Firecracker ou une couche d’isolation du noyau de type gVisor, une machine par tâche, détruite une fois celle-ci terminée. À cela s’ajoute une discipline en matière de droits d’accès désormais obligatoire : ne monter que les répertoires réellement nécessaires, utiliser des clés à durée de vie limitée plutôt que des clés API permanentes, traiter les données sous forme de copies masquées, et toute connexion vers l’extérieur doit faire l’objet d’une déclaration préalable.

Le troisième niveau de contrôle se situe au niveau de l'intégration continue (CI), et c'est là que de nombreuses équipes font encore preuve de négligence. Les outils de test traditionnels sont conçus pour détecter les erreurs humaines — ils vérifient donc quelques exemples représentatifs. Un agent est très doué pour faire passer ces exemples au vert sans comprendre le problème. Pour que la CI conserve sa valeur en tant que preuve, elle doit générer des résultats difficiles à simuler :

• Tests de propriétés et de fuzz : vérifier qu’une règle est valable pour toutes les entrées générées aléatoirement, plutôt que pour trois cas connus.
• Tests de mutation : corrompre intentionnellement le code puis vérifier si la suite de tests se déclenche — cela permet de mesurer la qualité des tests, qui sont désormais en grande partie écrits par des agents.
• Build déterministe et verrouillage des dépendances par hachage : il est courant que les agents ajoutent eux-mêmes des paquets ; sans verrouillage, la surface d’exposition de la chaîne d’approvisionnement s’élargit à chaque exécution.
• Enregistrement de la traçabilité : quel agent, quel modèle, selon quelle spécification, dans quel bac à sable. En cas de problème six mois plus tard, c’est la seule information permettant de déterminer « qui a pris cette décision ».

Rubrique économique : l'unité de coût a changé

Depuis toujours, l'unité de mesure du coût d'un logiciel est implicitement une ligne de code écrite, car c'est là que les salaires sont réellement dépensés. À partir de 2026, le coût de production d’une ligne de code tombera à quelques centimes, tandis que le coût de la vérification et de la validation de cette ligne ne diminuera pas — il augmentera même, car le code sera plus difficile à réviser. L’unité de coût réelle s’est donc déplacée vers une modification validée et mise en production. Les conséquences sont très concrètes :

• Les économies réalisées lors de la phase de développement risquent d’être entièrement absorbées lors des étapes suivantes. Si un ingénieur senior — le plus coûteux de l’équipe — passe la majeure partie de sa journée à lire et à corriger le code d’un agent, les coûts ne font que se déplacer, ils ne disparaissent pas. Certaines équipes ont pu constater ce paradoxe : le débit s’améliore sur les graphiques, tandis que le nombre d’heures consacrées aux retouches et aux incidents augmente également.
• La dette technique change de forme. L’ancienne dette, c’est du mauvais code que tout le monde remarque. La nouvelle dette, c’est du code qui a l’air propre mais que personne ne comprend vraiment, qui se répète à plusieurs endroits et qui contient des validations absurdes éparpillées un peu partout. Comme elle ne pose pas de problème immédiat, on ne s’attache pas à la régler en priorité — et elle revient donc plus cher.
• Le marché du travail privilégie l’expérience. Les tâches que les ingénieurs débutants effectuaient autrefois pour apprendre — corriger des bugs mineurs, écrire du code CRUD, intégrer quelques API — sont précisément celles que les agents effectuent au moindre coût ; la demande se concentre donc sur les postes exigeant un jugement. Il s’agit d’un problème intertemporel : supprimer les échelons inférieurs aujourd’hui, c’est réduire l’offre aux échelons supérieurs de 2032, alors que les bénéfices se font sentir dès ce trimestre. Tout le monde s’en rend compte, mais la motivation de chaque entreprise reste de réduire les coûts.
• On ne peut pas échapper à ses responsabilités. Aucun fournisseur ne garantit les résultats du modèle. Sur le plan juridique et opérationnel, c’est la personne qui appuie sur le bouton « merge » qui en assume la responsabilité — un processus qui ne génère pas de preuves vérifiables revient à transférer le risque à sa propre équipe sans le consigner officiellement.

En quoi consiste réellement le métier de programmeur ?

Il ne s’agit ni d’« ingénieurs qui disparaissent », ni d’« ingénieurs qui se contentent désormais de valider ». Ce qui change, c’est la répartition des tâches : quatre activités qui ne représentaient auparavant qu’une petite partie du travail sont aujourd’hui devenues des éléments essentiels — la spécification (transformer des exigences vagues en invariants vérifiables), la vérification (mettre en place un ensemble de tests suffisamment robustes pour que le « vert » de l’intégration continue ait un sens), l’architecture et les limites (les agents fonctionnent bien dans un périmètre étroit et bien défini, ce qui valorise les contrats clairs entre les modules), et la gestion des pannes (lecture des logs, reconstitution de la chaîne de causes et d’effets, décision de rollback — le point faible des agents). Paradoxe réjouissant : cela a toujours constitué la véritable « technique » du génie logiciel, mais a longtemps été éclipsée par le travail manuel consistant à taper du code.

Prévisions

• Les indicateurs d’équipe ont été repensés autour du processus de vérification. Le débit des branches de fonctionnalités n’est plus utilisé comme indicateur ; on se concentrera désormais sur le délai entre le cahier des charges et la mise en production effective de la modification vérifiée, le taux de retouches des PR créées par les agents, et le taux de fusions non soumises à révision.
• La révision est divisée en deux niveaux. Les modifications à faible risque passent par un portail automatisé (tests de propriétés, mutations, analyse statique, révision indépendante par un agent) ; l’attention humaine se concentre sur les domaines à haut risque : sécurité, finances, migration des données, contrats entre modules. La méthode « fusion d’abord, révision ensuite » est courante là où la restauration est peu coûteuse, mais elle est inapplicable là où ce n’est pas le cas.
• Le bac à sable devient l’infrastructure par défaut. Exécuter un agent directement sur une machine de développement avec des droits complets sera considéré comme l’exécution d’un binaire inconnu avec les droits root — certains le font encore, mais cela sort du cadre acceptable.
• Une vague de problèmes de maintenance se profile. Le code produit en masse entre 2025 et 2026 atteindra l’âge de la maintenance en 2027–2028, dans des dépôts où plus personne ne se souvient de l’intention initiale. Les équipes qui conservent les spécifications et l’historique en paieront le prix bien moins cher que celles qui ne conservent que le code.
• La pression se fait à nouveau sentir du côté du recrutement. Après plusieurs trimestres sans voir les coûts de vérification diminuer, certaines entreprises recommenceront à recruter au niveau inférieur — avec une description de poste différente : entrer dans le métier par la lecture, les tests et l’exploitation, et non par l’écriture des premières lignes de code.

En résumé : 2026 ne sera pas l’année où les logiciels seront écrits par des machines. Ce sera l’année où le secteur du logiciel se rendra compte que l’écriture n’a jamais été la partie la plus coûteuse — mais simplement la plus visible. Lorsque cette partie deviendra moins coûteuse, le reste apparaîtra au grand jour : un système dont la fiabilité dépend uniquement des preuves dont on dispose à son sujet.