Quel modèle de données choisir pour le passeport batterie ? (état au 18 septembre 2026)

État des faits au 18 septembre 2026. C'est la première chose à dire, et la plus importante : cet article décrit une situation qui bouge tous les deux à trois mois. Si vous le lisez au printemps 2027, sautez directement à la dernière section — au moins deux des lignes du tableau ci-dessous auront cessé d'être vraies.

Une entreprise qui cherche aujourd'hui « le modèle de données du passeport batterie » tombe presque systématiquement sur le dépôt GitHub batterypass/BatteryPassDataModel et sa version 1.2.0. Elle en conclut que c'est le standard à suivre. C'est l'ancien modèle, issu d'un projet terminé — et le dépôt le dit lui-même depuis le 14 septembre 2026.

La réponse courte

La suite explique pourquoi cette répartition existe, et pourquoi elle est instable par construction.

Ce qui est fixé, et ce qui ne l'est pas

Le règlement (UE) 2023/1542 impose un passeport numérique à partir du 18 février 2027 pour trois catégories : véhicules électriques, mobilité légère (LMT), et batteries industrielles de plus de 2 kWh, stockage stationnaire compris. Le passeport est à l'article 77, la liste des informations à l'annexe XIII. La Commission a précisé cette liste dans une guidance publiée en version 2.0 le 15 août 2026 : 71 points de donnée, avec leur applicabilité par catégorie.

Ce niveau-là est stable. Quelles informations doivent figurer dans un passeport batterie est une question tranchée par le droit.

Le règlement, en revanche, ne dit pas comment nommer les champs, comment les structurer, ni comment les sérialiser. Ce format doit venir d'un catalogue sémantique publié par la Commission, qui n'existe pas encore pour les batteries. Ce n'est pas une supposition : le guide utilisateur du registre européen des DPP, publié par la DG GROW, indique noir sur blanc que l'enregistrement des passeports batterie n'est pas disponible, précisément parce que le catalogue sémantique de ce groupe de produits n'a pas encore été défini. Nous l'avons détaillé dans notre article sur le registre DPP.

Ce qui existe, c'est l'infrastructure. Le comité CEN-CENELEC JTC 24 a produit huit normes pour le passeport numérique de produit — identifiants uniques, data carriers, protocoles d'échange, API, persistance, interopérabilité, soit les références EN 18216 à EN 18223, publiées en 2026. Elles décrivent la plomberie, pas le vocabulaire métier des batteries.

D'où la situation actuelle : la donnée est fixée, la tuyauterie est normalisée, et le vocabulaire qui relie les deux est encore l'objet de travaux pré-normatifs.

Le dépôt GitHub s'est déclaré obsolète lui-même

Le 14 septembre 2026, une bannière est apparue en tête du README de batterypass/BatteryPassDataModel :

Le projet BatteryPass s'est achevé avec succès en avril 2025. Ce dépôt n'est plus activement maintenu et n'est fourni qu'à titre de référence pour le moment. Il contient le modèle de données BatteryPass tel qu'il était en 2025. Pour les développements en cours et les dernières informations sur les exigences réglementaires et de normalisation, veuillez consulter le projet successeur BatteryPass-Ready.

C'est le fait le plus utile de tout cet article, parce qu'il est vérifiable en dix secondes et qu'il contredit ce que le référencement vous propose. Entre janvier 2025 et septembre 2026, le dépôt n'a reçu que des modifications éditoriales : passage des licences en CC BY 4.0 en octobre 2025, ajout de preferred names pour l'AAS en novembre 2025. Le modèle, lui, est resté en 1.2.0.

Un dépôt qui ne bouge pas pendant vingt mois dans un domaine où la réglementation bouge tous les trimestres n'est pas un standard stable. C'est un standard abandonné.

Les deux modèles ne sont pas deux versions du même objet

C'est l'erreur qui coûte le plus cher, parce qu'elle conduit à planifier une « migration 1.2.0 → 2.0 » qui n'existe pas. La documentation du BatteryPass-Ready Data Model est explicite, dans sa section Relation to Other Work :

Le BatteryPass-Ready Data Model est un développement nouveau et ne représente pas une version actualisée du précédent Battery Pass Data Model publié sur GitHub.

Même base normative — la DIN DKE SPEC 99100 —, mais reconstruction complète dix-sept mois plus tard, en intégrant en plus les travaux du JTC 24 et l'ESPR. Ce que cela change concrètement :

La dernière ligne est le seul domaine où l'ancien modèle garde un avantage, et il n'est pas mince : les semanticId par attribut le rendent directement exploitable dans un Asset Administration Shell ou dans un dataspace Catena-X. Le modèle BatteryPass-Ready ne les porte pas.

« v1.3 » n'est pas plus récent que « 1.2.0 »

Piège de numérotation, et il fait perdre du temps à tout le monde : la longlist et le data model sont deux objets différents, chacun avec son propre compteur de version.

