Mon blog

En octobre 2025, l'IAB et le W3C ont organisé un atelier à Londres sur la restriction d'accès à des services Internet en fonction de l'âge. Ce RFC est le compte-rendu de l'atelier. En tant que compte-rendu, il n'exprime donc pas une position officielle de l'IAB.

Le sujet est d'actualité, avec de nombreux politiciens qui proposent d'interdire les réseaux sociaux ou la pornographie aux mineurs. Des lois sont déjà votées, comme en Australie. L'UE a un plan en cours et un projet de logiciel. Vous pouvez consulter le site du projet logiciel. En France, où l'une des questions secondaires était la compatibilité d'un éventuel contrôle avec le droit européen, un arrêt du 16 juin 2026 de la Cour de justice de l’Union européenne a estimé que la France pouvait obliger des sociétés basées dans un État membre à mettre en place une vérification d’âge.

L'atelier devait explorer les différents techniques et choix d'architecture liés à ce désir de restriction. Comment combiner cette exigence de restriction aux mineurs tout en préservant les principes d'universalité et de décentralisation de l'Internet, ainsi que la vie privée ? Comment le faire sans mettre en place un système de contrôle qui fera le bonheur de gouvernements autoritaires voire dictatoriaux ? Et faut-il déléguer la sécurité des enfants aux opérateurs Internet, plutôt qu'aux adultes qui s'en occupent (parents, enseignants, etc) ? Les politiciens qui réclament des restrictions d'âge « pour protéger les enfants » ne se posent évidemment jamais ces questions (et les avertissements des experts sont systèmatiquement ignorés). Un exemple non-technique : ces restrictions peuvent servir à un gouvernement religieux et/ou réactionnaire pour bloquer l'accès à des sites Web LGBT, au détriment des mineurs en questionnement qui voudraient s'informer (notez que le RFC ne mentionne pas ce point). L'atelier n'a pas essayé de traiter les problèmes politiques, mais uniquement d'analyser les techniques existantes et de pointer leurs caractéristiques et leurs conséquences. Comme indiqué au début, cet atelier a été l'occasion d'exprimer des points de vue variés (sous la règle de Chatham House), ce RFC ne prétend pas en faire un synthèse, ni donner La Bonne Réponse. Le RFC inclut notamment un liste des propriétés attendues d'une « bonne » solution, dans l'annexe D. Ce point de départ d'un vrai cahier des charges manque dans la plupart des discours politiciens, où on ne fait que répéter des slogans, sans dire clairement quels sont les avantages attendus et les inconvénients acceptables. (L'annexe C est une intéressante liste des impacts - positifs ou négatifs - possibles du contrôle d'âge.)

L'agenda complet de l'atelier figure dans l'annexe A du RFC, la liste des participants dans l'annexe B. Passons maintenant au contenu.

Les « solutions » techniques peuvent être mises en œuvre dans le terminal de l'utilisateurice, dans le réseau (pas exemple dans le résolveur DNS) ou bien dans le service (regardez https://fr.pornhub.com/ depuis la France, pour voir ; n'hésitez pas, c'est SFW). Dans le terminal ? Cela donne du pouvoir à Microsoft ou Google et encourage les systèmes privateurs sur lesquels l'utilisateurice n'a aucun contrôle. (Encore que le logiciel libre peut aussi, par souci de conformité et pour se faire bien voir des politiciens, mettre en œuvre ces contrôles.) Dans le réseau ? Cela met en danger le cœur de l'Internet. Et cela donne du pouvoir aux acteurs de l'infrastucture. Et ce n'est pas très précis (pensez au cas d'un foyer où il y a adultes et enfants mais une seule adresse IP). Dans les services ? Cela met le problème sur le dos de chaque webmestre.

L'atelier a examiné quelques technologies « miracle » censées permettre de vérifier l'âge tout en préservant la vie privée (comme les ZKP). Même si elles résolvaient parfaitement le problème de vie privée, elles laissent ouverts les autres problèmes. Et ces technologies sont souvent récentes et leur sécurité n'est pas toujours testée en profondeur.

Bref, l'atelier n'a pas débouché sur une « solution » ni même sur un plan de travail pour l'IETF. La question reste très ouverte.

Le RFC pointe en section 3 les aspects les plus importants de ce sujet. D'abord, le fait que l'atelier a été utile car, alors que le sujet a bénéficié de nombreux articles dans la presse généraliste, et de nombreux discours politiciens, les discussions techniques ont été rares, de même que les forums impliquant toutes les parties prenantes. Et quand des techniciens étaient consultés, c'était toujours du point de vue des services, jamais de celui de l'infrastructure.

Ensuite, les discussions sont souvent peu productives car il y a eu peu d'efforts pour identifier les différentes rôles impliqués (cf. la présentation d'Hanson) :

