Résumé

  • L’aperçu définitif indique qu’après la consultation publique, l’expert de l’écriture chinoise a mené une analyse complémentaire assistée par IA et relevé 1 612 cas de similarité han. Après de nouvelles consultations d’experts, ICANN les a intégrés aux données chinoises, japonaises et coréennes selon son principe de prudence.
  • Ces cas appartiennent à la couche de preuve. L’outil SSE génère des ensembles de contention potentiels ; le panel peut les ajouter, les retirer ou les modifier, doit motiver le résultat portant sur la chaîne entière, puis peut réévaluer en cas d’erreur factuelle, procédurale ou système contestée dans les 21 jours.

Une donnée peut déclencher un examen sans avoir le pouvoir de le conclure. C’est toute la portée institutionnelle des 1 612 nouveaux cas han rendus publics par ICANN le 30 juillet.

Le document final décrit une analyse supplémentaire réalisée après la consultation de 2025. L’expert de l’écriture chinoise s’est appuyé sur quatre familles de méthodes assistées par intelligence artificielle : réseaux neuronaux convolutifs, analyse de la structure des traits, moments de Zernike et histogrammes en grille. ICANN rapporte que ce travail a fait apparaître 1 612 cas supplémentaires. Après un nouvel échange avec les experts des écritures, ils ont été incorporés aux fichiers chinois, japonais et coréen.

Cette précision permet deux lectures excessives, qu’il faut écarter. La première serait de présenter l’apport comme 1 612 décisions prises par une machine. La seconde consisterait à considérer que l’intervention d’experts garantit déjà chaque issue future. Les sources n’établissent ni l’une ni l’autre. Elles décrivent des relations de similarité ajoutées à un jeu de données servant à rechercher des cas possibles.

Une relation entre points de code peut accroître le nombre de comparaisons soumises au panel. Elle ne dit pas qu’une demande existe pour la chaîne concernée, que deux demandes forment déjà un ensemble de contention, ni qu’un dossier a échoué.

Après la consultation, la mise au point du jeu de données

La version d’octobre 2025 avait été publiée avec un parti pris assumé : mieux valait présenter un doute au panel que l’éliminer trop tôt. En cas d’ambiguïté, des éléments pouvaient entrer dans un ensemble de similarité. La transitivité des variantes et des relations visuelles pouvait également rapprocher deux éléments que les experts n’avaient pas qualifiés directement de confondables ; le fichier conservait alors une catégorie et un code de raison spécifiques.

Le dispositif couvrait un fichier commun et 26 fichiers propres aux écritures du Root Zone Label Generation Rules. Il devait alimenter un outil de présélection capable de réduire un nombre de comparaisons devenu très important avec les chaînes variantes. Dès cette version, les ensembles produits par l’outil étaient décrits comme potentiels et modifiables par le panel.

La consultation a été ouverte du 16 octobre au 4 décembre 2025. Onze contributions ont porté sur des ajouts ou retraits précis, l’accès public à l’outil, la maintenance ultérieure et la prudence à appliquer aux cas limites. Dans son rapport, ICANN a répondu à plusieurs propositions et annoncé qu’elle examinerait la faisabilité technique et logistique d’un accès public à l’outil. Elle a aussi indiqué qu’une version finalisée serait fixée pour le cycle 2026, les apports suivants étant mis en attente pour des travaux futurs.

La publication finale divulgue l’extension han. Elle en donne le volume, les techniques, les trois fichiers concernés et l’existence d’une consultation supplémentaire des experts. Il serait donc inexact de dire que le changement est caché.

Il serait tout aussi excessif de conclure qu’une modification postérieure à la consultation contourne nécessairement la consultation. Une procédure de commentaires doit être suivie d’une analyse et d’une finalisation. Le test pertinent est plus exigeant et plus sobre : peut-on reconnaître les changements matériels, leur origine, leur examen et leur effet lorsqu’ils rencontrent plus tard une demande réelle ?

Dans les pièces consultées, il n’existe pas de delta public, ligne par ligne et exploitable par machine, qui isole les 1 612 ajouts avec leur état antérieur, leur classe de provenance et leur traitement expert. Il n’est pas non plus possible de savoir lesquels rencontreront une chaîne demandée. Cette limite de visibilité ne prouve pas l’absence d’une trace interne ou d’une validation.

Une base commune figée, un jugement encore ouvert

Les données et les lignes directrices définitives portent toutes deux le numéro de version 1.0 et la date du 23 juillet 2026. Les lignes directrices précisent que ces versions s’appliqueront au cycle 2026. Les nouveaux signalements seront enregistrés et discutés avec les experts compétents, mais ne modifieront pas la base du cycle en cours.

Cette stabilité sert l’égalité de traitement. Deux candidats d’un même cycle ne devraient pas être comparés à des versions invisiblement différentes. Une version désignée rend le point de départ reproductible et évite qu’une relation change de sens en cours de route sans frontière claire.

Le gel du fichier ne transforme pourtant pas son contenu en décision automatique. L’outil SSE établit un rapport de présélection avec des ensembles de contention potentiels. Le panel le reçoit comme un élément parmi d’autres, peut mener une analyse complémentaire, puis ajuster, ajouter ou retirer des ensembles. Il porte la responsabilité de la décision finale.