• •La Data Attribute Longlist est un inventaire d'attributs, livré en tableur. Ses versions : 2023, v1.2 en janvier 2025, v1.3 en mars 2026 (100 attributs), v2.0 le 27 août 2026 (92 attributs).
• •Le Data Model est un jeu de schémas. Côté Battery Pass : 1.0.0 le 28 mai 2024, 1.2.0 le 14 janvier 2025. Côté BatteryPass-Ready : v1.0 le 24 juin 2026, v2.0 le 27 août 2026.

Le modèle BatteryPass-Ready est parti en v1.0 parce que c'était sa première version, pas parce qu'il serait antérieur à la 1.2.0 du dépôt GitHub. Quatre versions de la liste d'attributs en trois ans, deux modèles de données successifs en quinze mois : c'est la cadence réelle du domaine.

Ce que la v2.0 du 27 août 2026 a changé

• •92 attributs, contre 100 en v1.3.
• •8 catégories au lieu de 7, avec l'apparition d'une catégorie DPP header dérivée des exigences d'interopérabilité d'EN 18223.
• •Un marquage explicite des exigences : M (mandatory), C (conditional), V (voluntary), ou aucun.
• •De nouveaux attributs issus des normes JTC 24 (content specification IDs) et de l'acte d'exécution sur le registre (third party service provider).
• •Une base passée des brouillons du JTC 24 aux normes finales publiées en juin 2026, selon le changelog du projet.
• •Un onglet Technical references qui mappe explicitement la longlist vers le modèle — la pièce la plus utile du lot si vous devez construire un tableau de correspondance.
• •71 attributs obligatoires au 18 février 2027, ce qui recoupe exactement les 71 points de donnée de la guidance de la Commission.

Pourquoi ce sont des consortiums allemands qui publient le modèle

La question revient à chaque atelier, et la réponse évite des malentendus.

Deux projets successifs, financés par le ministère fédéral allemand de l'économie sur la même ligne budgétaire (16BZF363), ont produit ces livrables. Battery Pass (avril 2022 → avril 2025), coordonné par Systemiq, a produit la Content Guidance, la Technical Guidance, la spécification DIN DKE SPEC 99100 et le modèle publié sur GitHub. BatteryPass-Ready (2025 → 2027) lui a succédé, avec acatech, Bitkom, Fraunhofer IPK, GEFEG, TU Berlin, VDA, VDMA et ZIV : Data Attribute Longlist, nouveau modèle de données, et un environnement de test en ligne.

Pourquoi pas l'AFNOR ? Parce que ce n'est pas son rôle. Sur le DPP, la compétence est européenne — c'est le JTC 24 — et l'AFNOR y participe via sa commission miroir AFNOR/CN DPP, puis publie les normes européennes en NF EN ; les règles du CEN-CENELEC n'autorisent pas un organisme national à publier une norme concurrente pendant un travail européen en cours. Côté allemand, la DIN DKE SPEC 99100 n'est pas une norme non plus : une DIN SPEC est un document pré-normatif à cycle court, produit par un consortium auto-constitué, sans le consensus national qu'exige une norme. C'est l'instrument qui permet de publier vite, à côté du circuit normatif.

Le mot juste pour ces travaux est donc pré-normatif. Ils associent des fédérations industrielles et des institutions de recherche publiques, sur financement public, et leur production alimente le circuit normatif sans s'y substituer.

Alors, lequel choisir ? Quatre situations

Vous démarrez la collecte. Ne commencez pas par un schéma. Ouvrez la guidance de la Commission et la longlist v2.0, et posez sur chaque attribut la seule question qui compte : qui, dans l'entreprise ou chez un fournisseur, détient cette valeur aujourd'hui ? C'est ce travail-là qui prend des mois, et il est indépendant du format retenu.

Vous devez sérialiser maintenant — proof of concept, pilote, réponse à un appel d'offres. Prenez le BatteryPass-Ready Data Model v2.0 et son environnement de validation en ligne. C'est le référentiel sectoriel le plus avancé, et le seul aligné sur l'état 2026 du droit et des normes. En sachant qu'il n'a aucune valeur réglementaire et qu'il changera.

Vous êtes dans un dataspace AAS ou Catena-X. Le modèle GitHub 1.2.0 garde son utilité comme couche sémantique, à cause des semanticId par attribut, mais il ne doit plus servir de référence de périmètre : il ignore l'état du droit depuis janvier 2025. Traitez-le comme un dictionnaire sémantique, pas comme une spécification de conformité.

Vous construisez votre modèle interne. La règle est simple : un seul modèle interne, N exports. Modélisez la donnée métier — la batterie, ses composants, ses mesures, ses documents — et traitez la longlist, le modèle BatteryPass-Ready, l'AAS et le futur catalogue sémantique de la Commission comme autant de cibles d'export. Toute autre architecture vous fait refaire le travail à chaque publication de version.

Ce qui est stable, c'est la donnée. Ce qui bouge, c'est le format.

C'est le seul arbitrage vraiment structurant, et il a une conséquence opérationnelle directe.

