Pourquoi nous avons construit Junction autour d'un registre vivant

Chaque produit fait un pari sur le comportement de son marché. Le nôtre est que le passeport numérique de produit (DPP) sera traité comme un document à déposer, et que ce sera la manière coûteuse de faire.

Il vaut la peine d'expliquer le raisonnement, parce qu'il détermine ce que le produit fait et ne fait pas.

Le pari

Deux faits le soutiennent.

L'opérateur économique doit maintenir l'exactitude des données sur tout le cycle de vie du produit. Cette obligation ne s'arrête pas au lancement ; elle court aussi longtemps que le produit existe sur le marché, et le passeport doit servir réparateurs et recycleurs longtemps après la vente.

Et les produits changent constamment. Les fournisseurs sont remplacés, les matériaux reformulés, les sites déplacés, les certifications expirent. Aucun de ces événements ne s'annonce à un système de conformité.

Mettez les deux ensemble et un passeport assemblé une fois n'est pas seulement incomplet. Il dérive silencieusement hors de l'exactitude pendant que tout le monde croit la tâche terminée. Une déclaration publique fausse dont personne ne sait qu'elle est fausse est pire qu'une déclaration absente, d'autant que des données inexactes portent à la fois une exposition réglementaire et un risque d'indemnisation des consommateurs, comme traité dans les sanctions DPP.

Ce qui en découle

Si le registre doit rester à jour, alors il ne peut pas être un artefact distinct maintenu à côté de vos données produit. Il doit être généré depuis la source et mis à jour à mesure que la source change.

Junction garde donc le registre produit à la source et le met à jour à mesure que le produit change. Déposer le passeport devient une étape d'un processus plutôt qu'un projet avec une échéance.

Trois conséquences que nous avons acceptées délibérément.

La mise en place demande plus de travail que générer un fichier. Se connecter à l'endroit où vivent réellement les données produit et fournisseurs est plus difficile qu'exporter un tableur une fois. Nous pensons que ce coût se paie une fois et que l'alternative se paie chaque année.

La valeur apparaît en année deux. Un registre vivant n'est pas manifestement meilleur qu'un fichier généré le jour du lancement. Il l'est manifestement la première fois qu'un fournisseur change.

Cela n'aide que si la donnée en dessous est réelle. Aucun système ne convertit des déclarations fournisseurs non prouvées en preuves. Le travail fournisseurs décrit dans la checklist de préparation est le vôtre, et tout prestataire qui suggère le contraire vend quelque chose qui échouera à un contrôle.

La seconde chose que fait le code

L'autre décision de conception qui mérite d'être nommée : nous lions authenticité et passeport en un seul code par produit.

Le règlement ne l'exige pas. Il exige un support qui atteint un registre. Mais un code que n'importe qui peut photographier et réimprimer ne prouve rien sur l'exemplaire auquel il est attaché, ce qui veut dire que de bonnes données de durabilité peuvent finir attachées à un produit qui n'est pas le vôtre.

La plupart des systèmes de passeport traitent le scan comme un moyen d'atteindre des données. Nous le traitons comme un moyen de vérifier que l'exemplaire est authentique et d'atteindre ses données dans le même geste. Fait notable, l'architecture de référence CIRPASS-2 ne comporte aucun bloc de construction pour la vérification d'authenticité côté consommateur, ce que nous signalons comme une observation sur le périmètre de ce modèle et non comme une affirmation sur le produit d'autrui.

Ce que ce n'est pas

Ce n'est pas l'affirmation que tout le monde a besoin de la version vivante dès le premier jour. Une entreprise avec une gamme stable et un seul acte délégué devant elle peut raisonnablement commencer plus simplement.

C'est une affirmation sur l'endroit où tombe le coût. L'approche par fichier est moins chère à démarrer et plus chère à tenir, et la tenue court sur la vie de chaque produit que vous vendez.

Sources

• Commission européenne, *Digital Product Passport: FAQ*, mise à jour de janvier 2026, question 3 sur
• l'obligation d'exactitude des données sur le cycle de vie, question 30 sur les droits
• d'indemnisation des consommateurs.
• CIRPASS-2, *D4.1 Reference Architecture*, version 1.1, 9 juin 2026.