Digital Product Passport : au-delà du QR code, l'enjeu de la donnée produit

Introduction

Commençons par démystifier le Passeport Numérique des Produits. Contrairement aux idées reçues, cette carte d'identité digitale, mieux connue sous le nom de DPP, ne se résume pas à un QR code. L'enjeu est en effet bien différent : interface tripartite à destination des autorités, des marques et des consommateurs, le Digital Product Passport requiert de collecter, fiabiliser et structurer un grand nombre de données produit.

Composition, origine des matières, fournisseurs, certifications, déclarations de conformité et caractéristiques environnementales sont autant d'informations nécessaires à la création d'un DPP. Bien loin d'être centralisées dans une même interface, elles sont aujourd'hui dispersées dans de multiples outils (PLM, PIM, ERP, etc.), au service d'équipes aux objectifs divers.

Et si le QR code permet à vos clients d'accéder à une partie de ces données, il n'est que l'ultime étape d'un processus long et complexe : la structuration d'une base de données produit complète, fiable et interopérable.

Dès lors, plusieurs questions se posent : quels enjeux attendent les équipes IT dès 2027 ? Quelles premières étapes anticiper pour être en conformité dans les temps ? Le DPP va-t-il imposer de revoir l'ensemble de vos outils ?

Pour y répondre, nous vous proposons une démarche en trois temps : diagnostiquer, anticiper, puis agir.

1. Diagnostiquer : six questions pour faire l'état des lieux de vos données

À l'instar de tout projet transverse, la préparation au déploiement du Digital Product Passport se fait par étapes. La première ? Faire un état des lieux de votre écosystème de données et estimer la charge de travail requise pour atteindre les standards de conformité au DPP.

Si l'interface finale prend, pour certains, la forme d'un QR code, l'enjeu prioritaire est de vous assurer de trois points : l'exhaustivité de vos données, leur mise à jour et leur rattachement au bon produit et au bon fournisseur.

Pour évaluer votre maturité sur ces trois axes, rien de bien complexe. Six questions suffisent à dresser un premier diagnostic :

1. Où se trouve aujourd'hui la donnée produit de référence ? Exemple : toutes les données liées aux produits sont centralisées dans votre PLM.
2. Quels outils utilisent cette donnée ? Exemple : cette donnée est transférée à votre ERP, puis intégrée au CMS qui alimente votre site e-commerce.
3. Qui est responsable de la mise à jour de la donnée ? Exemple : c'est un alternant rattaché à l'équipe production qui est en charge de sa mise à jour.
4. Comment les informations liées aux fournisseurs sont-elles collectées ? Exemple : vos équipes sourcing collectent les données fournisseurs par e-mail, puis les centralisent dans des fichiers Excel partagés.
5. Les certificats et documents sont-ils associés aux bons produits, matières ou sites de production ? Exemple : les audits des sites de production sont facilement accessibles et exploitables pour vérifier que vos fournisseurs de rang 1 respectent les standards de votre marque.
6. Les données peuvent-elles facilement être réutilisées pour plusieurs usages ? Exemple : ces données alimentent tous vos cas d'usage, quel que soit le service concerné : gestion du risque fournisseur, fiches produit AGEC, éco-conception, conformité réglementaire, etc.

Vos réponses à ces six questions vous permettront de dresser un bilan clair de la structuration interne de vos données produit et fournisseur. L'objectif ? Éviter de créer une énième base de données en silo dédiée au DPP, sans anticiper les enjeux de fond liés à la qualité et à la circulation des données.

‍

Ce diagnostic posé, reste à identifier les chantiers à anticiper côté IT.

2. Anticiper : les quatre chantiers IT à préparer

Chantier 1 : cartographier la source de chacune de vos données produit, fournisseur et documentaire

Qu'elle soit unique (aussi appelée Single Source of Truth ou SSOT) ou multiple, la source de vérité de chacune de vos données doit être identifiée et accessible à l'ensemble de vos équipes. Et pour assurer la fiabilité des données qu'elles contiennent, ces sources doivent être régulièrement mises à jour. Sans cette cartographie, vos équipes encourent plusieurs risques :

