Résumé

  • Le 24 août 2026, l’IAB a averti que les contrôles d’âge imposés aux sites, aux prestataires spécialisés ou aux réseaux pouvaient concentrer des données sensibles, fragiliser la vie privée et le chiffrement, favoriser des contournements dangereux et morceler l’Internet.
  • Elle demande un signal minimal, limité à une finalité, qui ne permette ni le suivi entre sites ni la remontée de l’activité, qui cache les destinations à l’émetteur et qui n’alimente pas de base centrale sensible.
  • Les mécanismes intégrés au terminal lui paraissent aujourd’hui les plus prometteurs, mais ils confèrent aussi un levier important aux fournisseurs d’appareils et de systèmes d’exploitation. L’interface doit donc être ouverte, interopérable et adaptée aux appareils partagés.
  • Cette déclaration est un avis d’architecture. Ce n’est ni une loi, ni une certification, ni une norme IETF, ni un ordre de déploiement. Le RFC 9998 demeure, de son côté, le compte rendu informatif d’un atelier dont les opinions ne sont pas automatiquement celles de l’IAB ou du W3C.
  • La garantie manquante est une preuve de substituabilité : l’objectif de protection et la sémantique du signal doivent survivre au changement d’appareil, de navigateur, de système d’exploitation, de méthode d’assurance ou de fournisseur.

Le déplacement du contrôle ne fait pas disparaître le contrôleur

La vérification de l’âge est souvent présentée comme un problème de justesse statistique. Combien de mineurs passent à tort ? Combien d’adultes sont refusés ? Ces mesures sont indispensables, mais l’architecture a déjà distribué le pouvoir avant le premier calcul. Quel acteur peut demander une preuve ? Quelle donnée quitte le domicile ? Qui conserve le résultat ? Qui voit le service consulté ? Qui décide de l’échec et qui peut le contester ?

Lorsqu’un site effectue le contrôle, il devient collecteur, directement ou par l’intermédiaire d’un prestataire. Lorsque le réseau bloque les services jugés non conformes, l’opérateur doit reconnaître une destination et agir dans le chemin de communication. Lorsque le terminal fournit le signal, l’identité peut rester locale, mais la couche appareil-système d’exploitation gagne un rôle décisif dans l’accès.

Il n’existe donc pas un interrupteur neutre que l’on déplacerait sans conséquence. Chaque emplacement crée une combinaison différente de responsabilité, d’exposition aux fuites, de capacité de refus et de pouvoir de marché. Une meilleure protection de la vie privée face au site peut devenir une dépendance envers une plateforme. Une simplification pour le régulateur peut devenir une barrière à l’entrée pour un navigateur indépendant.

La déclaration actuelle de l’IAB est importante parce qu’elle refuse de choisir le prestataire avant d’avoir défini les propriétés du système. Elle ne présente aucun protocole achevé. Elle déplace la commande publique d’une question — « quelle solution pouvons-nous imposer maintenant ? » — vers une autre : « quelles limites doivent rester vraies quelle que soit la solution ? »

Pourquoi les voies du site et du réseau inquiètent l’IAB

La copie publiée sur la liste d’annonces de l’IETF fixe la date et restitue le texte intégral. L’IAB commence par partager l’objectif de protection des enfants. Son désaccord porte sur les moyens qui pourraient échouer tout en laissant une infrastructure plus intrusive.

Un service tiers d’assurance d’âge peut rassembler des pièces d’identité, des attributs et des traces de décisions dans une cible de grande valeur. Obliger chaque site à établir l’âge multiplie les points de collecte et banalise la demande d’identité. Même si la réponse finale n’est qu’une tranche d’âge, les journaux, les identifiants techniques et la connaissance détenue par l’émetteur peuvent recréer un historique.

Le blocage par le réseau ne résout pas cette difficulté. Pour empêcher l’accès à un service qui n’effectue pas le contrôle attendu, il faut identifier ce service et exécuter une règle au milieu de la communication. L’IAB renvoie au RFC 7754, qui analyse depuis 2016 l’emplacement du filtrage, sa granularité, ses dommages collatéraux, ses tensions avec le chiffrement ainsi que les besoins de transparence et de recours.

Le contournement fait partie du bilan de sécurité. Un adolescent qui abandonne un service visible pour un VPN gratuit d’origine inconnue, une identité empruntée ou une application distribuée hors des circuits habituels n’a pas seulement franchi une barrière. Il a peut-être accepté un intermédiaire plus dangereux. Le nombre de requêtes bloquées ne mesure donc pas, à lui seul, la protection obtenue.

Les obligations divergentes entre juridictions ajoutent une autre forme de coût. Un service confronté à plusieurs fournisseurs certifiés, plusieurs catégories d’âge et plusieurs lieux de contrôle peut quitter certains marchés. La fragmentation se matérialise alors par des services absents, des versions régionales et des parcours d’accès incompatibles — non par une simple diversité juridique abstraite.

Sept propriétés pour maintenir la preuve à sa juste taille

