Enregistrer un passeport de batterie dans le registre DPP de l’UE

L’enregistrement du passeport de batterie dans le registre DPP de l’UE passe par une API que la Commission européenne a documentée le vendredi 30 octobre 2026. Le fabricant envoie au registre l’identifiant unique de produit (UPI) du passeport, qui est une URL. Le registre récupère le passeport à cette adresse, le valide au regard des schémas de la Commission et ne l’enregistre que s’il est conforme. Il n’en conserve pas de copie. L’obligation s’applique à partir du 18 février 2027 à chaque batterie MTL, chaque batterie industrielle de plus de 2 kWh et chaque batterie de véhicule électrique.

Ce que la Commission a publié le 30 octobre 2026

Les documents se trouvent sur la page de la Commission consacrée aux ressources et à la documentation du DPP.

Les règles du registre figurent dans le règlement d’exécution (UE) 2026/1778. Selon le guide de l’API, le registre lit et valide chaque passeport « in accordance with » ce règlement. Notre article sur le lancement du registre en juillet en présente la base juridique.

Quelles batteries doivent avoir un passeport enregistré

L’article 77, paragraphe 1, du règlement relatif aux batteries, règlement (UE) 2023/1542, exige un passeport de batterie à partir du 18 février 2027 pour :

• chaque batterie MTL (moyens de transport légers, comme les vélos et trottinettes électriques)
• chaque batterie industrielle d’une capacité supérieure à 2 kWh
• chaque batterie de véhicule électrique

Les batteries portables et les batteries SLI ne sont pas concernées. L’article sur le passeport de batterie décrit son contenu.

Dans le registre, ces batteries relèvent du groupe de produits BATTERIES, avec un sous-groupe par catégorie. Les codes sont fournis par GET /api/v1/dpp/product-groups, et le guide demande d’utiliser les valeurs renvoyées. Chaque passeport d’une soumission indique aussi sa granularité : item, batch ou model.

Comment fonctionne l’enregistrement

L’illustration en haut de cet article montre les quatre étapes.

1. Faire vérifier votre organisation

Seule une organisation vérifiée peut enregistrer des passeports. Vous vous connectez avec EU Login, inscrivez l’organisation et soumettez une déclaration signée. Une personne morale la scelle avec un cachet électronique qualifié (QSeal). Le User Guide for Economic Operators (v3, 14 septembre 2026) décrit chaque étape.

2. Créer un compte de service

L’accès machine utilise OAuth 2.0 client credentials avec private_key_jwt. Les secrets client partagés ne sont pas pris en charge.

• Un administrateur crée le compte de service ; une organisation peut en avoir 5 au maximum.
• Il lui faut le rôle qui autorise l’enregistrement de passeports.
• Les clés sont à courbe elliptique : P-256, P-384 ou P-521.
• Chaque jeton d’accès vit 15 minutes au maximum.
• La validité recommandée d’un identifiant est d’un an, deux au maximum. Deux peuvent être actifs en même temps, ce qui permet de changer de clé sans interruption.

La clé privée reste chez l’opérateur économique. Le guide recommande de la générer dans un module de sécurité matériel.

3. Soumettre les passeports

Vous envoyez POST /api/v1/dpp/submission avec 1 à 100 passeports qui partagent le même groupe et sous-groupe de produits. Chaque requête doit porter un en-tête Idempotency-Key de 128 caractères au maximum. Une nouvelle tentative avec la même clé renvoie la tâche d’origine au lieu d’en créer une seconde. L’exemple du guide de l’API :

{
  "productGroup": "BATTERIES",
  "productSubGroup": "EV",
  "submissionItems": [
    {
      "uniqueProductIdentifier": "https://example.com/dpp/battery/0001",
      "granularity": "item",
      "batchIdentifier": "xxx-000",
      "modelIdentifier": "yyy-111"
    }
  ]
}

4. Suivre la tâche

