Davantage d'agents IA ne sauveront pas un projet en retard. Ils affineront la mauvaise réponse

Le 27 octobre, le développeur-blogueur j11g a publié une mise à jour en une ligne d'une règle de gestion logicielle vieille de 51 ans. La loi formulée en 1975 par Frederick P. Brooks Jr., tirée de son expérience à la tête du projet OS/360 d'IBM, énonce : « Ajouter de la main-d'œuvre à un projet logiciel en retard le met encore plus en retard. » La révision proposée par le billet pour 2026 : « Ajouter des agents à un projet dont les exigences sont floues vous donne la mauvaise réponse plus vite. »

Il s'agit de l'argument d'un seul blogueur, pas d'une étude, et il ne s'appuie sur aucune mesure. Mais il met le doigt sur un déplacement qui compte pour quiconque budgétise des outils de codage par IA : le goulot d'étranglement se déplace, il ne disparaît pas.

Pourquoi la loi de Brooks existait

Le raisonnement initial de Brooks reposait sur deux coûts. Les nouveaux arrivants mettent du temps à monter en compétence, et chaque personne ajoutée alourdit la communication : réunions quotidiennes, passations, désaccords sur qui est responsable de quoi. Au-delà d'un certain seuil, le coût de coordination d'une équipe plus grande dépasse l'apport de bras supplémentaires.

L'auteur du billet note que les agents IA semblent supprimer ces deux coûts. Un agent est, selon ses mots, opérationnel en quelques millisecondes et n'a pas besoin de pause-café. Si la loi tenait aux frictions humaines, elle devrait s'estomper.

Où la friction est passée

L'auteur soutient qu'elle ne s'est pas estompée, mais qu'elle a muté. Deux éléments de la pensée de Brooks survivent.

Le premier est ce que le billet appelle le « problème du bébé » : neuf agents ne peuvent toujours pas livrer un bébé en un mois. Certaines tâches sont séquentielles. L'étape deux a besoin du résultat de l'étape un, et aucune quantité de travail parallèle n'y change rien.

Le second est que la charge de coordination s'est déplacée au lieu de disparaître. Au lieu de gérer des personnes, vous gérez des agents. Quelqu'un doit définir ce que « terminé » veut dire, relire le code, repérer les hallucinations (des sorties assurées qui sont tout simplement fausses) et assembler les morceaux. Le résumé sans détour du billet : « Ce quelqu'un, c'est vous. »

Le billet décrit aussi un mode de défaillance sans équivalent humain net. Si vous lancez neuf agents autonomes sur une même base de code sans orchestration claire, dit l'auteur, ils réécriront volontiers le travail les uns des autres dans une boucle à grande vitesse. Les équipes humaines se heurtent aussi, mais assez lentement pour que quelqu'un s'en aperçoive. Les agents, eux, peuvent enchaîner les collisions à la vitesse de la machine.

Le signal

Lu comme un indice, le billet suggère que la ressource rare dans le développement assisté par IA passe de la saisie du code à la formulation de l'intention et à la vérification des résultats. Le volume de code généré est bon marché et le devient de plus en plus. Ce qui reste coûteux, c'est un énoncé précis de ce que vous voulez et un contrôle fiable pour savoir si vous l'avez obtenu. C'est le même goulot d'étranglement que Brooks avait identifié, sous un autre costume : la difficulté du logiciel n'a jamais résidé dans les frappes au clavier.

Si cela se confirme, l'histoire de la productivité des agents dépend moins du nombre d'agents que vous pouvez faire tourner que de la qualité des exigences que vous leur confiez. Les exigences floues ne sont pas un problème nouveau. Ce qui change, c'est qu'une spécification vague produit désormais très vite un grand volume de travail plausible mais faux, et que la relecture retombe sur les quelques personnes qui ont rédigé la spécification.

Une mise en garde : le billet est une observation, pas le résultat d'un projet contrôlé. Il ne cite aucune donnée sur des équipes d'agents, et ses affirmations sur les agents qui bouclent relèvent de la description de l'auteur, pas d'un résultat mesuré.

Les questions à vous poser

• Quelqu'un dans l'équipe peut-il énoncer, en un paragraphe, ce que « terminé » signifie pour ce projet, et deux personnes écriraient-elles le même paragraphe ?
• Quelles tâches de notre plan sont réellement séquentielles, et payons-nous des agents en parallèle pour un travail qui ne peut pas être parallélisé ?
• Qui relit la production des agents, combien d'heures cela représente-t-il par semaine, et ce coût est-il pris en compte dans la promesse de productivité qu'on nous vend ?
• Qu'est-ce qui empêche deux agents d'écraser le travail l'un de l'autre, et comment le remarquerions-nous si cela arrivait ?
• Si les exigences sont fausses, combien de temps faudra-t-il pour s'en apercevoir : après l'exécution d'un seul agent, ou après celle de neuf ?

À surveiller ensuite

Surveillez si les éditeurs et les équipes d'ingénierie commencent à rapporter le temps de relecture et les reprises en plus des lignes ou des fonctionnalités générées. Si les outils d'agents mettent en avant l'orchestration, la spécification et la vérification comme arguments de vente principaux, le secteur concède l'argument du billet. Si les promesses restent centrées sur le volume brut produit, attendez-vous à ce que la vieille loi continue de s'imposer dans les projets en retard.