Plusieurs agents IA ne forment pas une équipe

L’appel à projets lancé par Google DeepMind, Schmidt Sciences, la Cooperative AI Foundation et l’agence britannique ARIA arrive à échéance ce week-end. Jusqu’à 10 millions de dollars sont proposés pour comprendre comment des populations d’agents IA pourraient négocier, coopérer, se surveiller ou se dérégler lorsqu’elles agiront sur les mêmes réseaux.

La somme attire l’attention. Le motif devrait l’attirer davantage. Les organisateurs écrivent que la plupart des évaluations de sûreté regardent encore les modèles isolément, alors que les outils manquent pour prévoir, mesurer et suivre les comportements qui apparaissent lorsqu’ils interagissent. Autrement dit, l’industrie commence à vendre des équipes d’agents avant de savoir correctement noter l’équipe.

La distance entre les deux n’est pas théorique pour une entreprise. Un système qui confie la recherche à un agent, l’analyse à un deuxième, la rédaction à un troisième et la validation à un quatrième ne contient pas seulement quatre capacités. Il contient aussi au moins trois transmissions, plusieurs interprétations d’un même objectif et une responsabilité qui peut se dissoudre à chaque passage.

La division du travail est une organisation. Elle ne devient pas une architecture parce que ses postes portent des noms d’agents.

Le passage est un composant

Les démonstrations multi-agents donnent volontiers des rôles humains aux logiciels : chercheur, analyste, critique, superviseur. La mise en scène rend la séquence facile à comprendre. Elle cache ce qui doit être construit entre les rôles.

Que transmet exactement le chercheur à l’analyste ? Un texte libre, une liste de faits, des liens, un niveau de confiance, les données brutes ? Que doit faire l’analyste si une source manque ? Le critique voit-il le document original ou seulement le résumé produit en amont ? Peut-il corriger, bloquer, recommencer ou uniquement commenter ? Qui décide qu’un désaccord est résolu ?

Chaque flèche du schéma contient un contrat. Elle fixe un format, une provenance, des permissions, une durée de validité, une règle d’échec et un destinataire. Si ce contrat n’est pas explicite, l’agent suivant reçoit un mélange de données et d’instructions qu’il traite souvent avec la même docilité.

Le problème n’est donc pas seulement qu’un agent puisse se tromper. C’est qu’une erreur peut changer de statut en circulant. Une hypothèse devient une note. La note devient un fait dans un résumé. Le fait devient un paramètre d’action. À la fin, le système exécute proprement une décision dont personne ne retrouve l’incertitude initiale.

Dans un logiciel classique, on vérifie les interfaces parce qu’elles relient des composants écrits. Dans un système multi-agent, les interfaces relient des interprétations. Elles méritent davantage de rigueur, pas moins.

Quatre voix peuvent partager la même erreur

L’argument commercial le plus intuitif consiste à présenter les agents comme une petite assemblée. L’un propose, l’autre critique, un troisième tranche. La pluralité donnerait de la robustesse.

Elle peut en donner. Elle n’en donne pas par son seul nombre.

Si les quatre agents utilisent le même modèle, les mêmes données, le même vocabulaire et la même formulation de l’objectif, leurs erreurs sont probablement corrélées. Le critique peut reconnaître comme plausible ce que le premier agent a inventé, précisément parce qu’ils partagent les mêmes habitudes de raisonnement. Changer le nom du rôle dans le prompt ne crée ni indépendance statistique, ni expertise, ni intérêt contradictoire.

Le vote majoritaire devient alors une répétition coûteuse. Trois sorties semblables ne constituent pas trois preuves lorsque leurs causes sont presque identiques.

Une vraie séparation exige quelque chose de plus concret : une autre source de données, un autre outil de vérification, un accès plus limité, une règle déterministe, parfois un autre modèle, ou un humain qui possède une information que la chaîne ne peut pas reconstruire. Sans cette différence, le système imite la contradiction tout en conservant un point aveugle commun.

