Une vérification d’âge qui fonctionne vraiment : le plan 30-60-90 d’un CTO

Bruxelles a lancé une application de contrôle d’âge ; des hackers l’ont cassée en deux minutes. Ce n’est pas un problème « européen ». C’est un schéma récurrent : contrôles fragiles côté client, jetons prévisibles et absence de tests adversariaux. Si vous possédez un produit soumis à une pression de contrôle d’âge en 2026 — social, gaming, fintech, marketplaces UGC, ou tout ce qui touche au UK Online Safety Act, à la COPPA ou au EU DSA — vous n’êtes qu’à une implémentation bâclée d’un titre à la une et d’un email d’un régulateur.

Corrigeons cela avec un cadre de décision et un plan 30‑60‑90 jours réaliste. Pas un essai de conformité. Un plan d’ingénierie exécutable.

Premiers principes : à quoi ressemble le « bon »

• Modèle de menace d’abord : Vous devez vous défendre contre des mineurs motivés avec du temps, des adultes cherchant l’anonymat, des fermes automatisées et des moddeurs avec appareils rootés. Supposez qu’ils utilisent des LLM pour script-er et itérer des exploits. L’usage offensif de l’IA est un fait : des exploits récents montrent que de petits bugs plus un outil d’IA peuvent amplifier rapidement les dégâts.
• Vérifié côté serveur, résistant à la falsification : Ne faites jamais confiance à l’état du client pour les décisions finales. Les jetons doivent être de courte durée, liés à une audience, et vérifiés côté serveur ou à l’edge. Considérez que votre JavaScript est transparent pour votre attaquant.
• Minimisation des données par conception : Stockez une preuve de la preuve, pas de PII/données personnelles brutes. Si un fournisseur peut conserver les documents et que vous ne gardez que des attestations signées, faites-le.
• Instrumenté et mesurable : Suivez les faux positifs/négatifs, les taux de challenge, les entonnoirs de réessai et les indicateurs de bots. On n’améliore pas ce qu’on ne mesure pas.
• Échec sûr : En cas de doute, limitez l’accès de façon gracieuse, pas avec des murs de refus fragiles qui poussent les utilisateurs, par frustration, à chercher des contournements.

Choisissez votre niveau d’assurance avant de choisir votre fournisseur

Choisissez l’assurance dont vous avez besoin et la friction que vous pouvez tolérer. Il n’existe pas de parcours magique à la fois sans friction et inviolable.

1. Auto‑attestation + contrôles appareil (Faible assurance, Faible friction)
   Adapté à la classification de contenu à faible risque. Pensez filtrage de contenu, pas barrières d’âge légales. Implémentez des hooks de contrôle parental et des nudges honnêtes. Attendez‑vous à un fort contournement par des utilisateurs motivés.
2. Barrière via instrument de paiement (Assurance moyenne, Friction moyenne)
   Vérifiez une carte détenue par un adulte via une capture à 0 $ ou une autorisation de 1 $ via un PSP (p. ex., Stripe). Cela filtre généralement les mineurs mais échoue pour les cartes partagées ou prépayées. Coût : ~0,05–0,30 $ par vérification ; mise en place en 1–2 sprints.
3. KYC document + selfie (Forte assurance, Forte friction)
   Utilisez un fournisseur réglementé (p. ex., Onfido, Veriff, Persona, Trulioo) pour vérifier une pièce d’identité gouvernementale avec preuve de vie. Coût typique : 1–3 $ par vérification, plus élevé dans certaines régions. Attendez‑vous à 85–92 % de complétude au premier passage sur mobile avec une bonne UX. Stockez des attestations, pas des images.
4. eID / MNO / identité bancaire (Très forte assurance, Friction variable)
   Là où c’est disponible, utilisez l’eID gouvernementale (eIDAS, BankID), des vérifications par opérateur mobile (MNO) ou des attestations d’âge basées sur la banque. Idéal pour les marchés régulés ; la couverture varie fortement ; l’intégration peut être plus longue mais offre la plus forte défendabilité.

Faites correspondre ce qui précède à votre exposition réglementaire :

• COPPA (US) : Si vous collectez sciemment des données auprès de moins de 13 ans, vous avez besoin d’un consentement parental vérifiable. La vérification par paiement ou par pièce d’identité répond au niveau requis ; l’auto‑attestation non.
• UK Online Safety Act : Le contrôle de contenu nuisible pour les mineurs nécessitera probablement une assurance plus forte que l’auto‑attestation ; les régulateurs chercheront un raisonnement et des tests documentés.
• EU DSA/AVMSD et régimes locaux : Attendez‑vous à des variations ; documentez votre AIPD (DPIA) et vos contrôles de minimisation.

