La pile technologique derrière le futur PIC : Pourquoi une architecture de normes en couches est nécessaire pour remplacer le permis papier

Aucune norme unique ne remplacera le Permis International de Conduire (PIC) papier. Le véritable successeur est un ensemble de normes fonctionnant ensemble — et comprendre cet ensemble est la clé pour saisir la direction que prennent réellement les titres de conduite numériques transfrontaliers.

Pourquoi aucune norme unique ne remplacera le PIC papier

La plupart des discussions sur le futur PIC commencent par la mauvaise question : quelle norme remplacera le permis papier ? Ce cadrage suppose qu’une seule spécification peut accomplir l’ensemble du travail. Ce n’est pas possible.

Les travaux du NIST sur le mDL (permis de conduire mobile) indiquent explicitement que de nouvelles normes de titres numériques émergent dans des domaines problématiques distincts. La famille ISO 18013 elle-même est déjà répartie en plusieurs parties couvrant la conception physique, la sécurité, la présentation mobile et les extensions internet. Un futur titre de conduite transfrontalier n’est donc pas une seule spécification — c’est un ensemble coordonné de spécifications, chacune traitant d’une problématique distincte.

La pile du futur PIC en un coup d’œil

Voici les huit couches qui, prises ensemble, définissent ce à quoi ressemblera un futur PIC :

• Couche 0 — Base physique et données : ISO/IEC 18013-1
• Couche 1 — Sécurité du titre : ISO/IEC 18013-3
• Couche 2 — Présentation de proximité (en personne) : ISO/IEC 18013-5
• Couche 3 — Présentation à distance / internet : ISO/IEC 18013-7
• Couche 4 — Sémantique du titre : Modèle de données des justificatifs vérifiables W3C 2.0
• Couche 5 — Protocole d’émission : OpenID4VCI
• Couche 6 — Protocole de demande et de présentation : OpenID4VP
• Couche 7 — Distribution de confiance et autorisation des vérificateurs : Registres de confiance (modèle VICAL de l’AAMVA, modèle de parties utilisatrices basé sur les certificats EUDI)

Chaque couche est fondée sur des normes actuelles ou sur une documentation active de l’écosystème. Les sections suivantes expliquent ce que fait chaque couche — et, tout aussi important, ce qu’elle ne fait pas.

Couche 0 — ISO/IEC 18013-1 : La base physique et sémantique

La partie 1 est plus importante que la plupart des gens ne le réalisent, car elle ne porte pas uniquement sur la conception des cartes.

L’ISO/IEC 18013-1 définit les caractéristiques physiques et l’ensemble de données de base d’un permis de conduire conforme à l’ISO, créant une base commune pour l’usage international et la reconnaissance mutuelle. Elle repose sur une carte sécurisée au format ID-1 associée à un livret à usage international, remplaçant l’ancien modèle de PIC papier. L’ISO indique également que, dans de nombreux cas, une seule carte peut remplacer la nécessité d’avoir deux documents séparés.

L’implication pratique est simple : le futur PIC ne peut pas partir de la couche portefeuille. Si la structure du document sous-jacent, le modèle de données et la présentation ne sont pas d’abord normalisés, chaque couche numérique au-dessus devient un correctif de compatibilité sur des formats nationaux fragmentés. La partie 1 est le fondement dont dépend le reste de la pile.

Couche 1 — ISO/IEC 18013-3 : Sécurité du titre

La partie 3 est là où le titre passe du statut de données sur un document à celui d’objet de sécurité. L’ISO décrit la norme 18013-3 comme la partie qui spécifie les mécanismes pour :

• Le contrôle d’accès aux données lisibles par machine
• L’authentification des documents
• La validation de l’intégrité

Toutefois, l’ISO est également explicite sur le fait que la partie 3 ne traite pas des questions de confidentialité liées à l’utilisation ultérieure des données — et cette frontière est importante.

