Digital Product Passport (DPP) : le révélateur de la maturité de votre donnée produit

Le QR code est la partie visible du Digital Product Passport. Pour la DSI, l’essentiel se joue derrière : dans la capacité à identifier, gouverner, sécuriser et maintenir la donnée produit pendant toute sa durée de vie.

Pendant longtemps, l’information produit a été principalement conçue pour accompagner la commercialisation : alimenter une fiche e-commerce, produire un catalogue, transmettre des caractéristiques à un distributeur ou soutenir le lancement d’une nouvelle gamme.

Le Digital Product Passport, ou Passeport Produit Numérique, élargit considérablement ce périmètre. L’entreprise ne doit plus seulement publier une information attractive et cohérente. Elle doit être capable de fournir une information structurée, vérifiable, contextualisée et accessible aux différents acteurs de son écosystème.

Pour les directions des systèmes d’information, le sujet dépasse donc largement la création d’un QR code, d’une page web supplémentaire ou d’une application développée spécifiquement pour répondre à une première échéance réglementaire.

Le DPP n’est pas un document numérique

L’expression « passeport produit » peut laisser penser qu’il s’agit d’un document statique regroupant des informations réglementaires.

Cette représentation est toutefois trop réductrice.

Un produit évolue dans le temps. Ses composants peuvent changer, ses fournisseurs être remplacés, ses certificats renouvelés et les exigences réglementaires être mises à jour. Des informations relatives à la maintenance, à la réparabilité ou au recyclage peuvent également être ajoutées après sa mise sur le marché.

Le DPP doit donc être envisagé comme un service d’information vivant, associé à un produit, un modèle, un lot ou une unité, selon les exigences applicables.

Le règlement européen sur l’écoconception des produits durables, l’ESPR, pose le cadre général du passeport numérique. Il prévoit notamment que celui-ci soit relié à un identifiant unique persistant, par l’intermédiaire d’un support de données, et que les informations soient accessibles selon des droits adaptés aux différents acteurs.

Le code 2D constitue la porte d’entrée.
Le passeport est le système organisé qui se trouve derrière.

Pour la DSI, le véritable sujet est l’architecture de confiance

Les données nécessaires au DPP sont généralement réparties entre plusieurs systèmes.

L’identité du produit peut être gérée dans un PLM, un ERP ou un MDM. Ses caractéristiques commerciales se trouvent dans un PIM. Ses images, notices, certificats et documents de preuve sont stockés dans un DAM ou une GED. Les données de composition proviennent des fournisseurs. Les informations de production résident dans un MES ou un PLM. Les données environnementales peuvent être calculées dans une solution spécialisée.

Une architecture reposant sur des exports manuels, une base isolée ou une application développée sur mesure pour générer les premiers DPP peut suffire à réaliser un pilote. Elle devient toutefois difficile à maintenir lorsque le nombre de références, de fournisseurs, de pays et d’exigences augmente.

Le développement spécifique peut alors se transformer en dette technique majeure. Les attributs attendus, les normes européennes, les modèles de données et les modalités d’accès vont évoluer. Chaque modification risque d’imposer de nouveaux développements, des campagnes de tests et une dépendance durable à quelques compétences internes ou prestataires.

Le rôle de la DSI est donc de construire une architecture configurable et évolutive, dans laquelle chaque système conserve une responsabilité claire.

Selon l’organisation de l’entreprise :

• le MDM gouverne les référentiels structurants et données de références ;
• le PLM gère les données de conception, de composition et cycle de vie des produits ;
• le PIM consolide, enrichit et contextualise l’information pour ses différents usages ;
• le DAM ou la GED prennent en charge les médias, notices, certificats et éléments de preuve ;
• les workflows organisent les validations et les responsabilités ;
• les API et connecteurs rendent l’information disponible aux services autorisés ;
• une couche de diffusion expose la bonne donnée au bon acteur.

Dans cette architecture, le PIM ne remplace ni l’ERP, ni le PLM, ni le MDM. Il joue un rôle d’orchestration : il consolide les informations issues de ces environnements, les enrichit et les prépare pour les différents usages du passeport produit.

