Acceptation universelle : 1 formulaire écrit par l'IA sur 27 passe le test, 18 avec une page de règles

Quand on porte un nouveau gTLD, l'acceptation universelle est un sujet très concret. J'en fais l'expérience régulièrement avec le .corsica. Une association de l'île m'a raconté avoir renoncé à son adresse en .corsica parce qu'un service de l'État refusait ses mails. Je n'ai pas de trace écrite de ce refus, seulement leur récit. Mais c'est exactement le genre d'histoire qui fait perdre un titulaire à une extension territoriale.

Le GeoTLD Group la définit ainsi : tous les noms de domaine et toutes les adresses mail valides, quels que soient leur écriture, leur longueur ou leur format, devraient être acceptés, validés, stockés, traités et affichés correctement par toutes les applications, tous les appareils et tous les systèmes connectés. Un .corsica a sept lettres : une règle écrite quand les extensions en avaient deux ou trois ne l'attend pas.

Le sujet devient plus lourd avec les noms de domaine internationalisés, les IDN : пример.рф, contact@société.fr, ou une adresse entièrement en chinois comme 用户@例子.中国. Une application qui ne sait lire que l'alphabet latin les refuse, ou les abîme.

L'ICANN a un programme dédié à l'acceptation universelle. Le GeoTLD Group, qui réunit les registres d'extensions géographiques, a lancé la GeoTLD UA Local Initiative, « developed in cooperation with ICANN », pour aider chaque registre à organiser formation et sensibilisation sur son territoire.

Pendant des années, les refus que je voyais venaient de librairies de validation et de sites jamais mis à jour, avec une liste d'extensions figée ou une règle qui limite l'extension à quelques lettres. L'outil que je publie le montre sur une expression de ce type, qui n'accepte que deux à quatre lettres après le point : elle refuse les quatre adresses à extension longue de la batterie.

Aujourd'hui, une partie des formulaires est écrite par des modèles d'IA. D'où la question : le code qu'ils produisent est-il compatible avec l'acceptation universelle ?

L'ICANN s'est posé la question. Son rapport 2026 sur l'adoption des IDN et de l'acceptation universelle (1er septembre 2026, §2.2.2.1) a testé trois outils de code IA et conclut que « the AI coding tools evaluated are not inherently UA-ready, particularly for validation and processing, but can generate substantially more UA-ready applications when appropriate UA guidance and checks are incorporated into the development process ».

Le rapport ne nomme pas les outils testés et ne publie ni leurs prompts, ni les données de test, ni les consignes : on ne peut pas rejouer le test à partir du rapport.

J'en avais parlé à Séville, en juin, lors de la réunion ICANN86, avec un acteur des registres. Sa question était simple : les développeurs livrent depuis toujours des formulaires non conformes ; maintenant que l'IA écrit ce code, arrange-t-elle le problème ou l'aggrave-t-elle ?

Le résultat qui m'a le plus surpris concerne mon propre sujet. Les extensions longues passent : les adresses comme contact@boutique.corsica sont acceptées par les 54 formulaires, et les domaines de ce type par tous sauf un, qui refusait aussi example.com. Ce qui casse le plus souvent, c'est l'Unicode dans la partie de l'adresse avant le @. Sans consigne, l'adresse 用户@example.com est acceptée par 6 formulaires sur 9 chez Claude, 7 sur 9 chez GLM et aucun chez GPT-6 Astra. Avec la page de règles, 9 sur 9 chez les trois.

Ce test ne reproduit donc pas le refus vécu par l'association : sur ce prompt, les trois modèles testés ont écrit des formulaires qui acceptent .corsica. Le problème se déplace vers les adresses en Unicode.

Neuf formulaires par modèle et par condition, c'est peu : ce test ne classe pas les modèles. Il mesure une génération en un coup ; un assistant qui travaille dans un vrai projet peut se comporter autrement. Un seul navigateur, Chromium, et le côté client seulement : ce que le serveur fait de l'adresse ensuite n'est pas mesuré. Enfin, deux règles de notation ont été fixées après avoir regardé les pages. Je l'ai testé : quelle que soit la combinaison de ces règles, l'écart avec et sans consigne reste entre 10,6 et 12,6 points.

Tout est public : la batterie de 82 valeurs (CC0), la page de règles à charger dans Claude Code, Cursor ou Copilot (CC BY), le code (MIT), et les 54 formulaires générés, que chacun peut renoter. Le dépôt : github.com/guia-matthieu/ua-agent-kit. Les résultats : guia-matthieu.github.io/ua-agent-kit/bench.

La feuille de route dit ce qui reste à faire : d'autres modèles, un second passage avec des règles de notation fixées à l'avance, et surtout des formulaires écrits avec React ou avec les librairies de validation courantes, que ce premier test excluait.

J'ouvre le dépôt pour que d'autres registres fassent les mêmes tests chez eux. ua-kit check tape les 82 valeurs dans n'importe quel formulaire en ligne, sans jamais l'envoyer. Un registre peut ainsi vérifier les formulaires qu'utilisent ses titulaires.