Résumé

  • Depuis la révision du 12 mai 2026, la politique d’ICANN décrit un accusé de réception sous deux heures, une réponse sous 24 heures et, en cas d’exception justifiée, une limite extérieure de 72 heures.
  • La note d’application rattache toutefois l’entrée en vigueur de l’article 10.7 à la mise en œuvre complète d’une politique de consensus sur l’authentification des demandeurs.
  • Le groupe de travail sur les mécanismes d’authentification fournit un avis technique à une preuve de concept. Il ne produit pas de politique et ses jalons de décembre 2026 et mars 2027 ne constituent pas, à eux seuls, une date d’effet.
  • L’authentification établit une qualité du demandeur. Elle ne prouve ni l’urgence, ni la base juridique, ni la nécessité d’une divulgation. Un reçu d’activation doit rendre cette frontière vérifiable.

Deux phrases vraies, deux états différents

La politique relative aux données d’enregistrement a été révisée le 12 mai 2026. Sa définition d’une demande urgente est étroite : il faut un demandeur authentifié, une menace imminente pour la vie, un risque de blessure grave, une atteinte aux infrastructures critiques ou une situation d’exploitation d’enfants, et la divulgation doit être nécessaire pour combattre ou traiter la menace.

Une fois cette qualification posée, l’article 10.7 déroule des obligations précises. Le demandeur atteste que sa demande relève de l’une de ces circonstances. Le bureau d’enregistrement et l’opérateur de registre accusent réception dans les deux heures. Ils répondent sans délai indu et, en principe, avant l’expiration de 24 heures. Une circonstance exceptionnelle peut justifier un délai supplémentaire, mais l’avis d’extension doit encore être envoyé sous 24 heures, avec sa motivation, et la réponse ne peut dépasser 72 heures à compter de la réception.

Le texte délimite même l’exception. Un cas de force majeure ou une demande complexe portant sur de nombreux noms de domaine peut entrer dans cette catégorie. Un jour férié, un congé prévu ou un déplacement planifié n’y entre pas. La politique n’énonce donc pas un simple objectif de service ; elle construit une séquence mesurable.

Mais la note consacrée aux demandes urgentes fixe une condition supplémentaire : l’article 10.7 ne devient effectif que le jour où ICANN a pleinement mis en œuvre une politique de consensus établissant un processus d’authentification. L’annonce du 12 mai le dit autrement : le nouveau langage n’entrera pas en vigueur avant la mise en place du mécanisme d’authentification des services répressifs.

Il faut conserver les deux phrases. La première décrit la règle qui devra gouverner les demandes qualifiées. La seconde dit quand elle commence à obliger. Les opposer affaiblirait le dossier ; les fusionner fabriquerait une obligation prématurée.

Publier une norme ne suffit pas à lancer son chronomètre

La politique générale est entrée en vigueur le 21 août 2025. Il serait donc inexact de dire que toute la politique attend l’authentification. Seules les obligations urgentes de l’article 10.7 portent ce verrou d’application. Il serait tout aussi inexact d’inférer l’opposabilité actuelle de la présence des mots MUST et « 24 heures » dans le document en ligne.

La page de suivi des avis du GAC fournit une démonstration utile. Le Conseil d’administration ferme l’élément d’avis consacré au calendrier, parce que le délai de 24 heures a été publié. Dans la même entrée, il indique que son application reste suspendue à la disponibilité d’un mécanisme d’authentification. La fermeture d’un avis signifie que la tâche de rédaction demandée a été accomplie ; elle ne certifie pas que toutes les dépendances opérationnelles et contractuelles sont satisfaites.

Cette nuance disparaît facilement lors de la circulation de l’information. Une fiche de conformité peut extraire l’article 10.7 sans sa note. Un service de police peut retenir le délai annoncé. Un registrar peut organiser ses équipes autour d’une date présumée. Un résumé automatisé peut transformer « la politique comprend une exigence » en « l’exigence s’applique ». Chacun lit un fragment authentique et obtient un état différent.