L’IAB énonce sept propriétés. Le mécanisme ne doit révéler qu’un signal d’âge minimal et lié à un usage précis. Il ne doit rapporter l’activité de l’utilisateur à personne, produire de corrélation entre sites ni révéler les destinations à l’acteur qui a établi l’âge. Il ne doit pas créer de dépôt central de données sensibles, imposer de préjudice important aux utilisateurs de tout âge ou dépendre d’une interface fermée.

Ces exigences dessinent une séparation des fonctions. L’émetteur connaît assez d’éléments pour établir un attribut, mais ne reçoit pas un journal de navigation. Le site reçoit assez d’information pour appliquer une règle, mais pas automatiquement l’identité civile. Deux services ne disposent pas d’une poignée stable leur permettant de réunir leurs observations. Aucun acteur ne cumule par défaut l’émission, l’observation, la sélection de la politique et l’exécution universelle.

La minimisation doit devenir un format vérifiable. Un résultat « au-dessus du seuil pour cette action » n’autorise pas la communication de la date de naissance, de l’âge exact, du type de document, du lien familial ou de l’historique des contrôles. Une règle de finalité qui n’atteint pas les champs, la durée de vie et les journaux du protocole reste une intention.

L’ouverture exige, elle aussi, plus qu’un dépôt de code public. Une interface interopérable doit préciser la sémantique de la demande et de la réponse, les erreurs, la négociation de versions, les protections contre le rejeu, les propriétés de non-corrélation et les essais de conformité. Elle doit permettre une mise en œuvre indépendante sans demander au nouvel entrant de copier le graphe de comptes du fournisseur dominant.

Ces propriétés ne démontrent ni la sagesse de toute restriction d’âge ni son efficacité sociale. Elles encadrent l’architecture choisie par une juridiction qui a décidé d’imposer une règle. Cette limite maintient la légitimité de l’avis technique : décrire les dommages possibles sans se substituer au législateur.

Le terminal protège la localité, mais peut devenir un point de passage obligé

Compte tenu de la maturité actuelle des techniques, l’IAB juge la voie du terminal la plus prometteuse. La formule est prudente. Elle ne signifie ni que la solution a été choisie, ni qu'elle a été éprouvée. La déclaration ne valide aucun protocole, appareil, système d’exploitation, navigateur, portefeuille ou émetteur.

L’avantage attendu est tangible. Une propriété d’âge établie dans un contexte local pourrait être présentée ensuite sous la forme d’un signal étroit. Le site n’obtiendrait pas l’identité complète. L’émetteur ne connaîtrait pas chaque destination. Les contrôles successifs ne formeraient pas le même registre central. Le matériel que possède l’utilisateur pourrait médiatiser l’échange au lieu d’un serveur tiers placé au centre de toutes les transactions.

Mais la plateforme peut alors déterminer les méthodes reconnues, la représentation des membres du foyer, l’accès d’un navigateur concurrent, la durée de validité, le traitement des erreurs et les pays pris en charge. Elle peut modifier une version ou retirer une fonction. Le site conserve, de son côté, le pouvoir d’interpréter le signal. L’émetteur peut exclure ceux qui ne disposent pas des preuves acceptées.

L’appareil partagé est le test le plus concret. Une tablette familiale n’a pas l’âge d’une seule personne. Le foyer peut réunir adultes, adolescents et enfants soumis à des règles différentes. Une bascule de profil mal conçue peut divulguer l’état d’un autre utilisateur, bloquer l’adulte ou être si facile à contourner qu’elle ne protège personne. C’est pourquoi l’IAB mentionne explicitement un fonctionnement multi-utilisateur robuste.

L’interface ouverte empêche que la médiation locale devienne une souveraineté de plateforme. Tout appareil, système d’exploitation ou navigateur conforme doit pouvoir participer. Le site demande une propriété définie ; il ne doit pas exiger le compte ou le rituel propriétaire d’un fabricant. Cette différence paraît minime dans un schéma d’API. Sur un marché, elle décide si les mises en œuvre peuvent rivaliser ou si la conformité devient un avantage de distribution réservé.

L’atelier n’était pas la déclaration

L’IAB et le W3C ont organisé leur atelier en octobre 2025. La fiche AGEWS précise que le but était de comprendre plusieurs architectures, sans attendre nécessairement une solution unique. Vie privée, équité, centralisation, contournement, coût, précision, juridiction et censure figuraient parmi les sujets.

L’appel à contributions excluait le débat sur les contenus que les régulateurs devraient restreindre. L’atelier était consacré aux conséquences techniques. Il se tenait sur invitation, sous une règle de Chatham House adaptée, et devait produire un rapport.

Ce rapport est devenu le RFC 9998 en juin 2026. Il appartient au flux IAB et porte la catégorie Informational. Il ne suit pas la piste des normes Internet. Surtout, il indique que les positions relatées sont celles des participants, pas nécessairement celles de l’IAB ou du W3C, et que le texte ne prétend pas établir un consensus.

