Résumé

  • Dans sa lettre du 14 juillet, l’Inde demande une vérification du courriel et du téléphone avant activation, un signalement obligatoire et centralisé des abus DNS, ainsi qu’une authentification opérationnelle des services répressifs pour les demandes urgentes de données d’enregistrement.
  • Le président-directeur général d’ICANN répond que les deux premiers sujets méritent examen et figurent dans les discussions de priorisation du GNSO, dont il ne peut ni fixer les priorités ni déterminer les résultats.
  • Le groupe consacré à l’authentification affiche, lui, des réunions et des jalons allant de juin 2026 à mars 2027. Il ne produit pourtant pas de politique et son prototype ne rendra pas, à lui seul, la règle des vingt-quatre heures applicable.
  • Une fiche publique par demande devrait indiquer l’autorité compétente, l’état exact, la procédure, la prochaine décision autorisée et ce que cet état ne signifie pas encore.

Une même lettre, trois objets institutionnels

Le 14 juillet 2026, S. Krishnan, secrétaire du ministère indien de l’Électronique et des Technologies de l’information, écrit au président-directeur général d’ICANN, Kurt Erik Lindqvist. Le courrier rassemble trois sujets sous l’idée d’une réponse plus rapide aux risques pour la confiance et la sécurité. Cette présentation politique est cohérente. Elle ne transforme pas pour autant les trois mesures en un seul dossier.

La première demande vise la vérification des coordonnées. L’Inde souhaite que l’adresse électronique et le numéro de téléphone soient validés avant l’activation du nom de domaine. Elle conteste ainsi le dispositif qui laisse une période de réponse après une demande de vérification et estime qu’un ajustement contractuel limité pourrait suffire. Les documents d’ICANN sur le Whois Accuracy Program décrivent les conséquences possibles après plus de quinze jours sans réponse. Ils ne constatent ni modification du contrat ni adoption du modèle indien.

La deuxième demande porte sur les données de signalement. Les registres et bureaux d’enregistrement devraient, selon l’Inde, publier périodiquement le nombre de plaintes, la nature des abus, les mesures correctrices et les délais de réponse. ICANN devrait en outre offrir un mécanisme central. Deux choix sont donc imbriqués : créer une obligation de rendre compte et définir une infrastructure commune. Même centralisée, une statistique reste fragile si elle ne fixe pas les définitions, le périmètre, le dénominateur, la différence entre plainte et incident établi, ainsi que les règles de correction.

La troisième demande concerne l’accès urgent à des données d’enregistrement non publiques. La Registration Data Policy contient désormais un accusé de réception sous deux heures et une réponse sous vingt-quatre heures, avec une exception bornée. Sa note d’application précise cependant que la section 10.7 ne prendra effet qu’après la mise en œuvre complète d’une politique de consensus sur l’authentification des demandeurs. L’Inde demande donc que le mécanisme destiné aux services répressifs devienne opérationnel rapidement.

Ces trois positions sont des demandes gouvernementales documentées. Elles ne sont ni des décisions du GNSO, ni des avenants contractuels, ni la preuve qu’une solution donnée réduira effectivement les abus. L’enjeu de gouvernance commence précisément à cet endroit : rendre visible le chemin qui conduit d’une préférence publique à l’organe habilité à la traiter.

La réponse refuse d’emprunter un mandat

Dans sa lettre du 11 août, publiée le lendemain, Lindqvist reconnaît l’objectif de sécurité tout en séparant les compétences.

Il rappelle d’abord que l’avis consensuel du GAC à ICANN83 avait demandé un travail ciblé sur les enregistrements malveillants en masse et les vérifications de domaines associés. Le Conseil du GNSO a lancé le PDP 1 sur ce dernier sujet. C’est un véritable état de procédure. Ce n’est pas une autre manière de nommer la validation préalable des coordonnées, ni le système central de statistiques demandé par l’Inde.

