Résumé

  • Le Customer Standing Committee est tenu de suivre chaque mois les niveaux de service convenus pour le nommage à l’IANA, d’analyser le rapport de l’opérateur et de publier un constat : une cible manquée devient ainsi une phrase publique plutôt qu’une exception discrète.
  • Son constat de janvier 2024 a consigné un manquement nommé — la vérification technique en re-test à 12,88 minutes pour un seuil de dix minutes au 95e centile — tout en jugeant le mois satisfaisant ; celui de juin 2026 a consigné les 64 seuils alors définis comme atteints. Entre l’un ou l’autre constat et une conséquence réelle s’intercalent des étapes formelles qui s’ouvrent sur une défaillance de procédure ou de mise en œuvre, pas sur la seule mesure.

Un chiffre, et la phrase qui l’accueille

Le rapport mensuel de performance de janvier 2024 comporte une ligne inconfortable. La vérification technique en re-test — routine (technique) — y est enregistrée à 12,88 minutes pour un seuil de dix minutes au 95e centile (rapport de l’opérateur, janvier 2024). Le même document compte 123 re-tests sur le mois, avec une moyenne de 3,15 minutes, et attribue l’écart à l’attente de serveurs de noms injoignables, délais d’expiration et nouvelles tentatives compris. Le récit de l’opérateur précise qu’une seule requête a dépassé le seuil de dix minutes fixé pour la vérification technique.

Les deux chiffres cohabitent parce qu’ils ne répondent pas à la même question. Une moyenne sur 123 re-tests décrit le re-test ordinaire ; le seuil en cause est écrit pour la queue de distribution. Trois virgule quinze minutes ne peuvent pas transformer un 95e centile franchi en réussite, et aucune lecture honnête du tableau ne le leur demande. Le rapport lui-même ne confond pas les deux : 12,88 est la statistique de temps de réponse comparée au seuil, pas la moyenne coiffée d’une cible de dix minutes.

Le comité qui transforme une mesure en constat

C’est le Customer Standing Committee qui opère la conversion. Sa charte amendée a été approuvée par le conseil d’administration de l’ICANN le 3 mai 2026 et est entrée en vigueur le 3 juillet 2026. Elle lui impose de suivre mensuellement les niveaux de service convenus, d’analyser les rapports fournis par l’opérateur des fonctions IANA, de publier des constats mensuels et de travailler avec l’opérateur sur des plans de résolution de performance (charte du CSC). La même charte lui demande de rechercher des schémas systémiques ou persistants dans les plaintes, et lui indique dans le même souffle qu’il n’intervient pas dans les litiges entre l’opérateur et un client particulier.

La composition ne relève pas du comité mais des statuts. L’article 17.2(a)(i) exige « Two individuals representing gTLD registry operators appointed by the Registries Stakeholder Group », aux côtés de deux représentants des ccTLD nommés par le ccNSO et d’un agent de liaison de Public Technical Identifiers, avec un siège optionnel pour les autres registres de TLD et des observateurs non votants venus du GNSO, de l’ALAC, du NRO/ASO, du GAC, du RSSAC et du SSAC. Les listes annuelles sont approuvées par le ccNSO et le GNSO (statuts de l’ICANN).

Le 14 février 2024, le comité a publié son constat pour janvier 2024. La phrase générale dit : « PTI met the service level agreement for 98.4% of defined metrics. » Le manquement nommé était la vérification technique en re-test — routine (technique). Le comité a accepté l’explication de l’opérateur, n’a identifié aucun problème persistant, a conclu qu’aucune action supplémentaire n’était nécessaire et n’a signalé aucune nouvelle escalade (constat du CSC, janvier 2024).

Il faut lire ce pourcentage avec précision. Il mesure la part des mesures définies ayant atteint leur cible, pas la part des requêtes individuelles traitées dans les délais. Un mois où 98,4 % des mesures passent est un mois où le registre était majoritairement au vert, et c’est aussi un mois où une mesure de queue précise n’a pas franchi sa ligne. Les deux affirmations sont vraies, et ce ne sont pas les mêmes.

Trois propositions, pas une note globale

La tentation est de réduire la liasse à un verdict de performance. Les documents résistent, et cette résistance est instructive. Un résultat de mesure est une mesure. Un constat qualitatif est un jugement sur la question de savoir si cette mesure signale un problème qui mérite d’être poursuivi. Un registre d’escalade est une affirmation sur ce que l’institution a fait ensuite. Trois propositions, trois mains différentes, et la propreté de l’une ne garantit rien pour les deux autres.

