Le développeur-orchestrateur #2 — Pourquoi un agent seul ne suffit pas

Dans le premier article de cette série, j’expliquais pourquoi l’agentique change vraiment le développement web. Pas seulement parce qu’elle accélère certaines tâches, mais parce qu’elle transforme l’organisation même du travail. À partir du moment où l’IA entre dans le workflow, lit des fichiers, modifie du code, lance des commandes, prépare des livrables et participe à des chaînes d’exécution, on ne parle plus simplement d’assistance. On parle d’un système de production à piloter.

À partir de là, une idée revient très souvent. Elle est séduisante, intuitive, presque inévitable : pourquoi ne pas avoir un seul agent très puissant qui ferait tout ?

Un agent pour comprendre la demande.
Un agent pour produire l’architecture.
Un agent pour coder.
Un agent pour sécuriser.
Un agent pour tester.
Un agent pour packager.
Un agent pour documenter.
Un agent pour relire.
Un agent pour livrer.

Ou plutôt, pour le dire autrement : pourquoi ne pas demander à un seul agent de jouer tous ces rôles à la fois ?

Sur le papier, l’idée paraît parfaite. Une seule interface. Une seule boucle. Une seule logique. Un seul interlocuteur. C’est simple, confortable, séduisant. Cela donne l’impression d’un système fluide, presque magique. On lui parle, il comprend, il enchaîne, il restitue.

Le problème, c’est que cette vision tient surtout tant qu’on reste sur des tâches courtes, bien circonscrites, ou sur des démonstrations.

Dès qu’on entre dans le développement web réel, les choses se compliquent très vite.

Et c’est précisément là qu’il faut accepter une réalité moins spectaculaire, mais beaucoup plus solide : un agent seul ne suffit pas.

Le fantasme du super-agent est compréhensible

Il faut commencer par reconnaître une chose : cette idée n’est pas absurde. Elle attire parce qu’elle répond à un vieux rêve de simplification.

Depuis des années, le développement logiciel empile des couches de complexité. Plus d’outils. Plus de frameworks. Plus de pipelines. Plus de standards. Plus de validations. Plus de dépendances. Plus de contexte. Alors forcément, l’idée d’un agent unique capable d’absorber toute cette complexité et de la transformer en livrable propre a quelque chose de très séduisant.

Elle rassure aussi parce qu’elle reprend une logique familière : celle du développeur polyvalent qui sait tout faire ou presque. Comprendre le besoin, concevoir, implémenter, corriger, documenter, sécuriser, livrer. L’agent unique devient alors une sorte de projection augmentée de cette figure.

Et c’est vrai qu’au début, cela peut fonctionner.

Sur une tâche limitée, un agent bien guidé peut proposer un plan cohérent, générer une implémentation acceptable, corriger quelques erreurs, améliorer la forme, rédiger une base de documentation, et donner l’impression d’une étonnante continuité.

C’est même souvent ce qui crée la première vague d’enthousiasme.

On se dit : “Très bien, nous y sommes. Il suffit de lui donner assez de contexte et assez d’instructions.”

Mais cette impression de fluidité masque une fragilité structurelle.

Un agent unique finit vite par tout porter… donc par tout mélanger

Le vrai problème n’est pas qu’un agent unique soit incapable de produire quelque chose. Le vrai problème, c’est qu’il doit porter trop de couches de travail en même temps.

Comprendre la demande n’est déjà pas la même chose que concevoir une architecture. Concevoir une architecture n’est pas la même chose que produire une implémentation propre. Produire une implémentation n’est pas la même chose que raisonner sécurité. Raisonner sécurité n’est pas la même chose que penser packaging, review, compatibilité ou maintenance.

Dans un système humain, nous avons déjà appris cela depuis longtemps. Nous savons qu’un bon développeur n’est pas automatiquement un bon reviewer. Qu’un excellent architecte n’est pas forcément la meilleure personne pour valider une ergonomie de back-office. Qu’un spécialiste sécurité ne regarde pas le même objet mental qu’un spécialiste performance. Qu’un packager, un QA ou un responsable release ne portent pas la même attention aux mêmes détails.

Pourtant, quand il s’agit d’IA, beaucoup retombent dans l’idée qu’une seule boucle pourrait tout absorber.