L’unité de jugement change au passage. Les données classent des points de code ou des séquences. Le panel compare des chaînes entières. La position d’une forme, le rendu, la casse, les combinaisons et la lecture propre à une écriture peuvent modifier la perception d’ensemble. Les lignes directrices demandent l’intervention de lecteurs natifs des écritures concernées et une motivation de chaque résultat, notamment lorsque le panel s’écarte du prétri.

Dans un cas difficile, le texte recommande d’envisager l’option conservatrice et de considérer les chaînes comme similaires. Cette orientation est publiée. Elle ne permet pas de prédire la conclusion d’un cas qui n’a pas encore été examiné.

Quatre états doivent rester distincts :

  1. un cas de similarité figure dans un fichier d’écriture ;
  2. l’outil propose un ensemble de contention potentiel ;
  3. le panel décide sur les chaînes complètes et expose ses raisons ;
  4. une contestation dans le délai prévu vérifie une erreur factuelle, procédurale ou système et conduit soit au maintien, soit à une nouvelle évaluation.

Faire du premier état le troisième confond registre et autorité. Faire du deuxième un résultat indiscutable confond réduction de charge et mandat institutionnel.

La conséquence naît du résultat, pas de la ligne de données

Le Guide du candidat donne une portée concrète au résultat du panel. Selon la catégorie de comparaison, une similarité visuelle peut empêcher une demande de continuer, la mettre en attente ou former un ensemble de contention avec une autre demande. L’issue pertinente s’étend à l’ensemble de variantes concerné. ICANN prévoit de publier les résultats et leurs motifs sur la page des résultats d’évaluation.

La distribution des rôles est donc déterminante. Les données signalent des relations dignes d’examen. L’outil rend praticable un espace de comparaison massif. Le panel décide si deux chaînes complètes sont assez proches pour créer une probabilité de confusion si elles coexistent dans la racine. ICANN applique ensuite l’effet prévu par le programme.

Une voie de correction existe. L’auteur d’une demande dispose de 21 jours après réception du résultat pour déposer une Evaluation Challenge fondée sur une erreur de fait, de procédure ou de système. Si l’erreur est confirmée, l’évaluation est reprise en tenant compte de cette conclusion. Sinon, le résultat initial demeure. Ce mécanisme n’est ni une seconde appréciation illimitée du fond ni un moyen de remplacer la demande par une version matériellement différente.

Cette architecture borne mieux le pouvoir qu’une décision intégralement automatique. Elle exige néanmoins que les couches restent reliées. Sans identité de version, le résultat ne peut être reproduit. Sans raison propre au panel, la suggestion technique prend l’apparence d’une décision. Sans histoire de rectification, une contestation réussie peut corriger le dossier tout en laissant survivre l’ancien raisonnement dans le récit public.

Un reçu reliant le changement à la décision

La transparence utile ne commande pas de dévoiler une demande avant l’étape prévue, les délibérations protégées du panel ou des données personnelles. Elle doit permettre de relier les changements significatifs du corpus à un résultat lorsque celui-ci devient publiable.

Le reçu « changement-décision » proposé par Daniel Kade commence par la version des données et l’empreinte de chaque fichier. Pour chaque ajout, retrait ou reclassement important entre le corpus commenté et la version figée, il enregistre les points de code ou séquences concernés, l’état avant et après, puis l’origine : réponse à une contribution publique, correction d’expert, extension d’expert, candidat issu d’une analyse assistée par IA, ajout par transitivité ou transformation mécanique.

Le reçu conserve ensuite la date de l’apport, la méthode, la justification, les écritures touchées et l’état de la consultation des experts. Il distingue ce qui intervient dans le calcul de présélection de ce qui n’est gardé qu’à titre documentaire. Une consultation ne doit pas être présentée comme un accord unanime si la source ne le démontre pas.

Lorsqu’une relation contribue réellement à un ensemble potentiel, la partie protégée lie la version de l’outil et cette contribution. Au stade où le programme autorise la publication, la partie publique joint la décision sur les chaînes entières, la règle appliquée et la raison pour laquelle le panel a suivi, complété, retiré ou renversé la suggestion. Toute contestation, erreur reconnue, nouvelle évaluation, correction et substitution reste attachée.

ICANN n’a pas annoncé ce reçu ; il s’agit d’une proposition de Daniel Kade. L’organisation publie déjà les données finales en HTML et XML. Un delta entre version commentée et version finale, accompagné de totaux par écriture et type de provenance, rendrait cette ouverture beaucoup plus instructive sans transformer les demandes protégées en dossiers publics prématurés.

Les 1 612 cas ne sont donc ni un scandale en soi ni une preuve de perfection. Ils démontrent la nécessité de plusieurs capacités : une analyse capable d’explorer l’échelle, des experts sensibles aux écritures, un panel responsable du mot entier et un recours limité capable de corriger une erreur définie. La légitimité dépend du fait que chaque capacité demeure à sa place.

Sources

  1. ICANN — annonce des données et lignes directrices SSE, 30 juillet 2026
  2. ICANN — aperçu définitif des données SSE, version 1.0
  3. ICANN — lignes directrices SSE définitives, version 1.0
  4. ICANN — page de ressources String Similarity Evaluation
  5. ICANN — consultation publique sur les données SSE
  6. ICANN — rapport de synthèse de la consultation sur les données SSE
  7. ICANN — projet d’aperçu des données SSE soumis à consultation
  8. ICANN — Guide du candidat au cycle 2026 des nouveaux gTLD
  9. ICANN — FAQ sur la contestation d’un résultat SSE