Faire collaborer plusieurs agents IA sans perdre le contrôle

Commencer par le travail, pas par les personnages

Un système mono-agent reste souvent le meilleur point de départ. S’il peut appeler plusieurs outils, conserver un état et suivre une procédure courte, le diviser prématurément ne fait que déplacer la complexité. La première question n’est donc pas combien d’agents créer, mais quelles étapes exigent réellement des compétences, des permissions ou des contextes différents.

Une séparation devient pertinente lorsqu’une tâche produit un livrable autonome : rechercher des sources, analyser un contrat, exécuter des tests ou vérifier une conformité. Chaque rôle doit pouvoir être décrit par une entrée, une sortie et un critère d’acceptation. Un nom séduisant sans contrat clair ne constitue pas une architecture.

• Identifier les livrables intermédiaires.
• Séparer les responsabilités ayant des permissions différentes.
• Conserver un seul agent tant que la division n’améliore ni la qualité ni la sécurité.

Choisir qui garde la décision finale

Deux modèles d’orchestration couvrent une grande partie des besoins. Dans le modèle manager, un coordinateur appelle des spécialistes comme des outils puis assemble la réponse. Il garde une vision globale et peut appliquer les mêmes règles de validation à tous les résultats. Ce modèle convient lorsque la sortie finale doit rester cohérente.

Dans le modèle par transfert, un agent de triage remet la tâche à un spécialiste qui devient responsable de la suite. Cette approche réduit le bruit lorsque les domaines sont vraiment distincts, mais elle rend le passage de relais critique. Le choix doit être explicite : qui répond, qui peut agir et qui assume la décision lorsque deux spécialistes se contredisent ?

Définir des contrats entre spécialistes

Un transfert en langage libre oblige le destinataire à deviner ce qui est important. Une sortie structurée indique le statut, les faits observés, les hypothèses, les preuves, les incertitudes et la prochaine action proposée. Le coordinateur peut alors refuser une sortie incomplète avant de déclencher une étape coûteuse ou irréversible.

Le contrat doit aussi représenter l’échec. Un spécialiste peut répondre qu’une source manque, qu’un test est non concluant ou qu’une autorisation humaine est requise. Forcer chaque branche à produire un succès apparent transforme les incertitudes locales en erreurs silencieuses au niveau du système.

• Versionner les schémas d’entrée et de sortie.
• Distinguer résultat, preuve et niveau de confiance.
• Prévoir explicitement les états incomplet, refusé et à valider.

Partager le minimum de contexte utile

Transmettre toute la conversation à chaque agent paraît simple, mais augmente le coût et expose des données sans nécessité. Un spécialiste de test a besoin du changement, des critères et de l’environnement ; il n’a pas forcément besoin des échanges commerciaux ou des données personnelles qui ont précédé.

Le coordinateur prépare un paquet de contexte limité et traçable. Les références vers les documents originaux restent disponibles, tandis que les résumés sont identifiés comme tels. Cette séparation réduit les contradictions, facilite la confidentialité et permet de comprendre quelle information a réellement influencé une décision.

Placer les garde-fous autour des actions

Les instructions générales ne remplacent pas les contrôles techniques. Une opération de lecture, une modification locale et un paiement n’ont pas le même niveau de risque. Les outils doivent imposer leurs propres schémas, vérifier les permissions et demander une approbation lorsque l’effet dépasse le périmètre autorisé.

Les contrôles se placent avant et après les appels sensibles : validation des arguments, limitation des cibles, vérification du résultat et journalisation de la décision. Une action refusée doit rester un résultat normal du workflow, pas une exception que l’agent tente de contourner en reformulant sa demande.

Observer la collaboration comme un graphe

Un journal plat devient vite illisible. Une trace doit relier la demande initiale, chaque délégation, les appels d’outils, les validations, les reprises et la sortie finale. On peut alors distinguer un mauvais routage, un contexte insuffisant et une erreur de spécialiste.

Les métriques utiles ne se limitent pas au taux de réussite : nombre de transferts, tokens par rôle, délai critique, appels redondants, interventions humaines et proportion de résultats refusés. Une collaboration qui améliore légèrement la qualité mais multiplie les tours et la latence peut être une mauvaise décision produit.

Déployer avec une complexité plafonnée

La première version peut exécuter les spécialistes en observation sans appliquer leurs décisions. On compare leur proposition à la procédure existante, puis on active un parcours limité. Le nombre maximal de délégations, la durée, le budget et les actions autorisées sont fixés avant la mise en production.

Une rétrospective régulière supprime les rôles inutiles et transforme les décisions stables en code déterministe. Un bon système multi-agent ne cherche pas à faire intervenir tout le monde : il sait quand déléguer, quand vérifier et quand s’arrêter.

• Tester les transferts et les refus, pas seulement le chemin heureux.
• Fixer un budget de tours et d’outils.
• Conserver une sortie de secours compréhensible.
• Remplacer par du code les décisions devenues stables.