Le Model Context Protocol a résolu l'appel d'outils. Il n'a pas résolu qui a le droit d'appeler quoi, qui règle quand deux agents se disputent un résultat, ou comment un troisième agent découvre que les deux premiers méritent confiance. MCP est le transport ; AxoneOS est la couche en dessous qui transforme le transport en économie gouvernée.

Ce Que MCP a Apporté, et Là Où Il S'arrête

Le Model Context Protocol est un contrat propre : un client, un serveur, une interface JSON-RPC, un manifeste d'outils. Quiconque a intégré un serveur MCP dans Claude ou Cursor a senti à quel point les frictions disparaissent une fois le protocole en place. Découverte, négociation de schéma, invocation fonctionnent comme prévu. Le web agentique a enfin un format de wire.

Le problème de second ordre est plus difficile. Deux agents compatibles MCP peuvent appeler les outils l'un de l'autre. Ils ne peuvent pas répondre à trois questions que tout déploiement réel pose en quelques minutes :

  1. Autorisation. Quel agent est autorisé à invoquer quel outil, sous quelle juridiction, chaîne d'évidence, ou accord de niveau de service ?
  2. Règlement. Quand un agent paie un autre agent pour un résultat, quel rail porte la valeur, qui arbitre un désaccord, et qu'est-ce qui rend le désaccord définitif ?
  3. Confiance de découverte. Quand un troisième agent rencontre les deux premiers, qu'est-ce qui lui fait croire que leurs actes passés et leur statuts sont réels, plutôt qu'une affirmation auto-attestée ?

MCP lui-même ne répond à aucune de ces questions. Il spécifie un transport, pas un régime. Le protocole peut parfaitement transporter un appel d'outil attesté ; il ne peut pas, par lui-même, attester que l'appel a été autorisé. C'est pour cela que la couverture MCP récente ressemble soit à de la plomberie pure, soit à des gestures vagues vers des couches de confiance qui n'existent pas. La plomberie compte. La couche de confiance est ce qui manque. Pourquoi ce trou est structurel, et non un fix à court terme, est exposé dans Pourquoi MCP ne suffit pas.

AxoneOS Comme Couche de Gouvernance et d'Échange de Valeur Sous MCP

AxoneOS s'installe sous MCP, pas à côté. Un serveur MCP publie des outils sur JSON-RPC comme avant. Ce qui change, c'est que chaque acte au-dessus de ces outils — la requête, la réponse, le règlement, le litige, la mise à jour de réputation — devient une entrée dans un régime normatif. Le transport reste portable ; le sens d'un appel d'outil devient opposable.

Trois primitives rendent la couche concrète :

  • Des zones comme régimes Prolog. Chaque zone est un artefact typé : un programme Prolog, versionné par hash de contenu, instancié depuis un modèle, dont les règles décident quels actes deviennent opposables à l'intérieur. Les règles d'autorisation vivent dans la zone, pas dans le middleware du serveur MCP. Deux agents de part et d'autre d'un contrat découvrent la règle en interrogeant le régime, pas en faisant confiance au README de l'autre partie.
  • Pactum pour le règlement. Quand un acte médié par MCP est payé, disputé, ou annulé, la transition d'état résultante est committée sur Layer 1 via la couche Pactum. Le règlement n'est pas un callback webhook ; c'est un événement de chaîne que tout troisième agent peut auditer contre le régime qui l'a produit.
  • Le journal d'actes comme réputation portable. Les actes passés sont append-only, indexés par zone, et vérifiables par hash de contenu. La réputation voyage avec le journal d'actes, pas avec le tableau de bord d'un fournisseur. Un nouvel agent n'a pas besoin d'intégration privée pour évaluer un inconnu ; il lit le journal propre du régime.

Les serveurs MCP continuent d'évoluer sur leur propre feuille de route. AxoneOS ne fork pas MCP, ne le remplace pas, ne le rebadge pas. Le format de wire reste le format de wire. Ce qu'AxoneOS ajoute est la couche de système légal en dessous : le contrat, le tribunal, et les rôles de notaire public dont toute économie d'agents non triviale a besoin.

Régimes : Un Front-End Déployable Pour la Couche

La page Régimes (en ligne sur /regimes) est le visage concret de cette architecture pour les opérateurs qui ne veulent pas lire du Prolog avant d'expédier. Les Régimes sont l'unité déployable : un modèle typé, une fiche de paramètres, un build reproductible, et un artefact d'audit qu'une zone est autorisée à exécuter. La page expose la même machinerie décrite abstraitement plus haut comme une chose qu'on peut installer.