Le registre répond 202 Accepted avec un taskId. Cela signifie que la demande a été acceptée pour traitement, pas que quoi que ce soit est enregistré. Vous lisez l’état avec GET /api/v1/tasks/{taskId} : PENDING, PROCESSING, COMPLETED ou ERROR. Une tâche terminée a pour résultat SUCCEEDED ou FAILED. Le guide recommande d’interroger après 1, 1, 2, 3, 5, 8, 13, 21, 34 et 55 secondes, puis toutes les 60 secondes, en respectant Retry-After. Les résultats par passeport sont fournis par GET /api/v1/tasks/{taskId}/items, en JSON ou en CSV.

Une soumission est atomique. Si un passeport échoue à la validation, aucun passeport de cette soumission n’est enregistré, y compris ceux qui l’ont passée.

Ce que vérifie le registre lorsqu’il récupère votre passeport

Le registre utilise l’UPI exactement tel qu’il a été soumis, comme première adresse du passeport. S’il ne peut pas atteindre le passeport, l’élément échoue avec UPI_NOT_RESOLVABLE.

Première récupération, sans connexion. Le registre envoie un GET sans identifiants. Il suit au plus 3 redirections sur l’ensemble de la résolution, donc chaque étape doit répondre de façon anonyme. L’adresse finale répond 200 avec la partie publique du passeport.

Format. Selon le Semantic Data Guide, le registre demande du JSON, le seul format obligatoire selon l’EN 18216:2026. Le Self-Hosted Authentication Guide admet aussi JSON-LD et XML, avec JSON comme base.

Schémas. La validation se fait au regard des artefacts sémantiques, version 1.0.0 :

• Le schéma core exige 6 champs : digitalProductPassportId, uniqueProductIdentifier, granularity, dppStatus, lastUpdate et contentSpecificationIds.
• contentSpecificationIds désigne les spécifications que suit le passeport : core, batteries et, le cas échéant, le sous-groupe.
• La vue publique des batteries exige 25 champs. Ils comprennent le fabricant, la catégorie, le lieu et la date de fabrication, le poids, la capacité, la composition chimique, les substances dangereuses, l’agent d’extinction, les matières premières critiques, les tensions, la puissance, la résistance interne, la plage de températures, la déclaration UE de conformité et les informations sur les déchets de batteries.
• Les valeurs codées comme la catégorie, la composition chimique et les unités sont des URI tirés des vocabulaires de la Commission, pas du texte libre.

Les données de la batterie sont réparties en quatre vues : pub (publique) et les vues restreintes res1, res2 et res3.

Seconde récupération, avec un jeton. Le registre appelle ensuite la même adresse avec un jeton bearer du DPP Authentication Service. Votre serveur vérifie lui-même le jeton au regard des clés publiées par la Commission. Il doit contrôler l’audience du jeton (votre propre origine HTTPS), sa portée dpp:registry:read et une durée de vie de 120 secondes au maximum. Il répond alors avec les données publiques et restreintes.

Le guide demande aussi Vary: Authorization, pour que les caches distinguent les deux réponses, et aucune redirection après l’authentification.

Ce qui est conservé. Le guide de l’API indique que le registre ne conserve pas le contenu du passeport qu’il récupère. Le passeport reste sur votre serveur ou celui de votre prestataire.

Quand l’enregistrement ouvre

Le DPP Helpdesk nous a indiqué le 4 novembre 2026 que l’enregistrement n’est encore disponible dans aucun environnement. Selon le Helpdesk, une API de test est prévue dans l’environnement de recette en décembre, et la production est visée pour fin janvier 2027. L’obligation de l’article 77, paragraphe 1, s’applique à partir du 18 février 2027.

Il reste donc peu de temps entre l’ouverture de la production et l’obligation. Le travail qui ne dépend pas de l’ouverture du registre peut être fait dès maintenant.

Ce dont un fabricant de batteries a besoin avant le 18 février 2027

Ce que fait DPP Agent pour les passeports de batterie