Le rapport de la Cooperative AI Foundation classe les risques multi-agents en trois familles : mauvaise coordination malgré des objectifs compatibles, conflit entre objectifs différents et collusion indésirable. La première suffit déjà à défaire la métaphore de l’équipe. Des agents n’ont pas besoin de se combattre pour produire un mauvais résultat. Ils peuvent échouer en étant tous raisonnables localement.

La moyenne masque la cascade

Supposons que chaque agent accomplisse correctement sa tâche neuf fois sur dix. Il serait tentant de conclure que l’ensemble est fiable à 90 %. Ce calcul oublie la dépendance entre les étapes.

Une erreur précoce alimente les étapes suivantes. Un agent de contrôle peut la détecter, mais il peut aussi l’amplifier en ajoutant une justification crédible. Une reprise automatique peut réparer le flux, ou lancer une boucle. Un agent qui respecte son budget peut obliger les autres à multiplier les appels. Une permission étroite à chaque poste peut devenir large lorsqu’une chaîne de délégations les additionne.

La mesure utile n’est donc pas la moyenne des scores individuels. C’est la distribution des résultats de bout en bout : combien de séquences aboutissent, combien s’arrêtent proprement, combien cachent une erreur, combien dépassent leur plafond et combien accomplissent une action irréversible avant que le contrôle ne réagisse.

Le papier « Distributional AGI Safety » pousse cette idée vers un horizon très ambitieux : la capacité générale pourrait émerger d’un réseau de systèmes spécialisés plutôt que d’un modèle unique. Cette hypothèse reste une hypothèse, et une PME n’a pas à transformer son flux de factures en question d’AGI. Mais son déplacement de méthode est déjà utile. La propriété dangereuse ou avantageuse peut appartenir à la distribution des agents, pas à l’un d’eux pris séparément.

Un embouteillage n’est pas une propriété d’une voiture. Une panique bancaire n’est pas une propriété d’un compte. Une cascade d’agents peut de la même manière naître de réactions localement cohérentes qui se nourrissent entre elles.

Un principal ne vaut pas plusieurs mandants

Les systèmes actuels les plus simples restent souvent orchestrés par une seule organisation. Un agent central distribue des sous-tâches à des agents spécialisés, tous reliés au même objectif et au même propriétaire. Cette configuration est déjà difficile à observer, mais elle garde un mandant identifiable.

Le scénario visé par l’appel de recherche est plus large. Des agents appartenant à des organisations différentes pourraient partager une infrastructure, négocier, acheter, réserver ou vérifier au nom de mandants différents. La question ne serait plus seulement « l’agent a-t-il suivi son instruction ? », mais « quelle instruction l’emporte quand les droits, les intérêts et les informations privées divergent ? ».

Le NIST a lancé en février son AI Agent Standards Initiative précisément autour de l’identité, de l’autorisation, des protocoles ouverts et des interactions humain-agent ou agent-agent. Ce chantier confirme une limite actuelle : l’interopérabilité promet de faire circuler les actions plus vite que la confiance n’est définie.

Une PME n’a pas besoin d’attendre ce futur pour rencontrer le problème. Il suffit qu’un agent interne appelle l’agent d’un fournisseur, qui appelle lui-même un service tiers. À qui appartient l’erreur du dernier appel ? Quel agent pouvait voir la donnée personnelle ? Qui conserve la trace ? Quel mandant peut révoquer la chaîne entière ?

« Compatible » ne veut pas dire « responsable ». Un protocole commun permet l’échange. Il ne décide pas à lui seul qui peut promettre quoi au nom de qui.

Tester les liaisons, pas seulement les postes

Une évaluation multi-agent devrait commencer par le graphe réel du système. Chaque nœud représente un agent ou un outil. Chaque liaison indique ce qui circule, sous quelle identité et avec quel droit. Chaque action externe porte un point d’arrêt explicite.

Ensuite viennent les essais qui manquent aux démonstrations linéaires.