Le DPP devient alors le résultat d’une architecture maîtrisée, plutôt qu’un silo supplémentaire. Il constitue aussi un cas d’usage concret pour une stratégie Best-of-Breed : confier chaque fonction au système le mieux adapté, plutôt que d’étendre artificiellement l’ERP à des usages pour lesquels il n’a pas été conçu.

Transformer une donnée disponible en donnée exploitable

De nombreuses entreprises disposent déjà d’une grande partie des informations susceptibles d’alimenter leurs futurs passeports produits.

Mais la présence d’une information dans le système d’information ne garantit pas qu’elle soit immédiatement exploitable.

Pour être utilisée dans un DPP, une donnée doit notamment pouvoir être :

• associée au bon identifiant ;
• exprimée dans une unité normalisée ;
• reliée à une source connue ;
• accompagnée d’une date de validité ;
• contrôlée et approuvée ;
• attribuée à un niveau précis : gamme, référence, lot ou unité ;
• transmise sans ambiguïté à un système tiers.

Le DPP met ainsi en lumière une distinction essentielle entre la simple disponibilité d’une information et sa capacité à être prouvée, comprise et réutilisée.

Cette distinction est particulièrement importante pour les données reçues des fournisseurs. Dans de nombreux secteurs, une part significative des informations techniques, environnementales ou de composition se situe en amont de la chaîne de valeur.

La performance du dispositif dépend donc autant de la qualité du référentiel interne que de la capacité à industrialiser la collecte externe.

Portails fournisseurs, formats d’échange structurés, règles de complétude, contrôles automatisés et circuits de relance deviennent indispensables. Le fichier transmis ponctuellement par e-mail atteint rapidement ses limites dès lors que le dispositif doit changer d’échelle.

Le DPP impose une gouvernance dans la durée

Un passeport numérique engage l’entreprise bien après la publication initiale du produit.

Il faut pouvoir gérer :

• les versions successives d’une information ;
• les évolutions de composants ou de fournisseurs ;
• la validité des certificats ;
• les corrections apportées après publication ;
• les informations applicables aux produits déjà commercialisés ;
• la continuité d’accès pendant la durée requise.

Cette dimension temporelle est structurante.

Une fiche produit commerciale peut être retirée d’un site lorsque la référence n’est plus disponible. Un DPP peut, au contraire, devoir rester accessible afin d’accompagner la maintenance, la réparation, le réemploi, le démontage ou le recyclage.

Le cycle de vie de la donnée peut donc devenir plus long que le cycle de commercialisation du produit.

Pour la DSI, cela implique de définir des politiques explicites de versioning, d’archivage, de disponibilité et de réversibilité. La dépendance à une URL temporaire, à une application isolée, à un code spécifique difficilement maintenable ou à un prestataire sans stratégie de sortie représente un risque architectural.

La persistance ne constitue pas un simple détail technique. Elle fait partie de la promesse de confiance portée par le DPP.

Des accès différenciés selon les acteurs

Le passeport numérique s’adresse à plusieurs catégories d’utilisateurs : consommateurs, distributeurs, réparateurs, recycleurs, autorités de surveillance, services douaniers ou partenaires industriels.

Leurs besoins ne sont pas identiques.

Un consommateur peut rechercher des informations sur l’entretien, la durabilité ou la réparabilité. Un réparateur doit pouvoir identifier des pièces et consulter des instructions techniques. Un recycleur a besoin de connaître la composition du produit et les consignes de traitement. Une autorité doit pouvoir contrôler la conformité et consulter les éléments de preuve associés.

Concevoir un DPP ne consiste donc pas à rendre toutes les données publiques.

Il s’agit d’organiser des niveaux d’accès, de distinguer les informations ouvertes des données réservées et de protéger les secrets d’affaires, les informations personnelles ainsi que les éléments sensibles de la chaîne d’approvisionnement.

Le DPP devient ainsi un sujet conjoint de gouvernance des données, d’Identity and Access Management et de cybersécurité.

La DSI doit notamment anticiper :

• l’authentification de certains utilisateurs ;
• la gestion des rôles et des habilitations ;
• la traçabilité des consultations et des modifications ;
• la sécurité des API ;
• la protection contre l’altération des données ;
• la disponibilité du service ;
• la gestion des incidents et des corrections.