Qu’est‑ce qui a cassé en deux minutes ? Les suspects habituels

Nous n’avons pas besoin de comptes rendus fuités pour deviner la classe de bugs qui tue les contrôles d’âge rapidement :

• Confiance côté client uniquement : Flags dans LocalStorage, paramètres de requête, ou tout flux gardé par JS sans vérification côté serveur.
• Jetons prévisibles ou rejouables : JWT longue durée sans audience, nonce ni rotation ; HMAC sans liaison de contexte.
• Pas de preuve de vie : Photo uploadée acceptée comme « selfie », ou challenge de liveness affiché mais non lié à la session serveur.
• Open redirect / chemins de contournement : Routes alternatives vers le contenu qui sautent le middleware.
• Incohérence Edge/CDN : Configuration de cache servant du contenu gardé au mauvais cohort en raison d’en‑têtes Vary manquants ou de cookies mal scopés.

Architecture de référence (vérifiée côté serveur, minimisant les données)

• Middleware à l’edge en premier : Au niveau du CDN ou d’une fonction edge, vérifiez la présence d’un jeton « age‑ok » court‑vécu et lié à une audience. S’il est absent, redirigez vers un endpoint d’initialisation de vérification. Ne servez jamais de contenu gardé avant ce contrôle.
• Broker de vérification : Un service qui orchestre les flux (paiement, ID, eID). Il émet une session à usage unique, enregistre les résultats des fournisseurs et génère un jeton d’attestation (signé, TTL 5–30 min, lié à l’empreinte d’appareil + compte + classe de contenu).
• Périmètre des données personnelles : Externalisez la gestion de PII brute au fournisseur quand c’est possible. Ne stockez que : ID de référence fournisseur, horodatage, juridiction, résultat (pass/fail/review) et une signature/reçu détaché.
• Moteur de risque : Maintenez une allowlist de méthodes à forte assurance par marché. Élevez vers des contrôles plus forts selon les signaux : nouvel appareil, Tor/VPN, émulateur, entropie de clic anormale, réessais rapides.
• Observabilité : Émettez des métriques : taux de complétion, abandon par étape, estimations de faux accept/refus (via QA manuelle périodique), réattaques par IP/hash appareil, et latence des fournisseurs.

Le test du hack en 2 minutes : 12 contournements à bloquer dès le premier jour

1. Basculer n’importe quel flag client évident (localStorage/sessionStorage) et recharger le contenu gardé.
2. Rejouer le callback de vérification avec un statut modifié : status=“pass.”
3. Demander le contenu gardé via une URL d’actif directe qui contourne le middleware.
4. Utiliser une version en cache d’une page gardée depuis un cache partagé ou un snapshot de moteur de recherche.
5. Modifier une revendication « age » d’un JWT sans vérification (deviner le secret HS256, alg=none).
6. Usurper le user agent/appareil pour sauter une barrière mobile‑only.
7. Téléverser un selfie imprimé ou une photo statique pour tester la preuve de vie (liveness).
8. Utiliser un émulateur pour contourner des challenges de liveness basés sur le mouvement.
9. Retenter la vérification depuis plusieurs comptes sur le même appareil jusqu’à ce qu’un chemin faible apparaisse.
10. Frapper des endpoints régionaux où la barrière est mal configurée (EN vs. FR vs. BR).
11. Exploiter un open redirect ou une page de succès de checkout pour frapper un token sans vérification.
12. Abuser des clés de cache du CDN pour obtenir une réponse tokenisée d’une autre identité.

Si l’un de ces points fonctionne aujourd’hui dans votre environnement de staging, vous n’avez pas une barrière — vous avez du théâtre.

30‑60‑90 jours : livrez quelque chose de défendable sans tuer la conversion

Jour 0–30 : rendez‑le réel et mesurable

• Décidez du niveau d’assurance par marché : Minimal dans les marchés à faible risque, barrière par paiement dans les marchés moyens, doc+selfie dans les marchés à haut risque, eID là où c’est requis. Écrivez‑le.
• Mettez en place une barrière à l’edge : Bloquez les routes gardées sans jeton signé, court‑vécu et lié à une audience. Ajoutez un fallback HTML expliquant pourquoi la vérification est requise.
• Choisissez un fournisseur par méthode : Paiement (votre PSP), doc+selfie (shortlistez‑en 2, faites un bake‑off sur latence et taux de réussite dans vos 3 marchés principaux), eID (pays spécifiques). Visez un P95 de bout en bout < 7 secondes pour doc+selfie en 4G.
• Implémentez le broker de vérification : Interface unique qui normalise les résultats et émet le jeton d’attestation. Lie les jetons à : ID de compte, hash appareil, géolocalisation IP grossière, et classe de contenu.
• Minimisation des données : Assurez‑vous que les fournisseurs stockent la PII ; vous ne conservez que des reçus signés + métadonnées. Chiffrez au repos ; rétention 30–90 jours sauf obligation légale plus longue.
• Mode fantôme (shadow) : Affichez les invites de vérification mais ne bloquez pas le contenu pendant 1–2 semaines ; mesurez la conversion et la latence technique. Cela vous donne une base sans fâcher les utilisateurs.
• Tests de fumée en red team : Exécutez la liste des 12 contournements chaque semaine. Corrigez toute réussite sous 72 heures.

