ISO/IEC JTC 5 : préparer l’architecture à l’interopérabilité des DPP

Pourquoi l’architecture devient maintenant un sujet prioritaire

Le passeport produit numérique est introduit progressivement en Europe par des actes législatifs sectoriels. Les entreprises peuvent facilement en déduire que chaque groupe de produits a besoin de son propre modèle de données, de son propre support de données et de sa propre logique d’intégration. C’est précisément à cette interface qu’intervient l’ISO/IEC JTC 5 : le comité technique commun, créé en 2026, doit élaborer les fondements d’une interopérabilité DPP entre secteurs et systèmes. Sa première réunion annoncée aura lieu du 7 au 9 septembre 2026 à Berlin. L’ISO/IEC JTC 5 décrit explicitement son mandat comme un cadre pour le système DPP et l’écosystème DPP ; les normes spécifiques aux secteurs restent du ressort des comités spécialisés compétents.

Il ne s’agit ni d’une nouvelle obligation légale ni d’une norme ISO publiée. C’est toutefois une raison solide de dissocier sa propre architecture des champs de données à court terme. Le premier axe de travail, ISO/AWI 25534-1, en est encore au stade de projet 10.99 ; le projet a été approuvé le 12 février 2026. Selon l’ISO, il porte sur les termes, les principes fondamentaux, les catégories de données ainsi que les mécanismes de gouvernance et de confiance. La fiche publique du projet indique explicitement « under development ». En déduire dès aujourd’hui une obligation de certification ou un format d’échange finalisé serait prématuré.

Ce qui distingue le cadre international des exigences de l’UE

L’UE fixe déjà des orientations concrètes. La Commission explique que le DPP rend accessibles les informations relatives au produit dans un modèle décentralisé : les données complètes restent auprès de l’opérateur économique ou du fournisseur de services DPP ; le registre contient les identifiants uniques et les données d’enregistrement prescrites. Un support de données tel qu’un code QR relie le produit physique à son passeport. La DPP page de la Commission mentionne également des accès différenciés selon les rôles et des calendriers sectoriels.

À cela s’ajoutent les normes européennes harmonisées. La décision d’exécution (UE) 2026/1736 du 14 juillet 2026 renvoie à six normes DPP, notamment sur les identifiants, l’interopérabilité, les supports de données, les API, l’échange et le stockage des données. Leur rôle est concret : pour les exigences qu’elles couvrent, leur respect peut étayer la présomption de conformité au titre des articles 10 et 11 de la ESPR.

Le JTC 5 ne remplace pas ces niveaux. Il travaille au-dessus d’eux : un cadre neutre du point de vue sectoriel doit aider à expliquer comment les termes, les catégories de données, la confiance et la gouvernance s’articulent entre les systèmes. La conséquence pratique est importante. Un fabricant ne devrait pas attendre une future édition ISO pour mettre à disposition ses informations sur les batteries, les textiles ou l’acier. Il devrait en revanche éviter de figer les champs sectoriels actuels comme le noyau immuable d’un modèle DPP à l’échelle de l’entreprise.

Trois décisions d’architecture pertinentes dès aujourd’hui

1. Séparer l’identité stable des profils métier

Un passeport a besoin d’une identité technique durable : produit, variante, lot ou article individuel ; opérateur économique responsable ; résolution via le support de données. La base juridique détermine ensuite les informations métier nécessaires. Ces informations doivent être intégrées à des profils versionnés. Un module de batterie destiné aux données de CO₂ ou de niveau de charge n’est donc pas un schéma de base général. De même, les données sur les matériaux, les réparations ou le recyclage ne doivent pas être conservées uniquement sous forme de texte libre non structuré dans un passeport général.

En pratique, un identifiant central stable, un identifiant de profil documenté et une version de profil vont de pair. Chaque vue de passeport distribuée devrait permettre de déterminer quel profil et quelle version ont défini son contenu. Les équipes peuvent ainsi intégrer un acte législatif, une règle sectorielle ou, ultérieurement, une norme, sans réécrire les données historiques ni les URL.

2. Modéliser séparément la provenance des données et les accès

L’interopérabilité ne se résume pas à un format JSON. Elle dépend de la capacité du destinataire à évaluer l’origine, la validité et le rôle d’une information. Enregistrez donc, pour chaque élément ou paquet de données, au minimum la source, le champ d’application, la date de collecte, la partie responsable et la version métier. Une valeur de qualité interne est différente d’une déclaration de conformité juridiquement contraignante ; une information fournie par un fournisseur est différente d’une valeur mesurée.

Le deuxième aspect concerne l’accès. La Commission décrit des accès différenciés aux informations pour les consommateurs, les ateliers de réparation, les recycleurs et les autorités. Cela exige de séparer consciemment la vue publique du passeport, l’accès métier autorisé et l’espace de travail interne. Une URL ne doit pas devenir un droit d’accès. Les rôles, mandats, catégories de données et décisions traçables doivent être vérifiés côté serveur.

3. Tester les limites d’échange comme des contrats

Un système DPP comporte plusieurs transitions : l’ERP ou le PLM fournissent les données de référence, les fournisseurs apportent des justificatifs, un prestataire de services héberge les données, un registre reçoit les métadonnées et les utilisateurs externes consultent une vue publique ou protégée. Chaque transition nécessite un contrat lisible par machine : champs autorisés, identifiants, sémantique, cas d’erreur, gestion des versions et rétrocompatibilité.

Cela peut être testé dès maintenant. Les cas de test pertinents comprennent les versions de profil inconnues, les justificatifs expirés, l’absence de provenance des données, les rôles non autorisés, les enregistrements en double et un support de données renvoyant vers un passeport qui n’est plus disponible. Le test ne prouve pas encore la conformité à une future norme ISO. Il crée toutefois la traçabilité qui fera défaut lors de la transition ultérieure, si le modèle de données et les droits ont déjà été mélangés de manière indissociable.

Un plan de travail sur 90 jours, sans spéculation

Au cours des 30 prochains jours, il est utile d’établir un état des lieux : quels identifiants de produits existent, quels profils de données sont effectivement utilisés et quelles données ne figurent que dans des documents ? Vient ensuite une décision d’architecture : modèle central, registre des profils, modèle de provenance et matrice des accès. Dans un troisième temps, un produit réel devrait suivre toutes les transitions — du système source au passeport, puis jusqu’au rôle de l’atelier de réparation ou de l’autorité.

Les limites restent claires. ISO/AWI 25534-1 n’est pas une norme finalisée ; aucune clause publiée ne peut être mise en œuvre par les équipes. De même, le calendrier de la Commission est indicatif et ne remplace pas l’examen de l’acte législatif applicable à chaque groupe de produits. L’intérêt de cette veille ne réside donc pas dans une coche anticipée sur une liste de conformité, mais dans une architecture capable d’intégrer proprement de nouveaux profils, rôles et règles d’échange.