Une information exacte mais indisponible, inaccessible au bon acteur ou exposée sans contrôle ne répond pas aux objectifs du passeport produit.

L’interopérabilité, condition du passage à l’échelle

Le DPP s’inscrit dans des chaînes de valeur complexes, internationales et multi-acteurs.

Aucun système d’information ne pourra durablement fonctionner comme un environnement fermé. Les données devront être comprises et exploitées par des partenaires, des plateformes, des autorités et des prestataires utilisant des technologies différentes.

Cette interopérabilité ne repose pas uniquement sur la présence d’une API.

Elle nécessite :

• des identifiants uniques et persistants ;
• des modèles de données documentés ;
• des vocabulaires partagés ;
• des unités et classifications normalisées ;
• des formats d’échange ouverts ;
• des règles de versioning ;
• une sémantique compréhensible par les systèmes destinataires.

Les standards d’identification et de partage de données jouent ici un rôle déterminant. GS1 souligne notamment l’importance d’identifiants persistants et interopérables, compatibles avec des mécanismes d’accès web tels que le passage au QR code augmenté 2D (GS1 Digital Link).

La question n’est donc pas seulement :
« Sommes-nous capables de publier notre DPP ? »

Elle est aussi :
« D’autres systèmes seront-ils capables de l’interpréter sans développement spécifique pour chaque échange ? »

C’est cette seconde question qui détermine la capacité réelle du dispositif à passer à l’échelle.

Elle plaide également en faveur d’une architecture modulaire et Best-of-Breed, fondée sur des solutions configurables et interopérables. Le DPP ne doit pas devenir un prétexte pour concentrer de nouvelles fonctions dans un ERP rigide ou multiplier les interfaces spécifiques difficiles à faire évoluer.

Faut-il attendre que toutes les exigences soient stabilisées ?

Les exigences précises du DPP seront définies progressivement, au fil des textes applicables aux différentes catégories de produits.

Cette évolution peut donner le sentiment qu’il est préférable d’attendre avant d’engager un projet.

Pourtant, la majorité des chantiers structurants ne dépend pas de la liste définitive des attributs réglementaires.

Une entreprise peut dès aujourd’hui :

• cartographier les systèmes qui détiennent les informations produit ;
• identifier les propriétaires de chaque donnée ;
• auditer la qualité et la traçabilité des informations critiques ;
• stabiliser ses identifiants produit, opérateur et site ;
• structurer la collecte des données fournisseurs ;
• mettre en place des règles de contrôle et de validation ;
• organiser la gestion des documents de preuve ;
• tester la publication d’un jeu de données versionné ;
• définir une architecture d’accès et d’habilitation ;
• sélectionner une famille de produits pour un pilote.

Commencer maintenant ne signifie pas figer prématurément le modèle.

Cela signifie construire un socle suffisamment flexible pour intégrer de nouveaux attributs, de nouvelles règles et de nouveaux cas d’usage sans remettre en cause toute l’architecture.

Cette flexibilité dépend moins de la quantité de code produite que de la capacité des outils retenus à être configurés, intégrés et mis à jour. Un PIM, un MDM ou une solution spécialisée du marché peut faire évoluer ses modèles et ses workflows ; une application maison codée autour des exigences du moment risque, elle, de devoir être continuellement reprise.

Comment engager une trajectoire DPP pragmatique

Une démarche progressive permet d’éviter deux écueils opposés : réduire le DPP à un projet de conformité géré en périphérie du système d’information ou lancer immédiatement une transformation globale, longue et difficile à arbitrer.

Une trajectoire équilibrée peut s’organiser autour de quatre étapes.

1. Évaluer la maturité du socle produit

La première étape consiste à comprendre où se trouvent les données, comment elles circulent, qui en est responsable et à quel niveau de granularité elles sont gérées.

Cette analyse permet d’identifier les doublons, les ruptures de traçabilité, les dépendances aux fichiers, les développements spécifiques et les données sans propriétaire clairement désigné.

2. Construire un modèle DPP extensible

Le modèle doit distinguer les données d’identité, les caractéristiques techniques, les informations réglementaires, les données environnementales, les documents de preuve et les informations de traçabilité.