Jour 31–60 : renforcez et alignez‑vous avec les régulateurs

• Ajoutez la preuve de vie et des défenses anti‑rejeu : Si vous utilisez doc+selfie, assurez des challenges liés au serveur et de l’anti‑usurpation (clignement/tourner la tête, analyse de texture). Bloquez les émulateurs pour l’étape de liveness.
• AIPD (DPIA) et piste d’audit : Documentez les flux de données, contrats fournisseurs, rétention et contrôles de sécurité. Journalisez les décisions de vérification avec reçus signés, mais évitez le stockage de PII brute.
• Risque adaptatif : Élevez vers des contrôles plus forts quand des signaux se déclenchent (p. ex., sortie Tor, changement soudain de locale ou churn d’empreinte appareil). Gardez un budget quotidien pour les contrôles forts afin de maîtriser le coût.
• Cohérence à l’edge : Ajoutez du cache‑busting et des en‑têtes Vary pour le jeton de barrière ; validez les configurations régionales.
• Parcours de support pour les utilisateurs légitimes : Mettez en place une file de revue manuelle pour 0,5–1 % des cas ; SLA de complétion < 24 h ; publiez un formulaire d’appel.
• Optimisation de la conversion : Mobile‑first, texte clair (« Pourquoi on demande »), indicateur de progression. De bons parcours atteignent couramment 85–92 % de complétion sur smartphone ; vous pouvez y arriver aussi.

Jour 61–90 : scalez, surveillez et invitez les attaquants (selon vos règles)

• Blocage en production : Activez le blocage dur là où le marché l’exige ; poursuivez le mode fantôme ou soft gating ailleurs jusqu’à atteindre vos KPI.
• Bug bounty ou programme privé : Invitez à la divulgation responsable. Offrez 500–5 000 $ pour des contournements du gating et des résultats de vérification d’identité.
• Astreinte et tableaux de bord : Alertes pour variations du taux de réussite > 5 %, pics de latence fournisseur > 2× la base, ou grappes de réessais depuis le même appareil/plage IP.
• Vérification périodique des fournisseurs : Bake‑off trimestriel. Évaluez précision, latence et dérive des coûts. Les fournisseurs changent de modèles ; votre assurance se dégrade si vous ne surveillez pas.
• Exercice sur table avec Juridique/Policy : Simulez un article de presse et une demande d’un régulateur. Assurez‑vous de pouvoir produire en 48 heures : AIPD (DPIA), architecture, logs et preuve des contrôles fournisseurs.

Friction vs fraude vs coût : un rapide reality check

• Coût du contrôle via paiement : 0,05–0,30 $ par vérification ; forte couverture ; assurance limitée ; risque PII minimal.
• Coût du KYC doc+selfie : 1–3 $ par réussite ; certaines régions 5 $+ ; forte assurance ; charge de confidentialité plus lourde (externalisez au fournisseur).
• Latence fournisseur : De bons parcours mobiles P95 5–7 s ; au‑delà de 10 s, la complétion s’écrase. Mesurez sur Android entrée de gamme en 4G dans vos principaux marchés, pas seulement dans la Bay Area en Wi‑Fi.
• Déplacement de la fraude : Le gating pousse les acteurs malveillants vers la revente de comptes et le détournement de session. Coordonnez avec la sécurité des comptes (2FA, liaison d’appareil, détection d’anomalies).

Vie privée et conformité sans auto‑sabotage

• Minimisez les données personnelles : Stockez des attestations, pas des documents. Si les régulateurs demandent, montrez les reçus fournisseur et votre AIPD (DPIA) — pas un bucket plein de passeports.
• Routage sensible à la région : Tenez vos promesses de résidence des données. Utilisez des régions fournisseurs qui correspondent à l’emplacement utilisateur ; évitez les transferts transfrontaliers silencieux.
• Discipline de rétention : 30–90 jours pour les reçus sauf obligation plus longue. Les clés d’effacement cryptographique aident à prouver la suppression.
• Contrôles d’accès : Traitez les journaux de vérification comme sensibles. Contrôles à la SOC 2 : moindre privilège, journaux d’audit immuables, et revues d’accès trimestrielles.

