MCP standardise le format de communication. Il ne standardise ni l'auteur, ni l'autorité, ni la responsabilité, ni le règlement des différends. Une couche de gouvernance doit être la partie qui survit à tout transport — l'institution sous le protocole, pas le protocole lui-même.
Le Model Context Protocol est un transport puissant, adopté rapidement — et un transport est exactement ce que son nom promet. MCP nous donne une grammaire commune pour les appels d'outils entre agents et ressources. MCP ne nous dit pas qui a le droit de faire quoi, selon quelles règles, avec quelles conséquences, ni comment les différends sont réglés lorsque les choses tournent mal.
AxoneOS considère MCP comme un transport. AxoneOS ajoute l'institution : les Zones comme ensembles de règles juridictionnelles délimitées, Pactum comme mécanisme de règlement on-chain opposable, et une piste auditable ancrée par IBC qui enregistre chaque acte et ses effets. Pour la surface complète destinée aux développeurs, consultez docs.axone.xyz. Retrouvez aussi le hub de recherche en français et la bibliothèque des régimes.
MCP déplace des octets et des arguments. AxoneOS décide si ces mouvements sont autorisés, les enregistre on-chain et donne à chaque contrepartie une règle de référence ainsi qu'une voie de recours. Voici les primitives architecturales sur lesquelles repose cette couche.
Les Zones sont des régimes Prolog façonnés par une juridiction — la règle et sa frontière — opérés par des opérateurs identifiables et répliqués via IBC. Un acte adressé à une Zone peut être décidé selon les règles du régime, avec des effets réglés on-chain. La bibliothèque française des régimes présente les modèles correspondants.
Pactum est la famille de contrats Solidity qui rend ces effets opposables : une contrepartie peut toujours pointer vers une règle publiée, une piste de preuves et un résultat réglé. Les différends ne sont pas une conversation — ce sont des vérifications.
La piste auditable ancrée par IBC est la partie qui survit à tout transport. Remplacez MCP demain et la piste répond toujours à qui a fait quoi, dans quelle Zone, avec quelles preuves.
MCP est traité comme un transport : un excellent transport actuel. L'architecture part du principe que le fil change — l'institution, elle, ne change pas. Pour la surface développeur et les SDK de référence, consultez docs.axone.xyz.
Deux articles — l'un en anglais, l'autre en français — développent l'argument de bout en bout. Tous deux aboutissent à la même conclusion : MCP est nécessaire, mais ne suffit pas.
MCP permet aux agents de parler aux outils. Axone permet aux agents de conclure des accords, d'échanger de la valeur et de coopérer sous des règles exécutoires.
Lire l'article EN →MCP permet aux agents d'appeler des outils. Il ne leur permet pas de conclure un accord, d'échanger de la valeur, ni de coopérer sous des règles opposables. C'est la couche manquante, et c'est ce qu'Axone ajoute.
Lire l'article FR →Le blog est la surface publique de recherche consacrée à la gouvernance et à l'architecture d'AxoneOS. Poursuivez avec les deux textes longs ci-dessus — ou consultez le hub de recherche en français.