Il doit également pouvoir prendre en charge plusieurs niveaux de granularité : modèle, référence, lot ou unité.

L’objectif n’est pas de coder une structure définitive, mais de s’appuyer sur des modèles configurables capables d’intégrer progressivement de nouveaux attributs et de nouvelles règles.

3. Industrialiser les flux et les contrôles

La collecte, la validation et la publication doivent être intégrées dans des workflows répétables.

Les contrôles de format, de cohérence, de complétude et de validité doivent être automatisés autant que possible. Les anomalies doivent être attribuées au bon responsable et suivies jusqu’à leur résolution.

Cette industrialisation suppose de faire collaborer les systèmes plutôt que de chercher à tout centraliser dans un outil unique. L’ERP, le PLM, le PIM, le MDM et les solutions spécialisées doivent intervenir selon leurs responsabilités respectives.

4. Tester le dispositif de bout en bout

Un pilote pertinent ne doit pas seulement démontrer qu’un QR code ouvre une page.

Il doit vérifier que l’entreprise peut :

• retrouver la source de chaque information ;
• mettre à jour une donnée sans rupture ;
• gérer plusieurs profils d’accès ;
• maintenir l’historique ;
• exposer les informations par API ;
• faire évoluer un contenu sans changer l’identifiant ;
• garantir l’accès dans la durée ;
• superviser les erreurs et la disponibilité du service.

Il doit aussi permettre de mesurer l’effort nécessaire pour intégrer une nouvelle exigence. Si chaque évolution entraîne une modification du code, une nouvelle interface ou une intervention lourde dans l’ERP, l’architecture n’est pas encore suffisamment adaptable.

C’est ce test de bout en bout qui permet d’évaluer la maturité réelle de l’organisation.

Du projet réglementaire à l’actif stratégique

Le DPP est souvent présenté comme une contrainte réglementaire supplémentaire.

Il peut pourtant devenir un accélérateur de transformation.

En obligeant l’entreprise à mieux identifier, structurer et documenter ses produits, il peut améliorer de nombreux processus existants : onboarding des fournisseurs, gestion de la conformité réglementaires et garanties produits UE, service après-vente, maintenance, seconde vie, recyclage, lutte contre la contrefaçon ou communication avec les consommateurs.

Le même socle de données peut servir plusieurs usages, à condition d’avoir été conçu comme une plateforme plutôt que comme une réponse ponctuelle.

Pour la DSI, l’enjeu n’est donc pas de créer une architecture dédiée au seul passeport numérique. Il s’agit de faire du DPP une nouvelle vue, gouvernée et sécurisée, d’un système d’information produit déjà capable de servir l’ensemble de l’entreprise.

Le projet peut ainsi devenir un terrain concret pour éprouver une stratégie Best-of-Breed : conserver l’ERP dans son rôle transactionnel, le PLM dans la gestion de la conception et le PIM ou le MDM dans la structuration et la gouvernance de l’information, tout en organisant leur collaboration par des flux standardisés.

Le DPP rend visible la qualité du système d’information

Demain, un simple scan donnera accès au consommateur, au réparateur ou au régulateur à une partie des données produites par l’entreprise.

Cette apparente simplicité reposera sur une architecture exigeante : identifiants fiables, données structurées, contributions fournisseurs, preuves documentaires, règles de gouvernance, API sécurisées et gestion du cycle de vie.

Le DPP rendra ainsi visible ce qui restait jusqu’à présent en grande partie invisible : la maturité du système d’information produit.

Les entreprises les mieux préparées ne seront pas nécessairement celles qui auront créé le premier passeport.

Ce seront celles qui auront construit une architecture capable d’en produire et d’en maintenir des milliers, dans plusieurs marchés, pour différents usages et pendant toute la vie des produits, sans accumuler une dette technique à chaque évolution réglementaire.

Nous sommes convaincus que la conformité durable se construit au cœur du système d’information, et non à sa périphérie.

Elle repose sur un référentiel produit unifié, une gouvernance claire, des outils configurables et une donnée capable de circuler de manière fiable entre des systèmes complémentaires, les marchés et les acteurs.

Le DPP n’est pas la destination finale de cette transformation.
Il en est l’un des premiers révélateurs.

Your data. Your way. Your Growth.