Un renommage de champ est une opération de mapping : quelques jours de travail, sans dépendance externe. Une donnée non collectée est un chantier industriel : il faut identifier qui la détient, souvent chez un fournisseur de rang 2 ou 3, négocier son obtention, la mesurer, la faire remonter, la contrôler. Sur les matériaux, l'empreinte carbone ou le contenu recyclé, cela se compte en trimestres.

L'entreprise qui attend « le bon modèle » pour commencer à collecter perd le temps qui compte. Celle qui collecte dès maintenant, dans son propre modèle, encaissera les changements de format comme des tâches de mapping. Le reste de la méthode de validation est détaillé dans notre article sur comment tester son passeport batterie avant 2027.

Attention : le modèle complet n'est pas l'obligation légale

Sur 92 à 100 attributs selon la version de la longlist, seuls 71 sont dus au 18 février 2027. Et certains sont explicitement à ne pas renseigner à cette date — la déclaration et le label d'empreinte carbone, notamment, dont le format attend encore un acte d'exécution.

Confondre « le modèle complet » et « l'obligation légale » conduit à un résultat contre-intuitif : afficher un passeport non conforme alors même qu'il contient tout ce que la loi demande. L'excès de zèle expose aussi à publier de l'information industrielle sans aucune obligation de le faire.

Cet article a une date de péremption

Les auteurs des modèles le disent eux-mêmes. Le changelog de la longlist v2.0 précise que certaines informations sont susceptibles de changer et ne reflètent l'état des connaissances qu'au 26 août 2026, en particulier au vu des projets de textes omnibus environnementaux et des actes d'exécution attendus sur l'étiquetage, la déclaration d'empreinte carbone et l'accès aux données. Il ajoute que les formats de données seront revus en détail au fil de l'implémentation du modèle dans l'environnement de test. Le disclaimer du consortium ne garantit ni l'exhaustivité, ni l'exactitude, ni l'actualité du contenu.

Quatre événements rendront cet article faux, et ils sont tous attendus dans les douze mois :

1. 01.La publication du catalogue sémantique des batteries par la Commission. Ce jour-là, tout ce qui précède devient de la documentation historique : le format devient opposable, et les modèles des consortiums redeviennent ce qu'ils sont, des travaux préparatoires. À surveiller sur la page « DPP — batteries » de la Commission et dans les versions successives du guide utilisateur du registre.
2. 02.Une v3.0 de la longlist ou du modèle BatteryPass-Ready. La cadence observée est d'environ six mois. À surveiller sur thebatterypass.eu.
3. 03.La publication des actes d'exécution attendus, notamment sur l'empreinte carbone. Chacun rouvre des attributs aujourd'hui marqués « à ne pas renseigner ».
4. 04.L'ouverture effective de l'enregistrement des batteries au registre européen, qui signalera que le catalogue sémantique est en place.

Si vous lisez ceci après février 2027, l'obligation est déjà entrée en vigueur : reprenez ces quatre vérifications avant d'utiliser une seule ligne de cet article. La bonne pratique, dans ce domaine, est de ne jamais citer un modèle de données sans sa version et sa date — y compris le nôtre.

En résumé

Au 18 septembre 2026 : suivez la guidance de la Commission pour le quoi, le BatteryPass-Ready v2.0 pour le comment provisoire, les normes EN 18216 à 18223 pour les échanges, et oubliez le dépôt GitHub 1.2.0 sauf comme dictionnaire sémantique pour l'AAS. Aucun de ces modèles n'a de valeur réglementaire : ce sont des candidats, en attendant le catalogue sémantique de la Commission.

Arianee opère une infrastructure DPP ouverte conçue sur ce principe : un modèle de données interne, des exports vers les formats sectoriels, et des passeports qui survivent aux changements de spécification. Voir la page Battery Pass, évaluez votre situation avec le simulateur de préparation DPP, ou demandez une démo.

Sources

• •Règlement (UE) 2023/1542 relatif aux batteries — articles 77, 78 et annexe XIII (EUR-Lex)
• •Guidance Document: Digital Batteries Passport – data points by category, v2.0, 15 août 2026 (Commission européenne, DG GROW)
• •Page « Digital Product Passport — batteries » de la Commission européenne
• •Dépôt GitHub batterypass/BatteryPassDataModel — commit de la bannière, 14 septembre 2026
• •Projet Battery Pass (2022-2025) et projet BatteryPass-Ready (2025-2027) — ressources
• •Annonce de la Data Attribute Longlist v2.0 et du Data Model v2.0, 27 août 2026 · longlist v2.0 (XLSX) · longlist v1.3 (XLSX)
• •Documentation du BatteryPass-Ready Data Model (PDF, GEFEG) — les schémas eux-mêmes sont hébergés sur le GitLab de GEFEG, dont l'accès anonyme est restreint
• •DIN DKE SPEC 99100 (PDF gratuit)
• •Comité CEN-CENELEC JTC 24 « Digital Product Passport » et commission miroir AFNOR/CN DPP