En résumé, la norme 18013-3 assure la sécurité du titre, et non la gouvernance complète de l’écosystème. Elle aide à répondre à des questions telles que : Ce titre a-t-il été émis par l’autorité revendiquée ? Les données ont-elles été altérées ? Elle ne répond pas entièrement à : Ce vérificateur devrait-il seulement demander ce champ ? Cette demande devrait-elle être autorisée dans ce contexte ?

Il s’agit également d’une couche active plutôt que d’un produit achevé. L’ISO répertorie un amendement de 2022 pour le protocole PACE, un amendement de 2023 pour les mises à jour de l’authentification passive, et un nouveau projet de révision de la norme 18013-3 actuellement en cours d’élaboration.

Couche 2 — ISO/IEC 18013-5 : Présentation mobile en personne

Si la partie 1 définit le document et que la partie 3 le sécurise, la partie 5 transforme le permis en titre mobile.

L’ISO précise que la norme 18013-5 couvre l’interface entre le mDL et le lecteur, ainsi qu’entre le lecteur et l’infrastructure de l’autorité émettrice. Elle permet également à des tiers — y compris les autorités et les vérificateurs d’autres pays — de :

• Obtenir les données du mDL par machine
• Relier ces données au titulaire
• Authentifier leur origine
• Vérifier leur intégrité

Ce que la norme 18013-5 ne couvre pas est tout aussi important. L’ISO liste explicitement les éléments hors du champ d’application, notamment la manière dont le consentement du titulaire au partage des données est obtenu et les exigences relatives au stockage des données mDL et des clés privées. La partie 5 n’est pas un produit portefeuille complet, ni un modèle complet de consentement de l’utilisateur, ni un système de gouvernance complet. C’est la couche de transport et de vérification pour la présentation mobile.

Les recommandations de mise en œuvre de l’AAMVA précisent encore davantage cela en distinguant deux modèles de récupération :

• La récupération par l’appareil, où les données sont lues directement depuis l’appareil du titulaire.
• La récupération par serveur, qui peut permettre à l’autorité émettrice d’observer quand le mDL est utilisé, quelles données sont partagées, et même d’estimer la localisation physique par analyse IP.

Ce second point n’est pas une raison de rejeter la norme — c’est une raison d’être précis sur le modèle de récupération qu’un futur PIC devrait utiliser par défaut. L’AAMVA exige également que le portefeuille donne au titulaire un contrôle total sur les éléments de données partagés, ce qui correspond bien mieux à un futur PIC que l’ancien modèle « montrez l’intégralité du document ».

Couche 3 — ISO/IEC 18013-7 : Présentation par internet

La partie 5 résout le problème de la présentation en personne. La partie 7 étend ce modèle à l’utilisation à distance.

L’ISO décrit la norme 18013-7:2025 comme une extension de la norme 18013-5 permettant la présentation d’un mDL via internet à un lecteur. Internet n’est pas une considération secondaire dans cette architecture ; c’est une partie explicite de la norme.

Le guide européen sur le permis de conduire mobile traite déjà la présentation par internet comme pratique plutôt que théorique, décrivant des scénarios tels que :

• L’enregistrement lors de la location de voiture, où les utilisateurs partagent leur mDL en personne ou à distance à l’avance
• Les contrôles routiers par les forces de l’ordre
• Un profil d’utilisation général du mDL basé sur les normes ISO/IEC 18013-5 et 18013-7

Cela dit, les recommandations actuelles de l’AAMVA sont honnêtes quant aux limites : l’utilisation du mDL via internet est très souhaitable, mais certaines normes d’appui sont encore en cours de maturation. Il existe de réelles lacunes dans l’intégration actuelle entre les portefeuilles et les navigateurs, et sans liste de lecteurs de confiance, le côté mdoc pourrait ne pas avoir de moyen fiable de confirmer certaines propriétés de sécurité. La présentation à distance est réelle — et encore en développement.

