--- title: "JSON-LD pour les passeports numériques de produits (et la place d'EPCIS 2.0) — qr3.app Blog" description: "Un DPP n" canonical: "https://qr3.app/fr/blog/dpp-json-ld-epcis/" lang: "fr" robots: "index,follow,max-image-preview:large,max-snippet:-1" --- # JSON-LD pour les passeports numériques de produits (et la place d'EPCIS 2.0) — qr3.app Blog > Un DPP n Canonical: [← Blog](/fr/blog/) [Tutoriels](/fr/blog/category/tutorials/) 30 mai 2026 7 min de lecture [Tutoriels](/fr/blog/category/tutorials/) [dpp](/fr/blog/tag/dpp/)[json-ld](/fr/blog/tag/json-ld/)[epcis](/fr/blog/tag/epcis/)[gs1-digital-link](/fr/blog/tag/gs1-digital-link/)[interoperability](/fr/blog/tag/interoperability/) # JSON-LD pour les passeports numériques de produits (et la place d'EPCIS 2.0) Un DPP n'est utile aux machines que s'il est lisible par les machines. Ce guide montre le véritable JSON-LD qu'un passeport qr3 expose via le résolveur en direct, comment une seule URL sert à la fois les humains et les machines grâce à la négociation de contenu, et où s'inscrit le standard d'événements complémentaire EPCIS 2.0. par **QR3 Redaktion** ![JSON-LD pour les passeports numériques de produits (et la place d](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-json-ld-epcis/hero.png) Un passeport numérique de produit est destiné à être lu par des personnes *et* par des machines : le système de réception d'un recycleur, une API douanière, le robot d'exploration d'une marketplace, le script d'un auditeur en développement durable. Une page HTML réservée aux humains ne suffit pas. Le passeport doit être **lisible par les machines** — une charge utile structurée qu'un programme peut analyser, relier et exploiter sans avoir à faire du scraping. Ce guide s'adresse aux développeurs qui se posent la question évidente suivante : *une fois que j'ai un DPP, comment une machine le lit-elle concrètement ?* La réponse pour qr3, c'est le JSON-LD servi par le résolveur public. Nous allons montrer la véritable réponse, expliquer comment la même URL sert les humains et les machines, puis replacer EPCIS 2.0 — le standard d'événements GS1 complémentaire — dans son contexte. ## Ce que signifie la lisibilité par les machines pour un DPP La lisibilité par les machines, c'est bien plus que « renvoyer du JSON ». Pour un passeport produit, cela suppose trois choses : - **Structuré** — des champs qu'un analyseur peut adresser (`gtin`, `name`, …), et non du texte à scraper. - **Typé et relié** — des termes ancrés dans des vocabulaires partagés, de sorte que `Product` ait la même signification pour tout le monde. C'est le *Linked Data* du JSON-LD. - **Stable à récupérer** — une URL durable par article, qu'un script peut interroger avec un `GET` pendant toute la durée de vie du produit. JSON-LD (JSON for Linking Data) apporte ces trois propriétés. C'est du JSON ordinaire auquel s'ajoute un `@context` qui associe chaque clé à un terme d'un vocabulaire public — ici [schema.org](https://schema.org) et le [GS1 Web Vocabulary](https://gs1.org/voc/). Un robot d'exploration qui comprend déjà schema.org comprend le passeport sans aucune intégration sur mesure. ## Le DPP sous forme de JSON-LD (vrai curl + réponse vérifiée) Chaque passeport qr3 se résout à une URL GS1 Digital Link : `https://qr3.app/dpp/{gtin}/{serial}`. Ajoutez `?format=jsonld` pour demander la vue Linked Data. Avec la démo de batterie en direct : ``` curl -s "https://qr3.app/dpp/09520000000011/DEMO-BAT-01?format=jsonld" ``` renvoie : ``` { "@context": ["https://schema.org", "https://gs1.org/voc/"], "@type": "Product", "gtin": "09520000000011", "name": "EcoMax 5000 (Demo)" } ``` Trois points à noter : - `@context` est un **tableau** de deux vocabulaires — schema.org pour le web en général et `gs1.org/voc/` pour les termes produits de GS1. Les clés se résolvent dans les deux. - `@type: "Product"` indique à tout consommateur de Linked Data exactement de quel type d'entité il s'agit. - Les valeurs (`gtin`, `name`) sont réelles et en direct — il s'agit de la charge utile effective, pas d'une maquette. C'est là tout l'intérêt : le script d'un recycleur n'a pas besoin d'un client spécifique à qr3. Il effectue un `GET` HTTP, analyse du JSON-LD qu'il comprend déjà, et lit directement le GTIN et le nom du produit. ## Une URL, deux publics : la négociation de contenu La même URL `https://qr3.app/dpp/{gtin}/{serial}` sert un passeport HTML lisible par les humains *et* la vue machine — le serveur décide quoi renvoyer en fonction de ce que demande l'appelant. Deux façons de demander : | Vous voulez | Paramètre de requête | Ou en-tête Accept | | --- | --- | --- | | Page HTML pour humains | *(par défaut)* | `Accept: text/html` | | JSON-LD (Linked Data) | `?format=jsonld` | `Accept: application/ld+json` | | JSON brut | `?format=json` | — | | Linkset (ressources liées) | `?format=linkset` | — | | DCAT-AP (métadonnées de jeu de données) | `?format=dcat-ap` | — | Ainsi, l'appareil photo d'un téléphone qui ouvre le QR code arrive sur le passeport HTML lisible, tandis qu'un script demande à l'URL *identique* du `application/ld+json` et obtient des données structurées : ``` # Vue machine via négociation d'en-tête — même URL, sans chaîne de requête curl -s -H "Accept: application/ld+json" \ "https://qr3.app/dpp/09520000000011/DEMO-BAT-01" ``` Un identifiant, une URL, de multiples représentations. Le couple GTIN/numéro de série reste stable ; c'est la *vue* qui s'adapte à l'appelant. C'est exactement ce qui rend un DPP à la fois durable et interopérable. ## Où s'inscrit EPCIS 2.0 (événements vs. passeport) Une question récurrente : *et EPCIS — n'est-ce pas le standard GS1 pour cela ?* Distinction importante : - Un **DPP** est la **description statique d'un article produit** — son identité, ses matériaux, son empreinte carbone, sa recyclabilité. Il répond à la question *« qu'est-ce que cette chose ? »* Le JSON-LD ci-dessus est ce cliché. - **EPCIS 2.0** est le standard GS1 pour les **événements de la chaîne d'approvisionnement** — les données de visibilité décrivant *ce qui s'est passé, où, quand et pourquoi* : un article a été commissionné, expédié, réceptionné, recyclé. Il répond à la question *« qu'est-il arrivé à cette chose, et où se trouve-t-elle ? »* Ils sont **complémentaires, pas concurrents**. Le passeport vous dit que le produit est une batterie de 5,2 kWh avec 35 % de contenu recyclé ; un journal d'événements EPCIS vous dirait qu'elle a été fabriquée à Hambourg à une date donnée, qu'elle a transité par un centre de distribution et est arrivée chez un recycleur. EPCIS 2.0 est lui-même compatible JSON/JSON-LD, de sorte que les deux partagent la même vision du monde Linked Data et les mêmes identifiants GS1 (GTIN + numéro de série) comme clé de jointure. > **Périmètre de qr3 (soyons précis) :** qr3 **produit le DPP au format JSON-LD** — c'est ce que démontre cet article. qr3 ne fournit **pas** la capture d'événements EPCIS ni de points d'accès EPCIS. Considérez ici EPCIS 2.0 comme le standard *conceptuel et complémentaire* que vous adopteriez aux côtés d'un DPP pour une traçabilité complète de la chaîne d'approvisionnement, et non comme une fonctionnalité de qr3. Le modèle mental est donc le suivant : le DPP (qr3, JSON-LD) est la *fiche d'identité* du produit ; EPCIS 2.0 (système distinct) est son *journal de voyage*. Mêmes identifiants, deux questions auxquelles on répond. ## Générer un DPP qui expose du JSON-LD Vous n'avez rien de particulier à faire pour « activer » le JSON-LD — créez le passeport et le résolveur sert automatiquement chaque représentation : ``` import { QR3 } from "@qr3/sdk"; const client = new QR3({ apiKey: process.env.QR3_API_KEY! }); const passport = await client.dpp.create({ gtin: "09520000000011", serial: "SN-00012345", product_name: "PowerCell 5 kWh LFP", manufacturer: "ExampleTech GmbH", origin_country: "DE", category: "battery", market_countries: ["DE", "FR", "AT"], status: "live", battery_data: { capacity_kwh: 5, carbon_footprint_kg: 62, recycled_content_pct: 12, recyclability_pct: 95, }, }); // The passport now resolves at https://qr3.app/dpp/09520000000011/SN-00012345 // Humans get HTML; machines append ?format=jsonld (or send Accept: application/ld+json). console.log(passport.qr.svg); // QR encodes the GS1 Digital Link to the resolver ``` Une fois créée, l'URL de l'article répond immédiatement aux deux publics — aucune étape de publication supplémentaire n'est nécessaire pour la vue machine. ## FAQ **Pourquoi JSON-LD et pas du JSON brut ?** Le JSON brut est structuré mais pas *auto-descriptif* : un consommateur doit apprendre vos noms de champs. JSON-LD ajoute `@context`, qui associe chaque clé à des termes schema.org / GS1, de sorte que tout consommateur de Linked Data le comprend sans intégration sur mesure. Si vous avez seulement besoin d'une lecture rapide, `?format=json` reste disponible. **qr3 implémente-t-il EPCIS 2.0 ?** Non. qr3 produit le DPP au format JSON-LD. EPCIS 2.0 est le standard GS1 distinct et complémentaire pour les *événements* de la chaîne d'approvisionnement ; vous le feriez tourner en parallèle, relié par le GTIN + numéro de série partagés. **Comment obtenir la vue machine ?** Ajoutez `?format=jsonld` à l'URL du résolveur, ou envoyez `Accept: application/ld+json`. Les deux renvoient la même charge utile Linked Data. **Le `@context` est-il stable ?** Il épingle schema.org ainsi que le GS1 Web Vocabulary (`gs1.org/voc/`) — deux vocabulaires publics et versionnés, de sorte que les consommateurs peuvent se fier au sens des termes. ## Sources - [JSON-LD 1.1 (W3C Recommendation)](https://www.w3.org/TR/json-ld11/) - [GS1 Web Vocabulary](https://www.gs1.org/voc/) - [GS1 EPCIS and CBV 2.0](https://www.gs1.org/standards/epcis) - [schema.org Product](https://schema.org/Product) - [ESPR — Regulation (EU) 2024/1781](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) **Commencez gratuitement** et créez un DPP qui expose du JSON-LD : [app.qr3.app/sign-up](https://app.qr3.app/sign-up) Il s’agit de démonstrations fonctionnelles avec des données produit fictives et des GTIN d’exemple du préfixe GS1 952. Elles ne prouvent ni l’attribution d’identifiants produit, ni une inscription au registre, ni une certification. ## Articles liés - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-digital-link-resolver/hero.png) Tutoriels Le resolver GS1 Digital Link, expliqué (avec un exemple en direct) Un QR code DPP n'est pas un lien vers une page web — c'est un GS1 Digital Link, et le resolver transforme un identifiant unique en de multiples réponses adaptées au contexte. Voici comment ça marche, avec un passeport en direct que vous pouvez interroger avec curl dès maintenant.](/fr/blog/gs1-digital-link-resolver/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/gs1-resolver-test-suite-dpp-links/hero.png) Tutoriels Suite de tests du résolveur GS1 : vérifier la robustesse des DPP-Links avant la mise en production La suite de tests GS1 stable permet de tester le résolveur 1.2. Testez ainsi les redirections, les jeux de liens, CORS, les langues et les cas d’erreur avant la mise en production.](/fr/blog/gs1-resolver-test-suite-dpp-links/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/dpp-battery-passport-2027-20260715/hero.png) Actualités du secteur BatteryPass-Ready lance un environnement de test pour le passeport numérique des batteries Le consortium BatteryPass-Ready a lancé le 24 juin 2026 un environnement de test public pour le passeport numérique des batteries, en prévision de l’obligation européenne à partir de février 2027.](/fr/blog/dpp-battery-passport-2027-20260715/) - [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/sector-20260713/hero.png) Actualités du secteur Passeport numérique de batterie 2027 : ce que les fabricants doivent savoir dès maintenant Webinaires, outils open source et nouvelles normes : le passeport européen des batteries prend de l’ampleur. État des lieux en juillet 2026 et questions ouvertes jusqu’en février 2027.](/fr/blog/sector-20260713/) [← Tous les articles](/fr/blog/) [Démarrer gratuitement](https://app.qr3.app/sign-up)