Comment tester la conformité de votre passeport de batterie UE et de votre prestataire DPP : un guide étape par étape

Votre passeport de batterie numérique est prêt. Mais comment savoir s'il répond réellement aux exigences européennes ? Et comment vérifier que votre éditeur de logiciel DPP a mis en œuvre les normes techniques nécessaires ? Ce sont deux questions décisives pour les fabricants, les importateurs et les autres opérateurs économiques qui se préparent au règlement européen relatif aux batteries.

En vertu de l'article 77, paragraphe 1, du règlement (UE) 2023/1542, à partir du 18 février 2027, chaque batterie MTL, chaque batterie industrielle d'une capacité supérieure à 2 kWh et chaque batterie de véhicule électrique « mise sur le marché ou mise en service » doit disposer d'un passeport de batterie. Générer un QR code ou publier une page de caractéristiques ne suffit pas : le passeport doit satisfaire aux exigences de contenu informationnel, d'exactitude, d'accessibilité, d'interopérabilité et de fonctionnement technique fixées par les articles 77 et 78 et l'annexe XIII.

Les entreprises n'ont plus à se fier uniquement à leur propre interprétation de ces exigences. Le projet BatteryPass-Ready a ouvert un environnement de test accessible au public, dans lequel les organisations peuvent valider les données de leur passeport de batterie et tester l'interopérabilité technique de leurs systèmes DPP. Cet article explique comment l'utiliser, étape par étape.

Qu'est-ce que BatteryPass-Ready ?

BatteryPass-Ready est un projet de recherche financé par le ministère fédéral allemand de l'Économie et de l'Énergie (BMWE). Il est piloté par le Fraunhofer IPK, avec acatech, GEFEG mbH et la TU Berlin comme partenaires du projet, et plus de 100 partenaires associés et soutiens y contribuent. Son objectif est d'aider les entreprises à se préparer aux exigences européennes relatives au passeport de batterie grâce à des outils de validation pratiques, des guides de mise en œuvre et des tests d'interopérabilité.

L'environnement de test a été lancé le 24 juin 2026 et il est accessible à l'adresse batterypass-ready.gefeg.com. Son utilisation est gratuite, mais nécessite un compte. Sa documentation le présente comme un projet de recherche et un prototype, et la page de ressources du projet parle d'une première version : attendez-vous donc à ce que l'interface et le périmètre des tests continuent d'évoluer.

L'environnement comprend deux modules complémentaires :

Module de test	Ce qu'il vérifie	À qui il s'adresse
Data Validation	Si un fichier JSON de passeport de batterie téléversé correspond au schéma de sa catégorie de batterie (structure et syntaxe)	Fabricants de batteries, importateurs, équipes conformité et prestataires DPP
System-Level Testing	Si la Lifecycle API d'un système DPP se comporte comme prévu lorsqu'un TestExecutor l'appelle dans un réseau simulé, avec un registre UE et un fournisseur de sauvegarde émulés	Prestataires de solutions DPP, développeurs et équipes IT des entreprises

Un passeport de batterie parfaitement structuré ne signifie pas que le logiciel qui l'héberge et le gère est interopérable. De même, une plateforme DPP interopérable ne peut pas garantir que chaque fabricant a fourni des données exactes et complètes pour ses batteries. La qualité des données et l'interopérabilité du système doivent toutes deux être prises en compte.

Partie 1 : testez les données de votre passeport de batterie

La première partie s'adresse surtout aux fabricants de batteries et aux autres opérateurs économiques responsables des informations du passeport de batterie. Elle permet de vérifier si un jeu de données de passeport donné respecte les exigences structurelles du modèle de données BatteryPass-Ready. Nul besoin de construire une plateforme DPP pour effectuer cette première validation.

Étape 1 : accédez à l'environnement de test BatteryPass-Ready

Ouvrez https://batterypass-ready.gefeg.com/. La plateforme est gratuite, mais vous devez créer un compte, qui demande votre nom, votre organisation, votre adresse e-mail et un mot de passe. Une fois connecté, vous voyez les deux espaces, Data Validation et System-Level Testing. Pour cette première partie, utilisez Data Validation.

Important : l'environnement de test n'est pas le registre officiel de l'UE. Le vrai registre est le registre des passeports numériques de produits établi par le règlement écoconception (ESPR) (règlement (UE) 2024/1781, article 13, paragraphe 1), dans lequel l'article 77, paragraphe 10, du règlement relatif aux batteries impose de téléverser l'identifiant unique du passeport de batterie. BatteryPass-Ready n'émule un registre qu'à des fins de test. Nous expliquons ce que vérifie le vrai registre dans Ce que valide le registre DPP de l'UE.