Malgré ces réserves, la norme 18013-7 constitue la première réponse sérieuse à un problème que le PIC papier n’a jamais tenté de résoudre : la présentation à distance des droits de conduire, avant que la personne n’atteigne le guichet ou le point de contrôle.

Couche 4 — Modèle de données VC W3C 2.0 : La couche sémantique

Le modèle de données des justificatifs vérifiables W3C 2.0 n’est pas une norme pour les permis de conduire — et c’est précisément pourquoi il est important.

La Recommandation définit un modèle de données extensible pour les justificatifs vérifiables, explique comment ils peuvent être protégés contre toute modification, et décrit l’écosystème en termes de trois rôles fondamentaux : les émetteurs, les titulaires et les vérificateurs. Un permis de conduire figure parmi ses exemples fondamentaux.

Pour un futur PIC, le modèle VC 2.0 apporte un vocabulaire général pour les attributs, les présentations et les registres de données vérifiables. Le W3C précise explicitement que ces registres peuvent prendre plusieurs formes, notamment :

• Des bases de données de confiance
• Des bases de données d’identité gouvernementales
• Des bases de données décentralisées
• Des registres distribués

Cela brise le faux choix binaire entre une approche exclusivement basée sur la chaîne de blocs et une approche entièrement propriétaire. Le modèle de données est plus large que l’un ou l’autre.

Le modèle VC 2.0 est également clair sur la divulgation sélective. Le W3C note qu’un permis de conduire peut contenir plus de données qu’il n’en faut pour un cas d’usage donné, et recommande soit de diviser les informations en éléments plus petits, soit d’utiliser des mécanismes permettant la divulgation sélective. Pour un futur PIC, il ne s’agit pas d’un avantage optionnel en matière de confidentialité — c’est la différence entre un titre moderne et une simple copie numérique d’une carte plastifiée.

Le modèle VC 2.0 n’est cependant pas un remplacement complet de la norme ISO 18013. Le W3C souligne que le modèle de données n’exige pas un modèle traditionnel de chaîne de confiance basé sur une autorité de certification. En pratique, le modèle VC 2.0 constitue une solide couche sémantique, mais des couches explicites de distribution de la confiance et de gouvernance des vérificateurs doivent encore se superposer à celle-ci.

Couche 5 — OpenID4VCI : Le protocole d’émission

Un futur PIC a besoin d’un moyen normalisé de transférer un titre d’un émetteur vers un portefeuille. Tel est le rôle d’OpenID pour l’émission de justificatifs vérifiables (OpenID4VCI) 1.0.

La spécification définit une API protégée par OAuth pour l’émission de justificatifs vérifiables, et elle est intentionnellement indépendante du format. Parmi les formats de justificatifs qu’elle prend en charge :

• ISO mdoc
• SD-JWT VC
• Justificatifs W3C VCDM

Elle prend également en charge la liaison au titulaire et les présentations ultérieures sans intervention supplémentaire de l’émetteur. OpenID4VCI 1.0 a été approuvé en tant que spécification finale en septembre 2025.

Cela rend OpenID4VCI stratégiquement important pour un futur écosystème PIC. Plutôt que de construire des pipelines d’émission sur mesure entre chaque émetteur et chaque portefeuille pour chaque juridiction ou fournisseur de portefeuille, l’écosystème peut définir un profil d’émission gouverné sur la base d’un cadre d’émission normalisé — tout en choisissant si le titre résultant est encodé en mdoc, en VC ou dans un autre format pris en charge. Cette flexibilité constitue l’un des arguments les plus solides en faveur de la modularité de la pile du futur PIC.

Couche 6 — OpenID4VP : Le protocole de demande et de présentation

Si OpenID4VCI transfère le titre vers le portefeuille, OpenID pour les présentations vérifiables (OpenID4VP) le restitue de manière contrôlée.

La spécification définit un mécanisme pour demander et présenter des justificatifs. Sa version de base utilise des messages HTTPS et des redirections, mais elle prend également en charge l’utilisation via l’API des justificatifs numériques W3C à la place des flux de redirection. OpenID4VP 1.0 a atteint le statut de spécification finale en juillet 2025.

