Où va le goulot quand vous adoptez un agent de codage IA

Où va le goulot quand vous adoptez un agent de codage IA

Notre queue de support vidait les tickets en neuf minutes à peine, puis ils attendaient quatre heures avant qu'un agent les traite. La même histoire se joue en ce moment dans les équipes d'ingénierie avec un agent de codage IA : le code est écrit en minutes, puis il file en queue. Si vous venez d'ajouter un agent de codage IA et que le débit de votre équipe a à peine bougé, ce n'est pas un outil cassé que vous avez trouvé. C'est votre vrai goulot d'étranglement qui se révèle, et il n'est pas où vous le cherchiez.

C'est la bonne façon de lire ce qui se passe en ce moment dans les orgas d'ingénierie. Un agent de codage IA : un logiciel qui planifie, écrit et teste souvent les changements de code avec un minimum d'aide humaine (différent d'un assistant autocomplete). L'agent enlève la friction à l'étape d'écriture. Mais l'écriture n'est presque jamais le poste limitant d'un pipeline de développement. C'est presque toujours la review, l'intégration continue, ou le déploiement. Accélérer un poste qui n'est pas limitant ne donne pas plus de travail fini. Ça crée juste une queue plus grosse devant ce qui vient après.

Où s'est déplacé le goulot après avoir ajouté un agent de codage IA ?

Deux sources de données de 2026 pointent dans la même direction. Dans le rapport State of Software Delivery de CircleCI, le débit des branches de feature sur l'équipe médiane a grimpé de 15 % année sur année, mais le débit des branches main : les changements qui atteignent réellement la production : a chuté de 7 % sur la même période (CircleCI, 2026 State of Software Delivery). Plus de travail qui rentre par la porte, moins de travail qui sort par le fond.

De son côté, dans les recherches développeur de GitLab rapportées par InfoQ, 85 % des répondants s'accordent à dire que l'IA a déplacé le goulot de l'écriture du code vers sa review et sa validation, et 79 % disent que le processus de livraison dans son ensemble n'a pas suivi la vitesse du codage (InfoQ, AI coding outpaces governance). Ce n'est pas un problème d'outil. C'est un goulot qui s'est déplacé et personne n'a remessuré la ligne.

Little's Law s'en fout que le code soit écrit plus vite

Little's Law vous explique pourquoi ça arrive, et ce n'est pas spécifique au logiciel. C'est la même équation qui gouverne la queue d'un centre de fulfillment ou le processus de congé d'un hôpital :

WIP = Débit × Cycle Time

WIP c'est le travail en cours : tout ce qui stagne dans votre pipeline en ce moment (PRs ouvertes, tickets en review, commandes prélevées mais pas packagées). Débit (Throughput) c'est les unités finies par unité de temps. Cycle Time c'est combien de temps prend une unité du début à la fin.

Vous accélérez la génération de code sans toucher à la capacité de review, et vous enfilez plus d'unités par heure dans un poste dont le débit n'a pas changé. Le WIP doit bien aller quelque part. Il s'accumule en un backlog de PRs ouvertes, une merge queue qui grandit, ou des reviewers qui lisent les diffs plus vite et qui en ratent plus. Rien de tout ça n'est gratuit. Une pull request qui attend trois jours de plus ne coûte rien : ça coûte du contexte. L'auteur a avancé sur autre chose, le reviewer doit recharger le changement en entier dans sa tête, et le rework devient plus cher plus longtemps il attend.

Le poste de codage n'est pas le seul endroit où « agent IA » apparaît maintenant

Il faut séparer deux choses qui se confondent sous le label « agent de codage IA ». Certains outils sont construits au laser pour écrire et modifier du code source dans un repo. D'autres sont des agents généralistes qui comprennent un mode d'écriture de code parmi d'autres : recherche, navigation web, génération de docs.

Genspark est du second type : un « Super Agent » sans code qui peut naviguer le web, générer des slides ou des docs, et écrire et exécuter du code depuis un seul prompt. Cette largeur est utile pour un généraliste, mais c'est un outil différent pour un job différent qu'un outil pensé pour vivre dans votre pipeline CI et ouvrir des PRs contre votre vrai codebase. Associez la conception de l'outil au poste du pipeline que vous essayez de débloquer, pas l'inverse.

Manus va encore plus loin, en fonctionnant à l'intérieur d'un ordinateur virtuel complet (navigateur, terminal, file system) pour planifier et exécuter des tâches multi-étapes du début à la fin et rendre un livrable fini. Pour une équipe ops, c'est un modèle mental utile même en dehors du code : un agent qui termine une unité entière de travail, pas juste la sous-étape la plus rapide, c'est celui qui bouge vraiment le débit.

PCE : le seul nombre qui te dit si l'agent aide vraiment

Process Cycle Efficiency (PCE) c'est le ratio du temps valeur-ajoutée sur le temps total du cycle, et c'est le moyen le plus honnête de vérifier si un agent de codage IA a amélioré votre pipeline ou s'il a juste déplacé le goulot :

PCE = Temps Valeur-Ajoutée / Cycle Time Total

Avant d'adopter un agent de codage IA, mesure le split actuel : combien de temps dans la vie d'un changement typique, du premier commit au merge en production, est vraiment passé à écrire ou reviewer du code, par rapport au temps d'attente en queue. La plupart des équipes n'ont jamais tiré ce nombre et sont surprises. PCE en dessous de 25 % c'est courant sur les pipelines logiciel : ça veut dire que les trois-quarts de la vie totale d'un changement, c'est de l'attente, pas du travail actif.

