Type
Guide technique
Publié le
Durée
3 min de lecture
Auteur
rootzero
Read in English
Read in English →

Systèmes multi-agents : contrats, orchestration et reprise

Concevoir un système multi-agents vérifiable : tâches, messages typés, preuves, droits, idempotence, budget et reprise. Exemple de qualification cyber.

  • IA
  • Multi-agents
  • Architecture
  • Méthode

Un système multi-agents doit distribuer le travail sans diluer les responsabilités. Le rôle « vérificateur » ne suffit pas à rendre une conclusion indépendante : il faut préciser quelles pièces il reçoit, quels contrôles il exécute et ce qui lui permet de rejeter un résultat.

Le retour d’ingénierie d’Anthropic décrit un système de recherche avec délégation. Le travail Why Do Multi-Agent LLM Systems Fail? étudie des défaillances de conception, de coordination et de vérification. Pour un workflow cyber, nous proposons de rendre ces frontières observables avec des contrats de tâche.

Choisir le degré de liberté nécessaire

Un workflow fixe convient lorsque l’ordre des vérifications est connu. Un agent unique peut adapter sa recherche sans imposer une coordination entre plusieurs participants. Un ensemble d’agents peut être utile lorsque des sous-problèmes sont réellement séparables ou demandent des contextes différents.

Comparez les options avec le même objectif, le même corpus et le même budget. Si deux agents passent leur temps à se recopier les mêmes données, le découpage n’a peut-être pas créé d’indépendance utile. La quantité de messages n’établit pas la qualité du résultat.

Le contrat de tâche doit survivre à un changement de modèle

Dans un exemple fictif, un rôle collecte les références d’un avis, un autre rapproche les versions et un troisième examine la justification. L’orchestrateur garde la responsabilité du périmètre et des transitions.

{
  "tache": "qualification-17",
  "organisation": "alpha",
  "objectif": "rapprocher version observee et avis",
  "entrees": ["inventaire:8@3", "avis:12@1"],
  "sortie_attendue": "concerne, non_concerne ou inconnu",
  "preuves_requises": ["version", "conditions", "source"],
  "budget_actions": 6
}

Le contrat limite la tâche, mais ne donne pas à lui seul accès aux sources. L’environnement d’exécution doit vérifier les droits lors de leur lecture. Un identifiant d’organisation écrit par un modèle ne doit pas permettre de changer d’espace client.

Une machine à états évite les fins ambiguës

Une tâche peut être créée, en cours, bloquée, terminée ou rejetée. Définissez les transitions acceptées et les pièces nécessaires à chacune. Le statut « bloqué » a une utilité : il préserve un manque d’accès au lieu de produire une conclusion approximative pour finir le workflow.

Pour accepter une qualification « concerné », exigez les versions comparées et la référence applicable. Un message affirmatif sans pièce doit pouvoir être rejeté. Un rejet doit expliquer ce qui manque, afin que la reprise ne recommence pas toute l’enquête.

Reprise, concurrence et idempotence

Un délai réseau ne prouve pas qu’une opération a échoué. Si un agent demande la création d’un ticket puis perd la réponse, relancer aveuglément peut créer un doublon. Pour un effet externe, attribuez une clé d’idempotence et conservez un reçu d’exécution que la reprise peut consulter.

La mémoire partagée pose un autre problème : deux agents peuvent modifier la même entrée à partir de versions différentes. Une version attendue ou une opération atomique permet de détecter le conflit. Une seconde écriture ne doit pas écraser silencieusement la première parce qu’elle est arrivée plus tard.

Ces mécanismes appartiennent au système d’exécution. Un message « ne crée pas de doublon » ne remplace pas une vérification de la clé ou du reçu.

Mesurer le système complet

Conservez les décisions, appels d’outils, références et transitions utiles au diagnostic, avec une politique de masquage adaptée. Une trace exploitable n’exige pas de publier des secrets ni des raisonnements internes privés. Les pièces observables doivent suffire à comprendre pourquoi une action a été acceptée.

Testez un message incomplet, un agent indisponible, une pièce contradictoire, un dépassement de budget et une reprise après effet déjà réalisé. Mesurez la réussite de la tâche, les effets indésirables, la latence et les blocages correctement reconnus.

Lisez aussi les principes des agents IA cyber, la mémoire et ses versions et l’évaluation des agents cyber. Le dossier IA et cyber situe ces contrôles dans l’architecture complète.

#rootzero

Une question sur votre exposition ?

Écrivez-nous. Une personne de l’équipe technique vous répond, sources à l’appui.