La couche vraiment manquante : pourquoi MCP ne suffit pas pour les systèmes multi-agents

MCP mérite le crédit qu'on lui donne

Le Model Context Protocol a fait quelque chose de rare dans cette industrie. Il a résolu le bon problème au bon moment. Avant MCP, toute équipe qui voulait qu'un agent IA appelle un outil externe devait écrire une intégration sur mesure. Des centaines d'intégrations, toutes légèrement différentes, toutes cassées le mardi. MCP a remplacé cela par une interface propre et bien spécifiée. Le monde a raison de célébrer ce protocole, et l'équipe d'Anthropic qui l'a livré mérite un vrai crédit.

Mais MCP a résolu le problème d'un agent qui appelle un outil à l'intérieur d'un seul processus. Il a standardisé la manière dont un modèle unique atteint un environnement unique. C'est le problème pour lequel il a été conçu, et il le résout très bien.

Le problème que nous avons aujourd'hui est différent.

Le problème que nous avons aujourd'hui se pose entre plusieurs agents, plusieurs outils, plusieurs organisations, avec des conséquences. Et ce n'est pas du tout le même problème.

Ce que MCP est, et ce qu'il n'est pas

Soyons précis. MCP offre à chaque agent un moyen de :

• Découvrir quels outils existent.
• Inspecter le schéma et les paramètres d'un outil.
• Invoquer l'outil et obtenir une réponse structurée.
• Négocier les permissions via une application hôte.

C'est exactement la liste de ce dont un agent a besoin pour appeler une fonction. MCP coche cette liste. Si vous construisez un assistant IA qui doit lire votre agenda, interroger votre CRM et récupérer vos e-mails, MCP est le bon outil. Il restera le bon outil pour ce travail.

Mais MCP est silencieux sur les questions qui se posent dès que vous avez deux agents qui ne partagent pas le même hôte :

• Que peut faire cet autre agent, sous quelles règles, avec quelles preuves ?
• S'il fait quelque chose de travers, qui s'en aperçoit, qui peut le prouver, et qu'est-ce qui se passe ensuite ?
• Si je lui envoie un paiement ou je m'engage sur une ressource, quelles garanties ai-je ?
• Si nous nous sommes mis d'accord sur un prix hier, qu'est-ce qui l'empêche de changer le prix pendant la nuit ?

Aucune de ces questions n'est une question d'appel de fonction. Ce sont des questions de coordination. Des questions de gouvernance. Ce sont les questions qui décident si l'économie des agents passe à l'échelle ou s'effondre.

L'épine du problème

Retirons l'enrobage marketing et la situation est honnêtement simple :

MCP permet aux agents de communiquer. Axone leur permet de conclure des accords, d'échanger de la valeur et de coopérer selon des règles vérifiables.

La communication est nécessaire. Elle n'est pas suffisante. Chaque protocole qui a jamais passé à l'échelle, de TCP à HTTP en passant par SWIFT, a répondu aux deux moitiés de cette phrase. La pile agentique d'aujourd'hui n'a que la première moitié.

Ce dont un vrai système multi-agents a réellement besoin

Si vous construisez un système où deux agents autonomes échangent de la valeur ou engagent des ressources partagées, vous avez besoin de choses que MCP ne peut pas vous donner :

• Des règles déclaratives. Les règles qui gouvernent une interaction doivent être inspectables, et non cachées dans les poids d'un modèle ou dans sa fenêtre de contexte.
• Une exécution vérifiable. Les deux parties ont besoin d'une preuve cryptographique que ce qui s'est passé est ce qui était censé se passer.
• Une résolution des litiges. Quand les interprétations divergent, il doit y avoir un arbitre externe, et non un nouveau prompt du modèle.
• Une continuité d'identité. Le même agent demain doit être le même agent aujourd'hui, et la réputation doit s'accumuler d'une session à l'autre.
• Un règlement. Quand les conditions sont réunies, la valeur doit bouger automatiquement, sans comptable dans la boucle.

Ce ne sont pas des « nice to have ». C'est le plancher. Sans elles, chaque interaction multi-agents est un coup d'essai enveloppé dans la politesse.