Refais la même mesure 30 à 60 jours après le déploiement. Si PCE a augmenté, l'agent a libéré de la vraie capacité et votre équipe l'utilise. Si PCE est resté stable ou a baissé, l'agent a accéléré une étape déjà rapide et le surplus de production s'empile en queue, invisible jusqu'à ce que quelqu'un compte les PRs ouvertes un vendredi. C'est exactement le genre de verdict où une couche d'analyse IA gagne sa place : ce n'est pas assez de savoir que PCE a bougé, tu as besoin du diagnostic de quel poste a absorbé la différence, et ça se lit plus vite d'une automatisation que de quelqu'un qui fixe un tableau Kanban.

Trois signaux qui montrent que c'est la review, pas l'agent, qui plafonne

Quelques patterns ressortent régulièrement une fois que les équipes commencent à mesurer au lieu de supposer :

• Le nombre de PRs ouvertes monte pendant que le nombre de merges stagne. Plus d'unités rentrent par la porte, même nombre qui sort. Accumulation classique de WIP devant une contrainte inchangée.

• La taille moyenne des PRs grandit. Un agent de codage IA qui génère une feature complète en une passe produit des diffs plus gros qu'un humain qui tape par étapes. Les diffs plus gros prennent plus longtemps à reviewer par PR, ce qui réduit le throughput des reviewers même si l'effectif et la vitesse par ligne restent constants.

• Le temps avant la première review grimpe plus vite que le temps du merge après approbation. Si l'attente c'est surtout avant que quelqu'un ne regarde, c'est un problème de queue (pas assez de capacité de review, ou les reviews ne sont pas prioritisées), pas de qualité de review.

Aucun de ces patterns n'a besoin d'outillage exotique pour les tracker. Un pull hebdomadaire de l'API de votre host git, tracé contre la semaine où vous avez lancé l'agent, c'est assez pour voir la forme du déplacement.

Ce que les queues de support font bien et que les pipelines d'engineering oublient

Le support et le fulfillment combattent ce problème exact depuis plus longtemps que les agents de codage IA existent, et la solution généralise bien. Une queue qui répond aux tickets de first-contact en neuf minutes mais qui prend quatre heures avant de les envoyer à un tier spécialisé, ce n'est pas une histoire de ressources sur les spécialistes qui seraient lents. C'est un signal que le tier rapide est sur-resourceé par rapport à ce qui vient après, et que tirer plus de tickets par la porte n'aide pas jusqu'à ce que la capacité du tier arrière change.

Les équipes d'engineering sautent cette étape en permanence parce que la review de code n'a pas l'air d'une queue sur un dashboard comme le ferait un ticket count. C'est des PRs qui dorment tranquilles en état « waiting for review », faciles de ne pas remarquer jusqu'à ce que quelqu'un demande pourquoi une feature de deux semaines n'a pas encore livré. La Theory of Constraints : l'idée que le output total d'un système est limité par son un goulot, pas par la somme de la vitesse de chaque étape : dit que le fix ne sera jamais « rends la partie rapide plus rapide ». C'est trouve le vrai goulot, protège sa capacité, et seulement après décide si la partie rapide a même besoin de plus de vitesse.

Il y a une deuxième contrainte, plus discrète, qui émerge quelques mois après qu'un agent de codage IA livre plus de code, plus vite : la dérive de la doc. Personne ne remarque jusqu'à ce que l'onboarding d'un nouvel ingénieur prenne deux fois plus longtemps parce que les docs décrivent un système qui a changé il y a trois sprints. Une plateforme docs-as-code comme GitBook, qui se sync contre le même repo où l'agent commit, au minimum empêche le trail papier de décrocher plus vite que le code lui-même. Ça ne règle pas le bottleneck de review, mais ça arrête un deuxième de se former dans l'ombre.

Faut-il ralentir exprès votre agent de codage IA ?

Parfois oui, et c'est impopulaire à dire d'un outil dont tout le monde est enthousiasmé. Si votre capacité de review est gelée pour les deux prochains trimestres (effectifs figés, reviewers déjà au max), laisser un agent tripler le taux de PRs entrants ne crée pas plus de features finis et livrés. Ça crée une queue plus longue et, par les données CircleCI ci-dessus, un taux de succès sur la branche main plus bas, parce que les reviewers sous pression de volume en ratent plus.

L'honnête dans cette situation c'est de limiter combien un agent peut générer par cycle, ou de gater son output derrière une passe de pré-review (linting, checks de couverture de tests auto, politique de diffs plus petites) avant que ça n'atteigne jamais un reviewer humain. C'est pas une position anti-IA. C'est la même logique que de ne pas scheduler plus d'unités sur une ligne que votre poste le plus lent ne peut absorber.

Si la vraie contrainte s'avère être l'attention des reviewers plutôt que leur effectif, les agents workflow conçus pour triage et routing, comme Lindy AI gérant l'overhead d'inbox et de notifications autour de la journée d'une équipe, peuvent libérer des vraies heures de review sans toucher à ton codebase directement. Vaut le coup de tester avant d'assumer que le fix doit être « embauche plus de reviewers » ou « achète plus de sièges agent ».

Où investir vraiment ensuite

Fais le calcul de PCE avant d'expandre l'usage d'agent, pas après. Si le temps valeur-ajoutée en proportion du cycle total n'a pas bougé depuis le rollout, n'achète pas plus de sièges agent tout de suite. Mets la prochaine ligne budgétaire dans la capacité de review, le throughput CI, ou l'automation de merge queue : lequel les données pointent : et réexécute le nombre dans 30 jours.

Si PCE s'est amélioré et la review suit, c'est le signal pour expandre la portée de l'agent, pas avant. Mesure d'abord. Les équipes qui tirent des gains réels de débit d'un agent de codage IA ne sont pas celles qui l'ont adopté en premier. C'est celles qui ont trouvé leur vrai poste limitant et ont fixé la capacité là avant de laisser la partie rapide aller plus vite.