• Construit à partir des données que vous avez déjà. Les passeports sont remplis depuis Shopify, Centra, Akeneo, inRiver, un fichier CSV ou l’API, sans double saisie.
• L’usine renseigne ce qu’elle seule connaît. Un lien fournisseur permet à l’usine de fabrication de saisir le lieu et la date de fabrication, les substances dangereuses et la résistance interne, et vous validez chaque valeur.
• Un passeport par batterie. Chaque batterie porte son numéro de série dans son adresse GS1 Digital Link, avec un code QR et une étiquette prête à imprimer.
• Mises à jour par batterie. L’état de santé, le statut, les cycles de charge et les événements négatifs sont suivis par batterie, et chaque modification est enregistrée dans l’historique des versions. Une batterie réaffectée à un nouvel usage reçoit un nouveau passeport lié au passeport de la batterie d’origine (article 77, paragraphe 7).
• Les bonnes données pour le bon lecteur. Le public voit la partie publique. Les réparateurs, les reconditionneurs et les recycleurs reçoivent un lien de partage vers les données destinées aux personnes ayant un intérêt légitime, et les autorités reçoivent un lien vers les leurs (article 77, paragraphe 2).
• Prêt pour le registre DPP de l’UE. Chaque passeport répond dans le format propre au registre, et avec les vues restreintes lorsque le registre le lit avec son jeton.
• Les lacunes visibles avant l’enregistrement. Le validateur DPP montre ce qui manque au regard des schémas de la Commission, pour que vous puissiez le corriger avant la soumission.
• Dans vos langues et à l’image de votre marque. Le passeport s’affiche dans les langues de vos clients et avec l’identité visuelle de votre marque.

L’épisode de la DPP Academy sur le registre de l’UE explique qui dépose quoi, et l’épisode sur les batteries couvre le reste du passeport de batterie.

Questions fréquentes

Quand peut-on enregistrer des passeports de batterie dans le registre DPP de l’UE ?

Pas encore. Selon le DPP Helpdesk, le 4 novembre 2026, une API de test est prévue dans l’environnement de recette en décembre et la production est visée pour fin janvier 2027. L’obligation de passeport s’applique à partir du 18 février 2027.

Le registre DPP de l’UE stocke-t-il le passeport de batterie ?

Non. Le registre récupère le passeport à son UPI et le valide, mais l’API Integration Guide indique qu’il ne conserve pas le contenu du passeport. Le passeport reste à sa propre adresse.

Combien de passeports de batterie peut-on enregistrer en une requête ?

Entre 1 et 100, tous avec le même groupe et sous-groupe de produits. Chaque requête doit porter un en-tête Idempotency-Key.

Que se passe-t-il si un passeport d’une soumission échoue à la validation ?

Aucun passeport de cette soumission n’est enregistré. Les soumissions sont atomiques, et les résultats par élément indiquent quel passeport a échoué.

Quel format un passeport de batterie doit-il avoir pour l’enregistrement ?

JSON. Selon le Semantic Data Guide, le registre demande du JSON, le seul format obligatoire selon l’EN 18216:2026, et le valide au regard des schémas core et batteries 1.0.0.

Sources

• Règlement (UE) 2023/1542 (règlement relatif aux batteries) : article 77, paragraphe 1 (passeport de batterie). EUR-Lex
• Règlement d’exécution (UE) 2026/1778 de la Commission relatif au registre des passeports numériques de produits. EUR-Lex
• Commission européenne, ressources et documentation DPP : API Integration Guide v1.0, spécifications OpenAPI 1.0.0, Semantic Data Guide, Semantic Data Artifacts 1.0.0, Service Account Technical Integration Guide et Self-Hosted Authentication Guide v1.0 (30 octobre 2026) ; Battery data points by category v3.2 (19 octobre 2026) ; User Guide for Economic Operators v3 (14 septembre 2026). Page de la Commission
• DPP Helpdesk : réponse du 4 novembre 2026 sur la disponibilité de l’API d’enregistrement.