CEN et CENELEC publient les premières normes de l’UE pour le passeport produit numérique

EN 18216 à EN 18223 : CEN et CENELEC posent les fondations techniques du passeport produit numérique sous ESPR et du règlement sur les batteries. Ce que ces normes réglementent concrètement.

par QR3 Redaktion

CEN et CENELEC publient les premières normes de l’UE pour le passeport produit numérique

Le lancement de normes harmonisées pour la technologie DPP

Le 27 mai 2026, le CEN et le CENELEC ont publié les premières normes européennes harmonisées pour le passeport produit numérique (DPP) : la série de normes EN 18216:2026 à EN 18223:2026. Il ne s’agit pas d’un événement de routine. Jusqu’à présent, il existait certes un cadre politique — notamment le règlement sur l’écoconception ESPR et le règlement (UE) 2023/1542 relatif aux batteries — mais aucune spécification technique contraignante précisant comment un DPP doit concrètement être structuré, adressé et consulté. Les nouvelles normes comblent cette lacune.

Le 25 juin 2026, le CEN et le CENELEC ont organisé un webinaire public afin d’expliquer les normes et de répondre aux questions de l’industrie. La participation a été importante — ce qui montre la pression à laquelle sont soumis les fabricants, les importateurs et les fournisseurs de logiciels.

Ce que réglementent les normes EN 18216–18223

Identifiants univoques et supports de données

Le cœur de la série de normes repose sur trois domaines : les identifiants univoques des produits, les supports de données (notamment les codes QR, les RFID, les DataMatrix et autres) ainsi que les API pour l’accès automatisé aux données. Les normes sont délibérément agnostiques quant aux produits. Elles ne s’appliquent pas uniquement aux batteries, mais établissent la base technique de toutes les futures obligations DPP au titre de la ESPR — des textiles à l’électronique, en passant par les matériaux de construction.

Concrètement, la série de normes prescrit comment un produit doit être identifié de manière univoque pendant tout son cycle de vie. Elle s’appuie pour cela sur des standards établis : le GS1 Digital Link est prévu comme format privilégié pour relier le produit physique et l’enregistrement numérique. Cela signifie qu’un code QR apposé sur le produit ne doit pas nécessairement être une URL statique, mais peut être une adresse structurée et lisible par machine, par laquelle des services de résolution fournissent différents points de données — en fonction du demandeur et du contexte.

Interfaces API et interopérabilité

Un objectif central des normes est l’interopérabilité : les autorités, les entreprises de recyclage, les consommateurs et les fournisseurs doivent pouvoir consulter le même DPP via des interfaces standardisées, quelle que soit la plateforme qui héberge le passeport. Les normes définissent à cette fin des profils d’API basés sur REST. Les fabricants et les fournisseurs de plateformes DPP doivent veiller à ce que leurs systèmes implémentent correctement ces interfaces.

Pour les développeurs, cela signifie concrètement que l’API doit prendre en charge certains points de terminaison et formats de réponse. Un exemple simplifié de consultation conforme d’un DPP pourrait se présenter ainsi :

GET /dpp/v1/passport/{digitalLinkId}
Accept: application/json
Authorization: Bearer <token>

La réponse doit fournir des métadonnées structurées sur le produit, notamment des renvois vers des documents, des certificats et — pour les batteries — des données d’état dynamiques.

Le règlement sur les batteries comme précurseur : données statiques et dynamiques

Le règlement (UE) 2023/1542 relatif aux batteries, entré en vigueur en août 2023, constitue le premier cas d’application concret du DPP. Il distingue implicitement deux catégories de données :

Les données statiques sont fixées lors de la mise sur le marché : chimie, fabricant, capacité nominale, empreinte carbone de la production. Ces valeurs ne changent pas et peuvent être enregistrées une seule fois.

Les données dynamiques, en revanche, doivent rester actualisables pendant tout le cycle de vie. Il s’agit notamment du State of Health (SoH) et du State of Charge (SoC) — ces deux indicateurs évoluent à chaque cycle de charge et de décharge. Le règlement prescrit expressément la mise à jour de ces points de données. Cela pose aux fabricants et aux exploitants un problème d’architecture système : le DPP ne peut pas être un PDF statique, mais doit être relié à des sources de données vivantes.

