« Hack » de l'app européenne de vérification d'âge : la réalité

Ce qui s'est passé les 15 et 16 avril 2026

Le 15 avril 2026, la présidente de la Commission européenne Ursula von der Leyen a annoncé depuis Bruxelles que l'application européenne de vérification d'âge — souvent surnommée le « mini-portefeuille » parce qu'elle constitue un sous-ensemble restreint du futur portefeuille européen d'identité numérique (portefeuille EUDI) — était techniquement prête à être déployée. En moins de 24 heures, le consultant en sécurité Paul Moore a publié sur X une courte vidéo affirmant qu'il pouvait contourner les protections de l'application en moins de deux minutes. La presse a repris l'information rapidement, et l'affaire a explosé sur Reddit avec des dizaines de milliers de votes positifs sur r/europe, r/privacy, r/technology et r/BuyFromEU.

Si vous exploitez une caisse marchande, un backend vérificateur ou une plateforme soumise à restriction d'âge, le titre « piraté en 2 minutes » a de quoi inquiéter. Il est aussi trompeur. Voici la réalité technique.

Les trois défauts de conception identifiés par le chercheur

L'analyse de Moore, fondée sur le code source Android public disponible sur eu-digital-identity-wallet/av-app-android-wallet-ui, met en évidence trois faiblesses dans la gestion de l'état local de l'application sur un appareil Android.

1. Le code PIN n'est pas couplé au coffre d'identité

L'application stocke un code PIN chiffré dans son fichier de préférences locales. Or la clé de chiffrement n'est pas liée cryptographiquement au coffre de justificatifs où résident les attestations d'âge signées. En supprimant les entrées liées au PIN dans le fichier de configuration puis en redémarrant l'application, un attaquant peut définir un tout nouveau PIN tout en héritant des justificatifs de l'utilisateur précédent. Le coffre accepte le PIN réinitialisé comme un nouveau contrôle d'accès légitime, parce que le PIN et les justificatifs n'ont jamais été verrouillés ensemble.

Il s'agit d'un véritable défaut de conception. Une architecture respectueuse de la vie privée devrait invalider les justificatifs stockés dès que le PIN est réinitialisé.

2. La limitation de tentatives stockée comme un compteur en clair

L'application se protège contre les attaques par force brute du PIN grâce à un compteur qui s'incrémente à chaque tentative ratée. Ce compteur se trouve dans le même fichier de configuration modifiable que l'état du PIN. Remettez-le à zéro et l'application oublie toutes les tentatives précédentes.

3. Vérification biométrique contrôlée par un simple booléen

La vérification biométrique est activée ou contournée en fonction d'un unique drapeau true/false dans la configuration. Basculez-le sur false et l'étape biométrique n'est jamais exécutée.

La réserve que les gros titres passent sous silence

Les trois contournements exigent un accès physique à un appareil Android rooté et déverrouillé. À ce stade, l'attaquant dispose déjà d'un accès en lecture-écriture complet au stockage privé de l'application — exactement le même niveau d'accès que l'application elle-même. Il ne s'agit pas d'une exploitation à distance. Elle ne peut pas être déclenchée via le réseau. Elle ne laisse fuir aucun justificatif hors de l'appareil. Aucun tiers ne reçoit de données personnelles à la suite de ce contournement.

Le commentaire le plus voté sur le fil r/europe le résume simplement : « avec un accès physique à l'appareil rooté déverrouillé — c'est quand même un détail important ». Ce commentaire a atteint 140 votes positifs en quelques heures précisément parce que le public technique de Reddit a vu à travers la mise en scène.

Ce que cela signifie pour les vérificateurs et les marchands

Si vous intégrez la vérification d'âge dans une caisse ou une plateforme, la question pertinente est : un attaquant peut-il présenter une attestation d'âge frauduleuse à mon backend ? La réponse, sur la base de la divulgation actuelle, est non. Le contournement permet à l'attaquant d'accéder à ses propres justificatifs précédemment stockés sous un nouveau PIN, sur son propre appareil compromis. Il ne lui permet ni de forger un justificatif, ni d'en émettre un nouveau, ni de rejouer l'attestation signée de quelqu'un d'autre.

Le protocole OpenID4VP qui sous-tend le flux de présentation à distance fonctionne toujours exactement comme spécifié. Pour un regard plus approfondi sur la manière dont ce protocole protège les vérificateurs contre le rejeu et l'altération des justificatifs, consultez notre analyse approfondie d'OpenID4VP et notre explication technique du fonctionnement de la vérification eIDAS.

