Si l’on transpose un JSON-LD propre et idiomatique dans la sérialisation étendue de la norme EN 18223, c’est d’abord son ampleur qui frappe. Cette forme est remarquablement prolixe.
La norme EN 18223 est la norme du CEN/CLC JTC 24 relative à l’interopérabilité des systèmes du passeport numérique du produit ; sa clause 4 définit le modèle sémantique, tandis que sa clause 5.2 définit la sérialisation. Cette sérialisation se présente sous deux formes. La sérialisation compressée, utilisée en production, utilise l’elementId de chaque valeur comme clé d’objet et laisse la résolution des champs dictionaryReference et valueDataType au dictionnaire de données. La forme étendue écrit tout en détail : chaque valeur devient un objet doté de son propre elementId, dictionaryReference, objectType, valueDataType et value, et trois lignes de données sources deviennent vingt.
Ce que cette verbosité permet d’obtenir
Cette verbosité n’est pas le fruit du hasard, et il est utile de comprendre ce qu’elle permet d’obtenir.
C’est ce que devient la sémantique dès lors qu’on ne peut plus partir du principe qu’elle est ouvertement accessible en ligne. Un document JSON-LD véhicule généralement sa signification via un @context : un lien que le lecteur suit pour vérifier la signification d’un champ.
La forme compressée ne fonctionne que si le lecteur peut accéder au dictionnaire associé à un champ. Cela échoue lorsque le dictionnaire est ECLASS ou IEC CDD - tous deux payants, aucun ne pouvant être consulté librement comme un IRI @context ouvert. C’est là que la forme étendue justifie sa longueur : elle consigne la signification valeur par valeur - quel dictionnaire, quelle entrée, quel type, quelle valeur - et reste auto-descriptive lorsqu’on ne peut pas compter sur le fait que le lecteur clique pour accéder aux informations.
Lue ainsi, cette prolixité n’est pas un défaut de conception, mais une réponse rationnelle aux dictionnaires fermés.
Le contraste est concret. Les vocabulaires sur lesquels nous nous appuyons - l’OpenEPCIS DPP Core et ses extensions réglementaires - sont publiés en open access sur ref.openepcis.io et restent librement résolvables. Une seule référence @context porte en elle la signification qu’un dictionnaire fermé doit y inscrire.
Pourquoi le sens de la démarche est déterminant
Reconstituer une sémantique ouverte à partir d’un dictionnaire fermé est la démarche la plus difficile. L’inverse est simple.
Notre source JSON-LD contient déjà tous les attributs exigés par le modèle de la norme EN 18223 : une référence à la propriété, une référence au dictionnaire, un type de données pour la valeur, un tableau de langues par valeur. Ils sont simplement exprimés sous forme d’objets JSON-LD typés avec des IRI @context, au lieu de la structure plate « entité-attribut-valeur » de la norme EN 18223.
Générer une vue conforme à la norme EN 18223 à partir de ces données relève d’une simple tâche de mise en forme : il suffit de reprendre les champs déjà existants et de les adapter au format cible.
Le principe en une phrase : une source avec des espaces de noms ouverts transforme chaque dictionnaire fermé en une projection, de sorte que la verbosité devient un coût que seul celui qui a commencé avec une approche fermée doit payer. Si la signification est ouverte dès la rédaction initiale, ce coût disparaît de lui-même.
Des espaces de noms pluriels au lieu d’un vocabulaire canonique
Le fait que notre source prenne déjà cette forme est un choix délibéré, et non un hasard. Nous n’imposons pas à chaque règlement un vocabulaire unique.
Chaque règlement DPP de l’UE - batteries, textiles, électronique et ceux à venir - conserve son propre espace de noms en amont : celui de GS1, celui de l’OpenEPCIS DPP Core, celui de l’extension du règlement concerné. Tous coexistent en parallèle dans un tableau @context, aux côtés d’un espace de noms transpareo: délibérément allégé pour les quelques termes qui ne sont couverts par aucun espace de noms en amont.
La norme EN 18223 exige presque exactement cela dans sa propre clause introductive 0.3 : éviter les ontologies spécifiques à un secteur, autoriser l’utilisation parallèle des ontologies publiées pour chaque acte délégué et maintenir la couche horizontale aussi générale que possible.
Une architecture reposant sur des espaces de noms ouverts et parallèles n’est pas seulement compatible avec l’intention de la norme. C’est précisément ce vers quoi tend le principe de conception de la norme elle-même.
Un test de résistance : la liste d’attributs du Battery Pass
La preuve réside dans la manière dont l’architecture intègre un dictionnaire pour lequel elle n’a jamais été conçue.
La « Data Attribute Long List » du Battery Pass Consortium, version 1.3, est un troisième dictionnaire qui s’écarte indépendamment tant de la norme EN 18223 que de GS1 : environ 100 attributs, une nomenclature propre, des niveaux d’accès spécifiques, une interprétation de l’annexe XIII du règlement sur les batteries par le consortium.
Nous l’avons comparée à notre modèle de données existant. 91 des 100 attributs ont été affectés tels quels à des types de propriétés déjà existants. Une source s’appuyant sur des espaces de noms pluriels intègre un nouveau dictionnaire fermé comme une projection supplémentaire - elle n’impose pas de reconstruction.
Où en est la norme?
La ## normeEN 18223 et sa norme sœur EN 18216, qui définit le format de sérialisation concret auquel renvoie la norme EN 18223, sont toutes deux des normes européennes harmonisées.
Elles font partie de la première vague publiée de l’ensemble CEN-CENELEC-JTC-24-DPP : six des huit normes, les deux restantes - relatives à l’authentification et aux droits d’accès - suivront au cours de l’été 2026. Ces six normes ont été citées le 15 juillet 2026 dans la décision d’exécution (UE) 2026/1736 au Journal officiel de l’UE, ce qui leur confère le statut de normes harmonisées et, par conséquent, la présomption de conformité aux articles 10 et 11 du RGPD.
Le bon côté des choses
Rien de tout cela ne fait de la norme EN 18223 une mauvaise norme. Cette prolixité est le prix à payer pour l’interopérabilité dans un monde où tous les dictionnaires ne sont pas ouverts, et la norme rend justice à ce monde.
Le côté positif est simple : pour ceux qui utilisent déjà un JSON-LD propre, la norme EN 18223 est une projection, pas une reconstruction. C’est l’autre voie qui est coûteuse - celle que doit emprunter quiconque est parti d’un dictionnaire fermé.
Pour ceux qui s’appuient dès la première ligne sur une sémantique ouverte et résolvable, la verbosité de la norme cesse d’être un frein. Elle devient un format de sortie que l’on génère en cas de besoin.