1. Travailler sur des versions différentes d'une même information, entraînant des divergences potentielles dans les communications qui s'en nourrissent,
2. Collecter plusieurs fois les mêmes informations, surchargeant les destinataires de ces collectes,
3. Être incapable de justifier l'origine d'une donnée en cas de contrôle, faute de savoir d'où elle provient et quand elle a été mise à jour pour la dernière fois.

Mais identifier vos sources de vérité ne suffit pas. Encore faut-il que la donnée circule de l'une à l'autre, sans ressaisie ni perte d'information. C'est tout l'enjeu du deuxième chantier : la connexion entre vos différents systèmes.

Chantier 2 : assurer la connexion entre vos différents systèmes

Nouvelle réglementation ne rime pas forcément avec remplacement des outils en place. Dans le cas du Digital Product Passport, en revanche, la diversité des données exigées impose à vos différents systèmes de communiquer entre eux. Qu'elle passe par API, SFTP ou imports automatisés, l'interopérabilité de vos outils devra :

• Assurer la bonne transmission de vos données d'un outil à un autre,
• Rattacher les données fournisseurs et documentaires à la bonne référence ou au bon lot,
• Vérifier la cohérence des informations entre elles.

Mais si des systèmes bien connectés sont indispensables dans le cadre du DPP, ils ne garantissent pas pour autant des données fiables : une information erronée circulera tout aussi vite qu'une information juste. C'est là qu'entre en jeu le troisième chantier : le contrôle de la qualité des données.

Chantier 3 : contrôler la qualité des données

Dans le cas du DPP, comme pour la plupart des réglementations de l'Union européenne, les obligations portent sur le résultat, et non sur les moyens mis en place pour l'obtenir. Dans ce contexte, communiquer une donnée erronée peut coûter aussi cher à votre entreprise que de ne pas communiquer de donnée du tout.

Votre enjeu ? Garantir la qualité des données collectées auprès de vos différentes parties prenantes. Vos outils doivent ainsi vous permettre de :

• Réaliser une analyse des écarts (gap analysis) pour identifier les données manquantes,
• Connaître la date de mise à jour des données collectées,
• Évaluer la cohérence des données entre vos différents systèmes, et d'une campagne de collecte à l'autre,
• Disposer des preuves nécessaires pour justifier les déclarations de vos parties prenantes.

Une fois fiabilisées, ces données serviront bien au-delà de la seule conformité réglementaire. Encore faut-il avoir anticipé, dès le départ, l'ensemble de leurs usages possibles : c'est l'objet de votre dernier chantier.

Chantier 4 : anticiper les multiples usages de vos collectes de données

Collecter des données pour le seul Passeport Numérique des Produits reviendrait à reproduire l'écueil évoqué plus haut : créer une énième base de données en silo, coûteuse à alimenter et vite obsolète. Il faut en effet garder en tête que la plupart des informations exigées par le Digital Product Passport sont déjà demandées par d'autres équipes, pour d'autres usages.

Votre enjeu ? Concevoir, dès le départ, une collecte capable de soutenir l'ensemble des cas d'usage de vos équipes. Collectée une seule fois auprès de vos fournisseurs, une même donnée pourra ainsi alimenter :

• La conformité réglementaire, pour permettre à vos équipes juridiques et RSE de répondre aux exigences de la loi AGEC, de l'affichage environnemental ou du devoir de vigilance, et de justifier chacune de vos allégations environnementales,
• Le reporting extra-financier, en fournissant les données de la chaîne de valeur nécessaires au calcul de votre Scope 3 dans le cadre de la CSRD,
• La fin de vie et l'économie circulaire, car la composition précise de vos produits (fibres, pourcentages, accessoires, substances) conditionne leur tri et leur recyclage par les filières spécialisées. Associée à la part de matières recyclées et aux critères de durabilité, elle détermine aussi le montant de vos éco-modulations et facilite la revente de vos produits en seconde main,
• Les enjeux commerciaux et marketing, pour enrichir vos fiches produit e-commerce, répondre aux exigences des distributeurs et des marketplaces ou constituer vos dossiers d'appels d'offres, publics comme privés,
• Les achats et le pilotage, pour permettre à vos équipes sourcing de gérer la sous-traitance et le risque fournisseurs, et à vos équipes produit d'orienter leurs choix d'éco-conception.

