Les portefeuilles européens d'identité numérique sont attendus pour le 24 décembre 2026 : ce qui change pour les apps qui scannent des passeports

Si votre app demande aujourd'hui aux utilisateurs une photo de leur passeport ou de leur carte d'identité, vous avez sans doute entendu dire que les portefeuilles européens d'identité numérique (EUDI Wallet) arrivent « fin 2026 ». La date est réelle, et elle est précise : le 24 décembre 2026. Mais c'est une échéance pour les États membres, pas pour vous, et elle ne met pas fin aux scans de documents.

Cet article fait trois choses. Il montre d'où vient la date, calcul à l'appui. Il liste ce qu'un portefeuille transmet réellement, d'après les tableaux d'attributs des textes. Et il esquisse une conception qui accepte un portefeuille quand l'utilisateur en a un et se replie sur le scan d'un document quand il n'en a pas. Il est écrit par doc.cheap, une API OCR pour passeports et pièces d'identité : lisez donc les passages sur le produit en gardant cela en tête. doc.cheap lit des images de documents ; il ne lit pas les portefeuilles.

D'où vient le 24 décembre 2026

L'obligation figure à l'art. 5a(1) du règlement (UE) n° 910/2014, inséré par le règlement (UE) 2024/1183, la modification d'eIDAS. Il dispose que chaque État membre « fournit au moins un portefeuille européen d'identité numérique dans un délai de 24 mois à compter de la date d'entrée en vigueur des actes d'exécution visés au paragraphe 23 du présent article et à l'article 5c(6) ».

Le compteur ne démarre donc pas avec la modification d'eIDAS elle-même. Il démarre avec les actes d'exécution de la Commission. Les actes de l'art. 5a(23) sont quatre actes d'exécution de la Commission datés du 28 novembre 2024, parmi lesquels le règlement d'exécution (UE) 2024/2979 relatif à l'intégrité et aux fonctionnalités essentielles des portefeuilles. Il a été publié au Journal officiel (JO L, 2024/2979) le 4 décembre 2024. Son art. 15 dispose qu'il « entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l'Union européenne ».

Le calcul :

Étape	Date
Publication au Journal officiel	4 décembre 2024
Jour 1 après la publication	5 décembre 2024
Jour 20 après la publication : entrée en vigueur	24 décembre 2024
Plus 24 mois (art. 5a(1)) : portefeuilles attendus	24 décembre 2026
Plus 36 mois (art. 5f(2)) : certaines parties utilisatrices privées doivent accepter les portefeuilles	24 décembre 2027

Le « vingtième jour suivant » se compte à partir du lendemain de la publication : le 4 décembre plus 20 jours tombe donc le 24, pas le 23. La même entrée en vigueur fixe la seconde date du tableau, celle qui intéresse réellement la plupart des équipes produit (voir plus bas).

Ce que transmet un portefeuille

Un portefeuille n'envoie pas l'image d'un passeport. Il présente des données signées. Le jeu de données d'une personne physique est fixé à l'annexe du règlement d'exécution (UE) 2024/2977 : les « données d'identification personnelle » (PID, person identification data). L'annexe précise que les PID sont délivrées dans deux formats : ISO/IEC 18013-5:2021 et le « Verifiable Credentials Data Model 1.1 » du W3C.