Pour la vérification des données d’enregistrement et la transparence des signalements, la formulation est moins avancée. ICANN org les considère comme des sujets méritant un examen supplémentaire et comprend qu’ils sont discutés dans les efforts de priorisation du Conseil du GNSO. Une attention est ainsi attestée. En revanche, aucun rang, aucune charte, aucun groupe de travail, aucune négociation contractuelle et aucune date de livraison ne sont annoncés.

La limite vient des statuts. Le GNSO développe et recommande la politique substantielle concernant les gTLD et gère son processus de développement. Le GAC conseille sur les préoccupations des gouvernements et de politique publique. Le directeur général peut fournir des données, des moyens et une expertise opérationnelle, puis mettre en œuvre une politique adoptée. Il ne peut choisir les priorités du GNSO ni déterminer la conclusion d’un PDP.

Cette retenue ne signifie pas que les demandes sont rejetées. Elle empêche plutôt une préoccupation urgente de devenir, par simple correspondance, une règle opposable. Elle empêche aussi ICANN org de transformer son rôle d’exécution en pouvoir d’écrire la politique. Toute nouvelle obligation des parties contractantes doit être rattachée à la procédure de politique ou au véhicule contractuel qui lui donne sa force.

Le tableau public n’est pas au même niveau d’avancement

À la date du 31 août, les sources vérifiées conduisent à trois états distincts.

Mesure demandée État public Prochaine étape autorisée visible
Validation du courriel et du téléphone avant activation Reçue, reconnue, renvoyée à un examen supplémentaire et aux discussions de priorisation du GNSO Aucun vote de priorité, aucune charte, aucun PDP et aucune étape contractuelle datée ne sont identifiés
Signalement obligatoire et mécanisme central des abus DNS Reçue, reconnue, renvoyée à un examen supplémentaire et aux discussions de priorisation du GNSO Aucune décision datée sur l’obligation, le modèle de données, le système central ou la procédure n’est identifiée
Authentification des services répressifs pour les demandes urgentes Groupe constitué, réunions engagées, étapes du prototype publiées Présentation d’évolutions de l’interface RDRS en octobre 2026, essais en décembre 2026, synthèse en mars 2027, puis instrument de politique valable si nécessaire

Ce tableau ne hiérarchise pas l’importance des problèmes. Il mesure seulement la précision du dossier public.

Le procès-verbal du Conseil du GNSO du 13 août éclaire le passage entre communication et décision. Le Conseil travaillait à la charte du PDP 2 sur l’atténuation des abus DNS. Les participants débattaient du texte de départ, du risque de questions présumant déjà une obligation et de la portée des mécanismes automatisés. Un groupe de rédaction devait commencer des réunions hebdomadaires à partir de la semaine du 24 août.

Rien dans ce procès-verbal n’insère les deux premières demandes de l’Inde dans le PDP 2. Le document rapporte néanmoins que le représentant de liaison entre le GNSO et le GAC jugeait trop tardives, à ICANN86, les questions relatives au délai de vérification des titulaires : le Conseil n’avait pas eu le temps de consulter correctement ses composantes. C’est la trace d’un problème d’acheminement. Ce n’est pas la disposition d’une politique.

Le même échange précise que le GAC peut faire parvenir ses vues par la liaison, mais que la rédaction d’une charte relève du Conseil. La liaison ne devient pas l’avocat d’une position gouvernementale à moins que sa mission soit formellement modifiée. Une information traverse ainsi la frontière sans emporter avec elle le pouvoir de décider.

Les dates du prototype ne créent pas une obligation

Le parcours de l’authentification est plus facile à surveiller. La page d’ICANN prévoit la formation du groupe en juin, le début des réunions en juillet, des changements de maquette RDRS en octobre, les essais du prototype en décembre et la publication d’une synthèse en mars 2027. Elle fournit déjà les enregistrements des séances des 22 juillet et 12 août.

