Commencer par la frontière : données confirmées ou candidates
L’ESPR établit des briques communes du passeport, mais la mesure applicable au produit sélectionne les informations finales d’une catégorie. Un inventaire de préparation utile doit donc comporter deux couches : l’architecture confirmée et les données produit candidates.
L’architecture confirmée comprend le lien entre support, identifiant persistant et information structurée, l’exactitude et l’actualité des données, les droits d’accès et la continuité. Les données candidates peuvent couvrir les matériaux, la durabilité, la réparation, le contenu recyclé, la performance environnementale ou d’autres attributs retenus par la future règle.
Sources de cette section
Les sept groupes de données à cartographier maintenant
L’objectif n’est pas de prédire chaque champ final. Il s’agit de révéler où se trouvent les données, qui peut les attester et avec quelle fiabilité elles peuvent alimenter un service de passeport. Les groupes suivants offrent un point de départ transversal.
- Identité produit : modèle, lot, article, SKU, GTIN ou autres identifiants, variantes et liens entre eux.
- Opérateurs économiques : fabricant, importateur, mandataire, distributeur et entité juridique mettant le produit sur le marché de l’UE.
- Fournisseurs et sites : organisation source, identité du site, propriétaire de la preuve et niveau de divulgation autorisé.
- Composition : matériaux, composants, substances, poids, unités, méthode de calcul et pièces justificatives.
- Conformité et instructions : déclarations, certificats, essais, manuels, sécurité et codes marchandises applicables.
- Cycle de vie : réparation, pièces, démontage, usage, retour, remanufacture et fin de vie selon le cas.
- Gouvernance : responsable, réviseur, statut, date d’effet, corrections, classe d’accès, conservation et prochain déclencheur de révision.
Sources de cette section
Transformer l’inventaire en registre de preuves
Une valeur sans provenance devient un futur problème de rapprochement. Pour chaque champ candidat, enregistrez la valeur, l’unité, le niveau produit, le système et document sources, le fournisseur ou responsable interne, l’état de vérification, la date d’effet et la personne qui peut approuver la publication.
Utilisez des états explicites : fourni par le fournisseur, calculé, estimé, vérifié, expiré, inconnu et non applicable. Une interface propre ne fera ainsi pas paraître équivalentes une preuve faible et une donnée contrôlée. L’équipe peut mesurer les lacunes sans les remplir par du discours marketing.
- Nom du champ et définition en langage clair.
- Niveau modèle, lot ou article et identifiant de rapprochement.
- Système de référence et document justificatif ou calcul.
- Responsable, approbateur, état de vérification et audience autorisée.
- Événement de mise à jour, durée de conservation et chemin de correction.
Sources de cette section
Mener un sprint de préparation de 30 jours
Choisissez une famille de produits représentative au lieu de répertorier toute l’entreprise. Incluez assez de variantes et de complexité fournisseurs pour exposer les vrais raccordements, tout en gardant un périmètre assez petit pour terminer. Le résultat est un modèle opérationnel réutilisable, pas une démonstration isolée.
- Semaine 1 : classer le périmètre, les entités juridiques, les identifiants et les systèmes de référence.
- Semaine 2 : collecter les preuves des sept groupes et marquer les lacunes.
- Semaine 3 : définir l’accès, l’approbation, la correction, l’export et la sortie du prestataire.
- Semaine 4 : publier un prototype contrôlé, tester les pannes et consigner les hypothèses ouvertes.
Ce qu’il ne faut pas figer avant l’acte sectoriel
Ne transformez pas le modèle d’un consultant, le jeu de données d’un pilote ou les valeurs par défaut d’un logiciel en liste juridique d’une catégorie non stabilisée. Évitez les décisions irréversibles sur le support, l’identité à l’article, la conservation et l’accès public tant que l’acte applicable ne les soutient pas.
Vous pouvez néanmoins tester ces choix comme hypothèses. Consignez la source, la confiance, le coût de réversibilité et l’événement qui rouvrira la décision. Le prototype restera utile même si la règle finale diffère de l’estimation actuelle.
- Ne présentez pas chaque champ candidat comme obligatoire.
- N’assimilez pas une donnée fournisseur absente à zéro ou non applicable.
- Ne laissez pas un prestataire détenir l’unique copie des identifiants ou des preuves.
- Ne publiez pas de données sensibles sans décision d’accès au niveau du champ.
- Ne présentez pas un prototype terminé comme preuve de conformité juridique.
Sources de cette section
Questions fréquentes
Existe-t-il un modèle final de données DPP pour tout produit ?+
Non. L’ESPR établit l’architecture commune et des briques d’information possibles, tandis que la règle produit applicable détermine le jeu final, la granularité, l’accès et le calendrier de son périmètre.
Faut-il demander des données DPP aux fournisseurs maintenant ?+
Oui, si la demande est présentée comme cartographie des preuves et préparation. Définissez chaque champ, autorisez l’état inconnu, consignez la provenance et ne présentez pas la liste comme modèle juridique final lorsque l’acte sectoriel est en attente.
Quel système doit contenir les données DPP ?+
Il existe rarement un seul système de référence. Cartographiez les sources autoritatives entre ERP, PIM, PLM, fournisseurs, conformité et service, puis définissez comment les données sont assemblées, approuvées, publiées, exportées et corrigées.