Un flow agentique fait livrer beaucoup plus vite. Il a aussi un effet secondaire dont on parle peu. On échange moins, on se pose moins de questions, on mène plus de sujets à la fois, et l’on finit par moins bien connaître ce qu’on livre. Petit à petit, on perd la main sur son produit.
Je développe chaque jour avec Claude Code, et l’équipe avec laquelle je travaille utilise le flow commun que j’ai conçu et décrit dans Un flow agentique pour toute une équipe de développement. J’ai vécu cet effet et je l’ai vu autour de moi. Il ne me semble pas inévitable. Il se corrige en restant acteur à quelques moments précis du flow, et en acceptant de paralléliser moins que ce que l’outil permet.
Ce qui disparaît quand tout va plus vite
Quand une feature se livre en quelques jours, on prend de moins en moins le temps d’en parler. Les échanges qui passaient par les rituels agiles liés au produit, le refinement en tête, perdent leur substance.
Pendant le développement, on se pose aussi beaucoup moins de questions. L’agent assiste déjà la réflexion en amont, puis il planifie, implémente et teste. On s’habitue à un travail prémâché, et on se met à lire vite ce qu’il produit pour gagner du temps.
C’est là que la compréhension s’érode. Une étude publiée par Anthropic en janvier 2026 l’illustre bien (How AI assistance impacts the formation of coding skills). Cinquante-deux développeurs, surtout juniors, découvraient une bibliothèque Python. Ceux qui étaient aidés par une IA ont obtenu en moyenne 50 % au quiz final, contre 67 % pour ceux qui codaient seuls. Mais les participants qui demandaient des explications ou posaient des questions de fond, plutôt que de déléguer tout le code, ont gardé des scores d’au moins 65 %. L’étude porte sur l’apprentissage d’une bibliothèque, pas sur un flow d’équipe. Elle montre quand même que la façon de se servir de l’IA compte autant que le fait de s’en servir.
Une fatigue qui s’installe sur la durée
L’autre effet est plus lent. Enchaîner énormément de tickets, passer d’un sujet à l’autre, écrire et parfois répéter les mêmes choses à l’agent : à la longue, cela fatigue beaucoup. C’est une fatigue cognitive qui ne se voit pas sur une journée et s’installe sur la durée. Je l’ai éprouvée, j’en ai entendu parler autour de moi, et le sujet revient souvent dans ce qu’on lit.
Un flow de développement commun, comme celui que j’ai mis en place, réduit déjà une partie de cette charge. On se répète moins, tout est plus cadré, il y a moins de surprises et moins d’échanges inutiles. Les rules s’ajustent aussi au fil des développements de chacun, si bien que le flow s’améliore en continu.
Une autre partie de la fatigue vient d’un réflexe. Quand on découvre la puissance d’un harnais de développement plus ou moins automatisé, on veut combler chaque creux. Mes trois agents sont occupés, alors je prends un quatrième sujet et j’ouvre une quatrième session. Le creux disparaît, mais il n’était que temporaire. Les agents finissent par revenir vers nous, et si l’on a pris trop de sujets, ils reviennent tous en même temps. La charge mentale augmente d’autant.
Moins de sujets en parallèle, mais menés au bout
Au début, je menais trois ou quatre tâches en parallèle, parfois cinq. Aujourd’hui, j’en mène le plus souvent deux ou trois, dont souvent un sujet de fond qui n’a rien d’urgent : de la R&D, ou une réflexion pour introduire un gros sujet technique. Je préfère mener deux sujets au bout plutôt que quatre que je ne suis pas vraiment, et dont je ne peux pas garantir moi-même la qualité du développement et du rendu. J’ouvre parfois une session de plus pour un besoin rapide, sans en faire un sujet à part entière.
Ce chiffre n’a rien d’une règle. Plus les sujets sont petits, plus on peut paralléliser. Tout dépend aussi du produit, de la complexité du travail et de la charge du moment. Je n’ai d’ailleurs trouvé aucune étude qui mesure combien de sessions d’agent un développeur peut suivre en parallèle. Ce qui compte, c’est de ne pas ajouter du travail simplement parce qu’un creux apparaît.
Les creux sont inévitables. Je les remplis autrement : réfléchir au sujet en cours, aller chercher une information auprès d’une autre équipe, aider un collègue ou répondre à ses questions. Il y a toujours de quoi faire ailleurs que dans une nouvelle session.
La même logique vaut pour les scopes. Un développeur reste sur un même scope jusqu’à ce qu’il soit terminé. L’agent permettrait de passer d’un sujet à l’autre en permanence, mais il faudrait alors rattraper sans cesse des développements qu’on n’a pas vus passer, avec plus de charge cognitive, plus de lenteur et une qualité moins bien garantie.
S’approprier la feature avant que l’agent code
Garder la main commence avant la première ligne de code. Le flow que j’ai conçu prévoit une phase de réflexion sur le PRD, le document qui décrit le besoin produit, sous forme de séries de questions et de réponses. Elles font apparaître vite les cas limites, les inconnues, les zones floues et les incompréhensions, et elles obligent à s’approprier le sujet.
J’interroge ensuite l’agent sur les zones d’ombre qui restent. On sort de cette phase en connaissant bien mieux la feature qu’au départ.
Une revue commune au moment du plan, avec les personnes concernées (produit, QA, design), prolonge ce travail. Chacun voit ce qui va être fait et vérifie que tout colle.
Tester à la toute fin, quand l’agent a fini
Une fois le plan validé, l’agent implémente et vérifie lui-même son travail. Il lance ses tests de bout en bout plusieurs fois, parce qu’il trouve des défauts au début et les corrige. Je teste à mon tour, mais à la toute fin, quand l’agent est enfin satisfait.
Ce test ne fait pas doublon avec les siens. L’agent vérifie en cours de route, je fais la vérification finale. Je lui demande souvent de préparer un parcours de test type, que je déroule moi-même. Cela limite les surprises et, surtout, je comprends ce qui a été fait et je l’assimile. Si quelque chose m’échappe, j’en discute avec l’agent, quitte à reprendre le plan ou le PRD.
Une revue commune après le développement, avec le produit, la QA ou le design, joue le même rôle pour toute l’équipe. On montre ce qui a été fait, on vérifie que cela correspond à l’attendu, et chacun continue de s’approprier la feature.
Le but est de rester maître de ce qu’on livre et conscient de ce qui a été produit.
Confier la première revue à un outil
Dans mon précédent article, la revue était le goulot : l’agent produit plus vite qu’une équipe ne relit. Les assistants de revue comme CodeRabbit, que j’utilise aussi sur mes projets personnels, sont pour moi la meilleure réponse à ce goulot.
Un assistant de revue relève ce qui a échappé pendant le développement, bugs compris. Son regard est plus neutre que celui de la personne qui a suivi l’agent, et que celui de l’agent lui-même. Ce dernier a pu être induit en erreur par une incompréhension dans un échange, ou par une mémoire qui lui a fait mal interpréter quelque chose. Une revue prend une vingtaine de minutes. Bien intégré au flow, l’assistant dialogue avec l’agent sans qu’il faille relancer l’un ou l’autre à la main. CodeRabbit apprend aussi des retours qu’on lui fait en commentaire et s’adapte aux habitudes d’une équipe (documentation des learnings).
C’est un vrai gain de temps et un dernier filet avant le merge, qui libère du temps précieux pour les développeurs. Une revue humaine reste de mise pour les développements critiques. Sans assistant de revue, je pense qu’il vaut mieux relire chaque PR humainement, ne serait-ce qu’en diagonale. Ma préférence va quand même nettement à un assistant de revue.
Remplacer les rituels plutôt que les garder par principe
À ce rythme, plusieurs rituels agiles perdent leur intérêt. Le refinement n’en a plus aucun. Les daily et les rétros me semblent beaucoup moins utiles, et je vois beaucoup moins l’intérêt de fonctionner en sprints. Cela dépend vraiment de l’organisation de chacun.
Il faut en revanche garder des moments d’échange. Sans eux, l’information ne circule plus et le lien entre les équipes se distend. Il n’y a pas de recette miracle. La forme s’adapte selon les équipes, leurs besoins et leurs envies : une démo de ce qui a été livré, une présentation technique ou celle d’un POC, par exemple.
Choisir où placer l’agent, et où se placer soi-même
Un développeur a une expertise à apporter. Prendre un maximum de sujets et tout automatiser revient à la mettre de côté. Et à ce moment-là, à quoi sert-on ? Quelle est notre valeur ajoutée ?
Pour moi, tout est une question de placement. Il faut décider où l’on place le modèle, le harnais et le flow agentique, et où l’on se place soi-même dans tout cela. L’expertise doit rester présente et servir : pour trouver les zones d’ombre d’un PRD, pour juger un plan, pour faire la vérification finale.
Le coût différé d’un produit qu’on ne connaît plus
Avec la puissance actuelle de l’IA, on a vite fait de faire tout et n’importe quoi. La vitesse ressentie sur le moment ne dit pas grand-chose de ce qui arrive ensuite. Perdre la main sur son produit finit par coûter du temps : reprendre ce qui a été livré, absorber un changement de direction, découvrir des surprises.
C’est aussi une question de politique d’entreprise. Je suis persuadé qu’une entreprise gagne bien plus à toujours tirer parti de l’expertise de son équipe, en veillant à ne pas livrer n’importe quoi n’importe comment, qu’à livrer vite et à tout va parce que l’outil le permet. Sur le long terme, ce second choix me paraît désastreux. Ses pertes ne se voient pas le jour de la livraison. Elles arrivent plus tard, quand plus personne ne sait vraiment ce qui a été construit.