Comment Axone complète MCP

Axone n'est pas un concurrent de MCP. Il est ce qui se tient à côté de MCP. MCP reste la bonne réponse à l'intérieur du périmètre d'un agent unique. Axone est la bonne réponse quand les agents doivent s'engager les uns envers les autres.

Concrètement, Axone fournit :

• Les Zones, des environnements de gouvernance programmables où un groupe d'agents et d'humains partagent des règles explicites définies en Prolog.
• Law-Stone, un moteur de règles déterministe qui évalue chaque acte au regard du régime en vigueur au moment de l'acte, avec une trace vérifiable on-chain.
• Pactum, une couche de règlement qui transforme des conditions remplies en transferts de valeur automatiques, sans intermédiaires.
• Le Dataverse, une couche sémantique qui permet à des agents hétérogènes de se trouver, de se faire confiance et de composer leurs services sans registre central.

Un agent équipé de MCP appelle un outil. Un agent équipé d'Axone s'inscrit dans un régime, en accepte les conséquences, et peut y être tenu. C'est la différence entre un coup de téléphone et un contrat, et l'économie des agents aura besoin des deux.

Ce qui ne passe pas à l'échelle

La réponse actuelle à « comment les agents coopèrent-ils aujourd'hui ? » est en gros : ils ne coopèrent pas vraiment. Ils échangent des prompts. Ils s'appellent via des API. Ils espèrent. Quand quelque chose se casse, ils ouvrent un ticket de support, ou ils attendent que l'éditeur du modèle livre un correctif.

Cela fonctionnait quand il y avait quelques agents. Cela ne fonctionnera pas quand il y aura des millions d'agents à négocier du calcul, de la donnée et du capital en temps réel.

L'économie des agents ne se construira pas sur la politesse. Elle se construira sur des règles que les deux parties peuvent lire, que les deux parties peuvent vérifier, et auxquelles les deux parties peuvent être tenues. C'est ce que gouvernance signifie, et c'est à cela qu'Axone sert.

MCP et Axone ne sont pas des alternatives. Ce sont des compagnons de pile. L'un déplace des messages ; l'autre déplace des engagements. Il faut les deux pour construire quoi que ce soit qui ait des conséquences.

Construire sur les deux

Si vous concevez aujourd'hui un système multi-agents, la vraie question n'est pas « MCP ou Axone ? ». Elle est : « comment laisser mes agents utiliser MCP pour ce qu'il fait le mieux, et laisser Axone porter les règles, les preuves et les flux de valeur que MCP ne peut pas porter ? ».

Concrètement, cela signifie :

• Utilisez MCP pour la découverte et l'invocation d'outils à l'intérieur d'un seul agent.
• Enveloppez chaque interaction qui mérite un engagement dans une Zone avec des règles explicites.
• Utilisez Law-Stone pour évaluer chaque acte, on-chain, avec une trace vérifiable.
• Utilisez Pactum pour régler automatiquement tout flux conditionnel.

Le résultat est un système d'agents qui n'est pas seulement capable, mais responsable. Et la responsabilité, c'est ce que cette industrie va devoir livrer, aux régulateurs, aux partenaires, et finalement aux agents eux-mêmes.

Que faire maintenant

Si vous lisez ceci, vous construisez probablement un système d'agents, vous conseillez quelqu'un qui en construit un, ou vous essayez de déterminer dans quelle couche de la pile investir ensuite. La réponse honnête est : investissez dans les deux, dans le bon ordre.

Utilisez MCP pour l'interface agent-vers-outil. C'est excellent, c'est là, ça marche.

Utilisez Axone pour tout ce qui se passe quand l'appel d'outil doit signifier quelque chose : les règles, les preuves, les conséquences, le règlement.

L'économie des agents sera mesurée non pas à la fluidité des prompts, mais à la force de leurs engagements. La pile de protocoles qui passera à l'échelle sera celle qui connaît la différence.

La prochaine décennie de l'IA ne sera pas gagnée par le modèle le plus intelligent. Elle sera gagnée par l'architecture qui permettra aux agents intelligents de tenir leurs promesses.