Un seul article pour tout comprendre : du agent unique à la pipeline multi-agents en 2026

L'an dernier nous avons livré un « agent support tout-en-un » pour une équipe SaaS B2B : un seul system prompt avec personas pré-vente, SAV, devis et dépannage, plus une FAQ de vingt pages. Semaine 1 : métriques au vert. Semaine 3 : il poursuit des upsells dans des tickets de remboursement et envoie des codenames internes aux clients.

Personne n'a accusé le modèle d'être bête. Le problème était simple : quatre postes, un seul employé. En 2026 le consensus se fixe—l'agent unique n'est pas mort, mais il convient aux tâches à frontières nettes et chaîne d'outils courte. Dès que recherche → spec → code → tests → revue → release—un flux multi-étapes, parallèle et auto-correctif—entre en jeu, il faut modéliser une pipeline multi-agents.

Pas de lexique « qu'est-ce qu'un agent », seulement le chemin de migration vu chez OpenClaw, les agents IDE et nos PoC. Si mémoire et coût vous préoccupent déjà, croisez avec Agent Memory vs historique de chat et facture coût équipe.

Ère mono-agent : fort en jeu de rôle, faible en collaboration

Les premiers produits agents rivalisaient sur la qualité du system prompt et la fluidité des changements de persona. Empiler « architecte senior », « reviewer acide », « PM patient »—le modèle change de ton dans un fil. C'est le jeu de rôle mono-agent.

Avantages : un déploiement, des traces courtes, debug simple. Cursor, Claude Code et les GPT custom ont poussé cette voie en 2024–2025.

Le plafond est tout aussi net :

• Pollution du contexte—notes, diffs et logs de tests dans une même fenêtre.
• Responsabilité floue—échec de planification ou d'exécution ? impossible de relancer une seule étape.
• Zéro parallélisme—le modèle pense en ligne, les équipes humaines non.
• Permissions difficiles à séparer—l'agent code et l'agent base prod ne doivent pas partager les mêmes outils.

Quand la mission passe de « répondre » à « livrer une PR mergeable », épaissir le prompt rapporte peu. Ce n'est pas une régression du modèle—c'est un problème d'ingénierie avec handoffs et replay.

Ère multi-agents : d'un acteur masqué au protocole de handshake

La collaboration multi-agents change de métaphore : plusieurs rôles sur scène, reliés par script et mise en scène. Planner découpe seulement, Coder touche des chemins autorisés, Reviewer lit les diffs sans « corriger deux lignes au passage ».

Trois mécanismes d'alignement :

• État partagé—plans, snapshots, résultats de tests, todos dans le graphe ou un store, pas éparpillés dans le chat.
• Handoffs structurés—JSON, patches, checklists ; l'étape suivante ne consomme que des champs valides.
• Fin et arbitrage—terminé, escalade humaine, rollback : Evaluator ou règle, pas le dernier agent.

En scindant le bot support en Intent Router, FAQ Retriever, Ticket Writer et Escalation Guard, le jargon interne envoyé aux clients est tombé à zéro—parce qu'Escalation Guard n'avait pas d'outils client.

Dedans un agent : ReAct et couches

Avant de recruter une équipe, cartographier l'anatomie d'un agent seul. LangChain, OpenAI Agents SDK, Cursor—le squelette 2026 se ressemble :

De haut en bas :

• Couche d'instruction—system prompt, AGENTS.md, Skills traduisent les objectifs. Skills = sous-programmes réutilisables.
• Boucle ReAct—Reason → Tool → Observe. Le cœur.
• Outils & runtime—filesystem, Git, sandbox. MCP est le standard de fait en 2026.
• Garde-fous déterministes—hooks, middleware, evaluateurs hors boucle.
• État & mémoire—plans, logs, store alimentent la prochaine itération avec la réalité.

Le multi-agent duplique les boîtes et les relie en graphe. LangGraph sépare messages de thread et stores cross-thread (concepts mémoire).

Motifs de pipeline : quatre topologies

« Multi-agents » ≠ « plus de têtes ». Topologie d'abord :

Tendance 2026 : sortir le déterministe du LLM. Format, lint, tests, tags en CI ; l'agent pense et rédige. Sur Mac cloud, xcodebuild isolé pendant que l'agent ne soumet que des diffs—comme « les devs ne touchent pas la prod ».

Les concepts multi-agents LangChain modélisent Supervisor, Swarm, Handoff comme arêtes—l'arête bat le modèle.

Stack 2026 : Harness / Framework / Runtime

Au-delà de trois nœuds en IDE, VPS ou cron, « un script Python de prompts » ne scale pas. Trois couches :

Runtime (LangGraph)—quel nœud ensuite, où l'état vit, comment rollback. LangGraph en supersteps Pregel.

Framework (LangChain)—modèles, outils, RAG en pièces détachées.

Harness (DeepAgents etc.)—test, déploiement, alignement humain ; la course 2026 : qui ship en prod.

Checklist de mise en prod

Minimum pour pilotes internes—agnostique éditeur :

• Graphe d'état, pas organigramme—nœuds = verbes, arêtes = contrats de données.
• Schema par handoff—JSON Schema pour retries partiels.
• Outils minimaux par nœud—reviewer en lecture seule.
• Un trace id de bout en bout.
• Mémoire en couches—thread, session, RAG séparés.
• Budget coût par nœud—gros modèle planifie, petit formate.

Séparer aussi l'exécution : passerelle OpenClaw sur VPS, xcodebuild et automation lourde sur Mac cloud—éviter le portable unique qui s'éteint en fermant le capot.

Questions fréquentes