Notre passeport produit est un Asset Administration Shell

Deux mondes qui ne se parlaient pas

Dans une usine, un produit a déjà un jumeau numérique. Il s'appelle Asset Administration Shell (AAS), ou Verwaltungsschale dans le vocabulaire d'origine, et il est le pilier de l'Industrie 4.0 allemande depuis dix ans. Les MES, les PLM, les configurateurs machine et les outils de mise en service le lisent nativement.

À côté, depuis l'ESPR et le règlement batteries, le même produit doit porter un Digital Product Passport : un objet réglementaire, public, orienté conformité, cycle de vie et fin de vie.

Pour un fabricant de machines, d'électroménager ou de packs batterie, la question n'a jamais été « lequel des deux » mais « combien de fois vais-je devoir décrire le même produit ». Le passeport réglementaire d'un côté, le jumeau numérique de l'autre, et au milieu un export maison à maintenir.

Nous avons choisi de supprimer le milieu : un passeport Arianee est servi tel quel comme un Asset Administration Shell standard.

L'AAS en cinq lignes

L'Asset Administration Shell est normalisé par l'IEC 63278-1 et spécifié par l'IDTA (Industrial Digital Twin Association), le consortium qui porte le jumeau numérique industriel avec la Plattform Industrie 4.0.

Sa structure est simple : une coquille (le shell) identifie un actif, et l'information est rangée dans des submodels — un par aspect. L'IDTA en publie un catalogue normatif : plaque signalétique numérique (IDTA 02006), données techniques (02003), empreinte carbone et environnement (02023), documentation de remise (02004), nomenclatures hiérarchiques (02011).

L'IDTA a d'ailleurs ouvert un chantier DPP4.0 dont la thèse est exactement celle de cet article : le passeport produit européen n'a pas besoin d'un format inédit, il a besoin d'être exprimé dans le modèle que l'industrie utilise déjà, en coordination avec l'IEC et le CEN-CENELEC JTC 24.

Ce qui est implémenté

La plateforme expose la façade AAS Part 2 canonique. Les identifiants dans les chemins sont encodés en base64url, comme la spécification l'exige, et l'identifiant de coquille est dérivé de l'identifiant du passeport.

• •GET /shells/{id} — l'objet AssetAdministrationShell, avec son assetInformation et les références vers ses submodels.
• •GET /shell-descriptors/{id} — le descripteur de registre (AAS Registry / DTR).
• •GET /submodels/{id} — un submodel complet, avec les modificateurs ?content= (normal, value, metadata) et ?level= (deep, core).
• •GET /submodels/{id}/submodel-elements/{idShortPath} — un élément précis, résolu par chemin d'idShort.
• •GET /lookup/shells — Basic Discovery : d'un data carrier vers sa coquille.

Trois points comptent plus que la liste.

Un submodel par profil de données, avec sa sémantique. Chaque schéma sélectionné par le passeport devient un submodel distinct, estampillé du semanticId du schéma. Pour les modèles SAMM du passeport batterie, la sémantique descend jusqu'à la propriété : chaque SubmodelElement porte l'URN du modèle d'aspect dont il est issu, pas seulement l'enveloppe.

La nomenclature est navigable. Un passeport peut déclarer ses composants ; ils sont rendus dans la forme normative IDTA 02011 — un EntryNode, une entité par composant, des relations HasPart. Chaque composant est référencé par son data carrier, que /lookup/shells résout vers la coquille du composant. Concrètement : d'un chariot télescopique, on descend à son pack batterie, puis au passeport batterie réglementaire de ce pack, sans service d'annuaire propriétaire.

Rien n'est dupliqué. La coquille et ses submodels sont générés à la volée depuis les données vivantes du passeport. Il n'existe pas de seconde copie à resynchroniser, donc pas de dérive entre le passeport que lit un consommateur et le jumeau que lit une machine.

Catena-X : où nous en sommes

Catena-X est l'espace de données de la filière automobile européenne. Sa brique passeport produit s'appelle l'Eco Pass, standardisée par CX-0143 et implémentée en open source dans Eclipse Tractus-X. Les constructeurs et les rangs 1 y attendent leurs fournisseurs.

Ce qui est en place côté plateforme :

