DPP-Garder les données à jour : ce que la ESPR impose réellement

La question semble banale, mais ne l’est pas : à quelle fréquence un passeport produit numérique doit-il être mis à jour ? Celui qui cherche un chiffre concret dans le ESPR-règlement (UE) 2024/1781 sera déçu. Le texte exige seulement que le DPP contienne des « informations à jour et exactes » – sans fréquence, sans SLA ni spécification technique. Ce que cela signifie en pratique dépend fortement du type de produit, de la chaîne d’approvisionnement et des actes délégués qui doivent encore être adoptés pour chaque catégorie de produits.

Cet article explique quelles catégories de données peuvent réellement changer, quels modèles de mise à jour font leurs preuves dans les premières mises en œuvre et où se situent les pièges réglementaires.

Ce qui peut réellement changer dans un DPP

Un passeport produit n’est pas un PDF statique. Il se compose de points de données dont les cycles de vie sont très différents.

Données statiques vs. dynamiques

En simplifiant, les champs DPP peuvent être répartis en trois catégories :

Catégorie de données	Fréquence de modification typique	Exemples
Données de référence	Une fois (lors du lancement du produit)	GTIN, composition des matériaux, fabricant
Données de lot	À chaque cycle de production	Valeur PCF, origine des matières premières, certificats
Données du cycle de vie	Déclenchées par un événement	Historique des réparations, rappel, voie d’élimination

Le projet de données du JRC pour les produits sidérurgiques illustre particulièrement bien cette différence : l’empreinte carbone spécifique au produit (PCF) y est explicitement gérée au niveau du lot et doit être calculée selon des méthodes compatibles avec la norme ISO 14067. Cela signifie que chaque nouveau lot de production peut avoir une valeur PCF différente – le passeport doit référencer correctement cette valeur, et non la moyenne de l’année précédente.

L’exemple de la batterie comme modèle

Le passeport numérique de batterie, obligatoire à partir du 18 février 2027, montre à quel point les données DPP peuvent être dynamiques. Les rapports sectoriels sur la mise en œuvre du passeport numérique de batterie identifient la fragmentation des données et la mise à jour des données dynamiques comme les deux principaux problèmes pratiques. Les batteries accumulent des données tout au long de leur durée de vie : état de santé (SoH), cycles de charge, événements de réparation. Utiliser ici un ensemble de données statique ne permet pas de respecter le règlement.

Modèles de mise à jour : comment fonctionnent les mises en œuvre actuelles

Mises à jour événementielles via webhook

Le modèle le plus robuste dans les premiers systèmes DPP est la mise à jour événementielle : un système backend envoie un webhook dès qu’un point de données pertinent change – par exemple lorsqu’un nouveau certificat de contrôle est délivré ou qu’une réparation est terminée.

// Beispiel: Webhook-Handler für DPP-Update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Important : la ESPR exige implicitement une capacité de piste d’audit. Les modifications doivent rester traçables – un simple écrasement sans gestion des versions présente un risque réglementaire.

Mises à jour par lots pour les informations de lot

Lorsque les valeurs PCF ou les certificats sont mis à jour en une seule fois pour des lots de production entiers, une procédure d’importation en masse s’impose. Une liste de numéros de passeport est alors transmise avec la nouvelle valeur du champ :

# Beispiel: Bulk-PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Des plateformes comme qr3.app avec l’importation en masse prennent en charge ce modèle, afin d’éviter la mise à jour manuelle de chaque lot.

GS1 Digital Link comme couche de résolution

