Résumé

  • Le 3 septembre, l’ICANN a publié un courrier daté du 28 août dans lequel les coprésidents du groupe d’experts sur l’acceptation universelle annoncent avoir remis un document final consensuel au directeur général de l’organisation.
  • Le courrier indique que les retours de la consultation ont notamment conduit à mieux mobiliser l’intelligence artificielle et à proposer des priorités ainsi qu’un cadre de mesure.
  • Or la synthèse des contributions confie deux fonctions différentes à l’IA : détecter ou corriger les défauts d’UA, mais aussi faire partie des assistants de code, filtres de messagerie et services qui doivent prouver leur propre compatibilité.
  • Un registre à deux faces doit relier chaque affirmation à un rôle, une version, un périmètre de test, une autorité humaine, un dénominateur et une classe de résultat. Une production automatisée n’est pas un succès utilisateur.

Commencer par nommer le rôle, pas la technologie

L’index des correspondances de l’ICANN affiche depuis le 3 septembre une lettre d’Edmon Chung et Sarmad Hussain, coprésidents de l’Universal Acceptance Expert Working Group. Dans ce courrier du 28 août, ils expliquent avoir examiné les contributions reçues entre février et avril, mis à jour leurs orientations puis remis au président-directeur général de l’ICANN un texte final soutenu par consensus.

Le passage consacré aux changements ne cite qu’un exemple : tirer parti des technologies d’intelligence artificielle pour faire progresser l’acceptation universelle. Le document final proposerait aussi un ordre de mise en œuvre et un cadre permettant de suivre la sensibilisation, le soutien des politiques publiques, l’exécution technique et le développement des compétences.

Cette formulation ouvre deux dossiers. Dans le premier, une IA sert d’outil. Elle explore un dépôt, suggère une expression de validation, produit des cas de test ou repère qu’un champ refuse une adresse en écriture locale. Le résultat à contrôler est alors ce que l’outil a produit, la manière dont un humain l’a vérifié et l’autorité qui a accepté ou écarté la modification.

Dans le second, l’IA appartient au système observé. Un filtre antispam, un assistant vocal, une interface de création de compte ou un générateur de code peut lui-même transformer, classer ou rejeter un nom de domaine internationalisé ou une adresse EAI. Cette fois, il faut tester son comportement. Le nombre de correctifs qu’une IA a proposés n’apprend rien, à lui seul, sur la réussite de cette opération.

Employer le même indicateur pour les deux revient à confondre l’instrument de mesure et l’objet mesuré. C’est commode dans une présentation, mais impossible à auditer.

Le statut public reste celui d’un dossier remis pour examen

Le courrier ne dit pas que l’ICANN a adopté chaque recommandation. Il précise que le texte est soumis à son examen. Le groupe produit des orientations ; l’organisation conserve la décision sur la faisabilité, les priorités, les moyens et l’exécution. Un consensus interne au groupe établit l’état de son livrable, pas l’état opérationnel de toutes les plateformes visées.

Une prudence supplémentaire s’impose parce que les pages publiques consultées ne relient pas encore le courrier au texte final. La page de consultation close propose toujours le projet de février et annonce au futur sa finalisation et sa publication. L’entrée de correspondance mène à la lettre, tandis que l’index UA de l’ICANN n’affiche pas le document final à la date de vérification.

Cette absence de lien ne prouve ni l’inexistence du fichier ni l’absence de travaux internes. Elle fixe seulement la limite de ce qu’un lecteur peut vérifier. Il est possible d’attribuer aux coprésidents l’ajout d’un volet IA ; il ne serait pas honnête de reconstruire la formulation finale, son numéro ou son degré de priorité à partir de la seule lettre.

L’UA est une chaîne, pas une case cochée

Le projet publié en février donne une définition utile de la préparation à l’UA. Un système doit accepter, valider, stocker, traiter, afficher et faire interopérer tous les noms de domaine et toutes les adresses électroniques valides, y compris les IDN et l’EAI, selon les normes applicables.