Les nouvelles normes du CEN/CENELEC répondent précisément à cette exigence en définissant des profils d’API permettant à la fois les accès en lecture et en écriture — avec l’autorisation correspondante.

De nouveaux outils : environnement de test et validation open source

Parallèlement à la publication des normes, la pratique a également évolué.

Environnement de test BatteryPass-Ready

Le 24 juin 2026, le consortium BatteryPass-Ready a lancé un environnement de test public pour le passeport numérique des batteries. Les fabricants et les fournisseurs de logiciels peuvent y vérifier leurs implémentations sur des données de test réelles avant l’entrée en vigueur des échéances légales. L’environnement est exploité conjointement par le Fraunhofer IPK et est accessible sans obligation d’inscription.

Digital Passport Assessment Workbench (DP-AWB)

En juillet 2026, des chercheurs ont publié la Digital Passport Assessment Workbench (DP-AWB), un outil open source. Cet outil calcule des résultats d’évaluation déterministes directement à partir de spécifications de modèles SHACL et permet de valider formellement les structures de données DPP. Cela concerne tous ceux qui doivent s’assurer que leurs jeux de données sont non seulement corrects sur le fond, mais aussi conformes aux normes sur le plan structurel.

SHACL (Shapes Constraint Language) est un standard du W3C destiné à la validation des graphes RDF. Dans le contexte DPP, cela signifie que toute personne qui modélise ses données produit sous forme de Linked Data peut utiliser la DP-AWB pour vérifier automatiquement que tous les champs obligatoires sont présents et correctement typés — sans listes de contrôle manuelles.

La question en suspens : la registry DPP à l’échelle de l’UE

Les normes et les outils ne résolvent pas un problème : comment trouver un DPP lorsque l’on n’a devant soi qu’un produit physique ? La Commission européenne travaille à une registry centrale dans laquelle tous les DPPs doivent être enregistrés et rendus accessibles. Mais le diable est dans les détails.

Orgalim — l’association industrielle européenne des entreprises technologiques — a formulé à ce sujet des exigences claires : la registry doit prendre en charge des processus d’enregistrement automatisés à haut volume. Si l’on garde à l’esprit que des milliards de produits sont mis sur le marché chaque année dans la seule UE, on comprend le problème. Une registry qui exige des saisies manuelles ou tombe en panne lors des pics de charge est inutilisable pour les applications industrielles.

Orgalim demande également que la registry soit protégée contre les interruptions de service — la haute disponibilité n’est pas une option, mais une condition préalable. Car si un agent des douanes ou une entreprise de recyclage ne peut pas consulter un DPP parce que la registry est hors ligne, toute la chaîne de conformité s’effondre.

La Commission n’a jusqu’à présent publié aucun calendrier contraignant pour la mise en service de la registry. Il s’agit de l’une des principales zones d’incertitude de l’écosystème DPP.

Ce que les entreprises doivent faire dès maintenant

La publication des normes EN 18216–18223 marque un tournant : les exigences techniques sont désormais définies, même si la registry fait encore défaut. Les entreprises relevant du règlement sur les batteries ou se préparant aux futurs actes délégués ESPR devraient donner la priorité à trois étapes :

  1. Se procurer les normes et les lire. Les normes EN 18216–18223 sont disponibles auprès des organismes nationaux de normalisation (le DIN en Allemagne). La lecture des spécifications d’API est obligatoire pour tous ceux qui développent ou acquièrent leurs propres systèmes DPP.

  2. Vérifier l’architecture des données. Vos systèmes peuvent-ils fournir des points de données dynamiques (SoH, SoC, historique des réparations) via une API ? Si ce n’est pas le cas, le moment est venu de prendre une décision d’architecture — et non six mois avant l’échéance légale.

  3. Utiliser les environnements de test. L’environnement BatteryPass-Ready et la DP-AWB sont disponibles gratuitement. Tester rapidement son implémentation permet d’éviter de coûteuses corrections sous la pression du temps.

Les normes sont publiées. Le compte à rebours est lancé.

Sources