Une part croissante des questions produit ne passe plus par un moteur de recherche : elles sont posées à un assistant. « Ce sac est-il authentique ? » « Que contient cette batterie ? » « Cet article a-t-il un Passeport Numérique de Produit ? » Quand la personne qui pose la question tient le produit entre les mains, l'assistant a besoin de plus qu'une page web pour répondre : il lui faut un moyen d'interroger la preuve elle-même.
C'est ce que nous publions aujourd'hui. @sealtrust-io/mcp-server expose l'API publique de vérification de SealTrust sous forme de serveur Model Context Protocol (MCP) : tout agent compatible MCP (Claude Desktop, Claude Code et les autres) peut vérifier un produit et lire son passeport par lui-même. Le serveur est en lecture seule, ne travaille que sur des données publiques, et n'exige ni compte ni clé API.
Les agents IA deviennent des consommateurs de preuve produit
Jusqu'ici, les publics d'un passeport produit étaient des personnes et des institutions : le consommateur qui scanne une puce, le réparateur qui cherche une pièce, l'autorité de surveillance du marché qui contrôle la conformité. Un quatrième public arrive vite, les agents logiciels qui agissent pour le compte de quelqu'un. Un assistant qui accompagne un achat de seconde main, un outil achats qui passe des fournisseurs en revue, un bot interne qui prépare un dossier de conformité.
Ces agents ont un besoin précis : des réponses structurées et vérifiables. Une page marketing ne leur sert à rien ; un credential signé, un hash de contenu ou un ancrage on-chain, si : ils peuvent réellement les contrôler. Une preuve qu'un agent ne peut ni récupérer ni vérifier par programme n'existe tout simplement pas pour ce public. L'infrastructure que nous avons construite pour l'ESPR (endpoints publics, exports JSON-LD, credentials vérifiables, GS1 Digital Link) se trouve être exactement ce dont les agents ont besoin. Le serveur MCP est le connecteur qui manquait.
MCP, en deux mots
Le Model Context Protocol est un standard ouvert pour connecter les assistants IA à des outils et des sources de données externes. Un serveur déclare un ensemble d'outils aux entrées typées ; l'agent décide quand les appeler et raisonne sur les résultats. Le standard a largement dépassé son cadre d'origine et la plupart des plateformes d'agents sérieuses le parlent aujourd'hui.
Pour une marque, la conséquence pratique est simple : publier un serveur MCP, c'est rendre ses données utilisables par ce nouveau public, de la même façon que publier une API REST les a rendues utilisables par les développeurs.
Ce que le serveur SealTrust expose
Le serveur est une couche mince, en lecture seule, au-dessus des endpoints publics déjà documentés sur notre page développeurs. Il embarque six outils :
- verify_product : statut d'authenticité d'un produit (authentique, révoqué, expiré ou inconnu) avec ses informations publiques et le résumé du certificat ;
- get_passport : le Passeport Numérique de Produit publié, niveau d'accès public uniquement, en JSON ou JSON-LD ;
- get_passport_proof : le faisceau de preuves : hash SHA-256 des données du passeport, copie IPFS, ancrage on-chain sur Base avec son lien basescan.org, statut du credential ;
- get_certificate : le certificat d'authenticité public ;
- resolve_gs1 : résolution d'un GS1 Digital Link (GTIN + numéro de série) vers le passeport de l'article ;
- verify_credential : vérification du SD-JWT-VC du passeport contre la clé de signature
did:webde la marque.
L'installation tient en une commande, npx @sealtrust-io/mcp-server, ou en quelques lignes dans la configuration d'un client MCP. Les extraits exacts sont sur la page développeurs.
Trois situations où la réponse change
L'authenticité dans une conversation. Quelqu'un colle un numéro de certificat ou un identifiant produit dans un chat et demande si l'article est authentique. L'agent appelle verify_product et répond depuis le registre, y compris dans les cas inconfortables : un certificat révoqué est signalé comme tel, et un identifiant sans enregistrement revient « inconnu » plutôt qu'en supposition.
L'achat de seconde main. Avant d'acheter un article d'occasion, l'assistant de l'acheteur peut lire le passeport, vérifier que le certificat est actif et confirmer que le hash du contenu du passeport est ancré on-chain. Le discours du vendeur et le dossier du produit peuvent enfin être comparés, le temps de poser la question.
L'audit de conformité assisté. Les équipes qui préparent des dossiers ESPR peuvent laisser un agent récupérer les passeports en JSON-LD, vérifier les credentials et résoudre les GS1 Digital Links sur toute une gamme, les recherches répétitives d'un audit, effectuées par l'outil qui rédige déjà le document.
Ce qu'il ne fait volontairement pas
Le serveur ne sait que lire. Il n'émet que des requêtes GET vers des endpoints publics, rien de ce qu'il fait ne peut minter, transférer ou modifier un produit. Il ne voit que le niveau d'accès public d'un passeport : les niveaux restreints (chaîne de valeur, autorité) restent derrière l'authentification, exactement comme l'ESPR le prévoit. Et il ne manipule aucune donnée personnelle, il consulte des produits, pas des personnes.
Cette étroitesse est voulue. Une intégration que l'on peut confier à n'importe quel agent sans revue de sécurité des chemins d'écriture est une intégration qui se déploie vraiment.
Une preuve que les machines peuvent contrôler
Si cela fonctionne, ce n'est pas grâce au connecteur lui-même, c'est grâce à ce qui se trouve dessous. Chaque passeport SealTrust porte un hash SHA-256 de son contenu, peut être épinglé sur IPFS, est ancré sur Base L2 et peut être émis comme credential vérifiable signé. Ces propriétés ont été conçues pour que chaque affirmation soit vérifiable en toute indépendance. Les agents sont simplement le premier public qui vérifie systématiquement.
Envie que vos produits soient lisibles et vérifiables par les agents IA ? Parlons-en.
Sources
- Model Context Protocol, spécification et documentation : modelcontextprotocol.io
- Règlement (UE) 2024/1781 (ESPR), passeport numérique de produit et paliers d'accès : eur-lex.europa.eu
