Résumé

  • Le rapport final sur les diacritiques latins propose un opérateur commun et des transitions coordonnées pour les ensembles de gTLD admissibles.
  • Changer de fournisseur n’équivaut pas à retirer une extension de la racine, ni à permettre sa réattribution à un tiers.
  • Les recommandations sont soumises au GNSO Council. Leur examen préparatoire par le Board ne constitue pas une adoption.

Le devis devrait comprendre le départ

Une extension mieux adaptée à l’orthographe de ses utilisateurs peut sembler être un ajout modeste au catalogue d’un registre. Il faut pourtant regarder ce qui se passerait plusieurs années après son lancement, au moment de remplacer un prestataire technique.

Dans le dispositif proposé, l’opérateur ne pourrait pas déplacer isolément le service DNS d’un membre de l’ensemble en laissant les autres chez un fournisseur différent. Les chaînes correspondantes, déjà attribuées et déléguées, devraient suivre simultanément vers le même prestataire pour cette fonction. Voilà l’enjeu économique caché dans une question de caractères : l’unité de migration serait l’ensemble.

Cette règle figure dans la recommandation 22 du rapport final daté du 31 août, désormais accessible depuis l’index documentaire du GNSO. Il ne s’agit pas d’une migration observée ni d’une obligation déjà entrée en vigueur.

Le groupe traite un cas précis. Une extension générique ASCII et sa forme latine à diacritiques peuvent être visuellement confondantes sans être des variantes selon les règles de la racine. Le projet autoriserait leur coexistence sous certaines conditions, dont un opérateur unique. Les critères de caractères et les règles de génération des étiquettes de la racine continueraient de s’appliquer. Une telle exception ne rendrait donc pas admissible n’importe quelle graphie.

La cohérence ne signifie pas un fournisseur universel

La recommandation 18 prévoit un seul contrat de registre et des exigences de service et d’exploitation communes. Les changements de contrôle et les transitions de registre devraient englober les membres concernés. Le transfert d’urgence à un Emergency Back-End Registry Operator serait lui aussi effectué ensemble, vers le même opérateur de secours.

Il serait inexact d’en déduire que tous les services doivent être achetés à une seule entreprise. L’identité du prestataire est exigée pour chaque fonction critique à travers l’ensemble. Le rapport autorise même plusieurs fournisseurs DNS, pourvu que leur combinaison soit identique pour les différents suffixes.

La protection recherchée est compréhensible. Si des noms susceptibles d’être confondus passaient sous des contrôles divergents, les garanties justifiant leur coexistence pourraient s’affaiblir. La transition groupée maintient le lien.

Elle modifie néanmoins les conditions de remplacement. Une extension prête à changer de fournisseur ne suffirait plus à elle seule : la préparation devrait couvrir les autres membres concernés. Cela peut accroître les besoins de coordination, sans que le rapport démontre un surcoût effectif, un retard réel ou une concentration du marché. L’évaluation commerciale doit porter sur le périmètre à déplacer, pas seulement sur le suffixe à ajouter.

Trois sens du mot « sortie »

Le retrait de la racine obéit à une logique différente. Si le membre ASCII disparaît, l’ensemble proposé cesse d’exister, même si l’opérateur peut conserver un unique gTLD internationalisé. En revanche, le retrait volontaire d’un membre à diacritiques n’impose pas celui des autres.

Les recommandations 37 et 38 introduisent une protection d’au moins dix ans contre la réattribution des chaînes retirées à une autre entité que le détenteur restant désigné par les dispositions. Ce délai n’est pas une interdiction décennale de changer de prestataire. Une transition d’urgence qui garde l’ensemble intact ne déclenche pas ce régime de retrait.

Pour les titulaires de noms, la différence est essentielle. Déplacer un espace de noms actif et supprimer une extension ne préservent pas la même continuité. Lorsqu’une extension destinée au retrait contient des enregistrements de second niveau, l’orientation 39 prévoit un plan de transition à soumettre à ICANN. La recommandation 40 traite séparément le cas où un manquement au contrat conduit effectivement à un retrait : elle ne transforme pas tout manquement en suppression automatique.

Les situations anciennes ne seraient pas non plus uniformisées de force. Les gTLD déjà exploités indépendamment par plusieurs opérateurs bénéficient d’une exemption, assortie de limites aux nouvelles demandes. Les noms de second niveau existants qui ne satisfont pas au principe du même titulaire et du même bureau d’enregistrement sont protégés contre une modification rétroactive de leur situation contractuelle ou d’attribution. Pour les membres attribués d’un ensemble non exempté, le changement de bureau d’enregistrement serait en revanche collectif.

Une proposition, encore

Le groupe de travail a accordé son plein consensus aux 57 résultats du rapport. Le texte a été soumis au Council ; cette étape ne vaut pas décision finale. Le billet du 2 septembre sur l’atelier du Board annonce pour les 4–6 septembre un examen préparatoire des implications et des éventuelles préoccupations.

La procédure d’ICANN distingue élaboration, adoption par le Board et mise en œuvre. Le rapport n’intègre pas ses règles au guide actuel de la série de candidatures 2026 et ne fixe pas précisément la série future concernée.

La Note 64 de Lu Heng fournit ici une grille de lecture utile : expliciter la propriété de sécurité qui exige une règle commune, tout en préservant une portabilité praticable. Ce n’est ni une règle d’ICANN ni une preuve de ses intentions. La question est de savoir si le lien nécessaire entre les noms peut être conservé sans rendre leur dispositif d’exploitation irremplaçable.

Sources

  1. Rapport final sur les diacritiques latins
  2. Index des documents du GNSO
  3. Présentation de l’atelier de septembre du Board
  4. Mise en œuvre des politiques chez ICANN
  5. Lu Heng : spécification minimale et adoption volontaire