Résumé

  • Deux contrôles différents coexistent : les chaînes ASCII d’une ou deux lettres sont interdites dès la soumission, tandis qu’une chaîne demandée de deux caractères, ou l’une de ses variantes, peut échouer plus tard si le panel la juge visuellement similaire à une chaîne ASCII de deux caractères ou à une variante de celle-ci.
  • L’outil ne rend pas le verdict final. Le résultat utile doit montrer la paire décisive, les scripts et la casse examinés, les éventuelles comparaisons écartées, la motivation du panel et le délai de contestation de 21 jours.

Le piège tient dans une apparente évidence. Un candidat ne saisit pas un code pays ASCII de deux lettres. Il propose une étiquette de deux caractères dans une autre écriture, conforme aux règles techniques applicables, et le système accepte de poursuivre la demande. Il peut alors croire que la frontière des codes pays ne le concerne plus.

Or le Guidebook 2026 d’ICANN prévoit un second contrôle. Lors de la String Similarity Evaluation, la chaîne principale et ses variantes entrent dans un univers de comparaison qui comprend toutes les chaînes ASCII de deux caractères et leurs variantes. Si la chaîne demandée ou l’une de ses variantes est jugée similaire à un membre de cette catégorie, la demande ne continue pas.

Ce mécanisme ne se réduit pas à une liste noire. C’est une décision de similarité visuelle susceptible de traverser les écritures et les relations de variantes. Sa légitimité dépend donc moins d’une formule générale — « chaîne similaire » — que de la qualité de la trace laissée pour chaque décision.

Deux filtres que le dossier ne doit pas confondre

Le premier filtre intervient avant l’évaluation visuelle. La section 7.2.1 du Guidebook classe les autres chaînes ASCII d’une ou deux lettres parmi les chaînes non admises. La FAQ actuelle d’ICANN reprend cette interdiction. La section 7.2.1.1 décrit un contrôle automatisé : si l’étiquette choisie figure dans la catégorie bloquée, le système empêche le candidat de poursuivre avec cette chaîne et lui demande d’en choisir une autre.

La preuve attendue est alors simple. Il faut conserver l’étiquette saisie, sa forme normalisée, la catégorie exacte qui a correspondu, la version de la liste et l’horodatage du contrôle. Il n’est pas nécessaire d’inventer une appréciation visuelle pour expliquer une correspondance exacte.

Le second filtre pose une autre question. Une chaîne non ASCII de deux caractères, ou l’une de ses variantes, est-elle jugée visuellement similaire à une chaîne ASCII de deux caractères ou à l’une de ses variantes dans la String Similarity Evaluation ? Cette appréciation exige un dossier plus riche qu’un constat d’identité.

Si le résultat public ne dit pas lequel de ces deux filtres a agi, le candidat ne sait pas s’il doit contester une normalisation, une appartenance à une liste, une relation de variante, un rendu typographique ou le jugement du panel. La distinction n’est pas académique : elle détermine les faits à vérifier et le type d’erreur que la contestation peut utilement invoquer.

La variante peut être le véritable point de rupture

La portée de la comparaison ne s’arrête pas à l’étiquette principale. Le Guidebook inclut les variantes allocables et, dans les limites prévues, les variantes bloquées. Pour la relation étudiée ici, le paquet de faits gelé établit la comparaison avec toutes les chaînes ASCII de deux caractères et leurs variantes.

Pour la présente analyse, le fait décisif est le suivant : une variante peut créer la proximité visuelle qui arrête toute la demande. La section 7.10.3 indique en outre que les membres d’un même ensemble de variantes partagent le résultat de l’évaluation. Un seul lien critique peut donc transmettre sa conséquence à des étiquettes qui n’étaient pas, prises isolément, la paire la plus proche.

Un libellé comme « similaire à une chaîne ASCII de deux caractères » est trop pauvre pour un audit éditorial. Il faut préciser si la comparaison était principale-principale, principale-variante, variante-principale ou variante-variante. Une trace reconstructible indiquerait aussi les points de code, l’écriture, la casse et la relation de variante ; il s’agit ici d’une recommandation de gouvernance, non d’une description des champs qu’ICANN publiera effectivement.

Cette liste est une recommandation éditoriale pour obtenir une trace reconstructible, non une description des champs qu’ICANN publiera. Le paquet ne fixe pas le format d’un résultat individuel de la campagne 2026.

Les données de juillet 2026 révèlent la complexité du tri

Le jeu de données SSE publié par ICANN le 23 juillet 2026 a été construit avec des spécialistes des écritures. Les éléments de chaque écriture ont été comparés entre eux, avec des écritures apparentées et avec les caractères ASCII en minuscules et en majuscules. Les définitions de variantes du RZ-LGR ont ensuite été intégrées pour faire apparaître des ensembles potentiels de similarité.

Les exemples officiels montrent pourquoi le nombre de caractères ne suffit pas. Dans la partie consacrée à l’ASCII, ICANN documente notamment des relations entre i et l, m et rn, n et ri, ou vv et w, avec des niveaux de similarité distincts. Certaines relations proviennent directement de l’expertise visuelle ; d’autres sont propagées par les variantes ou par transitivité. La mise en majuscules peut aussi faire apparaître une proximité peu visible en minuscules.