• •L'aspect DigitalProductPassport de Catena-X (io.catenax.generic.digital_product_passport), avec les blocs metadata et identification à la forme officielle du modèle d'aspect. La version par défaut est la 4.0.0, celle que référence le CX-0143 publié ; les versions plus récentes se configurent.
• •L'identité BPNL de l'opérateur économique, portée jusque dans metadata.economicOperatorId.
• •Les specificAssetIds Industry Core dans le descripteur de coquille — manufacturerId, manufacturerPartId, digitalTwinType — avec le réglage de visibilité qui va avec : les identifiants de type sont publics par défaut, le numéro de série reste restreint.
• •L'adressage EDC du CX-0002 : quand le connecteur est configuré, les endpoints du descripteur portent subprotocol: DSP et le corps que le consommateur utilise pour négocier son contrat d'accès.

Et ce qui ne l'est pas encore : la certification Eco Pass est en cours, pas obtenue. Elle passe par un organisme d'évaluation de la conformité (CAB) mandaté par Catena-X, comme pour tout fournisseur d'application de l'écosystème. Nous publierons la date quand elle sera signée, pas avant.

Les conséquences concrètes

Vous arrêtez de décrire le produit deux fois

Le passeport réglementaire et le jumeau numérique sont le même objet, servi sous deux vues. L'intégration que vous financez pour la conformité ESPR alimente aussi vos outils industriels, et inversement. C'est le poste de coût qui disparaît, plus que la ligne de licence.

Vos outils existants lisent le passeport sans développement

Une coquille conforme se charge dans AASX Explorer, dans BaSyx, dans n'importe quel client AAS. Une équipe méthodes peut ouvrir un passeport produit le jour même, sans attendre qu'on lui écrive un connecteur. C'est aussi ce qui rend la recette possible : on vérifie contre un outil tiers, pas contre notre propre documentation.

Un donneur d'ordre automobile peut vous consommer

Si votre client vous demande un Eco Pass Catena-X, la réponse n'est pas un projet de six mois. Le modèle d'aspect, le BPNL, les identifiants Industry Core et l'adressage dataspace sont déjà là ; reste la configuration du connecteur et la négociation des contrats d'accès, qui sont des sujets de déploiement.

Vous ne pariez pas sur un seul standard

Le même passeport est déjà servi par trois surfaces normalisées : AAS / Catena-X pour l'industrie et l'automobile, CEN/CENELEC EN 18222-18223 pour le futur registre européen, et l'API métier pour vos propres applications. Une seule donnée, trois grammaires. Le jour où l'acte délégué de votre catégorie de produits tranche en faveur de l'une d'elles, vous n'avez pas de migration à conduire.

La granularité suit le règlement

La coquille déclare un assetKind aligné sur la granularité du passeport : Type pour un modèle, Instance pour un lot ou un article. C'est la distinction que l'ESPR et le règlement batteries imposent, et elle est portée par le standard plutôt que par une convention interne.

Ce que ça ne règle pas

Trois limites qu'il vaut mieux poser tout de suite.

La certification n'est pas la compatibilité. Servir l'aspect CX-0143 correctement et être certifié Business Application Provider par un CAB sont deux choses différentes. Nous sommes dans la première, en route vers la seconde.

Le dataspace demande un connecteur. Un descripteur sans adressage DSP donne un jumeau enregistrable mais non consommable à travers l'espace de données. L'EDC se déploie et se configure ; ce n'est pas un réglage dans une interface.

L'AAS ne remplace pas la conformité. Exprimer un passeport dans le bon format ne dit rien de la complétude des données réglementaires. C'est le travail du moteur de conformité, en amont, et il reste entier.

Pourquoi ça compte maintenant

Le calendrier réglementaire et le calendrier industriel se rejoignent. Le passeport batterie est exigible au 18 février 2027, les premiers actes délégués ESPR arrivent derrière, et dans le même temps les donneurs d'ordre automobiles poussent leurs fournisseurs vers Catena-X.

Un fabricant qui traite ces deux mouvements comme deux projets séparés paiera deux fois, et maintiendra deux vérités sur le même produit. Les traiter comme un seul suppose que l'infrastructure parle les deux langues nativement.

C'est la raison d'être de cette implémentation : le format dans lequel vous devrez livrer vos données produit n'est pas encore complètement fixé, et il ne devrait pas être une décision que vous prenez aujourd'hui, ni une que vous refaites dans trois ans.