Résumé

  • Les procédures de la GNSO v3.8, datées du 1er septembre 2026, intègrent un mécanisme de révocation approuvé par le Conseil de la GNSO le 21 mai. Il ne vaut que dans des circonstances limitées et extraordinaires, avant la fin de la mise en œuvre; rien n’indique qu’il soit déjà utilisé.
  • Un dialogue suffisamment long avec le Conseil de la GNSO est attendu — environ soixante jours n’est qu’un exemple. En revanche, la première déclaration publique obligatoire du Conseil d’administration intervient après son action, sans consultation publique ni saisine de l’équipe de mise en œuvre imposée au préalable.

Une recommandation peut avoir été adoptée sans être encore pleinement opérationnelle. Les juristes ont commencé à examiner les contrats, les équipes ont dessiné des systèmes, une IRT traite toujours des questions et des entreprises organisent déjà leurs investissements. Puis une information nouvelle surgit. Le Conseil d’administration estime que la recommandation n’est plus dans l’intérêt de l’ICANN ou de sa communauté et envisage de retirer son adoption.

Le problème institutionnel ne consiste pas à interdire tout changement d’avis. Il consiste à savoir quand les acteurs concernés peuvent voir et contester les éléments qui transforment un doute en décision. Le nouveau texte organise un échange préalable avec le Conseil de la GNSO. Il impose aussi une explication publique lors de la révocation. Entre les deux se situe pourtant le premier acte du Conseil d’administration, sans obligation d’ouvrir auparavant le dossier probatoire.

C’est la limite que révèle la version 3.8 des procédures opérationnelles de la GNSO. Le progrès par rapport à un vide procédural est réel. Une justification publiée après coup ne remplit toutefois pas la même fonction qu’une preuve consultable avant le vote.

Ne pas confondre trois dates

La page des procédures de la GNSO, actualisée le 2 septembre, présente la version 3.8 datée du 1er septembre. Son historique explique que le document consolidé incorpore l’annexe 2, consacrée au PDP, et l’annexe 5, consacrée au GGP, approuvées le 21 mai 2026. Les deux fichiers autonomes portent la date du 11 mai. Les autres retouches de la version 3.8 sont qualifiées d’administratives ou éditoriales.

La résolution du 21 mai est donc l’acte d’approbation. Septembre correspond à la consolidation et à la mise à disposition du recueil. Ni l’une ni l’autre de ces dates ne prouve l’ouverture d’une procédure concrète. Aucune source examinée ne désigne une recommandation aujourd’hui soumise à révocation.

Le rapport de la session stratégique de 2025 rappelle pourquoi le mécanisme a été conçu. Des difficultés liées à des recommandations déjà adoptées, dont la recommandation 20.6 du programme des nouveaux gTLD, avaient fait apparaître le vide. Cet antécédent éclaire la règle; il ne transforme pas ce dossier ancien en première application de la version 3.8.

La séquence désormais écrite

La section 16 du manuel PDP et la section 10 du manuel GGP suivent presque la même architecture. Le recours doit rester rare, limité à des circonstances extraordinaires. Il est possible tant que la mise en œuvre de la recommandation adoptée n’est pas achevée. Il ne l’est plus lorsqu’elle a été mise en œuvre et est en vigueur.

Avant d’agir, le Conseil d’administration devrait engager le dialogue avec le Conseil de la GNSO. Il devrait au minimum annoncer son intention, définir le problème, exposer les motifs et les effets attendus, puis expliquer pourquoi la révocation est la seule ou la meilleure solution. Le Conseil de la GNSO doit disposer d’un temps suffisant pour étudier la question et demander des précisions. La mention d’« environ soixante jours » illustre ce délai; elle ne fixe pas une échéance juridiquement ferme.

Le fond du test comporte deux étages. Il faut une information nouvelle ou un changement de circonstances. Il faut aussi conclure que la recommandation n’est plus dans l’intérêt de l’ICANN ou de sa communauté. Un changement isolé ne suffit donc pas, pas plus qu’une invocation abstraite de l’intérêt institutionnel privée d’une base factuelle renouvelée.

Le seuil de vote dépend du soutien initial de la GNSO. Si la recommandation avait obtenu une supermajorité de la GNSO, la révocation demande les deux tiers du Conseil d’administration. En dessous de cette supermajorité, la majorité du Conseil d’administration suffit.

Au moment d’exécuter l’action, le Conseil d’administration doit exposer son raisonnement dans une « Board Statement » transmise au Conseil de la GNSO. Cette déclaration et les documents qui l’accompagnent doivent être publics. Le Conseil de la GNSO l’examine ensuite, dialogue avec le Conseil d’administration et décide de confirmer ou de modifier sa recommandation. Sa recommandation supplémentaire retourne au Conseil d’administration selon des seuils qui tiennent, eux aussi, compte de la supermajorité.