Étape 2 : téléchargez le modèle de données de référence

Avant de soumettre un passeport, comprenez la structure de données qu'attend le validateur. Le 27 août 2026, BatteryPass-Ready a publié la Data Attribute Longlist v2.0 et le Data Model v2.0, qui intègrent les évolutions réglementaires et de normalisation. Lors de la dernière vérification, la version du schéma en vigueur était la v2.0.1.

La page de ressources de BatteryPass-Ready renvoie vers :

• la Data Attribute Longlist v2.0 ;
• le document « User Stories from a Technical Perspective v1.0 », qui décrit les interactions entre les acteurs du système DPP ;
• le dépôt du Data Model sur GitLab, où se trouvent les schémas JSON.

Le modèle de données définit la structure attendue des informations : éléments de données, formats, unités et vocabulaires contrôlés. Téléchargez le schéma correspondant à votre catégorie de batterie et utilisez-le comme référence pour préparer les données à tester.

Étape 3 : identifiez la bonne catégorie de batterie

Les exigences d'information diffèrent selon les catégories de batteries ; le modèle de données propose donc cinq schémas par catégorie :

• Batteries de véhicules électriques (EV)
• Batteries MTL (moyens de transport légers)
• Batteries industrielles stationnaires de plus de 2 kWh
• Autres batteries industrielles de plus de 2 kWh
• Batteries industrielles sans système de gestion de batterie (BMS), avec un schéma complet qui leur est propre

Depuis la v2.0, chaque schéma dispose en outre d'une variante « Feb27 » couvrant les exigences applicables à partir du 18 février 2027. Choisissez le schéma et la variante qui correspondent à la batterie testée. Une batterie de stockage d'énergie stationnaire de 10 kWh, par exemple, relève du schéma des batteries industrielles stationnaires, et non du schéma EV. Les champs et les attentes de validation diffèrent, et une mauvaise catégorie produit des erreurs hors sujet ou des résultats trompeurs.

Étape 4 : préparez votre passeport de batterie sous forme de fichier JSON

Le module Data Validation fonctionne avec des données structurées : il vous faut donc une représentation JSON du passeport conforme au schéma BatteryPass-Ready. Un site web, un PDF ou un QR code seul ne suffit pas pour ce test. Si vous utilisez une solution logicielle DPP, demandez à votre prestataire un export JSON compatible avec le schéma applicable.

Selon la catégorie de batterie et la version du modèle de données, le fichier peut contenir :

• Identification et informations sur l'opérateur : identifiant unique de la batterie, modèle et catégorie de la batterie, informations sur l'opérateur économique et le fabricant, informations de fabrication.
• Caractéristiques techniques : chimie de la batterie, capacité nominale, caractéristiques de tension, masse, paramètres de performance et de durabilité.
• Durabilité et circularité : composition des matériaux, informations sur l'empreinte carbone le cas échéant, contenu recyclé s'il y a lieu, et informations utiles au démontage, au recyclage et aux autres activités du cycle de vie.
• Documentation réglementaire : déclarations de conformité, étiquettes et symboles requis, documents et références pertinents.

La structure doit respecter le schéma sélectionné. Une mesure peut devoir contenir à la fois une valeur numérique et son unité plutôt qu'un simple nombre, et certains attributs n'acceptent que des valeurs prescrites au lieu d'un texte libre. Si une partie des données provient de fournisseurs de cellules ou de modules, voyez que faire lorsque des données fournisseurs manquent.

Conseil pratique : commencez par un passeport de batterie représentatif. Une fois que le processus fonctionne pour un produit, répétez-le pour vos autres catégories et configurations.

Étape 5 : ouvrez le module Data Validation

Dans l'environnement de test, ouvrez Data Validation, sélectionnez le schéma de la catégorie de batterie parmi les options proposées et téléversez votre fichier JSON. Avant de lancer la validation, vérifiez que :

1. le fichier contient un seul jeu de données de passeport dans la structure attendue ;
2. le schéma sélectionné correspond à la catégorie de batterie ;
3. les données sont correctement formatées ;
4. vous utilisez la version actuelle du modèle de données.

Lancez ensuite la validation.

Étape 6 : examinez les résultats de la validation

La plateforme vérifie le fichier JSON par rapport au schéma et renvoie un retour de validation. Lors de la dernière vérification, les contrôles portaient uniquement sur la structure et la syntaxe ; des contrôles de plausibilité sont prévus. Constats typiques :

