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 sept outils :
- verify_product : statut d'authenticité d'un produit (authentique, révoqué, expiré, trouvé sans certificat actif, 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, référence on-chain sur Base avec son lien basescan.org, qui porte la racine de Merkle du lot quand le lot a été ancré et sinon la seule opération de frappe du produit, laquelle établit que le jeton existe et rien du contenu du passeport, ancrage du hash du passeport lui-même dès que le balayage horaire est passé, statut du credential et nombre de vérifications physiques réussies, toute preuve absente étant omise plutôt que rendue vide ;
- get_certificate : le certificat d'authenticité public ;
- resolve_gs1 : résolution d'un GS1 Digital Link vers un passeport, celui de l'article avec un numéro de série, celui du modèle sans, ce que réclament les produits vendus au mètre, à la boîte ou à la palette ;
- verify_credential : vérification du SD-JWT-VC du passeport contre la clé de signature
did:webde la marque ; - get_product_history : la chronologie de l'article, vérifications et transferts de propriété, du plus ancien au plus récent.
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, et le guide complet, périmètre, branchement, choix de l'identifiant et les sept outils un par un, est dans notre documentation technique.
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, puis demander le faisceau de preuves, qui porte l'empreinte du contenu complet du passeport et, lorsqu'ils sont disponibles, l'ancrage sur Base et la copie IPFS épinglée, et enfin, quand la marque a émis un credential signé, le vérifier lui-même contre la clé did:web publiée. 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, réparateurs et recycleurs accrédités, acteurs amont, autorités de surveillance du marché, restent derrière l'authentification, comme le prévoit notre propre modèle d'accès. 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 : eur-lex.europa.eu
- Méthodologie DPP du Centre commun de recherche de la Commission (JRC145830, annexe 8), rapport scientifique sans valeur juridique dont sont issus nos niveaux d'accès. Le règlement, lui, n'en fixe aucun.