Cela suppose de penser vos modèles de données au-delà du seul périmètre du DPP : prévoir les champs nécessaires à chaque usage, faciliter les exports vers différents formats et ouvrir l'accès aux équipes concernées. Un effort initial plus important, mais qui vous évitera de solliciter vos fournisseurs à chaque nouvelle exigence.

3. Agir : enclencher le projet sans tout transformer

Sources de vérité, connexion des systèmes, contrôle de la qualité, anticipation des usages : ces quatre chantiers peuvent laisser penser qu'une refonte complète de votre système d'information est inévitable. Ce n'est pas le cas. Les exigences détaillées du Digital Product Passport ne sont pas encore toutes connues : elles seront précisées, catégorie de produits par catégorie de produits, par les actes délégués de la Commission européenne. Tout transformer aujourd'hui serait donc prématuré.

À l'inverse, attendre la publication de toutes les exigences réduirait d'autant votre marge de manœuvre.

Pour enclencher le projet sereinement, une démarche progressive vous permettra de limiter les risques tout en préparant le passage à l'échelle.

Définir votre cible

« Être prêt pour le DPP » ne recouvre pas la même réalité pour toutes les entreprises. Votre cible dépend de vos catégories de produits, de vos marchés, de la complexité de votre chaîne d'approvisionnement et de vos objectifs à court et moyen termes : étendre vos marchés à l'international, réintégrer une partie de votre supply chain, etc. C'est cette cible qui déterminera le périmètre de données à couvrir.

Concevoir l'architecture cible

Le pilote que vous lancerez ne doit pas être un test purement opérationnel, conçu pour fonctionner sur un périmètre restreint puis être abandonné. Son architecture doit refléter celle que vous déploierez à terme. Les quatre chantiers évoqués plus haut doivent donc être définis en amont :

• Les sources de vérité de chaque donnée,
• Les connexions entre vos systèmes,
• Les mécanismes de contrôle de la qualité,
• Les différents usages auxquels la donnée devra servir.

L'objectif ? Garantir une chaîne de traçabilité de la donnée (chain of custody) complète, de sa collecte à sa publication, que le pilote viendra ensuite éprouver.

Identifier les briques manquantes

Vos outils actuels couvrent généralement une partie du besoin. PLM, PIM et ERP gèrent efficacement la donnée produit interne, mais ils ne sont pas conçus pour collecter des données auprès de fournisseurs de rang 1, 2 et plus, stocker les preuves associées, ou suivre leur mise à jour. Ces fonctions requièrent aujourd’hui une solution complémentaire spécialisée dans la collecte et la traçabilité des données fournisseurs, qu’elle soit externe ou développée en interne. Si vous optez pour la première option, il s'agit alors d'identifier les solutions existantes, la partie du problème à laquelle chacune répond, et leur capacité à s'intégrer à votre architecture.

Cadrer et lancer le pilote

Pour assurer la maîtrise de votre pilote, mieux vaut partir sur un périmètre restreint : une catégorie de produits, une collection et quelques fournisseurs de rang 1. Sur ce périmètre, l'objectif est de collecter les données exigées par le DPP, en distinguant celles déjà disponibles en interne de celles à obtenir auprès de vos fournisseurs. Le pilote permet ainsi de :

• Valider vos choix techniques et financiers avant de vous engager à grande échelle,
• Vérifier les impacts de l’intégration d'une solution complémentaire à vos outils existants,
• Identifier les écueils de votre situation actuelle : données manquantes ou peu fiables, systèmes difficiles à connecter, réactivité inégale des fournisseurs, charge de travail sous-estimée pour vos équipes.

Ajuster, puis étendre

Les enseignements du pilote permettent de corriger l'architecture avant de la déployer. Une fois validée, elle pourra être étendue progressivement à d'autres catégories de produits et à d'autres fournisseurs, sans remise en cause structurelle de ses fondations.