Exemple de problème	Ce qu'il signifie	Comment le corriger
Champ obligatoire manquant	Un attribut attendu n'a pas été fourni	Ajoutez les données requises
Type de données incorrect	Un nombre, une chaîne ou un objet ne correspond pas au schéma	Corrigez la structure JSON
Unité non valide	Une mesure utilise une unité non prise en charge ou mal codée	Utilisez la représentation d'unité prescrite
Valeur d'énumération non valide	Un champ contient une valeur hors de la liste autorisée	Choisissez un code accepté
Imbrication incorrecte	Un attribut ne se trouve pas dans la structure d'objet attendue	Corrigez la hiérarchie des données

Un fournisseur peut par exemple décrire la chimie de la batterie en termes commerciaux, alors que le modèle attend un code normalisé. Le validateur peut rejeter la valeur même si une personne la comprend. L'interopérabilité lisible par machine exige davantage que de placer des informations dans un document numérique.

Étape 7 : corrigez les erreurs et relancez le test

Examinez chaque problème signalé par le validateur. Votre équipe technique ou DPP doit corriger la structure JSON ou, le plus souvent, le mapping de données qui l'a produite, puis exporter de nouveau le passeport et relancer la validation jusqu'à ce que le fichier soit accepté.

Ne corrigez pas seulement le fichier d'exemple si l'erreur vient de votre mapping de données de production, sinon elle réapparaîtra dans tous les autres passeports que vous générez. L'objectif est de corriger le système source ou la transformation, et non d'obtenir un seul résultat de validation positif.

Étape 8 : sachez ce qu'une validation réussie ne prouve pas

Une validation réussie est une étape importante, mais elle a ses limites. Le module Data Validation vérifie si les données sont conformes au schéma lisible par machine ; il n'établit pas que les valeurs sont exactes. Par exemple :

• une masse de batterie déclarée peut avoir le bon format et être pourtant fausse ;
• une valeur d'empreinte carbone peut être structurellement valide sans prouver que le calcul sous-jacent est correct ;
• une déclaration fournisseur peut être correctement référencée sans que son authenticité soit établie ;
• une valeur provisoire peut passer un contrôle de format tout en étant inadaptée à un passeport de production.

Des contrôles de plausibilité sont prévus, mais même eux ne remplaceront pas vos propres vérifications. Les fabricants ont besoin de processus distincts pour l'exactitude, l'exhaustivité, l'applicabilité et les justificatifs de leurs données produit. En vertu de l'article 77, paragraphe 4, l'opérateur économique qui met la batterie sur le marché doit veiller à ce que les informations du passeport soient exactes, complètes et à jour ; il peut autoriser par écrit un autre opérateur à agir pour son compte, mais il conserve cette responsabilité.

Réussir la validation des données prouve une conformité structurelle dans le périmètre testé, sans se substituer aux obligations de l'opérateur économique.

Partie 2 : testez votre prestataire de solution DPP

Le second module va au-delà des données d'un passeport et pose une autre question : le système DPP peut-il communiquer correctement, échanger des données et effectuer les opérations requises avec les autres acteurs du système de passeport de batterie ? C'est surtout décisif lorsque vous choisissez un prestataire de solution DPP. Une plateforme peut afficher un passeport de batterie séduisant sans pour autant disposer des interfaces nécessaires à une mise en œuvre réglementaire à grande échelle.

Étape 9 : comprenez ce qu'évaluent les tests système

Dans System-Level Testing, un composant backend appelé TestExecutor appelle la Lifecycle API de votre système dans un réseau simulé qui comprend un registre UE émulé et un fournisseur de sauvegarde émulé. Au lancement, l'environnement proposait 11 scénarios de test répartis sur trois cas d'usage, et une mise à jour prévue pour octobre 2026 devait couvrir la plupart des cas de test du document User Stories.

Selon le scénario, les tests peuvent vérifier si le système :

• crée et tient à jour les données du passeport de batterie via la Lifecycle API ;
• gère les opérations liées à la mise sur le marché d'une batterie ;
• répond aux requêtes des autres acteurs dans le format lisible par machine attendu ;
• applique les droits d'accès et les identifiants (credentials) pertinents ;
• interagit correctement avec le registre et le fournisseur de sauvegarde émulés.

Chaque test compare le comportement réel du système au résultat attendu. Les scénarios évolueront à mesure que le projet intégrera de nouvelles normes, de nouvelles exigences et les retours des utilisateurs.

Étape 10 : demandez un environnement de test à votre prestataire DPP

Contrairement à la validation des données, les tests système exigent un accès technique au logiciel DPP. Si vous faites appel à un prestataire externe, demandez-lui de mettre à disposition un environnement de test adapté. Le prestataire doit pouvoir fournir :