La même page avertit que le groupe ne produit aucune recommandation de politique. Sa charte est encore annoncée comme à venir. Le prototype peut explorer l’interopérabilité des dispositifs d’authentification, la minimisation des données et les journaux d’audit. Il ne décide pas qu’une demande est urgente, nécessaire ou licite, et ne donne pas un droit automatique à la divulgation.

Des jalons publics constituent donc un progrès de traçabilité, pas un supplément d’autorité. Ils permettent de constater un retard ou un changement de périmètre. Ils ne remplacent ni la politique de consensus dont dépend l’entrée en vigueur, ni les décisions prises pour chaque demande de données.

Une fiche de route par demande

ICANN rend les courriers accessibles. Le vide se situe après l’accusé de réception. Pour connaître l’état réel, un lecteur doit aujourd’hui recouper la réponse du directeur général, les pages du GNSO, un procès-verbal, le site du groupe technique et une note d’application.

Une fiche de route publique réduirait cette dispersion. Elle contiendrait l’énoncé exact de la demande, le statut d’autorité de son auteur, l’organe compétent, l’état courant, la procédure et le dossier public, le responsable du soutien au sein d’ICANN org, les dépendances, la prochaine décision avec sa date — ou la mention « non planifiée » —, la dernière preuve et l’historique des corrections.

Le champ essentiel serait négatif. « Reçue » ne voudrait pas dire prioritaire. « En cours de priorisation » ne voudrait pas dire qu’une charte existe. « Charte en rédaction » ne préjugerait pas des réponses. « Prototype » ne créerait ni devoir contractuel ni droit d’accès. « Mis en œuvre » renverrait à l’instrument qui autorise effectivement l’exécution.

La fiche doit suivre la mesure, pas le courrier. Une même lettre peut ouvrir trois chemins, mobiliser trois décideurs et obéir à trois calendriers. La formule vague « dialogue en cours avec l’Inde » ne montre aucune de ces différences.

Publier ce suivi ne confère pas de droit de veto au demandeur. Au contraire, cela protège l’autonomie du décideur tout en le rendant identifiable. Un gouvernement peut constater où se trouve son sujet. Les parties contractantes peuvent distinguer consultation et nouvelle obligation. La société civile peut suivre le moment où une question technique devient une décision de droits. Le GNSO peut expliquer un arbitrage de ressources sans laisser le silence tenir lieu de rejet.

Faire coexister urgence et compétence

La meilleure qualité de la réponse du 11 août est sa modestie institutionnelle. Elle refuse de faire du directeur général un chef de la politique gTLD. Sa faiblesse est documentaire : deux demandes restent décrites par des verbes d’attention, tandis qu’une troisième possède un calendrier opérationnel.

L’étape suivante ne consiste pas à promettre un résultat. Elle consiste à montrer le prochain acte autorisé. À cette condition, l’urgence ne deviendra pas un mandat gouvernemental et la procédure ne deviendra pas un alibi pour l’inaction.

C’est une version plus exacte du multistakeholderisme. Les participants apportent faits, préférences et objections. Le GAC conseille. Le GNSO choisit et conduit le travail de politique. ICANN org appuie et exécute. Les contrats et politiques de consensus portent les obligations. Une trace publique relie ces rôles sans transformer la présence, la correspondance ou l’urgence en souveraineté.

Sources

  1. ICANN — index de la correspondance
  2. S. Krishnan à Kurt Erik Lindqvist, 14 juillet 2026
  3. Kurt Erik Lindqvist à S. Krishnan, 11 août 2026
  4. ICANN — Élaboration des politiques
  5. Conseil du GNSO — procès-verbal du 13 août 2026
  6. ICANN — groupe sur les mécanismes d’authentification des services répressifs
  7. GNSO — DNS Abuse Mitigation PDP 1
  8. ICANN — Registration Data Policy
  9. ICANN — RAA 2013 et Whois Accuracy Program Specification
  10. Lu Heng — The Multi-Stakeholder Mirage