Voici les attributs, avec le caractère que le texte donne à chacun (tableaux 1, 2 et 5 de l'annexe, tels que publiés le 4 décembre 2024). La dernière colonne indique le champ le plus proche dans une réponse de scan doc.cheap, pour voir où les deux mondes se rejoignent et où ils divergent.

Attribut PID	Caractère	Champ le plus proche dans un scan de document
`family_name`	obligatoire	`holder.surname`
`given_name`	obligatoire	`holder.given_names`
`birth_date`	obligatoire	`holder.birth_date` (ISO 8601)
`birth_place`	obligatoire	une entrée `birth_place` dans `fields[]`, quand le document l'imprime
`nationality`	obligatoire (alpha-2, une ou plusieurs)	`holder.nationality` (alpha-3, une seule)
`resident_address`, `resident_country`, `resident_state`, `resident_city`, `resident_postal_code`, `resident_street`, `resident_house_number`	facultatif	aucun sur la page de données d'un passeport
`personal_administrative_number`	facultatif	pas la même chose ; `fields[]` peut contenir un `personal_number` imprimé sur le document
`portrait`	facultatif	`images.main_photo`
`family_name_birth`, `given_name_birth`	facultatif	pas de champ normalisé
`sex`	facultatif (codes 0, 1, 2, 3, 4, 5, 6, 9)	`holder.sex` (`M`, `F`, `X`)
`email_address`, `mobile_phone_number`	facultatif	absents d'un document
`expiry_date` (métadonnées)	obligatoire	`document.expiry_date`, mais celle du document, pas celle des PID
`issuing_authority` (métadonnées)	obligatoire	une entrée `authority` dans `fields[]`, quand elle est imprimée
`issuing_country` (métadonnées)	obligatoire (alpha-2)	`document.issuing_state` (alpha-3)
`document_number` (métadonnées)	facultatif	pas la même chose : le numéro des PID est attribué par le fournisseur de PID, `document.number` est celui du passeport
`issuing_jurisdiction`, `location_status` (métadonnées)	facultatif	aucun

Trois points de ce tableau comptent au moment d'écrire le code de correspondance.

Les codes pays diffèrent. Les PID utilisent ISO 3166-1 alpha-2 (DE). Les passeports et la zone de lecture automatique utilisent alpha-3 (DEU). Gardez une seule forme interne et convertissez en bordure du système.
« Obligatoire » ne veut pas dire « toujours connu ». Sous le tableau 1, le texte ajoute : « Lorsque la valeur d'un attribut n'est pas connue pour la personne ou ne peut pas être délivrée d'une autre manière dans le cadre de l'ensemble de données d'identification personnelle, les États membres utilisent à la place une valeur d'attribut adaptée à la situation. » Attendez-vous à des valeurs de substitution, pas à des clés absentes.
Seuls cinq attributs sur la personne sont obligatoires. Adresse, portrait, sexe et noms de naissance sont tous facultatifs. Si votre parcours a besoin de l'un d'eux, le portefeuille peut tout simplement ne pas le contenir pour un utilisateur donné.

Qui continuera d'arriver avec un document

L'échéance oblige chaque État membre à fournir un portefeuille. Elle n'oblige personne à l'utiliser. L'art. 5a(15) est sans détour : « L'utilisation des portefeuilles européens d'identité numérique est volontaire. » Et il poursuit : « Il reste possible d'accéder aux services publics et privés par d'autres moyens d'identification et d'authentification existants. »

Après le 24 décembre 2026, vous verrez donc encore :

Des voyageurs et des clients venant de l'extérieur de l'UE. Les considérants rattachent le portefeuille à « l'identité juridique des citoyens de l'Union, des résidents de l'Union ou des personnes morales ». Un visiteur muni d'un passeport d'ailleurs n'a pas de portefeuille de l'UE à présenter.
Des personnes qui n'en ont pas installé, qui ne le peuvent pas ou qui préfèrent s'en passer. Le texte protège ce choix.
Des parcours qui ont besoin du document lui-même. Certains processus veulent l'image du document, le numéro du document ou la zone de lecture automatique du document physique, pas une attestation sur la personne. Les PID d'un portefeuille portent leur propre document_number, attribué par le fournisseur de PID, qui n'est pas le numéro du passeport.
La période avant la mise en service du portefeuille d'un pays donné. Le 24 décembre 2026 est l'échéance légale. Le moment où chaque portefeuille national atteint réellement les utilisateurs est une autre question, et la seule réponse fiable pour un pays est l'annonce de ce pays lui-même ou celle de la Commission.

Une conception qui accepte les deux

La forme qui résiste à tout cela est simple : demandez la présentation d'un portefeuille quand l'utilisateur en a un, et repliez-vous sur le scan d'un document quand il n'en a pas. Les deux chemins aboutissent au même enregistrement interne.

user starts verification
        |
        v
  offers a wallet? --yes--> wallet presentation --> verify signature --> map PID
        |                                                               |
        no                                                              v
        |                                                      internal identity
        v                                                          record
  document photo --> POST /v1/scans --> map scan fields ----------------^

Quelques principes rendent les deux chemins interchangeables :

Faites correspondre les deux à un seul enregistrement avec vos propres noms de champs. Servez-vous du tableau ci-dessus comme table de correspondance.
Conservez la source. Enregistrez si une fiche provient d'un portefeuille ou d'un scan. Ils apportent des preuves différentes, et un contrôleur voudra savoir laquelle.
Considérez les null comme honnêtes. Dans une réponse doc.cheap, chaque clé est toujours présente et une valeur inconnue vaut null. Un portefeuille peut envoyer une valeur de substitution à la place. Normalisez les deux selon une seule convention.
Ne stockez que ce dont le parcours a besoin. Un scan peut être exécuté de sorte que rien ne soit écrit côté API (voir plus bas).

Voici l'appel de repli avec un simple fetch. La clé sandbox publique sk_sandbox_public est imprimée dans la documentation et ne demande aucune inscription ; son débit est limité par adresse client.

import { readFileSync } from "node:fs";
import { randomUUID } from "node:crypto";

async function scanDocument(path, apiKey = "sk_sandbox_public") {
  const response = await fetch("https://api.doc.cheap/v1/scans", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
      "Idempotency-Key": randomUUID(), // une relance renvoie le premier résultat
    },
    body: JSON.stringify({
      image: readFileSync(path).toString("base64"),
      options: { retain_hours: 0, return_portrait: false }, // rien n'est stocké
    }),
  });
  if (!response.ok) throw new Error(`scan failed: HTTP ${response.status}`);
  return response.json();
}

