Orchestration multi-agents : au-delà du chatbot

Un chatbot répond à des questions. Un système multi-agents exécute un process. La différence tient dans l’orchestration : au lieu de demander à une seule IA de tout faire, on décompose le travail en agents spécialisés — un qui extrait les données, un qui analyse, un qui rédige, un qui vérifie — coordonnés par un orchestrateur qui distribue les tâches, contrôle les résultats et fait remonter à l’humain ce qui doit l’être.

Le principe n’a rien d’exotique : c’est celui de toute organisation. Vous ne confiez pas la comptabilité, la vente et le juridique à la même personne « très polyvalente ». Chaque agent a un périmètre étroit, des instructions précises et des critères de réussite vérifiables — et c’est cette étroitesse qui fait la fiabilité de l’ensemble.

Pourquoi plusieurs agents font mieux qu’un seul ?

Un agent unique chargé d’un process complet accumule les rôles, et sa fiabilité se dégrade à mesure que ses instructions s’allongent : mission trop large, contexte encombré, erreurs qui se propagent sans contrôle d’une étape à l’autre.

La décomposition attaque ces trois faiblesses à la fois. Chaque agent reçoit uniquement le contexte utile à sa tâche, donc il la fait mieux. Chaque sortie est contrôlée avant de nourrir l’étape suivante, donc une erreur est arrêtée tôt au lieu de contaminer tout le résultat. Et quand une étape déçoit, on améliore cet agent-là — sans toucher au reste du système. Bonus opérationnel : les étapes indépendantes tournent en parallèle.

À quoi ça ressemble sur un vrai process ?

Prenez le traitement d’une demande client complexe — une réclamation avec enjeu contractuel. En version multi-agents :

• Un agent d’intake lit la demande, identifie le client, récupère l’historique et le contrat concerné.
• Un agent d’analyse confronte la réclamation aux clauses applicables et qualifie le niveau d’enjeu.
• Un agent de rédaction prépare le projet de réponse dans le ton maison, en citant les éléments du dossier.
• Un agent de vérification contrôle les faits cités, les montants et la conformité aux règles internes.
• L’orchestrateur assemble le tout : les cas simples partent en file de validation rapide, les cas à enjeu sont escaladés à un humain avec un dossier complet préparé.

Cinq schémas d’orchestration, du plus simple au plus souple

L’exemple ci-dessus n’est qu’un montage parmi d’autres. En pratique, l’orchestration d’agents IA se ramène à cinq schémas récurrents, qui ne demandent ni le même effort de conception, ni la même supervision, ni le même budget :

• Chaînage : la sortie d’une étape devient l’entrée de la suivante, avec un contrôle entre les deux. Prévisible et facile à déboguer, c’est le bon réflexe quand le process est linéaire et connu.
• Routage : un premier agent qualifie la demande et l’envoie vers le circuit adapté. Évite le prompt fourre-tout censé couvrir tous les cas de figure, et permet de traiter les cas simples par un chemin court.
• Parallélisation : soit on découpe le travail en parts indépendantes traitées en même temps, soit on fait exécuter la même tâche plusieurs fois pour ne retenir que ce qui concorde — utile sur les contrôles sensibles, où une seule lecture ne suffit pas.
• Orchestrateur-exécutants : un agent central décide lui-même des sous-tâches à créer selon la demande reçue, les distribue, puis agrège les retours. C’est le schéma de l’exemple ci-dessus : le plus souple, et le plus exigeant à superviser puisque le découpage n’est pas connu d’avance.
• Évaluateur-optimiseur : un agent produit, un second le critique selon des critères explicites, le premier reprend. Il ne rapporte que si les critères de qualité sont écrivables — sinon la boucle tourne sans converger.