Le problème, c’est que cette boucle unique devient vite un lieu de confusion. Elle doit conserver le fil du besoin, de l’existant, des contraintes métier, de l’architecture, des arbitrages, de la qualité de code, des validations techniques, des tests, de la sécurité, de la documentation et du rendu final. Elle doit aussi décider à quel moment explorer, à quel moment produire, à quel moment vérifier, à quel moment corriger.

Autrement dit, elle doit penser plusieurs métiers à la fois.

Et plus elle essaie de tout faire en une seule trajectoire, plus elle risque de lisser les différences entre ces rôles. Elle donne alors l’illusion d’une cohérence globale, alors qu’en réalité elle mélange des niveaux de responsabilité qui gagneraient à être séparés.

Le développement réel n’est pas une démonstration continue

C’est souvent là que la différence entre une démo impressionnante et un usage fiable apparaît.

Dans une démonstration, on peut très bien demander à un agent de produire une fonctionnalité de bout en bout. Il comprend la demande, il propose quelque chose, il modifie du code, il corrige quelques erreurs, il annonce que c’est terminé. La boucle semble élégante. Elle fonctionne bien parce qu’elle reste courte, cadrée et observée.

Mais un vrai projet n’est pas une démo prolongée.

Un vrai projet contient des zones grises, des contradictions, des dépendances mal documentées, des conventions historiques, des compromis anciens, des éléments qu’il ne faut surtout pas casser, des décisions qui n’ont de sens qu’en contexte, des règles qui ne sont écrites nulle part mais qui structurent quand même la qualité attendue.

Dans ce type d’environnement, l’agent unique commence à montrer ses limites. Pas nécessairement en échouant de manière visible. Souvent, le problème est plus subtil. Il avance, il produit, il semble cohérent, mais il dérive peu à peu. Il comble les trous avec des hypothèses. Il rationalise trop vite. Il transforme des flous en certitudes. Il confond ce qui est pratique avec ce qui est juste. Il réduit des tensions réelles à une solution moyenne.

Le danger n’est donc pas toujours le bug flagrant. Le danger est parfois la solution apparemment propre, mais mal alignée.

Et c’est précisément pour cela que l’agent unique devient fragile dès que le projet gagne en réalité.

La spécialisation n’est pas un luxe, c’est un mécanisme de fiabilité

À ce stade, il faut renverser la perspective. Beaucoup voient la spécialisation comme une complication. En réalité, c’est souvent une simplification bien pensée.

Spécialiser, ce n’est pas multiplier les agents pour le plaisir. Ce n’est pas construire une usine à gaz où chaque micro-tâche serait artificiellement séparée. Ce n’est pas remplacer une confusion par une bureaucratie.

Spécialiser, c’est reconnaître qu’il existe des différences de nature entre les types de travail.

Un agent qui raisonne architecture n’a pas besoin d’aborder le problème comme un agent qui raisonne sécurité. Un agent qui prépare un packaging n’a pas besoin de se comporter comme un agent qui inspecte la cohérence fonctionnelle. Un agent qui relit pour identifier des risques ne doit pas être exactement dans la même posture que celui qui a produit le code.

Cette séparation apporte quelque chose de fondamental : elle rend les responsabilités plus nettes.

Et quand les responsabilités sont plus nettes, plusieurs bénéfices apparaissent immédiatement. Le contexte devient plus ciblé. Les attentes deviennent plus explicites. Les sorties deviennent plus comparables. Les écarts deviennent plus visibles. Les erreurs de raisonnement deviennent plus faciles à identifier. La revue humaine redevient plus efficace, parce qu’elle ne s’applique pas à une masse floue, mais à des productions situées.

En clair, la spécialisation ne sert pas d’abord à produire plus. Elle sert à produire de manière plus fiable.

Un bon système agentique ressemble plus à une équipe qu’à une baguette magique

Je crois que c’est l’image la plus utile pour penser le sujet.

Un bon système agentique ne ressemble pas à un oracle unique qui répondrait à tout. Il ressemble davantage à une organisation du travail.

Avec des rôles.
Avec des séquences.
Avec des points de passage.
Avec des vérifications.
Avec des décisions de relais.
Avec des zones où l’on peut paralléliser.
Avec des moments où l’on doit, au contraire, ralentir et arbitrer.

