Audit des portefeuilles open source : la divulgation UE, une victoire

Le gros titre et la réalité

« L'application européenne de vérification d'âge peut être piratée en 2 minutes » : voilà le titre qui a déferlé sur Reddit et dans la presse spécialisée entre le 15 et le 17 avril 2026. Plus de 6 500 votes positifs à travers r/europe, r/privacy, r/technology et r/BuyFromEU ont présenté l'affaire comme un échec — l'UE livre un outil respectueux de la vie privée, un chercheur le casse, les critiques s'empilent.

Nous lisons cela autrement. Le cycle de divulgation qui a produit ce titre est exactement ce qu'une infrastructure numérique publique est censée faire. C'est le meilleur argument que nous ayons vu cette année pour expliquer pourquoi les logiciels critiques adjacents à l'État doivent être open source, et pourquoi chaque vérificateur qui s'intègre au portefeuille EUDI devrait emprunter la même voie.

Pour l'analyse technique de ce que Paul Moore a réellement trouvé, consultez notre décryptage détaillé de la divulgation sur l'application européenne de vérification d'âge. Le présent article prend de la hauteur.

Comment le cycle s'est réellement déroulé

Jour 0 — La Commission européenne annonce que l'application de vérification d'âge est techniquement prête. Von der Leyen insiste sur le fait que le code est entièrement open source et que chacun peut l'inspecter.

Jour 1 — Un chercheur en sécurité indépendant (Paul Moore) lit le dépôt Android public, identifie trois défauts de conception dans la gestion de l'état local et publie une courte démonstration sur X.

Jour 2 — Reddit et la presse technique amplifient l'affaire. Les communautés de la vie privée et de la sécurité plongent elles-mêmes dans le code source. D'autres chercheurs reproduisent les résultats, clarifient les réserves et séparent le FUD des préoccupations légitimes.

Jour 3 et au-delà — Le cycle de correctifs commence. L'équipe de référence de l'UE voit des tickets publics ouverts sur son dépôt. Les corrections seront intégrées à la branche principale, revues publiquement et livrées dans la prochaine version.

C'est une boucle d'audit qui fonctionne, et elle a pris trois jours. Un logiciel propriétaire ne bouge pas aussi vite, ne révèle pas les failles aussi publiquement, et ne permet pas à la communauté de construire sa confiance progressivement en lisant ce qui est corrigé et pourquoi.

À quoi ressemble la divulgation d'un portefeuille propriétaire

Comparons le cycle du portefeuille EUDI à la manière dont se sont historiquement déroulées les brèches chez les éditeurs de vérification d'identité. Parcourez n'importe lequel des incidents notables du secteur ces dernières années et un schéma se dégage :

• L'éditeur découvre ou suspecte un problème en interne.
• Des semaines, voire des mois, s'écoulent avant qu'une partie externe ne soit informée.
• La remédiation commence à huis clos, sans détail public sur ce qui est corrigé.
• La divulgation, si elle a lieu, est soit un dépôt réglementaire a posteriori, soit un communiqué de presse minimisant la portée.
• Les utilisateurs finaux et les intégrateurs n'ont aucun moyen de vérifier si le correctif traite la cause racine, puisque la source n'est pas publique.

Voilà le contrefactuel. Une application européenne de vérification d'âge propriétaire aurait été livrée avec les trois mêmes défauts que Paul Moore a trouvés. Personne en dehors de l'équipe de développement ne l'aurait su. Les défauts seraient restés non exploités (ou exploités en silence par des adversaires bien dotés) jusqu'à ce qu'une brèche publique impose la divulgation. Le cycle de correctifs serait plus lent. La confiance dans le système serait plus basse.

Les affirmations précises qui tiennent la route

La réaction technique sur Reddit mérite attention parce qu'elle ne s'est pas contentée d'approuver le chercheur. Elle a validé certaines parties de ses affirmations, contesté la mise en scène, et ajouté des observations qu'il avait manquées.

Critique valide, correctement rapportée. Trois défauts de conception dans la gestion de l'état local sur un appareil rooté physiquement compromis. Ils sont réels et seront corrigés.

Contestation de la mise en scène par le public technique. Plusieurs commentaires très votés à travers les subreddits ont souligné qu'« un appareil rooté avec accès physique » est un modèle de menace substantiellement plus étroit que ne le laisse entendre « piraté en 2 minutes ». Le commentaire à 832 votes positifs sur r/europe observait simplement : « c'est ainsi qu'un logiciel open source est censé fonctionner ».

Préoccupations supplémentaires soulevées par la communauté. L'exigence de s'appuyer sur l'attestation de plateforme (qui impose iOS ou Android), la dépendance aux Google Play Services dans la build Android, et l'absence de voie pour des clients libres — tous ces points ont été soulevés par des membres de la communauté lisant le même code source. Ce sont des enjeux stratégiques plus sérieux que les bugs d'état local, et ils auraient été invisibles dans une implémentation propriétaire.

Éloge technique informé. Le fil des développeurs hongrois sur r/programmingHungary portait la discussion la plus techniquement pointue que nous ayons vue : identification correcte de la pile sous-jacente OpenID Verifiable Credentials couplée à la divulgation sélective d'OpenID4VP, reconnaissance que l'architecture de confidentialité est l'une des meilleures conceptions de l'espace de la vérification d'âge, et critique simultanée de la dépendance aux Google Play Services. Ce genre d'évaluation publique nuancée ne peut tout simplement pas se produire contre du code fermé.

Pourquoi cela importe spécifiquement pour les vérificateurs