Le cycle de juin 2026 montre la même séparation, vue de l’autre côté. Le constat du comité, daté du 22 juillet 2026, indique : « PTI met all 64 of the currently defined thresholds. » Il a qualifié la performance d’excellente, n’a signalé aucune mesure nécessitant un suivi rapproché et n’a relevé aucune nouvelle escalade sur la période (constat du CSC, juin 2026). Le rapport de l’opérateur pour ce mois apporte la texture : vérification technique initiale à 3,50 minutes pour un plafond de 50 minutes au 95e centile, re-test à 1,18 minute pour 10 minutes au même centile, validation et revues à 1,54 jour pour 5 jours au 90e centile, publication de la zone racine à 58,00 heures pour 72 heures au 99e centile, disponibilité du système de gestion de la zone racine à 100,00 % pour un plancher de 99 %, exactitude du fichier de zone racine à 100,00 % pour 100 % (rapport de l’opérateur, juin 2026). Le tableau de synthèse porte le titre « Percentage of SLA thresholds met of those defined » et totalise 64 sur 64.

Ce titre est le plus honnête, et c’est aussi le piège. Soixante-quatre sur soixante-quatre est une affirmation de conformité portant sur les seuils en vigueur en juin 2026. Ce n’est pas une affirmation sur les seuils de janvier 2024, et cette revue n’a pas obtenu côte à côte les définitions de mesures, les dénominateurs et les valeurs cibles des deux périodes. Aucune amélioration n’est donc calculée ici entre le mois à 98,4 % et celui à 64 sur 64. Qui veut une tendance a besoin du tableau, pas de la note.

L’échelle, et ce qui la déclenche vraiment

Entre un constat publié et une conséquence pour l’opérateur, il y a une procédure écrite. Les procédures d’action corrective du CSC et de PTI, version 2.0, adoptées par le comité en janvier 2019 et par PTI en février 2019, obligent le comité à solliciter les observations du président de PTI avant de finaliser un constat sur un problème de performance, en principe sous dix jours ouvrables (procédures d’action corrective). Un rapport d’action corrective est ensuite adressé au président de PTI, avec copie au président de la Global Domains Division de l’ICANN ; la réunion, la remise du plan correctif et l’examen par le comité suivent des échéances successives de dix jours ouvrables.

Au-dessus, l’escalade est ouverte pour des manquements aux obligations de procédure, de mise en œuvre ou de reporting : au conseil de PTI, puis au directeur général de l’ICANN, puis au conseil d’administration de l’ICANN. Si le dossier reste ouvert après cela, le comité peut le porter devant les conseils du ccNSO et du GNSO, y compris, le cas échéant, par une revue spéciale indépendante. Les délais de réponse peuvent être modifiés d’un commun accord, et la mise en œuvre corrective suit des jalons convenus plutôt qu’une horloge statutaire fixe.

La rédaction elle-même est le constat. Ce qui déverrouille l’échelle, ce sont des défaillances de processus et de livraison, pas le franchissement d’une cible chiffrée en soi. Un mois où une mesure de queue manque, où l’opérateur explique pourquoi et où le comité accepte l’explication s’arrête au constat — exactement ce que montre le dossier de janvier 2024, y compris sa conclusion explicite qu’aucune action supplémentaire n’était nécessaire.

Au-dessus de la procédure se trouve le contrat. Le contrat des fonctions de nommage de l’IANA du 30 septembre 2016 impose au contractant d’« act in good faith to resolve issues identified by the CSC » (contrat des fonctions de nommage). L’article 7.3(c) permet à l’ICANN de modifier ou de résilier l’accord pour mettre en œuvre une revue approuvée, une revue spéciale ou une recommandation du comité de travail des statuts, sous réserve des statuts. Ceux-ci fixent ensuite les conditions d’une revue spéciale : échec de l’action corrective au titre des procédures, examen par les conseils, consultation élargie et approbation à la majorité qualifiée des deux conseils, avec appel à commentaires publics lorsqu’il est demandé. La charte ferme la boucle en indiquant que le comité ne peut pas déclencher lui-même un remplacement de l’opérateur par une revue spéciale.

La séquence qui mène d’un manquement mesuré à un changement d’opérateur traverse donc l’acceptation ou l’action corrective, le conseil de PTI, le directeur général de l’ICANN, le conseil d’administration de l’ICANN, la majorité qualifiée de deux conseils, une revue spéciale, puis le pouvoir contractuel de modification ou de résiliation. Chacune de ces étapes est réelle et a ses participants. Aucune n’est la publication d’un constat mensuel.

Le seul changement qui saute la file

Les seuils eux-mêmes ne sont pas figés dans le contrat. L’amendement n° 1, daté et effectif du 7 mai 2019, a remplacé l’annexe d’origine afin que la gestion de la zone racine se conforme à des niveaux de service publiés extérieurement et tenus à jour par une procédure de modification définie ; il distingue un processus, une mesure, un seuil par requête individuelle, un type minimum ou maximum, un pourcentage de conformité agrégé et une période de mesure (amendement n° 1).