C’est d’ailleurs assez logique. Le développement web n’a jamais été simplement une activité d’écriture. C’est une activité de coordination entre exigences parfois contradictoires : vitesse, maintenabilité, sécurité, lisibilité, compatibilité, coût, dette, robustesse, pression de livraison. Il serait étrange qu’un système d’IA mature ignore cette réalité et prétende la résoudre dans une seule boucle monolithique.

Penser en rôles spécialisés permet au contraire d’épouser la complexité réelle du métier.

Un agent peut explorer.
Un autre peut structurer.
Un autre peut produire.
Un autre peut vérifier.
Un autre peut relire sous un angle précis.
Un autre peut transformer une décision validée en livrable propre.

Le point important, ici, n’est pas de faire beaucoup d’agents. Le point important est de faire apparaître une architecture de travail compréhensible.

Ce n’est pas le nombre d’agents qui compte. C’est la qualité des responsabilités et des passages entre elles.

Les handoffs deviennent un vrai sujet d’ingénierie

Dès qu’on accepte qu’un agent seul ne suffit pas, une autre question apparaît immédiatement : comment passe-t-on correctement d’un rôle à un autre ?

C’est là qu’entre en scène un sujet souvent sous-estimé : le handoff.

Dans une équipe humaine, les passages de relais sont déjà critiques. Une mauvaise transmission entre le produit et la technique, entre l’implémentation et la QA, entre la sécurité et la livraison, crée de la perte, des malentendus, des retours arrière, des erreurs de lecture. Avec des agents, ce problème ne disparaît pas. Il change simplement de forme.

Un bon handoff doit conserver l’essentiel sans transmettre du bruit. Il doit préciser ce qui a été fait, ce qui a été décidé, ce qui reste ouvert, ce qui doit être vérifié, ce qui ne doit pas être remis en cause, et le niveau de confiance que l’on accorde à l’étape précédente.

Autrement dit, un handoff n’est pas un simple passage de texte. C’est une opération de structuration de contexte.

Et cela change beaucoup de choses. Car on comprend alors qu’un système agentique fiable ne dépend pas seulement de la qualité intrinsèque de chaque agent. Il dépend de la qualité des interfaces entre eux.

C’est souvent là que la maturité se joue. Non pas dans la capacité à faire beaucoup, mais dans la capacité à transmettre juste.

Pourquoi l’agent qui produit ne devrait pas être celui qui valide

Il existe une règle assez simple en ingénierie : ce qui produit ne devrait pas être seul à juger sa propre qualité. Bien sûr, l’auto-contrôle existe, et il est utile. Mais il ne remplace pas une validation sous un autre angle.

Avec les agents, cette règle reste vraie.

L’agent qui implémente a tendance à défendre implicitement la logique qu’il vient de construire. Même s’il tente de se relire, il reste prisonnier, au moins partiellement, de sa propre trajectoire de raisonnement. Il est donc vulnérable aux mêmes angles morts qu’un humain : rationalisation a posteriori, confiance excessive dans une hypothèse prise plus tôt, tendance à minimiser un risque pour préserver la cohérence de l’ensemble.

Séparer la production de la validation permet justement de casser cette inertie.

Un agent de review n’a pas le même objectif qu’un agent de build. Un agent de sécurité n’a pas la même grille de lecture qu’un agent d’architecture. Un agent d’évaluation n’est pas là pour prolonger la solution, mais pour la mettre à l’épreuve.

Cette dissociation ne rend pas le système plus lourd par principe. Elle le rend plus crédible.

Parce qu’elle réintroduit un principe essentiel : la qualité ne se décrète pas à l’intérieur de la même boucle qui a produit le résultat.

Le problème n’est pas d’avoir plusieurs agents, c’est d’avoir plusieurs responsabilités mal pensées

Il y a parfois une critique rapide des approches multi-agents : “Vous compliquez tout. Un bon agent généraliste avec assez de contexte suffirait.”

Parfois, cette critique vise juste. Il existe des systèmes inutilement complexes, avec trop de rôles artificiels, trop d’étapes, trop de cérémonial. Une mauvaise architecture multi-agents peut effectivement devenir plus fragile qu’un agent unique bien cadré.

Mais ce constat ne prouve pas que l’agent unique est la bonne réponse. Il prouve simplement qu’il faut concevoir les responsabilités avec sérieux.

