Résumé

  • Dans sa réponse du 21 août, le Conseil d’ICANN refuse un délai butoir susceptible de gêner l’examen exigé par les Bylaws pour des recommandations de complexité inégale. Il promet à la place une mise à jour avant chaque réunion publique d’ICANN et une revue permanente des politiques dans ses ateliers préparatoires.
  • Une fréquence de publication n’est pas un historique de décision. Une horloge reliant recommandation et décision devrait conserver la réception, les pièces requises, les questions, les responsables, les prévisions révisées et le sort de chaque recommandation, sans transformer un liaison, un caucus ou un échange avec le GNSO en autorité décisionnelle.

Une date limite et un rendez-vous d’information ne remplissent pas la même fonction.

Le 25 mai, les dirigeants de six groupes et collèges du Generic Names Supporting Organization ont écrit à Tripti Sinha, présidente du Conseil d’administration d’ICANN. Ils ne partaient pas d’un vide complet. L’Annexe A des Bylaws demande déjà au Conseil de se réunir pour discuter d’une recommandation du GNSO Council dès que possible et, de préférence, au plus tard lors de la deuxième réunion suivant la réception du Recommendations Report.

Leur objection portait sur la sortie du processus. La règle encourage l’ouverture de la discussion ; elle ne normalise pas la date à laquelle l’examen doit aboutir à une adoption ou à un rejet. Les signataires proposaient donc un cadre associant un nombre cible de réunions et un maximum en mois, citant six mois à titre d’exemple. Ils demandaient aussi des informations régulières, un emplacement pérenne pour le Consolidated Policy Scorecard et des échanges permettant au Conseil de poser des questions aux responsables du GNSO Council et des Working Groups concernés.

Le 21 août, Tripti Sinha a répondu que le Conseil partageait l’objectif de célérité. Mais elle a écarté une borne finale fixe : la nature et la complexité des recommandations varient, et une telle contrainte pourrait gêner l’examen que les Bylaws imposent au Conseil. La réponse retient plutôt la prévisibilité par les dates attendues et l’état d’avancement. Une mise à jour doit précéder chaque ICANN Public Meeting ; l’examen de l’état des politiques doit devenir un point permanent des ateliers du Conseil organisés avant ces réunions.

Le choix est substantiel. Une échéance mesure le temps écoulé. Un calendrier de communication oblige l’institution à décrire régulièrement son état. Le second peut rendre le premier plus contrôlable, mais seulement si les descriptions s’additionnent au lieu de remplacer la précédente.

Les deux dossiers cités ont été tranchés entre les deux lettres

La lettre de mai prenait deux exemples alors encore soumis au Conseil. Le paquet de recommandations IDN EPDP Phase 2 avait été transmis en décembre 2024. Celui du Transfer Policy Review l’avait été en avril 2025. Leur état a changé avant la réponse d’août.

Le 7 juin 2026, le Conseil a adopté les 47 recommandations du Transfer Policy Review et les 14 recommandations de politique d’IDN EPDP Phase 2. Il a demandé au President and CEO, ou à ses délégués, de les mettre en œuvre sous réserve de la priorisation et de toute considération opérationnelle, technique, juridique, de sécurité ou de ressources constatée pendant l’exécution.

Les motifs des résolutions reconnaissent expressément les préoccupations de la communauté sur la durée et le déroulement de l’examen. Ils recensent aussi des éléments considérés par le Conseil : Final Reports, contributions de Public Comment, analyses de faisabilité, notification au GAC et pièces propres à chaque sujet. Les décisions ne rendent pas la question du temps inutile ; elles transforment les deux exemples en cas terminés dont la chronologie peut être étudiée.

La page actuelle de mise en œuvre des politiques place désormais les deux projets dans l’implementation queue. Cette catégorie vient après l’action du Conseil, mais avant un démarrage démontré. Une file d’attente ne prouve ni l’affectation de personnel, ni la première réunion d’une Implementation Review Team, ni un projet de texte, ni une date d’entrée en vigueur.

Une photographie de mai laisserait croire que les recommandations attendent toujours le Conseil. Une photographie d’août pourrait faire croire que le problème a toujours été l’attente de ressources d’implémentation. Il faut la décision du 7 juin pour relier les deux états et localiser le transfert d’autorité.

Le verbe « discuter » ne fixe pas la date de décision

L’Annexe A emploie une formule prudente. Elle demande une discussion rapide, de préférence avant la deuxième réunion suivant la réception. Elle ne commande pas une décision lors de cette réunion. Les documents publics examinés ne permettent pas non plus de reconstituer la date de chaque délibération ni la manière dont une « réunion » a été comptée pour ces dossiers.

La durée calendaire ne suffit donc pas à établir une violation des Bylaws. La conclusion défendable est plus précise : le texte comporte une attente temporelle près de l’entrée du processus, sans délai butoir à la sortie.

Cette marge protège la responsabilité du Conseil. Une recommandation soutenue par une GNSO supermajority bénéficie d’une forte présomption d’adoption. Le Conseil doit normalement l’approuver, sauf si plus des deux tiers de ses membres ayant droit de vote estiment que l’adoption n’est pas dans l’intérêt supérieur d’ICANN ou de l’ICANN community.