La procédure qui régit ces changements a été modifiée pour la dernière fois le 16 juillet 2025 selon son propre texte. Public Technical Identifiers, l’ICANN ou le comité peuvent en demander un ; les niveaux existants restent inchangés sans accord mutuel ; les modifications ordinaires exigent un appel à commentaires publics et l’approbation des deux conseils, ccNSO et GNSO. Les changements portant uniquement sur les valeurs de seuil existantes sont dispensés de ces deux étapes (procédure d’amendement des SLA).

Cette dispense mérite une phrase simple. Une modification qui change ce qui compte comme réussite est la seule catégorie de changement qui n’a pas à passer par les commentaires publics et les deux conseils, alors qu’une modification de la mesure, du processus ou de la période de mesure doit y passer.

Le même document précise que les niveaux de service sont intégrés au contrat des fonctions de nommage et opposables par son intermédiaire, que la procédure ne prime pas sur les obligations contractuelles, et que le comité doit engager une revue complète des niveaux de service au moins tous les cinq ans, à compter de l’achèvement des résultats de la revue précédente.

Rien de tout cela n’établit qu’un seuil ait été déplacé pour flatter un constat mensuel. Aucune série de valeurs de seuil et aucun critère de notation globale du comité n’ont été obtenus ici, si bien que cette inférence est à la fois indisponible et inutile. Ce que le dossier établit est plus étroit et plus utile : le dénominateur de la formule « seuils atteints » est tenu à part du constat, et le moyen le moins visible de changer le sens d’un mois propre consiste à retoucher le tableau.

Là où cette revue s’arrête

Le dossier a des bords, et ils se placent à côté des affirmations qu’ils limitent. Le texte consolidé en vigueur du contrat des fonctions de nommage n’a pas été obtenu dans cette revue, pas plus que le tableau de niveaux de service en vigueur : la page des accords de Public Technical Identifiers et celle des niveaux de service pour le nommage n’ont renvoyé qu’un message exigeant JavaScript (accords PTI, page des SLA de nommage PTI). Chaque seuil cité ci-dessus est donc rattaché à janvier 2024 ou à juin 2026 et n’est pas présenté comme la cible actuelle.

Le fil des amendements est lui aussi irrégulier. Les états financiers consolidés de l’ICANN pour l’exercice clos le 30 juin 2026, avec un rapport d’audit daté du 6 octobre 2026, décrivent le contrat des fonctions de nommage comme modifié le 24 juin 2024, en vigueur depuis le 30 septembre 2021, conclu pour cinq ans avec renouvellement automatique sous certaines conditions et renouvelé le 30 septembre 2026 (états financiers de l’ICANN). Les états de l’exercice précédent qualifient le même contrat de modifié le 7 mai 2019. Le texte de ce qui a changé en juin 2024 n’a pas été obtenu, et rien ici ne suppose qu’il ait touché une disposition citée plus haut. Le document de procédure porte 24 septembre 2025 dans son nom de fichier alors que son texte indique une dernière modification au 16 juillet 2025.

Les chiffres de performance sont déclarés par l’opérateur. Aucun audit indépendant ni validation externe des données mensuelles n’a été identifié dans l’ensemble examiné, et les critères qui font d’un mois un mois « satisfaisant » ou « excellent » n’ont pas été obtenus. Aucune série pluriannuelle de constats et de plans de performance n’a été obtenue non plus : aucun schéma d’escalade et aucune tendance ne sont donc affirmés ici.

Qui emploie, finance ou dirige le secrétariat du comité n’est pas davantage établi par ces documents ; l’agencement décrit ci-dessus est un agencement de fonctions, d’information et d’approbations, et c’est tout ce qu’il est décrit comme étant.

Ce qui changerait la lecture est concret. Un constat qui nomme un manquement et qu’un rapport d’action corrective publié vient ensuite. Un plan de résolution de performance avec des dates et un responsable nommé au dossier public. Une modification de seuil accompagnée de sa date, de son ancienne valeur et de la nouvelle. Chacun de ces éléments ferait passer le constat mensuel du statut d’évaluation documentée à celui de décision assortie d’une conséquence.

En attendant, la description honnête de la surveillance du nommage à l’IANA est celle d’un registre tenu publiquement, vérifié chaque mois par un comité qui doit publier, et appliqué par des portes qui s’ouvrent sur des défaillances de procédure plutôt que sur un chiffre.

L’entrée du répertoire consacrée au sujet se trouve ici : IANA.

Sources