Architecture multi-agents : éviter l’agent géant qui contrôle tout

Un agent géant donne l’impression d’aller vite au début. Mais plus il reçoit d’outils, de mémoire et de responsabilités, plus il devient difficile à auditer, à sécuriser et à corriger. La promesse est séduisante : un seul agent lit les mails, consulte le CRM, prépare les devis, relance les clients, met à jour les statuts et publie des rapports. En pratique, cette concentration crée une boîte noire.

Les risques s’accumulent : trop d’outils, trop de données, trop de responsabilités, un prompt difficile à maintenir, des erreurs difficiles à attribuer, des permissions trop larges, des logs confus, une reprise sur erreur compliquée, des coûts qui explosent et une surface de sécurité plus grande. Quand une action échoue, l’entreprise ne sait plus si le problème vient du modèle, du contexte, d’un outil, d’une permission, d’une règle métier ou d’une donnée obsolète.

Une architecture multi-agents sert à découper ce risque. Elle ne rend pas l’IA parfaite, mais elle rend le système plus lisible : qui reçoit la demande, qui décide du flux, qui exécute, avec quel outil, sous quelle permission, et comment revenir en arrière si une étape se passe mal.

Le principe du moindre privilège est central. Un agent de recherche peut avoir accès en lecture à une base documentaire, sans droit de modifier les documents. Un agent CRM peut préparer une mise à jour, mais l’écriture peut être limitée à quelques champs, avec validation humaine sur les données sensibles. Un agent reporting peut lire des indicateurs agrégés sans accéder au détail nominatif.

Une architecture sérieuse distingue les scopes par agent, par outil et par tâche. Elle sépare l’identité technique de l’agent, l’identité utilisateur à l’origine de la demande, les droits délégués, les secrets, les tokens, les accès temporaires et les environnements de test ou de production. Elle sépare aussi lecture et écriture : lire une fiche client n’a pas le même risque que modifier son statut, envoyer un email ou créer une facture.

Cette rigueur protège l’entreprise contre les erreurs ordinaires et contre les attaques spécifiques aux systèmes LLM, notamment l’injection de prompt et l’usage excessif d’outils. Le référentiel OWASP LLM documente ces risques : il ne suffit donc pas de “faire confiance au prompt”. Les permissions doivent être vérifiées par le système, pas seulement demandées au modèle.

Il faut distinguer mémoire de conversation, mémoire utilisateur, mémoire projet, mémoire métier, mémoire d’exécution, état temporaire, logs, base de connaissances et données sensibles. Tout mettre dans un même bloc “mémoire” est dangereux : on ne sait plus ce qui sert à personnaliser l’expérience, ce qui sert à reprendre une tâche, ce qui constitue une preuve et ce qui devrait rester dans un système métier validé.

Concrètement, un agent peut retenir qu’une demande appartient à un projet, qu’une étape est en attente de validation ou qu’une préférence de ton a été choisie. Mais le montant d’une facture, le statut officiel d’un client ou la dernière version d’un contrat doivent être relus depuis la source de vérité. La mémoire améliore l’usage ; elle ne remplace pas la gouvernance des données.

L’idempotence signifie qu’une même action relancée deux fois ne doit pas produire deux effets indésirables. C’est indispensable dans les systèmes multi-agents, parce qu’une tâche peut être relancée après timeout, coupure réseau, erreur d’API, validation tardive ou redémarrage du service.

En pratique, on utilise des identifiants de tâche, des clés d’idempotence, des statuts intermédiaires, des journaux d’action et parfois des opérations en deux temps : préparer puis confirmer. Le but n’est pas de rendre l’erreur impossible, mais de rendre la reprise compréhensible.

Le journal de preuve répond à des questions très simples : qui a demandé l’action ? Quel agent a agi ? Quel outil a été appelé ? Quelle donnée a été utilisée ? Quel résultat a été produit ? Une validation humaine a-t-elle eu lieu ? Quelle erreur est survenue ? Un rollback a-t-il été nécessaire ? Combien de temps faut-il conserver ces traces ?

Ce journal n’est pas seulement technique. Il a une utilité commerciale et managériale : comprendre si le système fait gagner du temps, s’il respecte les règles internes, s’il produit des erreurs récurrentes, ou s’il déplace simplement le travail vers une personne chargée de corriger après coup. Un agent qui ne laisse pas de trace est difficile à défendre, même s’il semble efficace.

La cohérence avec une démarche d’automatisation IA pour PMEest essentielle : on n’ajoute pas des agents pour moderniser un schéma qui fonctionne déjà. Si une règle claire suffit, elle sera souvent plus fiable, moins chère et plus facile à auditer qu’un agent.

Les agents sont utiles quand il faut comprendre du langage, arbitrer entre cas variables, retrouver des informations dispersées ou adapter une réponse au contexte. Ils sont moins pertinents pour une séquence parfaitement connue : recevoir un formulaire, vérifier trois champs, créer une tâche, envoyer une notification. Là, un workflow classique gagne.