Cette frontière évite un emprunt de mandat. Une remarque d’atelier peut être pertinente sans devenir une position institutionnelle. La déclaration du 24 août constitue la nouvelle parce qu’elle exprime cette fois la position propre de l’IAB. Le rapport fournit la genèse et la diversité des arguments ; il ne transforme pas chaque intervention en décision.

Le RFC 7841 rappelle que tous les RFC ne sont pas des normes et que les flux extérieurs au flux IETF ne passent pas en règle générale par l’IESG et un dernier appel à l’ensemble de l’IETF. Il faut donc conserver des états séparés : observation d’atelier, déclaration IAB, projet de spécification, norme approuvée, produit certifié, obligation légale et déploiement observé.

Une autorité d’architecture, pas un législateur de l’accès

Le RFC 2850 définit l’IAB comme un comité de l’IETF et un organe consultatif de l’Internet Society. Il lui confie la surveillance de l’architecture à long terme, certaines responsabilités sur le processus des normes et des appels, ainsi que des fonctions de conseil et de liaison.

Le RFC 9281 confirme cette répartition dans une cartographie plus récente : l’IAB fournit une expertise technique, architecturale, procédurale et parfois politique sur l’Internet. Il ne devient pas pour autant le parlement d’une juridiction ni l’autorité qui certifie un téléphone.

Cette limite augmente l’utilité de l’avis. L’IAB peut avertir qu’une obligation technique fragilisera le chiffrement ou concentrera l’identité avant que les dépendances soient trop coûteuses. Le régulateur reste responsable de la base légale, du champ, des recours et de l’efficacité publique. Le processus de normalisation définit des comportements communs. Les fournisseurs les mettent en œuvre. Les services appliquent la règle pertinente. Les personnes contestent les erreurs.

Chaque acte doit garder sa propre preuve. Une déclaration prouve une position architecturale. Une norme prouve le statut d’une spécification. Une certification prouve le passage d’essais déterminés. Une loi prouve l’adoption d’un texte dans une juridiction. Les observations de production prouvent le fonctionnement dans des conditions données. Aucun de ces reçus ne peut être remplacé par le logo d’une institution.

Le RFC 3935 pose une dernière borne : une norme IETF décrit comment faire lorsqu’un acteur revendique la conformité ; elle n’impose pas son usage et ne police pas le déploiement. Une future norme de signal d’âge ne suffirait donc pas à créer une obligation légale ou à prouver le bénéfice social.

Prouver la substituabilité avant l’ossification

L’IAB avertit que les incitations économiques et les dépendances rendent un système installé difficile à déloger. Elle nomme ce phénomène l’ossification et recommande des obligations portant sur des résultats plutôt que sur une technologie.

Pour Daniel Kade, cette orientation doit produire un reçu de substitution. Il commence par une définition du résultat : personnes et services concernés, juridiction, décision d’accès attendue, bénéfice de sécurité recherché, erreurs tolérables et voie de recours. Le nom d’un fournisseur ne peut jamais tenir lieu de résultat.

Le reçu fixe ensuite le contrat du signal : champs minimaux, seuil, contexte, durée de vie, protection contre le rejeu, non-corrélation, version et comportement d’échec. Deux mises en œuvre sous contrôle indépendant doivent pouvoir satisfaire les mêmes tests. Le site ne doit pas refaire une intégration propriétaire pour chacune.

La migration doit être essayée, pas seulement annoncée. Il faut changer séparément l’émetteur, l’appareil et le navigateur ; vérifier que la divulgation n’augmente pas, que les profils d’un foyer restent séparés, que les services comprennent encore le signal, que le recours demeure accessible et que les anciens identifiants de corrélation deviennent inutilisables.

Enfin, des déclencheurs doivent rouvrir le choix : taux élevé de refus injustifiés, exclusion discriminatoire, concentration des fuites, contournement dangereux, pression sur le chiffrement, retrait de services ou domination excessive d’un fournisseur. Réexaminer le moyen ne revient pas à abandonner la protection de l’enfance. C’est maintenir la capacité d’atteindre le même but avec moins de dommages.

Sources

  1. IETF Datatracker : déclaration de l’IAB sur les restrictions d’âge et la sécurité en ligne
  2. Copie de la déclaration sur la liste d’annonces de l’IETF
  3. Index des annonces de l’IAB
  4. Registre des déclarations de l’IAB
  5. RFC 9998 : rapport de l’atelier IAB/W3C
  6. Fiche de statut du RFC 9998
  7. Annonce de publication du RFC 9998
  8. Fiche AGEWS dans le Datatracker
  9. Appel à contributions pour l’atelier AGEWS
  10. RFC 7754 : considérations techniques sur le blocage et le filtrage
  11. Fiche de statut du RFC 7754
  12. RFC 2850 : charte de l’Internet Architecture Board
  13. RFC 9281 : entités participant au processus de normalisation de l’IETF
  14. RFC 3935 : déclaration de mission de l’IETF
  15. RFC 7841 : flux, en-têtes et mentions des RFC