Un aspect souvent sous-estimé : le QR code apposé sur le produit ne doit pas changer – il est imprimé physiquement. C’est le contenu vers lequel il pointe qui doit pouvoir changer. C’est précisément là que GS1 Digital Link fournit la couche d’abstraction décisive. Le QR code encode un URI stable (par ex. https://id.example.com/01/04012345678901/21/SN-00042), puis le résolveur redirige vers la source de données actuellement pertinente.

Driscoll’s a démontré à GS1 Connect 2026 comment ce principe fonctionne à grande échelle : plus d’un milliard de barquettes de fruits rouges ont été dotées d’identités uniques et migrent actuellement vers des QR codes entièrement conformes à GS1 Digital Link. Le code sur l’emballage reste inchangé ; c’est l’ensemble de données situé derrière le résolveur qui évolue.

De nouvelles technologies, comme le partenariat entre Polytag et DataLase, montrent que les QR codes conformes à GS1 peuvent désormais être apposés sur des substrats d’emballage difficiles à la vitesse des lignes de production – l’obstacle physique diminue, mais la logique du résolveur reste la même.

Pièges réglementaires

La directive EmpCo comme pression supplémentaire

Penser qu’il suffit de surveiller la ESPR revient à sous-estimer l’ensemble du contexte. En juin 2026, la Commission européenne a engagé des procédures d’infraction contre 20 États membres pour transposition insuffisante de la directive EmpCo (UE) 2024/825. Cette directive interdit le greenwashing et exige des informations claires sur la durabilité et la réparabilité – des informations qui doivent être directement intégrées aux DPP. Des indices de réparabilité obsolètes ou des labels de durabilité invalides dans le passeport peuvent donc constituer non seulement une infraction à la ESPR, mais aussi une infraction à EmpCo.

Pas de délai explicite de mise à jour, mais des obligations implicites

L’absence de fréquence indiquée dans la ESPR n’est pas un blanc-seing. Plusieurs obligations implicites peuvent être déduites de la formulation « informations à jour et exactes » :

Actualité liée aux événements : dès qu’un rappel, une réparation ou une modification de certificat intervient, le passeport doit être mis à jour – sans délai.
Actualité liée au lot : les valeurs PCF et les justificatifs d’origine des matières premières ne doivent pas être transférés d’un ancien lot à un nouveau lorsque les valeurs diffèrent.
Conformité à la surveillance du marché : les autorités doivent pouvoir consulter le passeport pendant toute la durée de vie du produit. Un passeport qui n’est plus jamais mis à jour après la vente n’a aucune valeur pour les informations de réparation et d’élimination.

Ecommerce Europe recommande expressément, dans sa prise de position, une introduction progressive et une granularité flexible des données – ce qui signifie indirectement que les processus de mise à jour peuvent être construits de manière itérative, tant que les exigences essentielles sont respectées.

Recommandations pratiques

Prévoir un journal d’audit dès le départ

Toute modification apportée à un jeu de données DPP devrait être consignée avec son horodatage, son auteur et son motif. Il ne s’agit pas aujourd’hui d’une obligation explicite de la ESPR, mais elle est attendue dans les actes délégués et est indispensable en pratique pour la surveillance du marché.

L’architecture du résolveur avant celle des données

Définir d’abord la structure des données, puis réfléchir à la manière dont le QR code y renvoie, c’est prendre le problème à l’envers. L’ordre correct est le suivant : définir l’URI du résolveur (GS1 Digital Link), puis le schéma de données, puis les processus de mise à jour. Le passeport produit numérique de qr3.app suit ce principe : le QR code est stable, tandis que l’ensemble de données situé derrière est versionné et peut être mis à jour.

Utiliser systématiquement les identifiants de lot

Gérer les valeurs PCF ou les certificats au niveau du produit plutôt qu’au niveau du lot crée des problèmes au plus tard lors du premier contrôle de surveillance du marché. L’identifiant de lot doit être défini comme champ obligatoire dans chaque jeu de données DPP – et non comme un champ de métadonnées facultatif.

Le contexte réglementaire est complexe, mais les modèles techniques sont maîtrisables. L’essentiel est de ne pas considérer la capacité de mise à jour comme une fonctionnalité ajoutée après coup, mais comme un principe d’architecture dès le premier jour.