Une gouvernance responsable ne demande pas au lecteur de reconstituer l’état d’activation à partir de pages éloignées. Elle joint à la règle sa condition, son autorité de déclenchement et sa date d’effet vérifiable.

Le groupe d’authentification n’est pas un raccourci politique

Le groupe sur les mécanismes d’authentification des services répressifs travaille à une preuve de concept utilisable avec le Registration Data Request Service, ou son successeur. Sa mission couvre l’architecture du flux, les exigences techniques et les méthodes d’authentification. Le programme public prévoit des maquettes RDRS en octobre 2026, un début de tests en décembre et un rapport de conclusions en mars 2027.

Ce calendrier est une information de projet, non un calendrier d’entrée en vigueur. La page du groupe précise qu’il n’est pas un organe d’élaboration des politiques. L’appel à participation ajoute que son rôle est consultatif et orienté vers la mise en œuvre. Les participants examinent l’interopérabilité, les données nécessaires pour valider un agent, la minimisation, la sécurité, l’auditabilité, la journalisation et l’ergonomie.

Ce travail peut établir qu’un mécanisme est réalisable. Il peut révéler qu’une révocation ne se propage pas assez vite, qu’un attribut est trop intrusif ou que deux systèmes nationaux expriment différemment le même niveau d’assurance. Il peut améliorer RDRS. Il ne peut pas, par sa seule réussite technique, produire la politique de consensus exigée par la note d’application.

En parallèle, l’équipe GNSO chargée des recommandations supplémentaires examine les questions de politique autour de l’accréditation des demandeurs dans un futur système d’accès. La liaison entre ces travaux est nécessaire précisément parce que leurs pouvoirs ne sont pas interchangeables. Quand un choix technique décide en réalité qui peut entrer, quel attribut est obligatoire ou quel recours existe, il devient une question de gouvernance et doit remonter vers l’autorité compétente.

Un titre d’identité ne vaut pas autorisation de divulguer

Le gain d’un mécanisme commun est évident. Dans une urgence, un registrar ne devrait pas recommencer à zéro la vérification de l’existence d’une autorité, de l’appartenance de l’agent et de la validité de son titre. Une assertion portable, limitée et révocable peut économiser un temps précieux.

Le danger commence lorsque cette assertion est chargée de conclusions qu’elle ne prouve pas. Un demandeur authentifié n’a pas, du seul fait de son authentification, démontré l’imminence du danger. Il n’a pas établi la compétence territoriale, la base juridique, la proportionnalité de la demande ou la nécessité de chaque champ sollicité. Son certificat ne tranche pas un conflit de lois et ne transforme pas toute demande en droit à recevoir les données.

La politique maintient cette pluralité des tests. Le demandeur doit attester séparément le caractère urgent. La note d’application préserve les considérations de juridiction et de droit applicable. La réponse peut divulguer, divulguer partiellement ou refuser en donnant les raisons. L’article 10.8 permet des mesures correctives contre les demandes ou demandeurs abusifs.

L’authentification est ainsi un résultat borné : cet acteur possède, à cet instant et selon ce niveau d’assurance, la qualité indiquée. Le registrar ou le registre reste responsable de la décision suivante. La couche commune doit vérifier le minimum réutilisable, puis rendre la main à l’acteur qui supporte l’obligation juridique et le risque de divulgation.

La lettre à l’Inde rend la chaîne d’autorité visible

Dans sa réponse du 11 août 2026 au gouvernement indien, le directeur général d’ICANN confirme que l’exécution du délai de 24 heures dépend du mécanisme d’authentification. Il cite le groupe nouvellement constitué et le travail avec le Public Safety Working Group du GAC et les représentants des services répressifs.

La lettre répond aussi à une proposition de vérification sous quinze jours et à des obligations supplémentaires de publication de données. ICANN ne les traite pas comme des instructions directement applicables. Les nouvelles obligations des parties contractantes doivent passer par la procédure politique ou contractuelle appropriée. La GNSO élabore la politique gTLD et dirige son processus ; le directeur général peut fournir des moyens et appliquer une politique adoptée, non ordonner les priorités de la GNSO ni déterminer l’issue d’un PDP.

