Le 20 juillet 2026, la Commission européenne a mis en service le registre de l’UE pour les passeports numériques de produit ainsi que son environnement de test. Ainsi, une composante ESPR abstraite est devenue un système que les entreprises peuvent réellement expérimenter. Pour les fabricants, une distinction est désormais essentielle : le registre est l’index central, tandis que le passeport lui-même reste décentralisé.
Ce qui a été mis en service le 20 juillet
Le registre enregistre les identifiants uniques des produits, les données d’enregistrement et certaines métadonnées. Les informations complètes sur les produits restent auprès de l’opérateur économique responsable ou d’un prestataire DPP mandaté. C’est pourquoi la Commission décrit explicitement le registre comme un service d’indexation, et non comme un système central de gestion de contenu.
Les enregistrements sont prévus via une interface utilisateur sécurisée et une API. Les entreprises peuvent également générer une preuve électronique d’enregistrement. Cela est pertinent pour les processus B2B, car les fournisseurs et les clients peuvent ainsi prouver qu’un passeport a été enregistré dans le système de l’UE, sans dupliquer l’ensemble des données.
Le lancement ne concerne pas uniquement les groupes de produits ESPR. La Commission mentionne également les batteries, les produits de construction, les jouets, les détergents et les tensioactifs destinés aux utilisateurs finaux, dans la mesure où le droit de l’Union applicable impose un passeport numérique de produit. La première échéance contraignante reste fixée au 18 février 2027 pour certaines batteries.
Le registre, le résolveur et la source de données sont trois couches distinctes
Un système DPP robuste devrait séparer clairement les responsabilités :
- Le registre de l’UE confirme qu’un identifiant et les métadonnées prescrites sont enregistrés.
- Un résolveur redirige l’identifiant persistant du produit vers la ressource appropriée.
- La source de données proprement dite fournit des contenus à jour pour les utilisateurs et les machines.
Cette séparation n’est pas un détail. Le fait de stocker toutes les données exclusivement sur sa propre page produit ne constitue pas encore une intégration au registre. À l’inverse, l’enregistrement d’un simple identifiant ne suffit pas à fournir un passeport numérique de produit exploitable. Les deux éléments doivent être reliés par des identifiants stables.
Pour la résolution, un lien ouvert et pérenne est approprié. Un résolveur GS1-Digital-Link peut rendre accessibles différentes représentations à partir du même identifiant : une page web compréhensible, du JSON-LD lisible par machine ou une documentation complémentaire. Le support de données apposé sur le produit ou l’emballage reste ainsi stable, même si les systèmes cibles évoluent.
Ce que les entreprises devraient vérifier dans l’environnement de test
L’environnement de test n’est pas seulement destiné à un essai manuel. Il devrait être traité comme une étape préparatoire à l’intégration en production.
Organisation et rôles
Il faut d’abord déterminer quelle entité juridique procède à l’enregistrement, qui la représente dans le système et quelles équipes sont autorisées à créer ou modifier des enregistrements. Cela concerne les données de référence, la conformité, l’informatique et, le cas échéant, les prestataires externes. Un accès de test personnel ne remplace pas un modèle de rôles pour l’exploitation ultérieure.
Identifiants et granularité
L’équipe produit devrait déterminer si le futur passeport sera géré au niveau du modèle, du lot ou de l’unité. La réponse dépend du droit sectoriel applicable. Le test du registre est le moment idéal pour mettre en correspondance les identifiants produits internes, les GTINs, les identifiants de lot et l’identifiant persistant utilisé à l’extérieur.
API et répétabilité
Un processus de production nécessite davantage qu’un POST réussi. L’enregistrement, la mise à jour et la gestion des erreurs doivent être répétables et journalisés. Cela comprend des requêtes idempotentes, des accusés de réception techniques et une correspondance claire entre l’enregistrement ERP, le DPP et l’entrée du registre. Un processus DPP fondé sur une API réduit les écarts manuels lorsque les produits sont créés en grande quantité.
Séparation des métadonnées et des données métier
Les données du registre ne devraient pas devenir un second référentiel de données produit. Définissez quels champs sont requis dans le registre et quelles informations restent dans le passeport décentralisé. Pour chaque information, il faut une source de référence, une entité responsable et une règle de mise à jour.
Preuves et surveillance
Les preuves d’enregistrement devraient être conservées avec l’horodatage, l’identifiant utilisé et la réponse du système. Il faut également effectuer un rapprochement : le passeport existe-t-il, le résolveur est-il accessible et les métadonnées du registre correspondent-elles encore au statut du produit ?
Pourquoi les douanes ont besoin d’une chaîne de vérification dédiée
Le registre aide les autorités douanières à vérifier automatiquement, avant la mise en libre pratique, qu’un DPP enregistré valide et le code marchandise requis sont présents. Les importateurs sont ainsi confrontés à une nouvelle dépendance : l’identifiant du produit, l’enregistrement au registre et la déclaration en douane doivent être cohérents.
Une erreur ne sera donc pas nécessairement visible uniquement sur une page produit. Elle peut affecter le processus à la frontière. Les entreprises devraient simuler dès la phase de test les flux de données, de la création du produit jusqu’aux documents d’importation, et définir qui est habilité à corriger rapidement un enregistrement erroné.
Un plan de test pertinent sur 30 jours
- Sélectionner une entité juridique réelle et un assortiment de produits restreint mais représentatif.
- Documenter, pour chaque produit, la granularité DPP prévue et les identifiants de référence.
- Effectuer un parcours complet via l’interface utilisateur et, le cas échéant, l’API.
- Archiver conjointement la preuve d’enregistrement, la réponse du résolveur et les données produit lisibles par machine.
- Tester les cas d’erreur : identifiant en double, métadonnées obsolètes, hôte de données inaccessible et produit retiré.
- Déduire des résultats un modèle d’exploitation précisant les responsabilités, la surveillance et le circuit d’escalade.
La mise en service opérationnelle du registre ne signifie pas encore que toutes les exigences sectorielles en matière de données sont déjà pleinement applicables. Elle déplace toutefois la discussion des présentations vers des processus vérifiables. Les entreprises peuvent désormais déterminer si leurs identifiants, leurs rôles et leurs API sont cohérents avant l’entrée en vigueur des premières échéances obligatoires.