On donne au premier agent une donnée plausible mais fausse et l’on regarde où son statut change. On fait taire un agent intermédiaire. On ralentit un outil. On renvoie deux résultats contradictoires. On injecte une instruction dans un document transmis. On révoque une permission pendant la séquence. On force un dépassement de budget. On remplace une réponse structurée par du texte libre. On demande au superviseur d’expliquer non seulement la décision finale, mais les refus et les abandons.

OWASP recommande des frontières de confiance entre agents, la validation des messages, l’isolation des environnements et des coupe-circuits contre les cascades. Le coupe-circuit est particulièrement révélateur. Il oblige l’équipe à définir combien d’échecs, de répétitions, d’appels ou d’euros elle accepte avant d’arrêter. Sans lui, la persévérance ressemble à de l’autonomie jusqu’à ce que la facture ou l’incident arrive.

Le test doit enfin être rejouable. Il faut conserver la version des modèles, les instructions, les outils, les messages échangés, les validations humaines, les décisions d’arrêt et les sorties. Si le résultat ne peut pas être reconstruit, la multiplication des agents a surtout multiplié les endroits où l’explication se perd.

La spécialisation doit laisser une frontière

Il existe de bonnes raisons d’utiliser plusieurs agents. Un agent en lecture seule peut explorer une base sans recevoir le droit d’écrire. Un autre peut vérifier une somme avec un outil déterministe. Un troisième peut préparer une action, tandis qu’une règle indépendante ou un humain l’autorise. La séparation réduit alors réellement une permission, un contexte ou une capacité.

Il existe aussi de mauvaises raisons. Créer cinq rôles parce qu’un canevas de démonstration en propose cinq. Dupliquer le même modèle pour obtenir un débat. Ajouter un superviseur qui ne voit que les résumés produits par les agents qu’il supervise. Transformer une fonction déterministe en agent pour conserver l’esthétique de l’ensemble.

La question à poser à chaque nouveau rôle est brutale : quelle frontière disparaîtrait si cet agent était fusionné avec le précédent ? Si la réponse est « aucune », le rôle ajoute peut-être du théâtre, de la latence et du coût, mais peu d’architecture.

Le contrepoint d’ARIA mérite d’être pris au sérieux. Son programme Scaling Trust, doté de près de 50 millions de livres, veut construire des outils ouverts, une arène adversariale et des fondations théoriques pour permettre aux agents de coordonner, négocier et vérifier de façon sûre. Une infrastructure de confiance commune pourrait effectivement rendre possibles des coopérations que des intégrations fermées ou manuelles rendent trop chères.

Mais l’existence même de ce programme dit où nous en sommes. L’infrastructure est en construction. L’arène doit encore éprouver les mécanismes. Les garanties recherchées ne sont pas des propriétés acquises des produits actuels.

L’équipe commence au bouton d’arrêt

Une architecture multi-agent mûre ne se reconnaît pas au nombre de bulles dans son schéma. Elle se reconnaît à ses liaisons nommées, à ses permissions séparées, à ses erreurs injectées et à sa capacité d’arrêter la chaîne sans laisser d’action orpheline.

Il faut pouvoir répondre simplement : quel agent sait quoi, quel agent croit quoi, quel agent peut faire quoi, qui vérifie la transmission et qui reprend lorsque la séquence casse. Si ces réponses changent selon la démonstration, l’organisation n’existe pas encore.

La promesse des agents en groupe est séduisante parce qu’elle emprunte le vocabulaire du travail collectif. Recherche, débat, critique, délégation, supervision. Les mots portent des siècles d’institutions humaines : responsabilités, conflits, métiers, confiance, recours. Les appliquer à des appels de modèles ne transfère pas ces institutions avec eux.

Plusieurs agents peuvent accomplir davantage qu’un seul. Ils peuvent aussi rendre l’erreur plus longue, plus crédible et plus difficile à attribuer.

Une équipe n’est pas une collection de voix. C’est un système de frontières et de reprises. Pour les agents IA, elle commence moins par le premier prompt que par le premier passage que l’on sait refuser — et le bouton qui arrête tout le reste.