Pourquoi cela échoue en pratique : signaux d’alerte organisationnels

• Théâtre de sécurité : Livrer une jolie modale sans barrière serveur parce que « il nous la faut ce trimestre ». Cela vous achète un titre, pas du temps.
• Conformité détachée de l’ingénierie : Des politiques qui ne correspondent pas au vrai flux. Si le juridique ne peut pas pointer le chemin de code, vous n’avez pas de conformité — vous avez de la paperasse.
• Pas de tests adversariaux : La QA teste le happy path ; personne n’essaie de le casser. Vos attaquants, si.
• Religion du fournisseur unique : Les fournisseurs changent précision, prix et ToS. Construisez un broker pour pouvoir remplacer sans tout réécrire.

Réalité des ressources et du calendrier

Vous n’avez pas besoin d’une équipe Trust & Safety de 20 personnes pour y arriver. Une core team focalisée peut livrer une v1 défendable en 6–10 semaines :

• Noyau de build : 1 senior backend, 1 senior frontend, 1 SRE orienté sécurité, 0,5 produit/UX, 0,5 ingénieur sécurité (conseil). Ajoutez un conseil privacy pour revue AIPD.
• Fuseaux horaires : Avec une équipe nearshore basée au Brazil vous avez 6–8 heures de recouvrement avec le fuseau US, suffisant pour itérer vite et faire du red teaming quotidien.
• Coût : Mettre en œuvre paiement‑gate + doc+selfie via des fournisseurs coûte 20–30 % de moins avec une équipe nearshore qu’avec un staffing 100 % US, et vous évitez les délais multi‑trimestres d’une R&D KYC en interne.

Gouvernance : quoi mettre sur le tableau de bord du CTO

• Taux de réussite par méthode et par marché : Ciblez ≥ 85 % de complétion au premier passage pour doc+selfie sur mobile dans vos principaux marchés ; alertes sur des baisses de −5 %.
• Mix d’assurance : Part des utilisateurs par méthode (auto, paiement, doc+selfie, eID). Connaissez votre posture de risque réelle.
• Latence médiane et P95 : Par classe d’appareil et réseau. Corrélez les pics avec l’abandon.
• Tentatives de contournement : Nombre d’appareils uniques déclenchant des règles de contournement ; réessais par appareil/IP.
• Santé des fournisseurs : Deltas hebdomadaires de précision/latence ; SLA contractuels ; avis d’incident.
• Hygiène de la vie privée : Tickets d’accès ouverts aux données de vérification ; exceptions de rétention ; transferts transfrontaliers.

Ce qu’il faut arrêter de faire cette semaine

• Compter sur l’email ou le SMS seul comme preuve d’âge.
• Servir du contenu gardé pendant « l’attente du callback ».
• Accepter des selfies sans liveness lié au serveur.
• Laisser le produit livrer une barrière uniquement JS « pour la démo ». La démo devient la prod.
• Signer un contrat KYC mono‑fournisseur de cinq ans avant d’avoir mesuré taux de réussite et latence sur votre vrai mix de trafic.

L’essentiel

La vérification d’âge n’est pas un problème insoluble. C’est un problème d’ingénierie avec des modes d’échec clairs et des compromis praticables. Bruxelles s’est brûlée en deux minutes parce qu’ils ont déporté la confiance côté client et zappé les tests adversariaux. Ne faites pas la même erreur. Choisissez votre niveau d’assurance, faites du serveur la source de vérité, externalisez la PII brute et mesurez tout. Vous pouvez livrer une barrière difficile à contourner — tout en gardant une conversion raisonnable.

Points clés

• Choisissez d’abord le niveau d’assurance par marché ; ensuite les fournisseurs. Il n’y a pas de barrière universelle.
• Jetons à durée courte, vérifiés côté serveur, liés à une audience, et vérifiés à l’edge : non négociable.
• Stockez des attestations, pas des documents. La minimisation est votre meilleure défense privacy.
• Exécutez le test « hack en 2 minutes » chaque semaine ; corrigez les réussites sous 72 heures.
• Le mode fantôme 1–2 semaines vous donne de vrais métriques de réussite/abandon avant de bloquer.
• Attendez‑vous à 1–3 $ par contrôle doc+selfie ; visez une latence P95 sous 7 secondes sur mobile.
• Construisez un broker de vérification pour pouvoir changer de fournisseur sans réécriture.
• Invitez les attaquants selon vos règles : bug bounty et sprints de red team valent mieux que des audits dictés par Twitter.