Ce seuil respecte la politique élaborée de bas en haut tout en maintenant l’obligation du Conseil d’examiner le droit, la faisabilité, la sécurité, le coût et l’intérêt public. Une adoption automatique au terme du sixième mois viderait cette obligation. Un dossier maintenu indéfiniment sous l’étiquette « en cours » la rendrait incontrôlable. La bonne discipline consiste à montrer la raison du temps consommé.

Poser les questions plus tôt sans déplacer la compétence

La réponse du Conseil mentionne les Board liaisons, le dialogue anticipé avec le GNSO Council et les Board Caucus Groups. Ces instruments répondent à un problème documenté par le rapport Board Readiness de 2025. Celui-ci observait que l’examen du Conseil commençait traditionnellement des mois après la remise du Final Report et la dissolution de l’équipe du PDP. Les bénévoles connaissant les compromis, les options écartées et l’histoire rédactionnelle avaient repris leurs activités ordinaires.

Une alerte précoce peut éviter cette perte. Un liaison peut signaler une difficulté de conformité, de coût ou d’exécution pendant que le Working Group peut encore expliquer son choix. Un caucus peut structurer le travail des administrateurs. Le personnel peut réunir Public Comment et analyse de faisabilité. Les responsables du Working Group peuvent dire si une ambiguïté est volontaire ou accidentelle.

Ces fonctions n’accordent aucun pouvoir discret de réécriture. Le liaison fait circuler des questions ; il ne détermine pas le consensus du GNSO. L’analyse du personnel informe ; elle ne remplace pas le texte recommandé. Si le dialogue modifie la substance, le dossier doit indiquer qui avait qualité pour approuver ce changement et si le sujet devait revenir à l’organe de politique.

La réponse d’août pose elle-même cette limite : les échanges peuvent clarifier le dossier et faire remonter les questions sans altérer les rôles respectifs du Conseil et du GNSO Council. Une procédure n’est pas améliorée si elle gagne du temps en rendant l’auteur de la décision indéterminable.

Le Scorecard montre un emplacement, pas le chemin parcouru

ICANN org publie périodiquement le Consolidated Policy Scorecard afin de rassembler l’état des politiques issues de la communauté. Le service est utile : la communauté ne devrait pas devoir recouper à chaque fois les correspondances, les résolutions, les pages du GNSO et les tableaux de mise en œuvre.

Pourtant, un état courant ne répond pas à une question historique. Quand une ligne passe de « examen du Conseil » à « file d’implémentation », la nouvelle version montre l’arrivée. Sans conservation de l’ancien état et de l’événement de transition, elle ne montre pas quand le dossier était complet, ce qui a bloqué la programmation, pourquoi la prévision a changé ou si certaines recommandations ont été pended tandis que d’autres étaient adoptées.

Le mot « pending » peut cacher des conditions sans rapport : clôture d’un Public Comment, attente de la réponse du GAC, analyse de faisabilité inachevée, question juridique, atelier déjà programmé ou absence de propriétaire pour la prochaine action. Chaque cas appelle un responsable et un remède différents.

Il n’est pas nécessaire de publier un avis juridique privilégié ou une analyse de sécurité sensible. Une catégorie bornée — examen juridique, faisabilité technique, analyse des ressources, apport de politique publique, clarification demandée, capacité de l’agenda — suffit à identifier la dépendance. La justification de la confidentialité peut être revue plus tard.

Une horloge de la recommandation à la décision

L’horloge proposée par Daniel Kade commence à la réception du Recommendations Report faisant autorité. Elle conserve l’identité et l’empreinte du paquet, le vote du GNSO, la voie applicable dans les Bylaws et le seuil du Conseil. Elle dresse ensuite la liste des pièces nécessaires et la date à laquelle chacune entre au dossier : Public Comment, notification du GAC, analyse de faisabilité et autres éléments nommés.

Elle distingue coordination et décision. Un liaison, un caucus ou un membre du personnel peut être nommé comme responsable de la circulation d’une information ; le Conseil reste identifié comme décideur. La première discussion et les délibérations matérielles ultérieures sont horodatées sans prétendre qu’une présence en réunion équivaut à une conclusion.

Le vocabulaire devrait rester restreint : reçu, pièces en attente, prêt pour délibération, clarification demandée, décision programmée, adopté, rejeté, pended, retiré ou remplacé. À chaque état correspondent une date de preuve, une prochaine action, un responsable et une prévision. Si la prévision change, l’ancienne valeur et la raison demeurent visibles.

La décision est enregistrée recommandation par recommandation, avec vote, motif et éventuelle condition de mise en œuvre. Le passage vers une implementation queue fait l’objet d’un transfert séparé afin de ne pas confondre file d’attente et commencement.

Cette horloge n’impose aucune adoption mécanique. Un dossier complexe peut légitimement dépasser six mois. Elle exige seulement que le temps discrétionnaire laisse une trace contemporaine, plutôt qu’une succession de messages rassurants dont la communauté doit deviner le sens.

Sources

  1. Index des correspondances d’ICANN
  2. Tripti Sinha à Mason Cole, Rafik Dammak et autres, 21 août 2026
  3. Owen Smigelski, Mason Cole et autres à Tripti Sinha, 25 mai 2026
  4. Résolutions approuvées par le Conseil d’ICANN, 7 juin 2026
  5. Bylaws actuels d’ICANN
  6. Page d’ICANN sur la mise en œuvre des politiques
  7. Rapport final du GNSO Board Readiness Small Team
  8. Page du projet GNSO IDN EPDP
  9. Page du projet GNSO Transfer Policy Review