• Le vérificateur qui doit tester si une personne donnée a plus que l'âge requis,
• Le contrôleur qui doit empêcher une personne qui a « raté » le test précédent d'accéder au service,
• Le sélecteur de politique, qui définit la politique à appliquer (elle dépend en général du pays de résidence du client, qui est difficile à déterminer sur l'Internet),
• Et le classificateur qui doit déterminer si un contenu donné ou un certain service doit être restreint d'accès.

Cette question est aussi liée à celle de la terminologie, souvent peu définie. (Tiens, j'apprends dans le RFC qu'il existe une norme ISO sur la vérification d'âge, ISO/IEC 27566-1:2025, évidemment pas accessible aux mineurs - il faut laisser plein de données personnelles pour l'obtenir.)

Autre sujet mis en évidence à l'atelier, l'importance de la préservation de la vie privée. Cette exigence est largement méprisée par les défenseurs du contrôle d'âge, le record de connerie ayant récemment été battu par une parlementaire canadienne qui affirmait que la reconnaissance faciale respectait l'anonymat puisque le logiciel ne connaissait pas le nom de la personne. Une partie des acteurs cités plus haut va connaitre des informations personnelles sur les clients des services, et ces acteurs ne sont pas forcément connus de ces clients. Imaginez que vous alliez sur un site Web de contenu pour adultes puis soudainement vous êtes redirigé vers le site Web du vérificateur qui va vous demander de prouver votre âge. Si vous êtes raisonnablement prudent, vous refusez. Si vous tenez à voir le contenu, vous répondez et voilà : on a habitué les utilisateurs à faire confiance à des sites inconnus et inattendus. Une vraie aide au hameçonnage.

En parlant de confiance, un des points difficiles de toute solution technique au problème du contrôle d'âge est la nécessité de faire confiance à de nouveaux acteurs. Certes, il existe des méthodes mathématiques pour prouver quelque chose sans divulguer d'information mais elles sont récentes, peu testées, et sont loin d'épuiser le problème de la confiance. Le fait que beaucoup de techniques proposées ne soient pas en logiciel libre n'arrange rien. (Le RFC ne mentionne pas ce point, sauf pour enfoncer une porte ouverte en rappelant que le logiciel libre ne résoud pas tous les problèmes de confiance.)

Les participants à l'atelier ont aussi noté qu'il y avait peu de chances qu'une seule technique suffise : toutes ont des défauts graves. Les techniques reposant sur des documents étatiques écartent les gens qui n'en ont pas, ou ceux qui ont des documents non reconnus. Les techniques probabilistes d'estimation de l'âge (par exemple par examen du visage) ont beaucoup de faux positifs et de faux négatifs (et, pire, cela dépend de la couleur de peau). Une approche possible serait d'essayer successivement plusieurs techniques, en commençant par les moins invasives (mais cela créerait une discrimination envers les catégories de population qui échouent à ces premières techniques).

L'imperfection de toutes ces techniques a des conséquences sérieuses : exclusion de certaines personnes, contournement par d'autres (certains utilisateurs de contenu « pour adultes » n'ont pas l'âge mais sont motivés, techniquement compétents et ont du temps libre).

La plupart des architectures proposées ajoutent des parties à la relation traditionnelle entre le visiteur d'un site Web et le site en question, notamment le vérificateur et le contrôleur. On complique donc l'architecture du Web en ajoutant de nouvelles dépendances.

Et, bien sûr, la technique n'est pas tout. La sécurité des mineurs ne doit pas dépendre uniquement de techniques dont l'atelier a largement montré la fragilité. Le problème, il est vrai, est très difficile puisqu'il faut à la fois protéger les mineurs contre les dangers bien réels, tout en les préparant à leur future vie de majeur, où il n'y aura pas de restrictions techniques. Les contrôles techniques sont forcément grossiers et binaires, et ne prennent pas en compte toutes les nuances du monde. Il ne faudrait surtout pas déléguer des tâches aussi complexes et délicates que l'éducation à des « solutions » techniques.

Quelques autres ressources :

• La vidéo de présentation de l'atelier.
• Les documents présentés à l'atelier.
• La prise de position de l'Internet Society.
• Un précédent Internet-Draft sur les conséquences d'une restriction d'âge pour l'Internet.