Le sujet n’est donc pas “un agent ou plusieurs” au sens purement numérique. Le sujet est : où doivent se situer les frontières de responsabilité pour que le système reste lisible, fiable et pilotable ?

Parfois, une seule boucle suffit sur une tâche simple. Parfois, deux ou trois rôles bien définis créent déjà un énorme gain de qualité. Parfois, une chaîne plus riche devient nécessaire dès qu’on touche à la sécurité, à la compatibilité, au packaging, à la validation ou à la mémoire de décision.

La bonne architecture n’est pas celle qui impressionne le plus. C’est celle qui sépare juste ce qui doit l’être, et qui garde ensemble ce qui peut raisonnablement l’être.

L’agentique mature suppose de renoncer à la magie

Je crois que c’est, au fond, le cœur du sujet.

Tant qu’on cherche la magie, on cherche naturellement l’agent unique. Un seul interlocuteur, une seule intelligence, un seul flux. C’est élégant en apparence. C’est simple à raconter. C’est séduisant à vendre.

Mais le développement web réel récompense rarement la magie. Il récompense plutôt les systèmes capables d’absorber la complexité sans la nier.

C’est pour cela que l’agentique mature ressemble moins à un tour de force qu’à une architecture.

Une architecture où chaque rôle a une raison d’exister.
Une architecture où les handoffs sont pensés.
Une architecture où les validations sont séparées des productions.
Une architecture où le contexte n’est pas juste accumulé, mais distribué intelligemment.
Une architecture où l’humain garde un vrai pouvoir d’arbitrage.

Ce n’est peut-être pas la vision la plus spectaculaire. Mais c’est probablement la plus solide.

Le développeur-orchestrateur apparaît justement ici

C’est dans cette bascule que la figure du développeur-orchestrateur devient plus nette.

Si un agent seul ne suffit pas, alors la valeur n’est plus dans le simple fait de savoir “parler à l’IA”. Elle est dans la capacité à organiser une chaîne de travail cohérente.

Le développeur-orchestrateur n’est pas là pour remplacer tous les rôles par sa seule volonté. Il est là pour structurer les interactions entre les rôles, choisir les bons niveaux de séparation, injecter le bon contexte au bon endroit, exiger les bons points de contrôle, et savoir à quel moment une production doit être stoppée, corrigée, validée ou relancée.

Autrement dit, il devient le garant de la lisibilité du système.

Ce n’est pas un rôle décoratif. C’est même probablement une partie croissante de la valeur technique dans les années qui viennent.

Parce qu’un système agentique mal structuré peut produire vite sans produire juste.
Et parce qu’un système agentique bien pensé peut, lui, réellement changer le niveau de qualité d’une équipe.

Comme je l’expliquais dans J’ai arrêté BMAD, la méthode compte autant que l’outil. Et l’orchestration est précisément cette méthode.

Conclusion

L’idée de l’agent unique est séduisante, mais elle s’effondre dès que le développement web retrouve sa vraie nature : un travail de contraintes, de contextes, de responsabilités et de vérifications.

Un agent seul peut être utile. Il peut même être impressionnant. Mais il ne suffit pas dès que l’on cherche de la fiabilité, de la lisibilité et du contrôle sur des projets réels.

C’est pour cela que la spécialisation, les handoffs, la séparation entre production et validation, et la structuration des rôles deviennent si importants.

La maturité agentique ne consiste pas à rêver d’un super-agent capable de tout absorber. Elle consiste à construire une architecture de travail où chaque rôle sert la qualité d’ensemble.

Et c’est précisément ce qui ouvre la suite logique de cette série.

Parce que si un agent seul ne suffit pas, alors la vraie performance dépend d’autre chose : de la qualité du contexte, des skills et de la méthode.

C’est ce que j’aborderai dans le prochain article.

À suivre dans la série

Le développeur-orchestrateur #1 — Pourquoi l’agentique change vraiment le développement web
Le développeur-orchestrateur #2 — Pourquoi un agent seul ne suffit pas
Le développeur-orchestrateur #3 — Pourquoi les skills, le contexte et la méthode changent tout
Le développeur-orchestrateur #4 — Le nouveau métier : cadrer, orchestrer, arbitrer

Nicolas Dabène — Architecte de la transition AI-native du e-commerce & développeur du module MCP Tools Plus pour PrestaShop. Convaincu que l’orchestration agentique sera le différenciateur compétitif des développeurs de demain.