La GNSO conserve donc une réponse formelle. Le défaut plus précis porte sur le calendrier de la preuve: le premier document nécessairement public vient après le premier acte du Conseil d’administration.

La consultation avait demandé une ouverture plus précoce

La consultation publique s’est déroulée du 20 novembre 2025 au 22 janvier 2026 et a reçu dix contributions. Son rapport de synthèse constate un soutien général à un mécanisme exceptionnel assorti de garde-fous.

Certaines propositions ont modifié le texte final. La formule selon laquelle le Conseil d’administration « peut » suivre la procédure est devenue une attente exprimée par « devrait ». Les changements de circonstances ont été ajoutés aux informations nouvelles parmi les fondements possibles.

D’autres demandes ne sont pas devenues des étapes obligatoires. Plusieurs participants proposaient une courte consultation publique ou communautaire avant l’achèvement du processus. Les groupes des bureaux d’enregistrement et des registres, ainsi que Tucows, soutenaient une consultation obligatoire de l’IRT compétente. Le groupe des registres envisageait aussi, lorsque possible, de consulter le groupe de travail d’origine. Les manuels adoptés n’imposent rien de tel.

Il ne faut pas en déduire que les échanges seront secrets. Les conseillers peuvent interroger leurs composantes, le Conseil d’administration peut publier plus tôt, et les deux organes peuvent solliciter une IRT. Le constat est plus restreint: ces gestes sont possibles, mais ils ne conditionnent pas le premier acte.

Une frontière de mise en œuvre sans certificat

Le seuil d’accès au mécanisme semble binaire: « mise en œuvre non achevée » d’un côté, « mise en œuvre et en vigueur » de l’autre. Dans la pratique, un programme franchit rarement cette frontière en un seul instant. Le contrat peut être finalisé alors que les outils ne le sont pas. Une date d’entrée en vigueur peut coexister avec une migration incomplète, des questions encore ouvertes dans l’IRT ou une application différée. Une recommandation peut aussi dépendre d’un ensemble que le Conseil d’administration ne souhaite pas entièrement révoquer.

Les manuels ne nomment ni responsable chargé d’attester cet état, ni certificat commun, ni ensemble minimal de preuves. C’est une absence textuelle, pas la preuve qu’aucun travail interne n’existe. Mais elle compte, car une classification erronée modifie la disponibilité même du remède exceptionnel.

Déclarer trop tôt une recommandation « en vigueur » peut fermer le mécanisme malgré une information nouvelle sérieuse. La maintenir trop longtemps dans la catégorie « non achevée » peut autoriser une révocation alors que des registres, bureaux d’enregistrement, candidats ou utilisateurs se sont raisonnablement fondés sur l’adoption. Une déclaration publique ultérieure explique la qualification retenue; elle ne permet pas de la rectifier avant le premier vote.

Ouvrir un dossier de révocation avant le vote

La pièce manquante est un dossier public, borné et versionné, ouvert avant la première décision. Il n’a pas besoin de devenir une consultation sans fin ni de divulguer un avis privilégié. Il doit seulement relier la compétence exercée à la preuve disponible au moment utile.

Le dossier devrait identifier l’avis de déclenchement, chaque recommandation visée et ses dépendances, la décision d’adoption initiale, le seuil applicable, la phase de mise en œuvre et le gardien nommé de cette qualification. Ce dernier devrait renvoyer à un instantané daté plutôt qu’à une simple étiquette.

Il devrait ensuite consigner l’information nouvelle ou le changement de circonstances, leur provenance, les effets invoqués et les solutions alternatives étudiées. Les questions du Conseil d’administration et les réponses de la GNSO devraient conserver leurs versions. Une voie de contribution bornée devrait permettre à l’IRT, au groupe de travail et à la communauté d’apporter des éléments avant une heure de clôture visible. Les pièces protégées peuvent rester confidentielles si leur existence, leur gardien et leur incidence sont décrits.

Après la décision, le même dossier recevrait le vote, la Board Statement, la discussion avec la GNSO, la recommandation supplémentaire et la décision finale. Toute correction serait ajoutée avec un lien de remplacement, sans effacer l’état sur lequel le premier acte s’est fondé.

Cette proposition est la mienne, non celle de l’ICANN. Elle applique la cartographie de l’autorité défendue dans The Policy Mirror, l’exigence d’une exécution observable de Running-Code Primacy et la séparation entre fait et autoportrait institutionnel de Reality, Not Advocacy.

La version 3.8 admet à juste titre qu’une adoption ne peut neutraliser des faits ultérieurs. Elle doit maintenant reconnaître une autre différence: rendre un verdict transparent après l’action ne rend pas les preuves contestables avant l’action.

Sources