Les préoccupations structurelles légitimes

Indépendamment du « hack » lui-même, la divulgation a fait émerger deux critiques structurelles plus difficiles à écarter.

Le verrouillage par plateforme. Parce que l'application repose sur l'attestation du système d'exploitation et sur des binaires signés pour prouver son intégrité, elle ne fonctionne que sur des builds iOS et Android signés. Un post très voté sur r/privacy soutient qu'aucun client libre ne pourra jamais être publié, puisque tout binaire auto-compilé échouera à l'attestation. Cela pose problème si vous êtes une institution européenne dont le mandat de souveraineté numérique interdit les dépendances dures envers Apple et Google.

La dépendance aux Google Play Services. Des développeurs hongrois sur r/programmingHungary ont souligné que la build Android nécessite les Google Play Services pour fonctionner. Un outil d'identité numérique européen qui ne peut pas être utilisé sans accepter le contrat de licence utilisateur de Google cadre mal avec l'indépendance que l'UE revendique vis-à-vis des hyperscalers américains.

La discussion hongroise, techniquement très solide, a aussi fait l'observation positive la plus juste : la pile protocolaire sous-jacente — OpenID Verifiable Credentials combiné à la divulgation sélective d'OpenID4VP — constitue véritablement l'une des conceptions les plus respectueuses de la vie privée actuellement déployées pour la vérification d'âge. Les problèmes d'implémentation sont corrigeables ; l'architecture cryptographique, elle, est solide.

Pourquoi l'open source gagne cette manche

Le cycle de divulgation lui-même est le meilleur argument en faveur du choix open source de l'UE. Les failles ont été identifiées par un chercheur indépendant lisant du code source public, reproduites en 24 heures, et avancent déjà dans le pipeline normal de correctifs. Une implémentation propriétaire aurait été livrée avec les mêmes bugs, et personne en dehors de l'éditeur ne l'aurait su jusqu'à ce qu'une véritable brèche force la divulgation.

Nous avons longuement expliqué pourquoi nous avons retenu la même approche pour notre propre SDK — consultez Présentation d'OpenEUDI : notre SDK de vérification open source et les leçons que l'audit européen apprend aux créateurs de portefeuilles open source.

Ce que les marchands devraient faire aujourd'hui

1. Ne modifiez pas vos plans d'intégration. Le contournement n'affecte pas le flux de présentation OpenID4VP que votre backend vérifie. Les attestations signées restent cryptographiquement valides.
2. Surveillez le calendrier des correctifs. L'application Android de référence de l'UE sera patchée ; les trois problèmes ci-dessus sont des corrections logicielles simples.
3. Séparez la vérification d'âge de la récupération de compte. Si votre caisse stocke un état local lié à un utilisateur vérifié, appliquez la leçon : liez cryptographiquement les contrôles d'accès (PIN, passkey) aux données qu'ils protègent.
4. Si vous construisez votre propre vérificateur, adoptez notre modèle centré sur la vie privée — vérifiez une fois, ne stockez qu'un booléen, ne conservez aucune image de document. Consultez Vérification d'âge centrée sur la vie privée avec OpenEUDI pour l'implémentation de référence.

La perspective plus large

Cette affaire nous dit trois choses sur l'état de l'écosystème du portefeuille EUDI en avril 2026. Premièrement, l'UE livre véritablement du code auditable, et des chercheurs l'auditent véritablement. Deuxièmement, les applications portefeuille sont construites avec une dépendance substantielle à l'attestation de plateforme — un compromis aux implications sérieuses pour la souveraineté et la portabilité. Troisièmement, le flux de vérification côté marchand n'est pas touché par cette divulgation. Si vous aviez prévu d'ajouter la vérification par portefeuille EUDI à votre caisse, rien dans ces 72 dernières heures ne devrait modifier ce plan.

Pour une vue pays par pays de l'état des déploiements des portefeuilles dans les États membres, consultez notre état des lieux du déploiement du portefeuille EUDI en avril 2026. Pour le cadre juridique qui régit l'enrôlement des utilisateurs, consultez notre décryptage du règlement d'exécution 2026/798.

---

Vous cherchez une intégration vérificateur prête pour le portefeuille EUDI dès aujourd'hui et qui passe automatiquement en production ? Consultez les offres managées d'eIDAS Pro ou le guide de démarrage rapide du SDK OpenEUDI.