La plupart des systèmes en production en combinent deux ou trois : un routage à l’entrée, un chaînage sur le circuit standard, un orchestrateur dynamique réservé aux cas hors nomenclature. Le choix n’est pas esthétique — il détermine le coût de supervision. Un chaînage se contrôle à points fixes ; un orchestrateur qui invente son propre découpage demande des garde-fous sur ce qu’il a le droit de déclencher. Commencer par le schéma le plus simple qui fait le travail reste la décision la plus rentable.

La supervision : l’humain dans la boucle, au bon endroit

Un système multi-agents sans points de contrôle est une chaîne d’erreurs potentielles à grande vitesse. La conception de la supervision est donc un travail à part entière : définir où l’humain valide obligatoirement — engagements financiers, communications sensibles, cas hors nomenclature —, ce que chaque agent journalise, et quels seuils déclenchent une escalade.

Bien conçue, cette supervision est économe : l’humain ne revoit pas tout, il revoit ce qui compte, avec un dossier préparé. C’est le même principe qu’un manager avec une équipe : déléguer l’exécution, garder les décisions. Et comme tout est journalisé, chaque escalade dit pourquoi elle a eu lieu — la supervision s’améliore avec l’usage, au lieu de rester figée.

Ce qui relie les agents au système d’information

Un agent qui ne lit que son prompt ne fait que rédiger. L’orchestration ne prend de valeur que le jour où les agents lisent le CRM, la GED ou l’ERP, et écrivent dans les outils où le travail se fait vraiment. Cette connexion est devenue un sujet d’architecture à part entière, et elle s’est standardisée : le protocole MCP (Model Context Protocol), publié par Anthropic puis cédé le 9 décembre 2025 à l’Agentic AI Foundation de la Linux Foundation — co-fondée avec Block et OpenAI — n’est plus un format propriétaire lié à un fournisseur de modèle.

La conséquence pratique compte plus que le sigle. Dans la révision de spécification de juillet 2026, un serveur MCP est un resource server OAuth 2.1 : les droits d’accès de chaque agent transitent par l’annuaire d’identité déjà en place, avec des portées minimales et un jeton lié à son destinataire. Concrètement, l’agent d’intake peut lire le dossier client sans pouvoir y écrire, et l’agent de rédaction n’accède pas aux données qui ne concernent pas sa tâche.

Cela déplace la question de gouvernance au bon endroit. Elle cesse d’être « est-ce que l’IA a accès à nos données ? » — formulation qui n’appelle qu’une réponse binaire — pour devenir « quel agent dispose de quelle portée, accordée par qui, et révocable comment ? ». C’est une question à laquelle une DSI sait répondre avec ses outils existants.

Et les coûts ?

Oui, plusieurs agents consomment plus de tokens qu’une conversation unique — chaque étape a son propre contexte et ses propres échanges. Ce surcoût se pilote : réserver les modèles les plus capables aux étapes de raisonnement, utiliser des modèles plus légers pour l’extraction et le tri, éviter de recharger des contextes redondants entre étapes.

Mais le vrai calcul ne se fait pas en tokens. Il se fait contre le coût du process actuel : les heures humaines consommées, les délais de traitement, les erreurs qui passent. Un process qui mobilisait des heures de travail qualifié et qui s’exécute désormais en minutes supervisées rentabilise très largement sa consommation — et cette équation se mesure, elle ne se devine pas.

Par où commencer, sans se perdre

Pas par l’architecture — par le process. Choisissez-en un qui soit fréquent, structuré et coûteux en temps, puis décrivez-le comme vous l’expliqueriez à un nouveau : étapes, entrées, sorties, règles de décision, cas limites. Cette description est déjà le plan de votre système multi-agents ; si vous ne pouvez pas l’écrire, aucune orchestration ne fonctionnera.

Construisez ensuite agent par agent, en validant chaque étape sur des cas réels avant d’ajouter la suivante. C’est la démarche que nous suivons dans le Programme Autonomie Claude, sur les process de nos clients : l’orchestration multi-agents n’est pas une prouesse technique, c’est la traduction disciplinée d’un process que vous maîtrisez déjà.