L'UE a déjà construit une architecture de référence pour le passeport

Pendant que les entreprises attendent les actes délégués, des travaux financés par l'UE ont construit et testé ce à quoi devrait ressembler un système de passeport numérique de produit (DPP). CIRPASS-2 a publié une architecture de référence, version 1.1, en juin 2026, et les pilotes tournent sur les catégories mêmes qui affrontent les premières des règles contraignantes : textile, électronique, construction et pneumatiques.

Cela vaut la peine d'être connu même si rien de tout cela n'est la loi.

Ce qu'est, et n'est pas, une architecture de référence

C'est une description des blocs de construction dont un système de passeport a besoin, des rôles que jouent les différents acteurs, et d'un ensemble de recommandations sur la façon dont ils devraient interagir. Elle les met en regard des exigences de l'ESPR.

Elle n'est pas contraignante. Rien n'y oblige personne, et un système qui s'en écarte n'est pas non conforme.

Ce qu'elle est, en pratique, c'est l'énoncé public le plus détaillé de ce à quoi ressemble le « bien » du côté de l'écosystème qui influencera les normes. Quand l'interopérabilité sera jugée, c'est dans ce vocabulaire qu'elle le sera.

Pourquoi cela compte commercialement plus que techniquement

Le risque que les conseils d'administration manquent avec les passeports n'est pas d'échouer à un contrôle. C'est de choisir un système incapable d'échanger des données avec les systèmes que choisissent vos clients et vos fournisseurs.

Un passeport qui ne répond qu'à l'intérieur de la plateforme d'un prestataire fonctionne très bien jusqu'à ce que le système achats d'un client veuille le lire automatiquement, qu'une place de marché veuille l'afficher, ou qu'un recycleur veuille l'interroger dix ans plus tard. À ce moment-là, un système fermé cesse d'être une décision produit et devient quelque chose que votre chaîne d'approvisionnement doit contourner.

L'architecture de référence existe précisément pour éviter cette issue, c'est pourquoi s'y aligner est une couverture plutôt qu'un exercice de conformité.

Ce qu'il faut demander à un prestataire à ce sujet

Trois questions qui ne vous obligent pas à lire un document de 97 pages.

Connaissez-vous l'architecture de référence CIRPASS-2, et où vous en écartez-vous ? La réponse utile nomme un écart et l'explique. Un prestataire qui revendique un alignement complet avec un document encore à l'état de recommandation en fait trop.

Quelles catégories pilotes avez-vous examinées ? Les pilotes sont publics et font remonter de vrais problèmes d'intégration, en particulier sur l'échange de données avec les fournisseurs.

Comment gérez-vous les mises à jour soumises par des tiers ? Fournisseurs et réparateurs qui versent des données dans le passeport de quelqu'un d'autre, c'est là que l'architecture devient précise, et là que les implémentations divergent le plus.

La lacune à signaler

Une observation sur le périmètre de l'architecture plutôt qu'une critique : il n'y a pas de bloc de construction pour la vérification d'authenticité côté consommateur, et la contrefaçon n'est pas traitée comme un cas d'usage. Le scan est modélisé comme un moyen d'atteindre des données, pas comme un moyen de vérifier qu'un produit est authentique.

C'est là que se situe notre propre application consommateur, et c'est la raison pour laquelle nous traitons authenticité et passeport comme un seul code plutôt que deux systèmes. C'est une observation sur ce que couvre le modèle de référence, pas la preuve que personne d'autre ne s'en occupe.

Sources

• CIRPASS-2, *D4.1 Reference Architecture*, version 1.1, 9 juin 2026, y compris les blocs de
• construction du prestataire de services DPP et les recommandations d'architecture.