Comment dpp.gs est conforme aux nouvelles normes DPP de l'UE (EN 18216–18223)

Pendant deux ans, le passeport numérique de produit n'était défini que par la réglementation — l'ESPR exige un passeport, sans dire quelle forme il doit prendre au niveau des données. Cette lacune a été comblée en mai 2026, quand le comité CEN/CENELEC JTC 24 a publié les premières normes DPP : la série EN 18216–18223. Cet article met en correspondance dpp.gs avec chacune.

Pourquoi c'est important : l'ESPR (règlement (UE) 2024/1781) rend le passeport obligatoire. Les normes EN indiquent à tout autre système — recycleurs, douanes, places de marché, autorités — comment le lire. Un passeport que seul votre visualiseur ouvre n'est pas interopérable. La conformité à la série EN le rend portable.

La série EN 18216–18223 en un coup d'œil

Le JTC 24 a découpé le problème en couches. Chaque norme régit un aspect, et un passeport conforme doit répondre à toutes :

Norme	Aspect	Comment dpp.gs le met en œuvre
EN 18219	Identifiants uniques	GS1 Digital Link — chaque passeport est une URI résolvable `https://dpp.gs/01/{GTIN}`, avec lot (`/10/`) et série (`/21/`) en option.
EN 18220	Supports de données	Code QR (encode l'URL Digital Link complète) et GS1 DataMatrix avec FNC1 — générés pour chaque produit.
EN 18216	Protocoles d'échange	Récupération via HTTPS avec négociation de contenu : le téléphone reçoit du HTML, un système du JSON ou JSON-LD depuis la même adresse.
EN 18222	API de cycle de vie et de recherche	API `/dpp/v1` versionnée : rechercher des passeports par identifiant, opérateur, code douanier, secteur ou statut ; récupérer un passeport ; interroger le cycle de vie.
EN 18223	Interopérabilité des systèmes	JSON-LD basé sur schema.org + le vocabulaire GS1 + un espace de noms dpp.gs — le passeport est un graphe sémantique lisible par machine, pas un formulaire.
prEN 18246	Authentification et intégrité	Les passeports peuvent être émis comme W3C Verifiable Credentials, signés en Ed25519 (`vc+jwt`), vérifiables hors ligne — sans blockchain.

1. Identité et supports : GS1 Digital Link (EN 18219 / EN 18220)

Tout commence par l'identifiant. dpp.gs n'invente jamais d'ID propriétaire — il utilise le GTIN que vous possédez déjà, exprimé en GS1 Digital Link. Cette seule décision satisfait deux normes à la fois : la couche identifiants (EN 18219) et la couche supports (EN 18220). Le même code scanné par un client en magasin est lu par le scanner douanier à la frontière.

2. Récupération et recherche : une adresse, plusieurs formats (EN 18216 / EN 18222)

L'EN 18216 concerne comment un passeport est récupéré, et l'EN 18222 comment les passeports sont trouvés et comment leur cycle de vie est interrogé. dpp.gs répond aux deux depuis un seul endroit :

Récupération — GET /dpp/v1/passports/{GTIN} renvoie le passeport complet en JSON-LD (ou JSON).
Recherche — GET /dpp/v1/passports?sector=textile&operator=… trouve les passeports par identifiant, opérateur, code douanier, secteur ou statut, avec pagination.
Cycle de vie — GET /dpp/v1/passports/{GTIN}/lifecycle indique le statut d'enregistrement et les dates clés.

3. Un modèle de données sémantique, pas un export de formulaire (EN 18223)

L'interopérabilité échoue dès que deux systèmes divergent sur le sens d'un champ. L'EN 18223 pousse vers les données liées, et dpp.gs sert chaque passeport en JSON-LD : un graphe schema.org Product, étendu par le vocabulaire GS1 et un espace de noms dpp:. Le @context est structuré pour pouvoir pointer plus tard vers l'ontologie CIRPASS sans changer la forme des données.

4. Confiance : Verifiable Credentials signés (prEN 18246)

Le projet de norme sur l'authentification pose une question difficile : comment un recycleur, un douanier ou un consommateur sait-il qu'un passeport est authentique et inaltéré ? dpp.gs y répond par la cryptographie ouverte, pas par un registre. Chaque passeport peut être émis comme W3C Verifiable Credential, signé avec une clé Ed25519 sous forme de vc+jwt compact. Chacun récupère la clé publique de l'émetteur depuis /.well-known/jwks.json et vérifie la signature hors ligne — sans blockchain.

5. Préparation au registre (ESPR art. 12–13)

Outre la série EN, l'ESPR impose un registre DPP de l'UE central qui enregistre un petit ensemble d'identifiants obligatoires par passeport. dpp.gs capture déjà ces champs pour chaque produit et les tient prêts dès que le registre de la Commission sera en ligne. Ce jour-là, l'enregistrement est un interrupteur, pas une migration.

Note honnête sur le statut : la série EN 18216–18223 est toute récente (mai 2026) et prEN 18246 reste un projet ; certaines annexes et l'API du registre de l'UE elle-même sont en cours de finalisation. Nous suivons leur évolution. Nous ne prétendons pas détenir un certificat qui n'existe encore pour personne — mais nous montrons une plateforme bâtie sur les mêmes standards ouverts (GS1 Digital Link, JSON-LD, W3C VC, OpenAPI) sur lesquels repose la série EN elle-même.

Ce que cela signifie pour vous

En émettant des passeports sur dpp.gs, vous ne pariez pas sur un format propriétaire que les normes pourraient contredire plus tard. Vous émettez des identifiants GS1 Digital Link, des données JSON-LD, des supports QR + DataMatrix et, en option, des credentials signés — exactement les briques vers lesquelles convergent les normes européennes.

Émettez un passeport conforme aux normes dès aujourd'hui

GS1 Digital Link, JSON-LD, credentials signés et une API de recherche — gratuit pour vos 2 premiers GTIN.

Commencer gratuitement →