Résumé
- La révision du 5 septembre du projet individuel RMRP ajoute une Routing Completeness Attestation (RCA) : pour une période donnée, le moteur signe le nombre d’événements traités et le nombre de traces écrites. Le texte reste un Internet-Draft, pas une norme ni une preuve de déploiement.
- Une preuve de Merkle et un ancrage externe protègent les entrées qui existent. Si un appel est exécuté sans jamais devenir une entrée, aucun hash ne peut signaler son absence. RMRP reconnaît que sa RCA « ne prouve pas la complétude ».
- La comparaison avec la facturation du fournisseur apporte un dénominateur indépendant. Elle peut faire apparaître une dépense sans trace interne, à condition d’aligner compte, période, modèle et périmètre avant d’interpréter l’écart.
Un comité reçoit un chiffre rassurant : 50 000 décisions de routage d’IA, 50 000 lignes d’audit, une racine de Merkle signée et déposée chez un tiers. Il peut vérifier que la ligne numéro 31 742 appartient bien à l’ensemble publié. Il ne sait toujours pas si un cinquante-mille-et-unième appel a emprunté une clé directe et n’a produit aucune ligne.
Cette asymétrie est au cœur de la révision 01 du Reilly Model Routing Protocol. Le document de L. J. Reilly, daté du 5 septembre et visé comme Informational, propose un cadre de politique, de routage, d’audit et de coûts pour des environnements multi-modèles. Son état I-D Exists signifie qu’il s’agit d’un travail en cours. Ce n’est ni un RFC, ni un consensus de l’IETF, ni un certificat de conformité.
Le texte 01 ajoute au texte 00 les signatures, les engagements de champs, les budgets agrégés, les preuves d’inclusion, les points de contrôle externes, la révocation, les niveaux de conformité et la réconciliation des coûts. L’apport le plus utile est conceptuel : ne pas confondre authenticité d’une trace, appartenance à un ensemble, exhaustivité de l’ensemble et concordance avec le monde extérieur.
Une signature engage une déclaration, pas la réalité entière
La forme canonique de RFC 8785 et la signature JSON de RFC 7515 permettent à un tiers de vérifier les octets signés. Si un résultat, une politique ou un coût est modifié après signature, la vérification échoue. C’est une propriété forte et bornée.
La chaîne de hash rend visible une rupture dans une séquence connue. L’arbre de Merkle inspiré de Certificate Transparency permet de vérifier l’inclusion d’une trace sans télécharger des millions d’entrées. Une preuve de cohérence montre qu’un arbre ultérieur prolonge l’ancien.
Mais toute cette mécanique commence après la décision de créer une trace. Si le moteur appelle un modèle puis supprime à la fois l’Audit Log Record et le Cost Attribution Record, l’arbre restant peut être parfaitement valide. Il atteste fidèlement un sous-ensemble incomplet.
La complétude exige donc un dénominateur : combien d’événements pertinents ont réellement eu lieu ? Le producteur du journal peut annoncer ce nombre, mais cette annonce demeure une affirmation du même système. Une source indépendante doit pouvoir contredire ce total.
L’ancrage extérieur fige une histoire, pas sa population
RMRP formule une limite rarement écrite aussi nettement : une racine signée par l’opérateur qui contrôle aussi le stockage ne borne rien que cet opérateur ne puisse modifier. Le projet propose de publier périodiquement la racine auprès d’une cible hors de son contrôle administratif. Un dépôt d’archives, un service d’horodatage ou un autre journal peut alors témoigner de l’état reçu.
Une cible encore PENDING ne doit pas être présentée comme attestée. Plusieurs cibles augmentent le coût d’une falsification rétroactive sans rendre les données « immuables ». L’intervalle compte également : entre deux dépôts, la fenêtre d’altération demeure ouverte.
Cet extérieur est indépendant pour la garde de la racine, non pour le recensement des appels. Publier très solidement la racine d’un ensemble auquel manque une entrée préserve très solidement cette omission. Un conseil d’administration doit donc demander : indépendant de quoi, et témoin de quel fait ?
La RCA rend le mensonge attribuable
Au niveau C3, le routeur doit émettre une RCA pour une fenêtre UTC. Elle contient l’identité du moteur, le nombre total d’événements traités, le nombre de traces, leur répartition par résultat et par niveau de modèle, la racine correspondante, l’identifiant de la RCA précédente et une signature. Toute différence entre événements et traces appelle une explication. La chaîne des RCA révèle aussi une période manquante.
Le projet exige une clé du moteur distincte de celle de l’autorité de politique. Deux clés limitent la confusion cryptographique des rôles ; elles ne prouvent pas que deux personnes ou deux organisations les détiennent. Le modèle de menace reconnaît qu’un protocole ne peut imposer la séparation humaine.
Surtout, RMRP qualifie la RCA de déclaration du système audité sur sa propre exhaustivité. Elle ne prouve pas cette exhaustivité. Un opérateur prêt à omettre puis à signer un faux total n’est pas empêché. Il laisse toutefois un objet daté et attribuable, susceptible d’être confronté à d’autres preuves.
Ce déplacement a une valeur de gouvernance. Une interface non signée peut être réinterprétée après coup comme une requête mal cadrée. La RCA fixe la période, l’identité, les comptes et la succession revendiqués. Dans la logique de RFC 9334, elle reste une preuve à évaluer selon une politique ; elle n’est pas elle-même le verdict de confiance.
La facture voit parfois ce que le routeur ne voit pas
La Cost Reconciliation Record compare les coûts consignés en interne avec ceux que le fournisseur de modèles rapporte pour la même période et le même périmètre. Le champ de dépense non attribuée vise le cas précis où le fournisseur a facturé une inférence sans Cost Attribution Record correspondant.
Le projet dit que cette réconciliation est son seul contrôle capable de détecter une inférence entièrement passée hors du moteur. La causalité est solide : le fournisseur produit sa mesure de l’autre côté de l’appel. Une équipe utilisant une clé directe peut donc disparaître du journal interne tout en restant visible dans le compte fournisseur.
La facture n’est pas une vérité parfaite. Fuseaux horaires, retards de remontée, retry, cache de jetons, arrondis, tarifs engagés ou identifiants partagés créent des écarts honnêtes. Il faut comparer nombre de requêtes et coût, compte et clé, modèle et région, période UTC et centre de coûts. Un écart ouvre une enquête ; il ne prouve pas à lui seul une fraude.
Les niveaux C2, C3 et C4 condensent ces garanties différentes. Dire « C4 » sans préciser la fréquence des ancrages, le gardien externe, le rythme de réconciliation et les tolérances transforme une liste de mécanismes en slogan. Les couches de réalité de Heng Lu imposent de garder séparés le projet de protocole, la déclaration de conformité, la RCA, le journal, le compte fournisseur et l’exécution observée. Leur concordance donne de la confiance ; aucune signature ne fusionne leurs pouvoirs.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