Ces verbes décrivent une chaîne de défaillances possibles. Le navigateur peut accepter l’adresse et l’API la refuser. La base peut l’enregistrer, mais le service de récupération ne pas l’utiliser. Le courrier peut être remis, puis classé à tort par une couche de sécurité. Un affichage correct de gauche à droite ne démontre rien sur les chaînes bidirectionnelles. Une réussite locale doit rester attachée à l’étape réellement testée.

Le projet sépare déjà quatre familles d’indicateurs. La sensibilisation compte des actions de communication et leur portée. Le soutien politique concerne notamment normes, politiques et achats publics. La mise en œuvre vise l’usage réel, dont la réussite de parcours complets. Le développement des capacités suit formations, cursus, outils et personnes formées.

La tentation sera d’additionner ces familles. Pourtant, dix ateliers, mille dépôts analysés et cinquante correctifs proposés ne peuvent compenser l’échec persistant d’un parcours de connexion. Ce sont des éléments de causalité, pas des unités interchangeables.

La consultation a révélé la symétrie

La synthèse des 37 contributions rassemble des demandes d’intégrer l’IA au travail des développeurs : assistants de code, génération de modèles conformes, détection automatisée et tests à grande échelle. Cette face promet d’abaisser le coût de découverte et de correction.

La même synthèse demande que les systèmes d’IA constituent une catégorie de parties prenantes. Elle cite les grands modèles de langage, les outils de sécurité du courrier, les générateurs de code, les analyseurs d’adresses, les filtres antispam, les assistants vocaux, les chaînes de données d’entraînement et les outils de diagnostic. Ici, l’IA n’apporte plus seulement une solution ; elle constitue l’une des dépendances dont la réponse doit être observée.

La contribution de l’ISPCP relie cette question à des indicateurs propres à l’IA, à des étapes de déploiement et à une gouvernance explicite. Ces propositions demeurent des contributions. Elles ne sont ni un règlement ni une obligation contractuelle. Elles montrent néanmoins pourquoi l’étiquette générale « IA » ne suffit pas.

Un registre en deux colonnes, puis une chaîne de preuve

Chaque pilote devrait commencer par une déclaration de rôle : outil de diagnostic, générateur de proposition, composant testé, aide à la décision ou opérateur autonome. Une même technologie peut apparaître deux fois, mais jamais dans une ligne ambiguë.

Vient ensuite l’autorité. Qui a choisi l’outil et le corpus ? Qui peut accepter le correctif, déployer la version et revenir en arrière ? Le fournisseur du modèle ne reçoit pas les pouvoirs de l’opérateur. L’outil ne peut pas signer sa propre mise en production.

Le registre doit attacher le résultat à un état : version du modèle ou du service lorsqu’elle est disponible, spécification du test, sortie produite, révision du dépôt, version compilée et dépendances pertinentes. Un service hébergé peut changer entre deux évaluations ; l’horodatage et la date d’expiration sont donc des données de méthode.

Le périmètre fonctionnel doit rester visible : saisie, validation, stockage, authentification, récupération de compte, remise du courrier, affichage ou interopérabilité. Il faut aussi décrire le corpus : écritures et langues couvertes, adresses valides et invalides, longueur, cas droite-gauche, combinaisons de domaines, fournisseurs traversés et exclusions.

Enfin, la classe du résultat doit être impossible à gonfler. Une alerte n’est pas une correction. Un correctif proposé n’est pas un code revu. Un code fusionné n’est pas un déploiement. Un composant conforme n’est pas un parcours réussi. Chacun mérite sa propre date, son propre dénominateur, ses échecs, ses faux positifs, sa voie de correction et son déclencheur de nouveau test.

Ce registre peut rester compact et protéger les secrets industriels. Son rôle n’est pas de centraliser les systèmes, mais d’empêcher une affirmation de voyager plus loin que sa preuve.

Sources

  1. Index des correspondances de l’ICANN
  2. Lettre du groupe d’experts UA, 28 août 2026
  3. Consultation publique sur le projet d’orientations UA
  4. Projet d’orientations pour l’adoption de l’UA
  5. Rapport de synthèse de la consultation
  6. Contribution de l’ISPCP
  7. Charte du groupe d’experts UA
  8. Index des annonces et billets sur l’UA