// Fait correspondre un scan au même enregistrement que remplirait la présentation d'un portefeuille.
function fromScan(scan) {
  if (scan.meta.status !== "recognized") return null;
  const field = (name) => scan.fields.find((f) => f.id === `${name}@0`)?.value ?? null;
  return {
    source: "document_scan",
    family_name: scan.holder?.surname ?? null,
    given_name: scan.holder?.given_names ?? null,
    birth_date: scan.holder?.birth_date ?? null,
    birth_place: field("birth_place"),
    nationality_alpha3: scan.holder?.nationality ?? null,
    issuing_country_alpha3: scan.document?.issuing_state ?? null,
    document_number: scan.document?.number ?? null,
    mrz_status: scan.mrz.status, // "passed", "failed" ou "absent"
  };
}

meta.status vaut l'une de cinq chaînes : recognized, no_document_found, unreadable, unsupported_document ou rejected. Seule la première doit remplir un enregistrement ; les autres doivent renvoyer l'utilisateur reprendre la photo. Avec une clé payante, le solde n'est débité que lorsque le scan est facturable.

Nous avons exécuté un appel de ce type sur sk_sandbox_public le 24 septembre 2026 à 21:17 UTC, avec le document de test du produit lui-même, un passeport. La réponse est revenue avec HTTP 200. Toutes les valeurs du document ci-dessous sont masquées, et fields, images et mrz.lines sont tronqués :

{
  "meta": {
    "schema_version": "1.0",
    "id": "<SCAN_ID>",
    "status": "recognized",
    "billed": true,
    "confidence": "medium",
    "timing": { "upload_ms": 255, "processing_ms": 409, "total_ms": 678 },
    "created_at": "<RUN_TIMESTAMP>",
    "reference": null
  },
  "document": {
    "kind": "passport", "country": "<ISO3>", "country_name": "<COUNTRY>",
    "issuing_state": "<ISO3>", "number": "<DOCUMENT_NUMBER>", "series": null,
    "issue_date": "<DATE>", "expiry_date": "<DATE>", "is_expired": false, "days_remaining": "<N>"
  },
  "holder": {
    "given_names": "<GIVEN_NAMES>", "surname": "<SURNAME>", "full_name": "<FULL_NAME>",
    "birth_date": "<DATE>", "sex": "<SEX>", "nationality": "<ISO3>"
  },
  "mrz": { "status": "passed", "reason": null, "lines": ["<LINE_1>", "<LINE_2>"], "text": "<MRZ>" },
  "quality": { "overall": "pass" },
  "authenticity": { "overall": "not_checked", "checks": [] }
}

billed: true signifie ici que le scan était facturable et a été décompté du quota gratuit de la sandbox ; la clé sandbox elle-même n'est jamais débitée. Le tableau fields de cette exécution contenait des entrées birth_place, authority et personal_number, là où le tableau ci-dessus renvoie pour ces attributs PID. La page de données d'un passeport porte sa MRZ sur deux lignes au format TD3 ; la page sur les formats TD1, TD2 et TD3 montre les formats côte à côte.

Notez authenticity.overall: "not_checked". Un tel scan relève de la reconnaissance : il lit ce qui est imprimé et vérifie les chiffres de contrôle de la MRZ. Ce n'est pas de la détection de faux, et cela n'offre pas la même garantie que la présentation signée d'un portefeuille. Si votre processus exige un niveau de garantie plus élevé sur le chemin du scan, il doit venir d'une autre partie de votre parcours. Si vous choisissez un fournisseur pour le repli, notre comparatif des API OCR de passeport présente les options, y compris celles qui vont au-delà de la reconnaissance.

Ce qu'il faut surveiller ensuite

24 décembre 2026 – portefeuilles attendus. Art. 5a(1), règlement (UE) 2024/1183, compté à partir de l'entrée en vigueur des actes d'exécution comme montré plus haut.
24 décembre 2027 – parties utilisatrices privées. L'art. 5f(2) dispose que les parties utilisatrices privées tenues, par la loi ou par contrat, d'utiliser une authentification forte de l'utilisateur pour l'identification en ligne « acceptent également, au plus tard 36 mois à compter de la date d'entrée en vigueur des actes d'exécution visés à l'article 5a(23) et à l'article 5c(6), et uniquement à la demande volontaire de l'utilisateur, les portefeuilles européens d'identité numérique ». Le texte cite les transports, l'énergie, la banque, les services financiers, la sécurité sociale, la santé, l'eau potable, les services postaux, les infrastructures numériques, l'éducation et les télécommunications, et il exclut les microentreprises et les petites entreprises.
Les très grandes plateformes en ligne. L'art. 5f(3) les oblige à accepter les portefeuilles pour l'authentification des utilisateurs, là encore uniquement à la demande volontaire de l'utilisateur et pour les données minimales nécessaires.
Les modifications des actes d'exécution. Le considérant 4 du règlement d'exécution (UE) 2024/2979 indique que la Commission « devrait le réexaminer et le mettre à jour » si nécessaire. Vérifiez les tableaux d'attributs du 2024/2977 avant de figer une correspondance.

En pratique : construisez le chemin du portefeuille lorsque les pays de vos utilisateurs lancent leurs portefeuilles, gardez le chemin du document, et faites correspondre les deux à un seul enregistrement dès le premier jour. La documentation de l'API OCR pour passeports et pièces d'identité couvre entièrement la partie scan.

Ceci est un résumé technique, pas un conseil juridique.