• une instance de test de son système DPP ;
• le point de terminaison de la Lifecycle API ;
• le Test Adapter qu'exige BatteryPass-Ready (voir l'étape 11) ;
• des identifiants de test ou un autre mécanisme d'authentification adapté ;
• un support technique pour configurer et exécuter les tests.

Les entreprises qui développent leur propre logiciel DPP s'en chargent normalement via leur équipe d'ingénierie. Exécutez les tests dans un environnement contrôlé plutôt que d'exposer inutilement des données de production.

Étape 11 : configurez votre système dans System-Level Testing

Connectez-vous, ouvrez System-Level Testing et choisissez le rôle que joue votre système : Economic Operator ou Backup Provider. Indiquez ensuite deux points de terminaison :

• Lifecycle API : l'interface par laquelle votre système DPP effectue les opérations de passeport testées.
• Test Adapter : une interface dédiée qui permet à l'environnement de test de préparer votre système à l'exécution automatisée.

Le Test Adapter expose deux opérations :

• PUT /TestSetup crée les conditions initiales d'un scénario. Ses commandes comprennent insertBatteryPass, bringBatteryToMarket et issueCredentials.
• PUT /TestTeardown ramène ensuite le système à un état contrôlé.

Ces fonctions servent à l'automatisation des tests et ne doivent pas être confondues avec les interfaces de production exposées aux utilisateurs métier. Les détails figurent à la section 4.4 de la documentation BatteryPass-Ready.

Important : cette configuration exige un travail technique de la part du prestataire DPP. On ne devrait pas attendre d'un fabricant qui achète une solution DPP hébergée qu'il construise lui-même le Test Adapter. Si vous évaluez un prestataire pour le rôle de sauvegarde, notre article sur les fournisseurs de sauvegarde DPP certifiés explique ce que ce rôle implique.

Étape 12 : sélectionnez et exécutez les scénarios de test

Une fois votre système connecté, sélectionnez les scénarios disponibles. Chacun simule un événement ou une requête du cycle de vie du passeport de batterie, par exemple un acteur externe qui demande des informations précises au système DPP. L'exécution se déroule en quatre phases :

1. Préparation : l'environnement de test prépare les données et l'état du système via le Test Adapter.
2. Exécution : le TestExecutor envoie les requêtes prédéfinies à votre Lifecycle API.
3. Validation : les réponses sont comparées aux résultats attendus.
4. Rapport : la plateforme enregistre et présente le résultat.

Cela révèle des problèmes d'interopérabilité qu'un simple examen du passeport de batterie dans un navigateur ne montrerait jamais.

Étape 13 : analysez les résultats des tests système

Examinez le résultat de chaque scénario, y compris les étapes de test individuelles et les écarts signalés entre comportement attendu et comportement réel. Problèmes typiques :

• une opération d'API renvoie une réponse inattendue ;
• des données requises ne sont pas renvoyées dans le format attendu ;
• une demande d'information échoue ;
• des contrôles d'accès manquent ou sont incorrects ;
• une opération du cycle de vie laisse le système dans un mauvais état ;
• une interface se comporte différemment de la spécification technique.

Lorsqu'un test échoue, le prestataire doit analyser les détails d'exécution, corriger la cause et relancer le test. Une évaluation sérieuse couvre tous les scénarios pertinents disponibles, et non une seule démonstration d'un passeport récupéré avec succès. L'objectif est une interopérabilité reproductible, pas un unique appel d'API réussi.

Étape 14 : demandez des preuves des résultats de test

Si vous achetez une solution DPP, ne vous fiez pas uniquement à l'affirmation du prestataire selon laquelle sa plateforme est conforme. Demandez des preuves des tests réalisés :

Ce qu'il faut demander	Pourquoi c'est important
Date des tests	Confirme quand l'évaluation a été réalisée
Environnement de test et version du modèle de données	Identifie l'implémentation de référence
Spécifications applicables	Montre quelles exigences techniques ont été testées
Rôle et scénarios exécutés	Établit le périmètre réel de l'évaluation
Résultats de test individuels	Montre quels scénarios ont réussi ou échoué
Points en suspens	Identifie les limites connues
Politique de nouveaux tests	Explique comment la conformité est maintenue à mesure que les exigences évoluent

Demandez aussi si le prestataire a réalisé à la fois la validation des données et les tests système. Ils vérifient des aspects différents de la solution.

Partie 3 : ce que signifie vraiment un test réussi

BatteryPass-Ready offre un cadre précieux et indépendant pour vérifier les implémentations de passeport de batterie. Mais il existe une différence importante entre réussir des tests techniques de conformité et détenir une certification réglementaire formelle. La documentation elle-même est explicite : "Results should be treated as indicative feedback, not as a certification or a substitute for formal conformity assessment." (Les résultats doivent être considérés comme un retour indicatif, et non comme une certification ou un substitut à une évaluation formelle de la conformité.)