Cela est important car cela donne à la pile du futur PIC une couche de présentation native au web que les sites web, les applications et les vérificateurs en ligne peuvent implémenter directement. Plusieurs développements récents viennent renforcer cela :

• En août 2025, la Fondation OpenID a annoncé une analyse de sécurité formelle d’OpenID4VP utilisé avec l’API des justificatifs numériques, sans nouvelles vulnérabilités détectées dans le modèle de protocole vérifié.
• Le projet actuel du NIST sur le mDL base son modèle de menaces sur la demande et la présentation de mDL via OpenID4VP et l’API des justificatifs numériques W3C, avec FIDO CTAP utilisé pour imposer la proximité et résister au hameçonnage dans les flux concernés.

Le volet web de la pile et le volet mDL convergent. OpenID4VP ne doit pas être considéré comme un concurrent de la norme ISO 18013-7 — c’est la couche de protocole web qui rend la présentation par internet pratique dans les environnements réels de navigateurs, de portefeuilles et de vérificateurs.

Couche 7 — Registres de confiance : Là où la pile devient un écosystème

C’est la couche que beaucoup de discussions omettent — et la couche qui détermine si l’ensemble du système fonctionne réellement.

Un vérificateur ne peut pas faire grand-chose avec un titre signé s’il ne connaît pas trois choses :

• Quels émetteurs sont légitimes
• Quelles clés publiques sont à jour
• Si la partie requérante est elle-même autorisée

Du côté des émetteurs, le Service de confiance numérique de l’AAMVA offre une réponse concrète. Il fournit un moyen unique, sécurisé et résilient pour que les parties utilisatrices obtiennent les clés publiques des autorités émettrices, distribuées via la Liste des autorités de certification d’émetteurs vérifiés (VICAL). Les recommandations de l’AAMVA décrivent le rôle du fournisseur VICAL en termes pratiques : collecter les clés publiques auprès des autorités émettrices légitimes, vérifier que ces autorités gèrent leurs clés de manière sécurisée, regrouper les clés dans une VICAL unique et la distribuer aux vérificateurs.

Du côté des vérificateurs, l’Europe aborde le problème de confiance sous un autre angle. Dans le Cadre d’architecture et de référence EUDI, les parties utilisatrices s’enregistrent, obtiennent des certificats d’accès et utilisent ces certificats pour s’authentifier auprès des applications de portefeuille lors de la demande d’attributs. Le portefeuille vérifie ensuite la chaîne de certificats, contrôle l’état de révocation, présente la demande à l’utilisateur et ne libère que les attributs approuvés.

Le modèle VC du W3C contribue également ici, traitant les registres de données vérifiables comme un rôle distinct dans l’écosystème. Comme mentionné précédemment, ces registres peuvent être des bases de données de confiance, des bases de données d’identité gouvernementales, des bases de données décentralisées ou des registres distribués. Un futur registre de confiance pour le PIC n’a pas besoin d’être construit sur une chaîne de blocs. Il doit être gouverné, auditable et lisible par machine.

Si la norme ISO 18013 définit l’apparence et le transport du titre, les registres de confiance déterminent si quiconque devrait lui accorder crédit.

Comment fonctionne une transaction PIC future de bout en bout

Voici la pile en fonctionnement, décomposée en quatre moments clés du cycle de vie d’un titre.

1. Émission. Une autorité nationale — ou un émetteur autorisé et étroitement gouverné — vérifie le dossier de permis sous-jacent et émet un titre dans le portefeuille du titulaire. OpenID4VCI est la couche d’émission la plus pratique disponible aujourd’hui, car elle prend déjà en charge les formats ISO mdoc, SD-JWT VC et W3C VCDM. La norme ISO 18013-5 elle-même exclut de son champ d’application la collecte du consentement et le stockage des clés privées, ce qui explique précisément pourquoi l’émission et la gouvernance des portefeuilles doivent fonctionner au-dessus de la couche de transport ISO de base.

