Architecture multi-agent : quand découper un agent complique le service

Ajouter un agent à chaque étape d’un processus peut sembler rendre le système plus modulaire. Mais chaque séparation ajoute aussi un transfert de contexte, une décision de routage et un endroit où une erreur peut se propager. Pour une PME qui conçoit un service numérique, la question utile n’est donc pas « combien d’agents peut-on créer ? », mais « quelle responsabilité distincte justifie chaque agent ? ».

Une présentation de l’architecture multi-agent de la plateforme publicitaire de Spotify, résumée par InfoQ, met notamment en avant les frontières entre agents, la propriété des domaines, les garde-fous déterministes, les schémas d’outils et l’évaluation fondée sur les traces. Ces thèmes fournissent des points de vigilance, pas une recette universelle : le résumé disponible ne permet pas de transposer les choix de cette plateforme à un autre contexte.

Voici une méthode de cadrage centrée sur les erreurs de conception les plus coûteuses à découvrir après intégration.

Cas fictif : une demande qui traverse trop d’agents

Imaginons une PME qui veut préparer des réponses aux demandes de devis reçues par son équipe commerciale. Un premier agent classe le message, un deuxième extrait les besoins, un troisième consulte un catalogue interne et un quatrième rédige une proposition. Le système remet ensuite le résultat à une personne pour validation. Ce scénario est fictif : il sert à examiner des décisions d’architecture, et ne décrit pas un déploiement réel.

Au début, chaque agent paraît avoir une tâche nette. Puis une demande manque d’information : le premier agent la classe de travers, le suivant comble le vide par une interprétation, et le rédacteur transforme cette hypothèse en formulation convaincante. Le problème n’est pas seulement une réponse imprécise. Il devient difficile de savoir à quel moment l’information a été perdue, qui devait la vérifier et quelle étape peut être relancée sans répéter une action.

Cette petite histoire fait ressortir une règle de conception : une frontière entre agents doit correspondre à une responsabilité utile, avec une entrée attendue, une sortie vérifiable et un responsable de sa qualité. Si l’équipe ne peut pas expliquer ces trois éléments, la séparation risque d’ajouter de la coordination plutôt que de la maîtriser.

Trois pièges qui rendent le système difficile à reprendre

Découper par rôle apparent plutôt que par responsabilité

Des noms comme « agent chercheur », « agent analyste » ou « agent rédacteur » décrivent une activité, pas nécessairement une frontière d’architecture. Si deux agents interprètent les mêmes données ou peuvent tous deux décider de la prochaine étape, leurs responsabilités se chevauchent. En cas de résultat incohérent, les équipes peuvent devoir examiner plusieurs étapes sans savoir laquelle avait autorité pour trancher.

Pour chaque agent, précisez ce qu’il peut décider, ce qu’il doit renvoyer à un autre composant et ce qu’il ne doit pas supposer. Si une étape n’a pas besoin d’interprétation, une règle explicite ou un traitement classique peut être plus facile à tester et à maintenir qu’un agent supplémentaire.

Laisser les transferts de données implicites

Un passage de relais n’est pas une simple conversation entre composants : il transporte des éléments nécessaires à la décision suivante. Si le format de sortie est flou, un agent peut recevoir une réponse partielle, confondre une hypothèse avec une donnée confirmée ou ignorer qu’une vérification manque. Les conséquences possibles sont une réponse incohérente, une reprise manuelle ou une action déclenchée sur une base incertaine.

Définissez un contrat lisible pour chaque transfert : champs attendus, éléments absents, niveau de confiance si vous en utilisez un, et comportement en cas de sortie invalide. Un schéma d’outil désigne la description structurée de ses paramètres et de ses résultats. Il doit limiter les ambiguïtés et permettre au composant appelant de traiter un refus ou une erreur sans improviser.

Confondre autonomie et absence de contrôle

Une consigne demandant à un agent d’être prudent ne remplace pas une limite appliquée par le système. Si une étape peut modifier un dossier, envoyer un message ou engager une dépense, le droit d’effectuer cette action doit être contrôlé en dehors de la seule réponse générée. Sinon, une interprétation erronée peut devenir une opération réelle avant qu’une personne ait eu l’occasion de l’examiner.

Prévoyez des garde-fous déterministes : ce sont des règles explicites, appliquées par le logiciel, qui n’exigent pas d’interpréter la réponse du modèle pour décider si une action est autorisée. Selon le risque, l’agent peut préparer une proposition tandis qu’un service distinct vérifie les droits et demande une validation humaine.

Pour approfondir le cadrage des droits d’un agent connecté au SI, consultez les garde-fous à comparer avant d’ouvrir le SI à un agent IA.

Évaluer le coût complet, pas seulement la réponse produite

Un système multi-agent appelle à examiner le coût de l’ensemble du parcours : appels aux modèles et aux outils, reprises après erreur, traitement des cas ambigus, journalisation et temps passé à diagnostiquer un résultat. Le montant dépend du système et de son usage ; sans périmètre ni relevés, il serait trompeur d’annoncer un gain ou un seuil général.

Avant de choisir une architecture, demandez à l’équipe de décrire les scénarios à mesurer et de comparer, sur les mêmes cas, la solution multi-agent à une option plus simple. Examinez aussi ce que coûteront la surveillance, l’évolution des contrats entre agents et la reprise manuelle.

Quand la tâche peut être décrite par des règles stables, confrontez l’option agent aux alternatives évoquées dans la comparaison entre agent IA et automatisation classique.

Liste de vérification avant d’ajouter un agent

Cette liste peut servir en revue d’architecture ou lors du cadrage d’une prestation. Elle vise à rendre les arbitrages vérifiables, pas à imposer un nombre idéal d’agents.

• La tâche confiée à cet agent est-elle distincte de celle des autres composants ?
• Son entrée et sa sortie sont-elles décrites, y compris les cas incomplets ou invalides ?
• Un propriétaire est-il nommé pour le domaine métier et pour le comportement technique ?
• Les outils accessibles sont-ils limités à ce qui est nécessaire à la tâche ?
• Les actions sensibles sont-elles contrôlées par des règles qui ne dépendent pas uniquement du modèle ?
• Les traces permettent-elles de retrouver les transferts, les décisions et les erreurs sans conserver inutilement des données sensibles ?
• Un scénario de reprise précise-t-il ce qui se passe lorsqu’un agent échoue, répond hors format ou fournit un résultat à vérifier ?
• Le coût et la qualité sont-ils comparés sur un périmètre défini, avec des cas d’essai représentatifs et des critères de décision écrits ?

Les livrables à demander avant un pilote

Pour éviter une démonstration convaincante mais difficile à évaluer, demandez une carte des responsabilités, les contrats d’entrée et de sortie, la liste des outils accessibles et les règles d’autorisation. Ajoutez des cas de test couvrant les entrées incomplètes, les résultats incohérents et les erreurs de transfert, ainsi qu’une définition de la réussite et des conditions d’arrêt.

Précisez enfin quelles traces seront disponibles pour diagnostiquer une décision, qui les examinera et combien de temps elles seront conservées selon les règles de l’entreprise. Une trace utile doit permettre de comprendre le chemin suivi ; elle ne justifie pas de journaliser toutes les données échangées.

La bonne architecture n’est pas celle qui compte le plus d’agents ni celle qui promet le plus d’autonomie. C’est celle dont l’équipe peut expliquer les responsabilités, contrôler les actions, évaluer le coût et reprendre le service quand une étape ne se déroule pas comme prévu. Si un agent supplémentaire ne clarifie aucune décision, ne créez pas cette frontière par défaut.