4. Cas concret : chez IKKS, une approche automatisée au service du DPP

Chez IKKS, l'architecture qui servira demain au DPP est déjà en place. À l'origine du projet, une triple pression : 

1. Les exigences croissantes des distributeurs qui commercialisent les collections de la marque, comme La Redoute ou les Galeries Lafayette, sur la fiabilité des allégations environnementales ; 
2. Une charge de travail manuelle devenue difficile à tenir, notamment en raison des changements de composition tardifs liés au développement produit ; 
3. La nécessité d'anticiper les obligations réglementaires. 

Pour y répondre, la marque a fait le choix d'une approche automatisée, construite en quatre temps : cadrer les besoins métier, connecter son PLM à une brique de traçabilité, valider l'intégration avant la mise en production, puis répliquer l'architecture sur de nouveaux usages.

Cadrer : définir le « pourquoi » avant le « comment »

Avant toute intégration technique, le projet a commencé par un cadrage métier, mené conjointement par les équipes RSE, achats, IT et commerce. Trois objectifs ont été fixés : réduire les risques business, anticiper et sécuriser la conformité réglementaire, et optimiser la productivité des équipes. Le constat de départ était clair : l'alimentation de l'outil de traçabilité et la génération des QR codes étaient entièrement manuelles, et les données utilisées pour le bilan carbone manquaient de fiabilité.

Connecter : faire du PLM la SSOT

Plutôt que de recréer les données produit dans une nouvelle plateforme, le choix a été fait de restructurer le PLM Lectra et de le conserver comme source de vérité produit. Ses données clés sont désormais transmises de manière automatique et quotidienne à Trace For Good, qui joue le rôle de brique complémentaire. Les doubles saisies et les retraitements disparaissent, et les informations restent cohérentes entre le PLM, l'outil de traçabilité et les passeports produits.

Valider : sécuriser l'intégration avant la mise en production

Avant de basculer définitivement, l'ancien processus manuel et le nouveau flux automatisé ont fonctionné en parallèle (double run). Les équipes ont ainsi pu comparer les données transmises par les deux canaux, vérifier leur cohérence et corriger les écarts avant la mise en production. L'outil a été ajusté par itérations rapides, à partir des usages réels, et les équipes achats et produit ont été formées dans le même temps, sans qu'aucun logiciel existant ne soit supprimé.

Répliquer : une architecture prête pour la suite

Les fiches produit, les QR codes et les books produit destinés aux équipes de vente et aux distributeurs sont désormais générés sans intervention manuelle. Les données sont exploitables pour l'analyse de cycle de vie, l'affichage environnemental et le pilotage de l'éco-conception. Surtout, l'architecture mise en place peut être répliquée sur d'autres périmètres et d'autres besoins métier, dont le DPP. Une architecture qu'il s'agira de déployer, à plus grande échelle, lorsque les exigences du Passeport Numérique des Produits entreront en vigueur.

Conclusion : 3 étapes pour lancer votre projet DPP sans tout transformer

Le DPP, un simple QR code ? Vous l'aurez compris : loin de là. Si le QR code en est la partie visible, le Digital Product Passport repose avant tout sur une infrastructure de données produit, fournisseur et documentaire : des sources de vérité identifiées, des systèmes connectés, une qualité contrôlée et une collecte pensée pour servir bien au-delà de la seule conformité. Un sujet qui concerne donc, en premier lieu, vos équipes IT.

Pour autant, nul besoin de tout transformer pour vous y préparer. La marche à suivre tient en trois temps :

• Diagnostiquer : faire l'état des lieux de vos données, de leurs sources et de leur circulation,
• Anticiper : préparer les quatre chantiers IT qui structureront votre architecture,
• Agir : lancer un pilote sur un périmètre restreint, conçu dès le départ pour passer à l'échelle.

Comme le montre l'exemple d'IKKS, les fondations posées aujourd'hui pour répondre à vos enjeux actuels seront celles de votre DPP demain. Plus tôt elles seront posées, plus sereinement vous aborderez les futures exigences réglementaires et commerciales.

Votre première étape ? Le diagnostic.