Si vous construisez un vérificateur qui consommera en production des attestations de portefeuille EUDI, le cycle de divulgation auquel vous venez d'assister est celui sur lequel vos clients vous jugeront. Les marchands et les utilisateurs finaux ne liront pas votre code source. Ils liront des articles sur les brèches, les correctifs, et la vitesse à laquelle ils sont intervenus. Un SDK vérificateur open source qui corrige ses bugs en public hérite des propriétés de construction de confiance de l'écosystème de portefeuilles auquel il participe.

Nous avons construit OpenEUDI sur ce principe. Chaque ligne de la logique vérificateur est sous licence MIT et auditable publiquement. Quand quelqu'un trouve une faille, il peut la signaler, nous la corrigeons publiquement, et chaque intégrateur voit la correction. Quand quelqu'un veut comprendre comment nous gérons un cas limite délicat d'OpenID4VP, il peut lire le code plutôt que de faire confiance à notre marketing. Le tutoriel de démarrage rapide du SDK OpenEUDI parcourt la même implémentation qu'un chercheur en sécurité auditerait.

L'argument de la souveraineté

Il existe un deuxième argument qui n'a rien à voir avec les bugs. L'UE a passé des années à articuler une défense de la souveraineté numérique : les données d'identité des citoyens européens, les clés cryptographiques des institutions européennes, les droits d'audit des régulateurs européens ne devraient pas dépendre de logiciels dont personne en dehors d'un éditeur étranger ne peut lire le code.

La seule conclusion honnête de cette position est que toute l'infrastructure d'identité imposée par l'UE doit être open source. Pas « open source » comme argument marketing, mais du code à source ouverte, reproductiblement constructible, et auditable par la communauté. Tout ce qui est moindre laisse une brèche de souveraineté qu'aucun dossier de certification ne peut combler.

L'UE a pris cette conclusion au sérieux avec le portefeuille et l'application de vérification d'âge. L'infrastructure vérificateur devrait la prendre tout aussi au sérieux. Un vérificateur qui fait confiance à des attestations de portefeuille open source et qui fait tourner lui-même du code propriétaire est incohérent au mieux, stratégiquement fragile au pire.

Ce que « open source » devrait signifier pour un vérificateur

Pour être clair, « open source » est une condition nécessaire mais non suffisante. Un vérificateur open source devrait aussi :

Être auditable, pas seulement lisible. Du code sans couverture de tests ou avec des chaînes de dépendances opaques est techniquement lisible mais pas pratiquement auditable. Le projet de schéma de certification de l'ENISA capture cette distinction dans le contexte des portefeuilles, et le même standard s'applique aux vérificateurs.

Corriger les bugs en public. Un correctif privé poussé vers un dépôt public ne vaut que la moitié. Les trackers de tickets, les pull requests publiques et les journaux de modifications transparents sont ce qui fait fonctionner la boucle d'audit.

Accepter les contributions. Permettre à des chercheurs externes de soumettre des correctifs maintient le mainteneur honnête et la communauté investie.

Conserver une licence permissive. MIT, Apache 2.0, ou une licence similairement permissive. Les licences copyleft sont philosophiquement défendables mais limitent en pratique qui acceptera de s'intégrer à votre code.

Les leçons côté vérificateur

La divulgation d'avril 2026 laisse trois leçons durables à quiconque construit sur l'écosystème du portefeuille EUDI.

Utilisez du code auditable. Que vous adoptiez notre SDK OpenEUDI, une autre implémentation ouverte, ou que vous bâtissiez la vôtre, choisissez une pile que les chercheurs en sécurité peuvent lire. Si votre vérificateur est livré en code fermé, vous acceptez le mode d'échec décrit plus haut : correctifs plus lents, confiance moindre, aucune voie pour les contributions externes.

Laissez l'écosystème faire une partie de votre revue de sécurité. Lire ce que les chercheurs trouvent dans les projets open source connexes — le portefeuille, l'application de vérification d'âge, les vérificateurs de référence — est l'une des activités de sécurité à plus fort levier pour une équipe vérificateur. Vous obtenez des découvertes avant qu'elles ne deviennent des incidents.

Séparez l'architecture de confidentialité des bugs d'implémentation. Les critiques qui disent « l'application européenne de vérification d'âge a des bugs, donc toute l'approche respectueuse de la vie privée est cassée » ont tort. La conception cryptographique est solide. Les bugs sont dans la gestion de l'état local, pas dans le protocole. Consultez Vérification d'âge centrée sur la vie privée avec OpenEUDI pour construire sur les mêmes primitives respectueuses de la vie privée.

La victoire discrète

S'il y a une phrase à retenir de tout cet épisode, c'est celle écrite par l'utilisateur le plus voté sur r/europe : « c'est ainsi qu'un logiciel open source est censé fonctionner ». Ce n'est pas une défense des bugs. C'est une description du système qui les trouve et les corrige. Ce système est meilleur que l'alternative, avec une marge qui grandit à chaque fois qu'un éditeur propriétaire subit une brèche et la gère à l'ancienne.

L'UE s'est engagée à construire son infrastructure d'identité au grand jour. Les bâtisseurs de vérificateurs devraient prendre le même engagement. Pour l'état actuel de cette infrastructure à travers les 27 États membres, consultez notre traqueur de déploiement d'avril 2026, et pour le cadre réglementaire qui la sous-tend, consultez notre décryptage du règlement d'exécution 2026/798.

---

OpenEUDI est sous licence MIT, auditable et gratuit. Pour une vérification en production avec des certificats WRPAC managés et une base de code entièrement open source, consultez les offres managées d'eIDAS Pro.