DPP-Maintenir les données à jour : ce que la ESPR prescrit réellement

Depuis l’adoption de la ESPR-règlement (UE) 2024/1781, le Digital Product Passport (DPP) relève du droit contraignant de l’UE. Ce que de nombreuses entreprises sous-estiment : le DPP n’est pas un document statique créé une seule fois lors de la mise sur le marché. Il doit rester à jour pendant toute la durée de vie du produit — et les exigences à cet égard deviennent de plus en plus précises.

Cet article explique quelles données doivent être mises à jour et à quel moment, comment l’architecture du registre influence le modèle de mise à jour et quels modèles techniques font leurs preuves dans la pratique.

Ce que le règlement prévoit concernant le cycle de mise à jour

Champs de données statiques et dynamiques

La ESPR elle-même ne mentionne aucune fréquence de mise à jour explicite, mais elle dispose que le DPP doit contenir des « informations actuelles et exactes ». La précision s’effectue au niveau sectoriel — et le projet du JRC pour les produits semi-finis en fer et en acier fournit à ce jour l’image la plus claire.

Le projet distingue systématiquement deux niveaux de granularité des données :

Niveau	Identifiant	Exemples de données	Déclencheur de mise à jour
Niveau du lot (Lot)	Numéro de lot	Teneur en matériaux recyclés, composition de l’alliage, PCF selon ISO 14067	Modification de la production, nouveau lot
Niveau du produit (Item)	Numéro de série	Dimensions, certifications, déclarations de conformité	Recertification, rappel, réparation

Cette distinction est décisive pour l’architecture de la base de données : les données de lot sont généralement écrites une fois par cycle de production et restent ensuite stables — sauf si un nouveau calcul de l’empreinte carbone fournit une valeur corrigée. Les données au niveau du produit, en revanche, peuvent évoluer pendant toute la durée d’utilisation, par exemple lorsqu’un appareil est réparé ou qu’une certification est renouvelée.

Le règlement sur les batteries (UE) 2023/1542 connaît déjà implicitement cette distinction : les données de capacité qui évoluent sous l’effet de la dégradation doivent rester à jour — une exigence difficilement réalisable sans architecture claire.

Le registre comme répertoire, et non comme espace de stockage des données

Un malentendu fréquent concerne le rôle du DPP-registre central. Le projet de règlement d’exécution relatif au registre DPP précise que le registre stocke exclusivement l’identifiant unique, le point de terminaison du résolveur et le code marchandise — et non les données du passeport proprement dites.

Cela implique pour la gestion des mises à jour que le contenu du passeport et le registre sont deux systèmes distincts. Lorsqu’il met à jour les données d’un produit, l’opérateur n’a généralement pas besoin d’intervenir dans le registre — sauf si le point de terminaison du résolveur change, par exemple lors d’un changement de système. Le consortium CIRPASS-2 a explicitement souligné ce modèle d’architecture dans sa prise de position sur le projet de registre et recommande d’intégrer la norme EN 18219 comme référence contraignante dans le règlement d’exécution — notamment afin de garantir l’interopérabilité avec le GS1 Digital Link.

Scénarios de mise à jour dans la pratique

Scénario 1 : Nouvelle empreinte carbone due à un changement de fournisseur

L’empreinte carbone spécifique au produit (PCF) est gérée au niveau du lot selon le projet du JRC sur l’acier et doit être calculée à l’aide de méthodes compatibles avec la norme ISO 14067. Si un producteur d’acier change de source d’énergie ou de fournisseur de ferraille, le PCF du nouveau lot change — mais pas celui des lots déjà livrés.

Techniquement, cela signifie que l’enregistrement DPP de l’ancien lot reste inchangé. Un nouvel enregistrement est créé pour le nouveau lot ; il peut utiliser le même point de terminaison du résolveur, mais porte un nouveau numéro de lot comme identifiant.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scénario 2 : Expiration d’une certification au niveau du produit

Les déclarations de conformité et les certifications ont des dates d’expiration. Dès qu’une nouvelle certification est délivrée, le DPP doit être mis à jour au niveau du produit. Le point de terminaison du résolveur restant inchangé, aucune mise à jour du registre n’est nécessaire — seul l’enregistrement situé derrière le point de terminaison est modifié.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scénario 3 : Migration du résolveur lors d’un changement de système