Ces exemples décrivent la méthode. Ils ne prouvent pas qu’un candidat 2026 précis a soumis l’une de ces chaînes, ni qu’ICANN l’a rejetée. Le présent paquet de sources ne contient aucun résultat individuel de la campagne 2026. Il serait donc fautif de transformer un exemple de données en cas réel.

En revanche, les exemples établissent qu’un résultat doit indiquer la représentation examinée. Deux séquences distinctes peuvent produire un rapprochement par la forme, la casse, une variante ou une chaîne de relations. Sans la paire précise et sa catégorie, le lecteur ne peut pas savoir ce que le panel a réellement vu.

L’outil présélectionne, le panel tranche

Les lignes directrices SSE de juillet 2026 donnent à l’outil une fonction de présélection. Il produit des ensembles potentiels que le panel examine ensuite. Le panel peut ajouter, retirer ou modifier ces ensembles, à condition de motiver son choix. L’absence d’une chaîne dans le rapport de l’outil ne vaut pas acquittement automatique : une vérification manuelle de la chaîne et de ses variantes reste requise.

Le partage des rôles vérifié est plus précis : l’outil fournit une présélection, tandis que le panel peut modifier les ensembles avec une motivation et doit aussi examiner manuellement les chaînes absentes du rapport. Le paquet ne formule aucune affirmation supplémentaire sur la composition professionnelle du panel.

Le Guidebook exige que le panel établisse les listes de comparaison, tienne compte des variantes allocables et bloquées, documente toute omission permise, effectue les comparaisons et consigne son analyse. Ce sont les faits procéduraux gelés ; cet article n’ajoute pas de test d’affichage propre aux résultats individuels.

Un bon résultat dira donc si la paire venait de l’outil, quelle catégorie celui-ci lui attribuait, ce que le panel a décidé et pourquoi. Si le panel a ajouté une paire absente, écarté une alerte ou retenu une similarité malgré l’incertitude, cette transition doit être visible. La motivation ne doit pas être remplacée par le score.

Deux relations, deux conséquences dans la même catégorie

Le tableau 7-5 distingue les conséquences. Une chaîne identique à une chaîne ASCII de deux caractères, ou qui en est une variante, n’est pas acceptée. Une chaîne visuellement similaire mais qui n’est pas une variante ne peut pas poursuivre.

La distinction est structurante : l’identité ou la relation formelle de variante ne constitue pas le même constat que la similarité visuelle, même si les deux arrêtent la demande dans cette catégorie. Le glossaire d’ICANN décrit la catégorie comme un espace de possibles futurs ccTLD ; le paquet gelé n’en déduit aucun autre processus.

Cette formulation officielle n’est pas une preuve de propriété. Elle ne démontre pas qu’ICANN, l’Agence de maintenance ISO 3166 ou un État possède juridiquement une étiquette de deux lettres. Le Guidebook fixe une règle du programme gTLD ; il ne tranche pas, à lui seul, toutes les théories de souveraineté ou de droits patrimoniaux sur les identifiants.

Vingt et un jours exigent un dossier immédiatement exploitable

Le candidat dispose de 21 jours après réception du résultat pour contester la String Similarity Evaluation en invoquant une erreur factuelle, procédurale ou de système. Si l’erreur est confirmée, l’évaluation est reprise en tenant compte des conclusions de la contestation. Sinon, le résultat initial demeure.

Un délai aussi court n’est équitable que si les motifs sont livrés avec la décision. Le candidat ne devrait pas consacrer la moitié de la période à découvrir quelle variante a déclenché la comparaison, quelle casse a été utilisée ou pourquoi le panel s’est éloigné du rapport de présélection.

Le dossier minimal devrait donc publier :

  1. le filtre déclenché — identification directe ou évaluation de similarité ;
  2. les formes normalisées des étiquettes principales et variantes de la paire décisive ;
  3. les A-label, U-label, points de code, écritures, casses et contexte de rendu ;
  4. la catégorie de similarité et la règle appliquée ;
  5. le résultat de présélection et toute modification apportée par le panel ;
  6. toute comparaison de variante bloquée omise et sa justification ;
  7. l’effet transmis à l’ensemble complet de variantes ; et
  8. l’heure de transmission, l’échéance de contestation et un identifiant stable du résultat.

Cette liste relève d’une recommandation éditoriale de gouvernance. Ce n’est ni un constat d’ICANN ni la preuve qu’une décision existante est défectueuse. Elle applique la doctrine de Heng Lu selon laquelle un contrôle lourd de conséquences doit laisser une trace reconstructible du déclencheur, des preuves, du raisonnement, du décideur et du recours. La doctrine sert à poser les questions ; elle ne prouve ni l’erreur, ni le dommage, ni l’issue d’une contestation.

Le filtre ASCII à deux caractères protège une frontière lisible de la racine. Pour que cette frontière reste contrôlable, ICANN doit préserver la différence entre deux propositions. Une chaîne ASCII courte peut être interdite dès la soumission. Une autre étiquette de deux caractères, ou sa variante, peut être écartée plus tard après une appréciation visuelle motivée. Lorsque le résultat montre laquelle de ces propositions a décidé le cas, le public peut auditer la règle sans prendre un outil pour un juge ni une réserve de codes pays pour un candidat concurrent.

Sources