Version condensée en français. La version complète en anglais —y compris la discussion sur la révocation ouverte par Alex Shev en commentaires— est la version canonique. Pourquoi en français L'Europe a une culture unique de souveraineté numérique et d'exigence réglementaire (DSP2, DORA, IA Act) — et pourtant, toute la conversation sur la confiance inter-agents se joue en anglais. Les équipes francophones qui construisent des agents IA se retrouvent à faire confiance à des verdicts qu'on ne leur explique pas comment auditer. Ce texte corrige ça : ce que Visa et Mastercard ont lancé, ce qu'elles ne donnent pas, et ce que vous pouvez vérifier vous-même, aujourd'hui, avec des URLs publiques. Ce qui vient de se passer En 2026, les réseaux de paiement ont arrêté de parler de « agent commerce » dans l'abstrait et ont commencé à publier des spécifications : Visa a publié le Trusted Agent Protocol (TAP) : repo ouvert avec spec et implémentation complète (registre d'agents, backend et frontend marchand, agent vivant). Chaque requête d'agent porte une signature cryptographique avec horodatage, session ID unique, identifiant de clé et algorithme — liée au domaine du marchand et à l'opération précise, sans rejeu possible. Mastercard a lancé Verifiable Intent (VI) : le marchand valide la créance d'intention signée en temps réel dans le flux d'autorisation, avant que l'argent ne bouge. Autour : x402 (Coinbase → Linux Foundation) et AP2 (Google + Visa + Mastercard + PayPal + ~60 partenaires). Quand les entreprises qui déplacent la majeure partie de l'argent du monde construisent la même couche en même temps, ce n'est pas une tendance — c'est une validation. L'infrastructure de confiance entre agents est devenu structurant. La brèche que personne ne couvre Ce qu'un tiers ne peut pas faire avec ces protocoles : Auditer le vérificateur. Comment savoir que la chose qui dit « cet agent est fiable » n'est pas corrompue, patchée, ou en train de mémoriser les réponses ? Dans un protocole de réseau, on fait confiance au verdict parce qu'on fait confiance au réseau. Circulaire. Reproduire la créance. Un externe peut-il reconstruire l'artefact depuis des octets publics et obtenir le même résultat, bit à bit ? Trouver une preuve immuable. Où est le registre append-only, hébergé par un tiers, prouvant ce qui a été publié et quand — et que même l'éditeur ne peut pas réécrire ? La différence en une ligne : TAP et VI donnent à un agent la permission de transiger à l'intérieur d'un réseau. Une ATC donne à n'importe qui une preuve vérifiable en dehors de tout réseau — hors ligne, sans adhésion, sans clé API. L'analogie : les réseaux délivrent le permis de conduire. Nous publions les dossiers de justice — vérifiables par n'importe quel inconnu, scellés dans un journal public que personne ne peut éditer. Le commerce a besoin des deux. Les trois leçons que nous avons adoptées De Visa : la fraîcheur doit être bilatérale et dérivée des octets. Notre runner de référence impose une fenêtre de validité bilatérale — issued_at <= NOW < expires_at. Une carte datée dans le futur (notre vecteur premature-atc, émis le 2030-01-01) échoue exactement comme une carte expirée. Et la vérification dérive des octets de la carte, pas d'une métadonnée latérale : un sidecar menteur ou supprimé ne peut pas inverser le verdict. De Mastercard : la vérification appartient au flux — la nôtre tourne hors ligne. Une ATC se vérifie hors ligne en quelques millisecondes : une vérification Ed25519 contre des ancres épinglées, zéro appel réseau, zéro clé API, zéro adhésion. La vérification dans le flux sans demander la permission au flux. Des deux : un registre, mais append-only et hors de notre contrôle. Chaque release de notre suite de conformance est contresignée et ancrée dans Rekor, le journal public de transparence de Sigstore. L'entrée #3 (logIndex 2764479676) porte les condensés de toute la suite v1.3.3. Si nous tentions de réécrire l'histoire en silence, le journal nous contredirait. Les reçus (tout vérifiable par un inconnu, URLs vivantes) Suite de conformance : 14 vecteurs + 24 vérifications comportementales + 10 mutants qui doivent être attrapés — https://www.marketnow.site/uta/conformance/ Build reproductible : le tarball publié sur npm se reconstruit octet par octet depuis la source publique — https://www.marketnow.site/uta/conformance/repro/ Ancres Rekor : 3 entrées immuables, vérifiables avec 9 contrôles — https://www.marketnow.site/uta/conformance/anchors/ Code : https://github.com/alicelabs-llc/universal-trust-adapter Le bug qui a motivé le v1.3.3 a été trouvé par un inconnu qui exécutait nos propres outils contre nous. Ce n'est pas un embarras — c'est le produit qui fonctionne. Conclusion honnête Les géants vont gagner la couche de permission du commerce inter-agents — c'est à ça que servent les réseaux. Ce que nous construisons, c'est la pièce que les réseaux ne vendent pas structurellement : une preuve qui n'exige pas de faire confiance au vendeur. Quand une entreprise demande « qui audite les auditeurs ? », la réponse ne peut pas être « les auditeurs ». Elle doit être : n'importe qui peut, et voici les commandes. Ils ont validé la couche. Nous, on garde les reçus. — AliceLabs / MarketNow · marketnow.site · UTA sur GitHub