2. Présentation en personne. Lors d’un contrôle routier ou à un comptoir de location, le portefeuille présente le titre en utilisant un flux de proximité basé sur la norme 18013-5. Le lecteur valide l’origine et l’intégrité en utilisant les clés de l’émetteur obtenues depuis un registre de confiance — plutôt que de prendre des décisions de confiance de manière autonome. Le titulaire n’approuve que les champs nécessaires à cette situation spécifique.

3. Présentation à distance. Pour les vérifications préalables à la location ou d’autres processus en ligne, le vérificateur demande un ensemble minimal d’attributs via un flux compatible avec internet en utilisant les normes 18013-7 et/ou OpenID4VP. Le portefeuille indique quels attributs sont demandés, le titulaire approuve, et le vérificateur reçoit une présentation structurée plutôt qu’un scan ou un téléchargement de PDF. L’architecture actuelle du NIST, construite autour d’OpenID4VP et de l’API des justificatifs numériques, démontre qu’il s’agit désormais d’une voie d’ingénierie pratique.

4. Confiance et autorisation des vérificateurs. Le portefeuille ne fait pas confiance aveuglément à chaque requérant. Dans un écosystème mature, la partie utilisatrice est authentifiée, les chaînes de certificats sont validées, l’état de révocation est vérifié, et l’utilisateur dispose d’une visibilité sur qui demande quelles données. Le modèle EUDI est particulièrement solide à cet égard, traitant l’enregistrement des vérificateurs et les certificats d’accès comme des éléments essentiels du système plutôt que comme des compléments optionnels.

Ce flux complet explique précisément pourquoi un futur PIC doit être une pile. Aucune couche unique ne peut le réaliser seule. Ni l’ISO seul. Ni les VC seuls. Ni OpenID seul. Et certainement pas un PDF joint à un formulaire.

Ce qui manque encore à la pile du futur PIC

Le problème le plus difficile qui reste à résoudre n’est plus de créer de nouvelles cryptographies — c’est de parvenir à une interopérabilité gouvernée.

Considérons l’état actuel de l’écosystème :

• Le NIST a décrit le paysage normatif actuel comme étant en cours de développement dans des domaines séparés.
• L’AAMVA a mis en place un service de confiance régional pour l’Amérique du Nord.
• L’Europe intègre une confiance basée sur des certificats pour les parties utilisatrices dans son architecture de portefeuille.
• OpenID a finalisé les spécifications d’émission et de présentation et développe son infrastructure de conformité.

Ce sont encore des réponses propres à chaque écosystème. Il n’existe pas encore une couche de confiance transfrontalière mondiale unique pour les titres de conduite. Le travail restant consiste à définir :

• Quelles parties de la pile sont obligatoires
• Quels formats de titres sont acceptables
• Comment la confiance envers les émetteurs et les vérificateurs est distribuée
• Comment la conformité est testée
• Comment la reconnaissance transfrontalière est gouvernée sans compromettre la vie privée

Conclusion : Le futur PIC est une pile, et non un document

Un futur PIC n’apparaîtra pas parce qu’une organisation de normalisation rédige un seul document. Il émergera lorsqu’une pile cohérente sera définie, gouvernée et adoptée dans toutes les juridictions. Cette pile possède déjà des couches identifiables :

• ISO/IEC 18013-1 pour la base documentaire
• ISO/IEC 18013-3 pour la sécurité du titre
• ISO/IEC 18013-5 pour la présentation mobile en personne
• ISO/IEC 18013-7 pour la présentation à distance
• W3C VC 2.0 pour la sémantique portable
• OpenID4VCI pour l’émission
• OpenID4VP pour la demande et la présentation
• Les registres de confiance pour la confiance machine et l’autorisation des vérificateurs

Voilà l’architecture derrière un futur PIC. Ni un livret. Ni une application. Une pile.