Résumé

  • La publication du 5 octobre ajoute des règles de référence pour l’écriture javanaise et l’écriture syllabique autochtone canadienne, et en actualise sept autres. Les variantes entre écritures font de l’ensemble une mise à jour liée, pas deux ajouts isolés.
  • Ces références de second niveau guident la conception et l’examen des tables IDN des registres. Leur couverture ne prouve ni délégation au premier niveau, ni compatibilité universelle des applications, ni adoption réelle.

Analyse

Une liste de langues peut ressembler à un catalogue. La publication de l’ICANN du 5 octobre se comprend mieux comme une carte de dépendances.

L’ICANN ajoute des règles de génération d’étiquettes (LGR) de référence pour l’écriture javanaise et l’écriture syllabique autochtone canadienne (UCAS), puis met à jour sept autres ensembles : écriture arabe, langue arabe, langue inuktitut, langue japonaise, écriture japonaise, écriture latine et ensemble complet des variantes latines. L’organisation indique que ses références couvrent désormais 30 écritures et 32 langues. Ces totaux décrivent les documents publiés, pas le nombre de langues prises en charge de bout en bout par chaque bureau d’enregistrement, navigateur, système de messagerie ou application.

Les notes de mise à jour montrent pourquoi le nombre d’ajouts ne suffit pas à décrire l’enjeu opérationnel. La nouvelle règle UCAS s’accompagne de variantes entre écritures dans les règles de langue inuktitut. Un caractère latin ajouté pour les langues algonquiennes au Canada entraîne aussi une modification des variantes entre écritures de l’ensemble complet latin. Les règles japonaises de langue et d’écriture sont alignées sur la version 6 des règles de génération d’étiquettes de la zone racine. Les changements de l’écriture arabe soutiennent l’écriture du pégon en Indonésie.

Chaque entrée a donc des liens avec d’autres règles que les registres ou les équipes d’examen peuvent devoir prendre en compte.

Ces règles alimentent une décision concrète. L’ICANN les présente comme des références que les opérateurs de registres génériques de premier niveau peuvent utiliser pour concevoir leurs tables de noms de domaine internationalisés (IDN). L’ICANN s’en sert aussi pour examiner les tables soumises par ces registres au regard de la sécurité et de la stabilité. La table définit les étiquettes qu’une zone donnée peut accepter selon sa politique, ainsi que le traitement de leurs variantes. Une modification d’un fichier de référence peut donc avoir des effets au-delà de l’écriture citée dans le titre de l’annonce.

Cela ne signifie pas que les registres ont déjà adopté les versions d’octobre ni que toutes les tables concernées doivent changer de la même façon. Il s’agit d’abord d’une question de versions : quelle référence l’opérateur a-t-il utilisée, qu’est-ce qui a changé, et quelles étiquettes ou relations de variantes faut-il retester ? Un registre qui ne suit que les deux nouvelles écritures pourrait manquer une modification connexe dans sa table IDN ou dans son processus d’examen.

La distinction entre les niveaux est essentielle. Les LGR de référence de second niveau concernent les tables IDN utilisées sous les extensions génériques. Pour les chaînes IDN de premier niveau, le Guide du candidat du cycle 2026 utilise la version 6 des règles de la zone racine pour valider les chaînes et calculer leurs variantes. Les deux systèmes sont liés par des alignements et des dépendances techniques, mais ne répondent pas à la même question. Une règle de référence de second niveau n’approuve pas à elle seule une nouvelle extension, ne délègue pas une étiquette et ne confère pas au titulaire un droit d’usage.

Le bilan de la consultation publique fait état de 33 commentaires pertinents : 32 soutenaient les nouvelles règles et leurs mises à jour proposées, et un portait sur une coquille et une demande de précision concernant l’écriture javanaise. Ce chiffre renseigne sur les contributions reçues par l’ICANN. Il ne vaut pas vote de tous les registres, de tous les utilisateurs de ces écritures ni de toutes les communautés linguistiques. La formule « élaboré avec les communautés » doit être lue dans ce cadre : des experts et groupes concernés ont été consultés, mais le nombre de commentaires a un périmètre précis.

La publication ne constitue pas non plus une preuve d’acceptation universelle. Des règles de génération lisibles par machine aident un registre à évaluer une étiquette et à traiter ses variantes. Elles ne rendent pas un formulaire compatible, ne garantissent pas la remise d’un courriel et ne forcent pas un logiciel à stocker ou afficher correctement un nom. L’annonce laisse la possibilité d’ajouter d’autres langues et écritures à mesure que des contributions pertinentes sont disponibles. La couverture publiée est un socle d’examen technique, pas une mesure d’usage.

Pour les registres, la réponse pratique consiste à traiter la publication comme un ensemble de changements. Comparer la version en vigueur aux nouveaux fichiers, rattacher chaque modification à sa propre table IDN, tester les étiquettes et variantes touchées, puis coordonner les dates de politique et de déploiement avec les prestataires de registre. Les liens entre écritures méritent une attention particulière : les utilisateurs et les registres manipulent des étiquettes, pas des listes abstraites de points de code.

La question décisive n’est donc pas seulement le nombre d’écritures ajoutées par l’ICANN. Il faut savoir si l’ensemble reste cohérent à mesure que sa couverture s’élargit. La publication d’octobre montre qu’un ajout peut se propager : l’inclusion d’une écriture peut conduire à réexaminer les variantes d’une autre langue, tandis qu’un caractère supplémentaire peut modifier un ensemble complet de variantes entre écritures. Le catalogue est aussi une surface de maintenance.