Si une entreprise change de prestataire de services DPP, le point de terminaison du résolveur change. Dans ce cas, le registre doit être mis à jour — pour chaque identifiant concerné. Il s’agit du type de mise à jour le plus complexe, car il nécessite une écriture dans le registre.

Recommandation : utilisez votre propre résolveur stable (par ex. dpp.ihrunternehmen.de) comme couche intermédiaire, en redirigeant en interne vers le prestataire concerné. Le point de terminaison enregistré dans le registre reste ainsi stable durablement.

Exigences techniques du système de mise à jour

Gestion des versions et piste d’audit

La ESPR n’exige pas explicitement la gestion des versions, mais la combinaison de la responsabilité du fait des produits et des contrôles douaniers rend une piste d’audit pratiquement incontournable. Si, en 2030, un agent des douanes examine le DPP d’une poutre en acier produite en 2027, il doit être possible de déterminer quelles données étaient applicables au moment de l’importation.

Schéma minimal pour une table DPP avec gestion des versions :

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

Le GS1 Digital Link comme ancrage stable de l’identifiant

Le GS1 Digital Link sépare clairement l’identifiant et le résolveur : le code QR apposé sur le produit encode une URL telle que https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, qui renvoie, via le résolveur GS1 ou un résolveur propre, vers l’enregistrement DPP actuel. Les mises à jour de l’enregistrement ne nécessitent pas de nouvel étiquetage — le support physique reste inchangé.

TEKLYNX a mis à jour son logiciel CODESOFT et prend désormais en charge les schémas de codage GS1 « ++ », qui permettent d’écrire directement des URL web dans la mémoire des étiquettes RFID RAIN — une exigence découlant de la combinaison de la norme EN 18220 et du standard GS1 Digital Link.

Gouvernance : qui peut mettre à jour quoi ?

Au-delà de la question technique se pose celle de la gouvernance : quels acteurs de la chaîne d’approvisionnement peuvent écrire quels champs du DPP ? Le consortium CIRPASS-2 a identifié à ce sujet des points critiques concernant la souveraineté des données dans les chaînes d’approvisionnement transfrontalières.

Un modèle pratique distingue trois rôles :

Fabricant (Creator) : écrit tous les champs lors de la création ; peut mettre à jour tous les champs.
Acteur autorisé (Editor) : peut mettre à jour les champs définis (p. ex. historique des réparations, nouvelles certifications) — avec traçabilité au moyen de son propre identifiant.
Lecteur (Reader) : peut lire tous les champs publics, sans droits d’écriture.

Ecommerce Europe a demandé, dans sa prise de position sur la mise en œuvre de la DPP, que des « DPPs partielles » soient également possibles pour les produits d’occasion — c’est-à-dire des enregistrements qui ne mettent à jour qu’une partie des champs initiaux. Cette possibilité est déjà réalisable techniquement, mais ne constitue pas encore une catégorie formelle dans les règlements d’exécution.

Conclusion

Maintenir à jour les données DPP n’est pas une tâche ponctuelle, mais un processus opérationnel. Les principaux enseignements de l’état actuel de la réglementation sont les suivants :

Séparez le lot et le produit — la stratégie d’identification détermine quelles données doivent être mises à jour et à quel moment.
Le registre n’est pas un espace de stockage des données — les mises à jour du contenu du passeport ne nécessitent généralement pas d’écriture dans le registre.
La gestion des versions est de facto obligatoire — même si le règlement ne l’exige pas explicitement.
Le GS1 Digital Link dissocie le support physique de l’enregistrement — ce qui réduit considérablement les efforts liés aux mises à jour des données.
Les rôles de gouvernance doivent être définis à l’avance — qui peut écrire quoi, et comment ces opérations sont-elles consignées ?

Les normes gagnent en précision et les premiers projets pilotes sont en cours — ceux qui mettent dès maintenant en place une architecture adéquate éviteront des corrections coûteuses lorsque les règlements d’exécution sectoriels entreront en vigueur.