Cette répartition paraît lente lorsque le sujet est la sécurité publique. Elle est néanmoins la condition de l’opposabilité. Un gouvernement formule une préoccupation. Le GAC conseille. ICANN org apporte l’expertise et met en œuvre. Un groupe technique teste. La GNSO produit la règle lorsque son mandat l’exige. Le Conseil agit. Les parties contractantes exécutent. Supprimer un maillon ne supprime pas la contestation ; cela la déplace vers l’application.

Le reçu d’activation à publier

Le dispositif a besoin d’un objet public très court. Le reçu d’activation proposé par Daniel Kade ne serait ni une nouvelle politique ni un registre nominatif des enquêteurs. Il servirait à prouver que la condition indiquée dans la politique a bien changé d’état.

Il devrait contenir la version exacte de la politique et son empreinte, la dépendance de consensus, l’acte qui la satisfait, l’autorité compétente, la date et l’heure d’effet, le fuseau horaire et la source canonique. Il devrait décrire les classes de demandeurs éligibles, la version de la fédération de titres, le niveau d’assurance, le signal de révocation et la liste des points d’entrée capables de lancer le délai.

Le reçu doit définir la réception. Le temps commence-t-il à l’acceptation par RDRS, à l’arrivée sur le système de la partie contractante ou à l’ouverture humaine ? Comment un nouvel envoi est-il dédoublonné ? Quel horodatage prévaut lors d’une panne ? Quel régime s’applique à une demande déjà en cours lors de l’activation ? Sans ces réponses, un délai précis repose sur un événement imprécis.

Il doit enfin inscrire la limite de la preuve : le titre atteste les attributs énumérés, rien de plus. L’urgence, la nécessité, la légalité, la compétence et la décision de divulguer restent des appréciations distinctes. Les données publiques du reçu ne doivent jamais révéler le nom de l’agent, l’agence impliquée dans une affaire, le domaine visé, le dossier ou les données d’enregistrement non publiques.

Mesurer une réponse sans noter le taux de divulgation

Dans SAC122, le SSAC recommandait de publier des mesures agrégées : nombre de demandes, vitesse de traitement, part des demandes indésirables ou invalides et respect des délais contractuels. Ses détails antérieurs ne remplacent pas le texte final de 2026, mais la distinction des mesures reste saine.

Après activation, le dénominateur devrait compter les demandes authentifiées reçues par une surface reconnue. Il faut distinguer un échec de titre, une demande mal formée, un classement non urgent, un refus juridique, une prolongation et une panne. L’accusé de réception sous deux heures, la réponse sous 24 heures et la conclusion sous 72 heures sont trois observations différentes.

Un refus motivé et ponctuel peut respecter l’obligation de réponse. Une divulgation tardive peut la violer. Le volume de données livré n’est donc pas un indicateur de qualité et le taux de divulgation ne doit pas devenir une cible. Le système doit mesurer la discipline du traitement, non récompenser la sortie de données personnelles.

Limites des éléments examinés

Les sources publiques examinées ne fixent ni la date finale d’activation, ni le fournisseur d’identité, ni le modèle de fédération, ni le profil d’assurance, ni le traitement des demandes en cours, ni le dénominateur de conformité. Elles ne disent pas que les tests de décembre 2026 déclenchent l’article 10.7. Le présent article n’affirme pas qu’aucune demande urgente ne peut être traitée avant cette activation par une autre voie licite. Le reçu d’activation et la conception d’une authentification minimale sont des propositions de Daniel Kade.

Sources

  1. ICANN — Politique relative aux données d’enregistrement
  2. ICANN — Annonce de l’exigence relative aux demandes urgentes
  3. ICANN — Groupe sur les mécanismes d’authentification
  4. ICANN — Appel à participation
  5. ICANN — État des avis du GAC
  6. ICANN — Lettre de Kurt Erik Lindqvist à S. Krishnan
  7. SSAC — Résumé de SAC122
  8. ICANN — Synthèse des travaux RDRS