BatteryPass-Ready n'est pas le registre de l'UE, et ses résultats ne certifient pas qu'une batterie ou une implémentation DPP satisfait à toutes les exigences applicables. Il évalue des aspects définis des données de passeport et du comportement du système au regard de son modèle de référence et de ses scénarios de test ; un résultat doit donc toujours être lu avec le périmètre du test, la version et les exigences couvertes. D'autres points nécessitent toujours une vérification distincte, notamment :

• l'exactitude des informations techniques et de durabilité propres au produit ;
• les justificatifs des déclarations du fabricant ;
• les obligations d'évaluation de la conformité applicables ;
• les exigences de marquage physique et de QR code ;
• la sécurité opérationnelle et la disponibilité des données ;
• les restrictions d'accès aux informations confidentielles ;
• les changements introduits par des mises à jour réglementaires ou techniques ultérieures.

Un programme de conformité solide associe les tests BatteryPass-Ready à des contrôles qualité internes et à une analyse juridique. Les questions que le règlement laisse encore ouvertes sont traitées dans Passeport de batterie UE 2027 : les questions ouvertes.

Étape 15 : mettez en place un processus de validation continue

La conformité DPP n'est pas une étape ponctuelle. La réglementation et les normes évoluent, et les plateformes DPP sont mises à jour tout au long de leur vie. Répétez les tests pertinents lorsque :

• vous introduisez de nouvelles catégories de batteries ;
• les structures de données du passeport changent ;
• de nouvelles versions logicielles sont déployées ;
• des API sont modifiées ;
• BatteryPass-Ready publie des schémas ou des scénarios de test mis à jour ;
• les spécifications réglementaires ou techniques changent.

Vous détectez ainsi les problèmes de format de données et d'interopérabilité avant qu'ils n'affectent un grand nombre de passeports de batterie en service, et vous disposez de preuves continues de votre préparation technique.

Partie 4 : GoodsTag a réussi les scénarios de test BatteryPass-Ready

Chez GoodsTag, nous pensons que la conformité au passeport numérique de produit doit être démontrée par des tests pratiques, et non simplement affirmée. GoodsTag est partenaire de BatteryPass-Ready, et nous avons testé notre solution DPP batterie dans l'environnement de test BatteryPass-Ready. Notre implémentation a réussi les scénarios de test exécutés et a été déclarée entièrement conforme dans le périmètre de test évalué.

Cela renforce la confiance dans l'alignement de la plateforme sur les exigences de données et d'interopérabilité qu'évalue BatteryPass-Ready, et reflète notre approche : bâtir des passeports sur des identifiants normalisés, un échange de données structuré et une infrastructure interopérable. Comme tout résultat BatteryPass-Ready, il porte sur les scénarios et les versions évalués. Il ne s'agit pas d'une certification, ni de la plateforme, ni de la conformité réglementaire d'une batterie individuelle.

Pourquoi c'est important pour les fabricants de batteries

Choisir un prestataire DPP ne se résume pas à générer des passeports numériques. Les fabricants doivent pouvoir compter sur une solution qui prend en charge l'architecture technique requise, gère des informations produit structurées et interagit avec les autres systèmes de l'écosystème du passeport de batterie. Une fois le volet technique testé, les fabricants peuvent se concentrer sur la tâche critique qui reste : collecter, vérifier et maintenir des données exactes sur leurs batteries.

Que vous prépariez votre premier passeport de batterie, que vous révisiez une implémentation existante ou que vous évaluiez des prestataires, des tests de conformité structurés font partie de votre préparation à février 2027. Vous pouvez explorer directement l'environnement de test gratuit ou contacter GoodsTag pour discuter de vos exigences de conformité et d'intégration.

Sources

1. Règlement (UE) 2023/1542 relatif aux batteries et aux déchets de batteries, articles 77 et 78 et annexe XIII
2. Règlement (UE) 2024/1781 (règlement écoconception, ESPR), article 13
3. Page du projet BatteryPass-Ready
4. Ressources BatteryPass-Ready
5. BatteryPass-Ready launches test environment for the digital battery passport
6. Now published: Data Attribute Longlist v2.0 and Data Model v2.0
7. Dépôt du modèle de données BatteryPass (schémas JSON)
8. Environnement de test BatteryPass-Ready
9. Documentation de l'environnement de test BatteryPass-Ready

Dernière vérification : 10 octobre 2026. L'interface et les scénarios de test peuvent évoluer.