Un agent IA est un programme qui fait agir un modèle de langage en boucle. Il lit des fichiers, lance des commandes et écrit des modifications, jusqu'à mener une tâche à bout. Le modèle de langage, c'est le programme qui lit et écrit du texte derrière un assistant IA. Une équipe d'agents en réunit plusieurs, qui se partagent le travail.
Un cours rapporte une expérience : la même tâche, écrire un programme, confiée à quatre équipes d'agents organisées différemment. Toutes avaient le même modèle. L'une d'elles, appelée pipeline, alignait onze agents à la chaîne : chacun reprenait le travail du précédent. Elle disposait de 50 $ pour payer l'usage du modèle.
Le pipeline n'a pas planté. Il a travaillé : plans, découpages, architectures. Il a fait cinq étapes de planification, c'est-à-dire de préparation du travail sans encore l'écrire. Puis il a manqué d'argent avant d'écrire la première fonction. À l'arrivée : zéro ligne de code.
Un agent seul, avec le même modèle, a obtenu la note maximale : 28 sur 28.
L'expérience vient de Beyond Code, un cours vidéo de Jeremy McEntire paru en 2026. Je l'ai lu en transcription pour ma fiche de lecture, mon résumé critique de ce cours.
Elle m'a gêné, parce que j'ai vécu l'inverse au printemps. J'ai fait travailler 26 agents IA ensemble sur mon propre code. Ils ont trouvé une vraie faille de sécurité, un défaut qu'un attaquant peut exploiter.
Alors, agent seul ou multi-agents (en équipe) ? Les deux résultats sont vrais, parce qu'ils ne mesurent pas le même travail.
Quatre organisations d'agents, une tâche, 28 points contre 0
La tâche du cours : écrire la partie serveur (le backend) d'une plateforme de réservation de locations de vacances. Elle est découpée en sept microservices, sept petits programmes indépendants qui se parlent par le réseau. Chaque organisation avait le même modèle de langage et la même tâche. Le pipeline disposait de 50 $. Seule changeait la façon de répartir le travail :
- Agent seul : un agent fait tout, du début à la fin. Score : 28 sur 28.
- Hiérarchie : un coordinateur distribue le travail à des spécialistes. Score : 18. Le coordinateur a fini par tout coder lui-même. Il était freiné par deux limites. D'abord, un nombre limité d'étapes par agent : passé ce nombre, il doit s'arrêter. Ensuite, un contexte réduit : ce que l'agent a sous les yeux en même temps. Une comparaison : une table de travail de taille limitée.
- Essaim : huit agents travaillent en même temps sur des fichiers partagés, sans chef. Ils se répartissent les tâches grâce à un tableau où chacun les note. Score : 9. L'essaim a livré cinq services sur sept, 152 fichiers, et des frontières entre services toutes incompatibles. Une frontière, c'est la manière dont deux services s'échangent des données. Dans l'essai, la moitié des agents nommait les champs en snake_case, comme
nom_client. L'autre moitié écrivait en camelCase, commenomClient. Les services ne se comprenaient plus. - Pipeline : onze agents spécialisés à la chaîne, un par étape. Les étapes : diagnostic, découpage, architecture, exécution, tests, vérification, revue, et ainsi de suite. La revue, c'est un agent qui relit le travail d'un autre et peut le refuser. Score : 0.
Le cours le dit sans détour : « The pipeline spent its entire budget on five planning stages. It produced zero lines of implementation code. » Autrement dit, les 50 $ sont partis en planification, avant la première ligne de code. L'agent seul, lui, a coûté à peu près autant que la seule planification du pipeline, et il a obtenu 28 sur 28.
D'où sortent les 28 points ? D'une grille de sept critères, qui vérifie si le programme respecte un cahier des charges écrit d'avance. Le cours n'en cite que quatre : les routes, les modèles de données, la cohérence des contrats d'API et la gestion des erreurs. Les routes sont les adresses que propose un service. Les modèles de données décrivent la forme des informations, comme un client ou une réservation. Un contrat d'API, c'est la description écrite de ce qu'un service promet aux autres : routes, formats, erreurs. Le cours ne détaille pas comment les 28 points se répartissent entre ces critères.
Cette grille ne mesure pas la qualité. Le cours le reconnaît lui-même : c'est un indicateur. Il ne publie pas son protocole, ne nomme pas le modèle et ne dit pas combien de fois chaque organisation a tourné. Personne n'est nommé derrière « les chercheurs ». L'auteur prévient aussi que ces systèmes ne représentent pas l'état de l'art. Le 28 contre 0 est donc un récit d'expérience, pas une mesure. Je le prends comme l'illustration d'un mécanisme, pas comme une preuve.
Une partie du mécanisme se calcule. Quand chaque agent doit s'entendre avec tous les autres, chaque paire ouvre un canal de discussion. Avec 5 agents, cela fait 10 canaux. Avec les 8 agents de l'essaim, 28. Avec 10 agents, 45. La formule est n(n-1)/2, pour n agents. Le coût de la coordination monte bien plus vite que le nombre d'agents.
Le pipeline, lui, est une chaîne : chaque agent attend le travail du précédent. Le cours explique aussi son échec par un autre mécanisme. À chaque passage de relais, un agent ne transmet qu'un résumé de son travail. Ce qui est perdu ne revient pas. Dans un autre essai, avec une architecture proche sur une version plus complexe de la tâche, l'étape de revue a rejeté sept travaux sur huit. Quatre de ces rejets ne relevaient aucun problème réel, seulement des objections subjectives, de 15 à 23 chacun.
Le cours rapporte aussi une cinquième configuration, qui écrivait les contrats avant le code. Ses contrats étaient typés, c'est-à-dire écrits dans un format strict, et des tests remplaçaient les revues. Elle a évité les rejets subjectifs. En revanche, elle a brûlé son budget en contrats de plus en plus élaborés : 607 lignes de JSON pour un module de quatre fonctions. Un contrat aussi peut devenir une fin en soi.
Mes 26 agents d'audit, eux, ont trouvé une faille
Au printemps, j'ai fait auditer par 26 agents ShareBox, un de mes projets perso : un site en PHP qui diffuse des vidéos. Un audit, c'est une lecture méthodique du code pour y chercher des défauts. Le récit complet est dans mon audit de code par 26 agents IA.
Onze agents lecteurs ont lu chacun une partie du code, en parallèle. Deux agents ont relié leurs comptes rendus. Douze agents ont noté chacun un seul axe : sécurité, performance, architecture, tests. Un dernier agent, le juge, avait pour consigne d'être sévère. Il a relu toutes les notes pour descendre les trop gentilles. Cela fait 11 + 2 + 12 + 1 = 26 agents.
Les agents ont trouvé une injection de code : une valeur qui finit exécutée comme du programme. Elle se cachait dans le script de démarrage de l'application. Cette application tourne dans Docker, un outil qui emballe un programme pour le faire tourner partout. L'injection se trouvait juste sous un commentaire, une note laissée dans le code, qui prétendait l'empêcher. Une vraie faille, que j'ai vérifiée dans le source avant d'y croire.
Mon audit et le pipeline du cours ne se contredisent pas. Mon audit aussi enchaînait des étapes : lire, relier, noter, juger. La différence tient à ce que chaque agent devait produire. Mes agents lecteurs lisaient. Chacun avait sa tranche, et aucun n'attendait le travail d'un autre pour commencer. Leur production, une liste de constats, n'avait pas à s'emboîter avec celle du voisin. Le juge final notait sévèrement, et je vérifiais chaque faille dans le source.
Le pipeline du cours, lui, construisait. Chaque agent attendait la sortie du précédent, et tout devait s'assembler en un seul système qui marche.
J'en tire une règle qui est la mienne : le cours ne la formule pas ainsi. Des agents en parallèle marchent sur des tranches indépendantes à lire, quand chaque constat se vérifie ensuite dans le code. Une chaîne d'agents qui doivent se coordonner pour construire s'épuise à se préparer.
L'essaim du cours confirme la règle par l'autre bout. Ses huit agents travaillaient bien en parallèle, mais pour construire, et sans contrat entre eux. Le cours résume : « Parallel decomposition without contracts produced volume without coherence. » En clair, découper en parallèle sans contrat a produit beaucoup de fichiers, pas un système dont les morceaux s'emboîtent.
Se croire plus rapide avec l'IA : l'étude METR et l'écart de perception
Le cours cite une étude que tu as peut-être croisée. Elle sert mon sujet : avec l'IA, on peut se sentir plus rapide sans l'être. METR est un organisme de recherche à but non lucratif qui évalue les modèles d'IA. De février à juin 2025, il a mené un essai contrôlé randomisé : le hasard décide, tâche par tâche, si l'IA est permise.
Seize développeurs expérimentés de projets open source, dont le code est public, ont traité 246 tâches réelles. Chaque tâche était tirée au sort : IA autorisée ou interdite. L'outil principal était Cursor Pro (un éditeur de code avec IA intégrée), avec Claude 3.5 et 3.7 Sonnet.
Avant l'étude, ces développeurs prévoyaient d'aller 24 % plus vite avec l'IA. Après coup, ils estimaient avoir gagné 20 %.
Mesurés au chronomètre, ils ont mis 19 % de temps en plus. Ils étaient donc plus lents, alors qu'ils se sentaient plus rapides. Entre le ressenti et la mesure, il y a 39 points d'écart (20 + 19). Sources : l'article de METR et l'article de Becker, Rush, Barnes et Rein sur arXiv.
Les limites sont réelles. Seize personnes, c'est peu. Les tâches portaient sur des projets mûrs que ces développeurs connaissaient par cœur, avec cinq ans d'expérience en moyenne. METR présentait d'ailleurs le résultat comme un instantané du début 2025.
En février 2026, METR a publié une suite et marque désormais l'étude de 2025 comme dépassée. Elle porte sur 57 développeurs. Les nouvelles marges d'incertitude (les intervalles de confiance) incluent zéro : elles couvrent à la fois un gain et une perte. Aucun effet n'est donc démontré, dans un sens ou dans l'autre.
METR juge lui-même ces chiffres peu fiables : des développeurs refusaient désormais de travailler sans IA. Son avis, sans le chiffrer, est que les outils de début 2026 font gagner davantage que ceux de 2025.
Le chiffre de 2025 ne tient donc plus, sans qu'un nouveau le remplace. Rien ne dit pourtant que l'écart entre ressenti et mesure ait disparu. Le pipeline de onze agents en est la version extrême : beaucoup d'activité visible, des plans, des documents, et rien qui tourne.
Une vérification mécanique plutôt qu'un avis
La leçon pratique du cours tient en deux phrases : « Advisory review asks whether someone did the work. Mechanical verification asks whether the work succeeded. » Un avis demande si quelqu'un a fait le travail. Une vérification mécanique demande si le travail marche.
Un avis, même celui d'un agent, dit que le travail a l'air fait. Un test, un compilateur ou un script répond par oui ou par non, et répond pareil à chaque fois. Le cours appelle cela une porte mécanique : un contrôle automatique qui bloque la suite tant qu'il échoue.
Chez moi, avec Claude Code (l'agent de code d'Anthropic, qu'on pilote depuis un terminal), l'idée a pris quatre formes. Chacune répond à un problème réel.
- Un hook qui relit la prose. Un hook est un script que Claude Code lance tout seul avant ou après une action. Après chaque modification d'une fiche de lecture, le mien lance un contrôle de prose. Il compte les phrases de plus de 25 mots et repère les points-virgules et une liste de mots interdits. Il ne donne pas d'avis : il répond oui ou non. L'agent reçoit les remarques et corrige avant de continuer, sans que j'aie à lui rappeler la règle. Plus d'exemples dans mon article sur les hooks Claude Code.
- Une consigne écrite qui perd contre un réglage par défaut. Mon fichier de consignes disait : jamais de signature d'IA dans un commit (un enregistrement de modifications dans Git, l'outil qui garde l'historique d'un projet). L'outil, par défaut, ajoute une ligne
Co-Authored-Byqui nomme Claude. Le réglage par défaut a gagné. La ligne est arrivée dans l'historique partagé, la liste des modifications enregistrées par tous, et j'ai dû réécrire cet historique. Depuis, un hook refuse toute commande de commit ou de pull request dont le message porte cette signature. Une pull request est une demande pour fusionner son travail dans le projet principal. Une consigne espère être lue, un hook s'exécute à chaque fois. - Un deux-points qui éteint un skill. Un skill est un fichier d'instructions que Claude Code charge quand sa description correspond à la demande. Cette description s'écrit en tête du fichier (l'en-tête), en YAML : un format de configuration où le deux-points sépare un nom de sa valeur. Un deux-points suivi d'un espace, dans un texte sans guillemets, rend cet en-tête invalide. Claude Code charge alors un en-tête vide sans aucun message, et le skill ne se déclenche plus. J'ai vu le cas sur trois skills le même jour. Seul un script qui lit tous les en-têtes un par un l'attrape.
- Un juge IA qui recopie la note qu'on lui montre. Mes fiches de lecture portent chacune une note sur 10. J'en ai fait renoter quatre par des agents juges, avec la note publiée pour référence. Premier test : le juge voyait d'abord une note proposée, volontairement fausse de 1,5 point. Sa note s'écartait en moyenne de 0,95 point de la note publiée. Second test : le juge ne voyait aucune note, mais recevait un barème et des comparaisons entre livres. Il s'écartait alors de 0,4 point. Quatre livres, c'est peu. Les notes publiées qui servent de référence ont elles-mêmes été posées par une IA, et je n'en ai corrigé que quelques-unes. Le test mesure surtout la résistance à l'ancrage : le premier chiffre vu attire les suivants. Quand un avis reste nécessaire, on lui retire ce qui l'influence (j'en parle dans l'article sur le relecteur qui n'est jamais l'auteur).
Agent seul ou équipe d'agents : la règle que j'applique
Le cours propose un partage que je trouve juste :
- Un agent seul tant que la tâche tient dans son contexte (ce qu'il peut avoir sous les yeux en même temps).
- Une coordination par traces partagées pour un travail peu couplé, c'est-à-dire dont les morceaux dépendent peu les uns des autres. Cela suppose des contrôles mécaniques qui refusent ce qui ne s'emboîte pas. Les agents lisent ces traces et les complètent. Les traces, ce sont les fichiers, les tests et l'intégration continue, un outil qui relance les tests à chaque envoi de code.
- Une hiérarchie seulement pour les arbitrages ambigus, quand plusieurs choix se défendent.
Mes réglages actuels vont dans le même sens. Aujourd'hui, jamais plus de deux ou trois agents en parallèle. Un seul agent pour un lot de petites tâches semblables, plutôt qu'un agent par tâche. Ces règles sont nées d'un abonnement qui limite l'usage (un quota) et que je ne voulais pas épuiser. Elles servent aussi la qualité : chaque agent reçoit sa tranche, et rien d'autre.
Ce dernier point rejoint une autre idée du cours : « The well-written tutorial is a trap ». En français : « le tutoriel bien écrit est un piège ». Un texte bien écrit mais hors sujet, placé dans le contexte de l'agent, dégrade le modèle plus que du bruit aléatoire. Le bruit se repère et s'ignore. Un tutoriel propre sur le mauvais sujet, le modèle le suit.
L'exemple du cours vient d'AWS, l'hébergeur d'Amazon. Un tutoriel sur les prix d'un de ses services (EC2) est collé pour une question sur les prix d'un autre (Lambda). Les deux sujets se ressemblent, donc le modèle croit tenir la bonne page. Donner tout le code du projet à chaque agent « au cas où » revient à lui tendre ce piège.
Pour prolonger, deux autres articles du blog résument des livres sur le sujet. Le premier : ce que deux livres disent des agents en parallèle. Le second : quatre livres sur Claude Code.
Conclusion
Le pipeline de onze agents n'a pas manqué d'intelligence. Chaque agent produisait un document pour l'agent suivant, et aucun ne pouvait échouer à un test, puisqu'il n'y avait rien à exécuter. Mon audit a marché pour la raison inverse : chaque constat se vérifiait dans le code, et je l'ai vérifié avant d'y croire.
Ajouter un agent ajoute surtout de la coordination. Quand une équipe d'agents patine, il lui manque rarement un agent de plus. Il lui manque presque toujours quelque chose qui sait dire non sans discuter : un test, un hook, un script.