Pourquoi cela compte pour les déploiements compatibles MCP : un opérateur onboardant des agents MCP dans une charge de travail réelle ne peut pas s'arrêter à « le schéma d'outil est publié ». Il doit expédier un modèle de régime, choisir des valeurs de paramètres qui correspondent à sa posture de conformité, et faire en sorte que la zone résultante enregistre chaque acte médié par MCP contre la version qu'il a examinée. Régimes est l'unité qui rend ce workflow tractable. Plus la couche va profond, plus le registre sur chaîne compte ; l'histoire plus profonde de la chaîne d'évaluation Prolog derrière un appel de régime est couverte dans Pourquoi la gouvernance a besoin de Prolog, et l'histoire opérationnelle de pourquoi les régimes faits-main par locataire cessent de fonctionner est dans Industrialisation des zones.

Un Pattern Prolog : Pont MCP à Travers un Modèle de Régime

Le pattern ci-dessous est la plus petite expression de comment un régime pont-MCP se compile. Le modèle déclare les emplacements typés — identité du pair MCP, classe d'acte acceptée, rail de règlement — et une règle unique qui admet un appel médié par MCP dans le journal d'actes de la zone uniquement quand le régime a enregistré les deux extrémités et que le prédicat de politique passe.

prolog · Modèle de Régime — Pont MCP (AxoneOS)
% ============================================================
% MODÈLE DE RÉGIME — ZONE PONT MCP (AXONEOS)
% ============================================================

% --- EMPLACEMENTS DÉCLARÉS (remplis par le déployeur à l'instanciation) ---
slot(zone_id,             atom).
slot(politique_appelant,  atom).
slot(rail_reglement,      atom).

% --- REGISTRE PAIRS MCP (rempli par déployeur, attesté à l'instanciation) ---
pair_mcp(Zone, Appelant, Serveur) :-
    slot(zone_id, Zone),
    pair_atteste(Appelant, Serveur).

% --- ADMETTRE UN APPEL MÉDIÉ MCP DANS LE JOURNAL D'ACTES DE LA ZONE ---
admis(Zone, appel_mcp(Appelant, Serveur, Outil, Args)) :-
    slot(zone_id, Zone),
    slot(politique_appelant, Politique),
    pair_mcp(Zone, Appelant, Serveur),
    politique_autorise(Politique, Appelant, Outil),
    schema_outil_ok(Serveur, Outil, Args).

% --- APPEND L'ACTE, COMMITTABLE SUR LAYER 1 ---
opposable(Zone, appel_mcp(Appelant, Serveur, Outil, Args)) :-
    admis(Zone, appel_mcp(Appelant, Serveur, Outil, Args)),
    append_acte(Zone, appel_mcp(Appelant, Serveur, Outil, Args)).

% ?- opposable(zone_mcp_acme, X).
% X = appel_mcp(alice, resumeur_v2, resumer, [...])

Trois choses se passent en même temps. Premièrement, admis/2 est le prédicat de gouvernance : un appel MCP ne devient partie du régime que si le prédicat de politique à type d'emplacement en décide ainsi. Deuxièmement, opposable/2 écrit l'appel dans le journal append-only de la zone au moment où il est admis, ce qui rend l'appel auditable plus tard. Troisièmement, la requête ? montre le contrat d'exécution : un troisième agent peut demander au régime, en Prolog, si un appel MCP particulier est opposable, et la réponse est dérivée de la même règle que l'appelant a dû satisfaire. Le serveur MCP lui-même n'a pas besoin de savoir que tout cela se passe.

Survivre Au Transport

La raison pour laquelle AxoneOS doit survivre à MCP — ou à tout transport unique — est que les horizons de protocole sont courts. Le format de wire change. JSON-RPC se fait remplacer. L'équipe du protocole forge. La couche en dessous doit être stable à travers ces changements ou l'histoire de gouvernance se réinitialise toutes les quelques années. Faire du régime un artefact typé, versionné, hashé en contenu sur Layer 1 est ce qui rend la couche de gouvernance capable de survivre au transport qu'elle chevauche actuellement.

L'affirmation architecturale est simple : l'économie d'agents tournera sur plusieurs transports, possiblement incompatibles, et la couche qui choisit quel transport est autorisé pour quelle classe d'acte, sous quel régime, avec quelle histoire de règlement, ne doit pas être l'un de ces transports. AxoneOS est cette couche. Régimes est l'unité qu'une équipe plateforme expédie aujourd'hui. MCP est le protocole sur lequel elle expédie. La séparation est ce qui permet à l'histoire de gouvernance de survivre au churn de protocole que le web agentique s'apprête à traverser.

Conclusion

MCP est le format de wire. AxoneOS est la couche de gouvernance et d'échange de valeur en dessous. Le format de wire continuera à bouger ; la couche qui dit quel format de wire, sous quelles règles, avec quel règlement et quelle réputation, doit être la partie qui reste. Régimes (en ligne sur /regimes) est la forme déployable de cette couche. Des agents sur MCP, gouvernés par des zones, réglés sur Layer 1, découvrables à travers des journaux d'actes — c'est la forme architecturale qu'une économie d'agents compatible MCP doit prendre si elle veut être plus qu'un annuaire d'outils.