Prêt pour le registre
pour l'enregistrement en production
Le registre DPP de l'UE est en service depuis le 20 juillet 2026. PassportLab construit chaque passeport au format de registre CIRPASS-2, avec un adaptateur testé contre l'implémentation de référence CIRPASS-2, des enregistrements d'audit en chaîne de hachage et des preuves W3C VC. Les enregistrements de production démarrent dès que les étapes de vérification de l'opérateur sont terminées.
L'outil de vérification de la Commission arrive. Le nôtre fonctionne aujourd'hui.
Le cadre du registre DPP de l'UE prévoit une plateforme de vérification officielle, exploitée par la Commission, que les autorités de surveillance du marché et les douanes pourront utiliser pour contrôler les passeports. Cette plateforme n'a pas été lancée et n'a pas de date publique.
En attendant, passportlab.io/verify exécute des contrôles sur les mêmes lignes : résolution GS1 Digital Link, vérification des preuves W3C VC, conformité au schéma ESPR et validation des shapes SHACL contre le modèle de données CIRPASS-2. Ses passeports sont publiés sur des points de terminaison ouverts et signés que tout outil de vérification peut lire.
Une indisponibilité du registre n'interrompt pas votre historique de conformité.
Si le registre central est injoignable, la vérification en aval échoue — et l'art. 15 du règlement d'exécution (UE) 2026/1778 permet à la Commission de suspendre le registre sans préavis en cas d'incident.
Le PassportAuditLog de PassportLab est un journal chaîné par hachage, en ajout seul — chaque modification de champ est cryptographiquement liée à l'entrée précédente. Des déclencheurs MySQL imposent l'immuabilité au niveau de la base de données ; aucune suppression ou modification côté application ne peut retirer une entrée silencieusement. C'est l'enregistrement qui survit à une panne du registre.
entry[n].prevHash = SHA-256(entry[n-1]) entry[n].hash = SHA-256(entry[n] + prevHash) integrity = chain unbroken since genesis db trigger = DELETE / UPDATE → rejected
Construit pour le registre en service.
PassportLab parle déjà le format CIRPASS-2. Chaque DPP est construit comme charge utile d'enregistrement pour POST /metadata/v1/registerDPP avec la charge utile complète requise : UPI, reoId basé sur l'EORI reoId, URL en direct, URL de secours, niveau de granularité, liste des sites et indicateur de désactivation.
Le registre DPP de l'UE est en service depuis le 20 juillet 2026, avec un environnement de test public et une API. Une fois un produit enregistré, le registre délivre une preuve d'enregistrement. Les actes délégués des art. 77/78 régissant le modèle de données complet du passeport batterie sont encore en attente — notre schéma est versionné pour absorber ces changements sans projet de migration.
{
"upi": "DPP-04012345000010-A001",
"reoId": "DE123456789012", // EORI
"liveURL": "https://www.passportlab.io/dpp/…",
"backupURL": "https://backup.passportlab.io/…",
"granularityLevel": "item",
"facilitiesId": ["GLN-4270054032051"],
"deactivated": false
}Ce qui est fait. Ce qui reste en attente côté UE.
L'intégration du registre par PassportLab n'est pas un point de feuille de route : l'adaptateur est construit et testé contre l'implémentation de référence CIRPASS-2. L'enregistrement en production exige trois étapes de vérification selon le règlement d'exécution (UE) 2026/1778 — le cachet qualifié propre de l'opérateur (art. 4), la vérification de PassportLab en tant que tiers (art. 5) et l'autorisation de PassportLab par l'opérateur (art. 19(4)).
Connaissez votre position vis-à-vis du registre avant vos concurrents.
Réservez un appel de 30 minutes. Nous cartographierons vos produits selon leur format UPI CIRPASS-2, confirmerons que votre EORI est correctement connecté et vous montrerons à quoi ressemble une soumission au registre de bout en bout sur vos propres données.
Standards notice: Standards status: EN 18216:2026–EN 18223:2026 — including the data-carrier standard EN 18220 and the data-persistence standard EN 18221 — were published by CEN/CENELEC on 27 May 2026. In July 2026, CEN/CLC JTC 24 formally recognised six of these EN standards, including EN 18222 (interface/API layer). They are not yet cited in the Official Journal of the EU, so they do not yet confer formal presumption of conformity. EN 18239 (access rights) and EN 18246 (data authentication) remain in draft, expected late 2026. ESPR (EU 2024/1781) delegated acts and per-category Annex I requirements are still being finalised. CBAM Reg. 2023/956 obligations continue to evolve under Commission guidance. Results are a readiness indication based on the latest available standards and drafts, and do not constitute legal advice.