Résumé

  • Le dossier public examiné ici établit qu'ICANN exploite un programme d'opérateur de registre de secours d'urgence et qu'une désignation de 2013 a nommé trois prestataires. Toutes les sources retenues sont des synthèses ; aucun contrat, aucune ligne budgétaire et aucun instrument de désignation n'ont été lus au cours de cette revue.
  • Cinq faits distincts décident si cette assurance est exerçable : une désignation actuelle, un droit de déclenchement opposable, une capacité financée et entretenue, une reprise éprouvée, et un périmètre défini. Les comptes publics traitent régulièrement le premier comme la preuve des cinq. Dans ce dossier, seuls les deux premiers sont documentés, et le second uniquement par un article de presse spécialisée citant une annonce de 2013.

Les registres défaillent de manière peu spectaculaire : un opérateur manque de trésorerie, perd ses équipes techniques, cesse de répondre. Le remède qu'ICANN annonce pour ce scénario est un back-end de substitution — une partie déjà préparée à reprendre les fonctions critiques d'un domaine générique afin que celui-ci continue de résoudre pendant qu'une décision plus longue s'organise. La question posée ici est plus étroite que celle de savoir si l'idée est bonne. Elle est de savoir si le dossier public montre que ce dispositif peut effectivement être déclenché.

Ce que le dossier dit, et ce qu'il ne dit pas

Quatre documents forment l'intégralité de la base probante de cette revue. La page de programme d'ICANN décrit le dispositif comme assurant la continuité pour les exploitants de nouveaux gTLD en cas de défaillance critique ou de transition (page du programme EBERO d'ICANN). La page relative à l'accord de registre est décrite comme contenant les exigences contractuelles applicables aux exploitants, dont une spécification 10 portant sur le processus de transition de registre, et comme présentant l'opérateur d'urgence comme un filet de sécurité de continuité (page de l'accord de registre gTLD). La présentation du programme datée du 2 avril 2013 est résumée comme expliquant que le service est destiné à être utilisé lorsqu'un exploitant ne fournit pas, ou ne peut maintenir, les fonctions essentielles du registre — avec référence à cinq fonctions critiques, temporairement ou pendant une transition (présentation du programme EBERO, 2 avril 2013).

Le quatrième document est le seul à nommer quelqu'un. Un article de presse spécialisée indépendant, conservé ici sous forme d'extrait rapporté, indique que le Centre d'information du réseau internet chinois, la société américaine Neustar et la société britannique Nominet ont été retenus, en l'attribuant à un communiqué d'ICANN (article d'InfoWorld sur la sélection de 2013).

C'est tout, et c'est plus mince qu'il n'y paraît. Les quatre sources sont des synthèses. La provenance de l'extrait est consignée comme rapportée par le service pour l'article de presse, et aucun extrait n'a été conservé pour les trois pages d'ICANN : les descriptions ci-dessus sont donc la caractérisation qu'en fait le service de recherche, et non le texte lu dans les instruments. La page de l'accord de registre est une page d'accueil, pas l'accord ; la spécification 10 est mentionnée, non citée.

La revue entreprise pour ce briefing a tenté d'aller plus loin et n'a pas pu. Une demande de consultation directe portant sur l'accord, la page du programme et la présentation de 2013 a échoué, faute de capacité disponible après une attente bornée. Une seconde demande, visant les deux branches totalement dépourvues de soutien — qui détient aujourd'hui le rôle de secours, et si la capacité est financée — n'a retourné aucun candidat. Cela fait deux échecs sur la même classe d'instruments, et la recherche s'est arrêtée là. La lacune est consignée comme une frontière datée, non comblée par inférence.

Cinq niveaux, systématiquement ramenés à un seul

La discipline utile consiste à cesser de traiter « l'opérateur d'urgence existe » comme un fait unique. Il se décompose en cinq, et la preuve d'un niveau ne dit rien du suivant.

Un : un programme annoncé. Documenté. ICANN publie une page de programme dont la continuité est l'objet affiché.

Deux : un prestataire nommé. Documenté, mais pour 2013 seulement, et uniquement par un article de presse spécialisée. C'est à ce niveau que s'arrête l'essentiel de la discussion publique.

Trois : un droit de déclenchement opposable en vigueur. Non établi. Rien dans le dossier examiné ne montre qu'un prestataire nommé soit actuellement sous désignation, quelle en est la durée, quelles conditions de préavis ou de déclenchement s'y attachent, ni qui est habilité à l'actionner. Une désignation échue ou re-attribuée est un fait différent d'une désignation en vigueur, et cette différence est exactement celle qui sépare un plan d'un numéro de téléphone.

Quatre : une capacité financée et entretenue. Non établi. Une capacité de réserve n'est pas gratuite : quelqu'un paie l'infrastructure réservée, la familiarité des équipes avec de nombreuses plateformes de registre et les validations périodiques. On ne trouve nulle part, dans le matériel conservé, si le budget adopté d'ICANN porte une telle ligne, ni comment le coût d'une invocation se répartit entre ICANN, l'exploitant défaillant et les titulaires dont les noms sont en jeu.

Cinq : une reprise testée et appelable. Non établi. Un remède que personne n'a exercé dans des conditions réalistes reste une hypothèse. Le dossier ne contient aucun compte rendu d'exercice, aucun délai de reprise, et aucune définition de ce que « temporairement » signifie en jours.

Deux niveaux sur cinq documentés, au stade de la synthèse. C'est le résultat, et ce n'est pas un scandale. C'est la mesure de la portée réelle du dossier public.

Une lacune structurelle, pas un piège

Il serait facile, et faux, de lire ces lignes comme une accusation. Considérons de quoi un remède de continuité est fait.

Un accord de registre lie l'exploitant. Mais l'obligation qui compte le plus — coopérer à une transition, remettre les données d'enregistrement, maintenir la zone en service pendant qu'un autre prend la main — devient urgente précisément quand l'exploitant est le moins en mesure de l'exécuter. Une obligation opposable seulement après la défaillance est un vrai recours pour une procédure ultérieure. Ce n'est pas un substitut au substitut.

Les deux sont des instruments différents, aux modes de défaillance différents, et j'opère cette distinction par raisonnement, non en la rapportant comme une description des contrats d'ICANN, puisque ces contrats n'ont pas été lus ici.

Le substitut acheté est l'autre instrument, et il vit entièrement hors du contrôle de l'exploitant défaillant. Il exige un contrat avec une durée, une ligne budgétaire qui survit à un changement de direction, et une routine qui prouve que la machinerie tourne encore. Ce sont des artefacts peu glorieux. Ce sont aussi les seuls qui comptent au moment du déclenchement, parce que ce sont ceux qui ne dépendent pas de la coopération d'une partie qui a déjà cessé de coopérer.

Il existe de bonnes raisons pour que les termes d'un marché ne soient pas toujours publiés : confidentialité commerciale, détail sensible pour la sécurité, tarification. Mais la confidentialité des termes et l'absence de toute vérification sont deux situations distinctes, et le dossier examiné n'établit même pas laquelle s'applique.

Portée : la continuité n'est pas la sécurité

Même un dispositif pleinement vérifié ne signifierait pas ce que l'usage courant suggère. Le programme est décrit comme s'activant lorsqu'un exploitant ne peut maintenir cinq fonctions critiques du registre, temporairement ou pendant une transition. C'est un périmètre technique délimité : le domaine continue de résoudre, et un ensemble défini de fonctions continue de tourner, pendant qu'une décision de sortie se prépare.

Ce n'est pas une garantie d'absence de risque sur les noms. Cela ne dit rien sur l'exactitude des données des titulaires, sur leur capacité à transférer ou renouveler pendant la transition, sur les conditions commerciales qu'imposerait un substitut, ni sur la durée pendant laquelle un arrangement temporaire peut durer avant que la question de gouvernance sous-jacente ne devienne le vrai problème. Continuité d'une fonction et clarté d'un titre sont deux assurances séparées. Tout compte qui les fusionne surestime ce qu'un filet de sécurité technique peut faire.

Légitimité, formulée avec prudence

Il y a une question institutionnelle sous la question technique, et elle peut être posée sans prêter d'intention.

La légitimité, au sens qui compte pour une fonction d'assurance, est une relation entre ce qu'une institution affirme et ce qui peut être vérifié indépendamment. Une page de programme publiée et un communiqué nommant des prestataires sont des formes d'assurance. Elles coûtent peu à produire et communiquent de la confiance. La vérification indépendante — une désignation assortie d'une durée, une ligne budgétaire, un compte rendu d'exercice — coûte cher à produire et communique la même chose avec moins de portée.

Cette asymétrie produit une dérive prévisible : la forme d'assurance bon marché circule, la forme coûteuse est rarement demandée, et l'écart entre les deux devient invisible par défaut. Les titulaires, les revendeurs et les gouvernements évaluent alors la réassurance plutôt que la capacité. Quand les deux divergent, le coût atterrit sur les parties qui avaient le moins de moyens de vérifier.

Ce n'est pas un constat de mauvaise foi, et ce n'est pas l'affirmation que la capacité est absente. C'est une affirmation sur ce que le dossier soutient : qu'une allégation de sécurité catégorique devancerait la preuve, et que la classification honnête est une révision à la baisse de la confiance, non un verdict.

Ce qui permettrait de trancher

Cinq artefacts combleraient l'écart, et chacun est publiable sans divulguer d'élément sensible : une désignation en vigueur avec une durée et un titulaire ; les conditions de déclenchement et l'organe habilité à l'actionner ; le financement tel qu'il apparaît dans un plan d'exploitation adopté, au niveau d'agrégation que le budget utilise déjà ; un compte rendu d'exercice ou de test daté ; et un historique documenté des invocations, avec dates et durées.

Aucun de ces éléments n'exige la révélation des annexes confidentielles d'un contrat. Tous permettraient à un titulaire, à un revendeur ou à un gouvernement de distinguer un secours appelable d'un secours simplement annoncé.

En attendant, l'énoncé exact sur le filet de secours d'ICANN est celui que ce dossier soutient : il existe, il est présenté comme un filet de sécurité, trois prestataires ont été nommés une fois, et les conditions qui décident s'il est exerçable n'ont pas été montrées. Les lecteurs qui prennent l'annonce pour l'assurance font confiance à un instrument qu'ils n'ont pas vu. La fiche du programme dans le répertoire se trouve ici : Emergency Back-End Registry Operator Program – ICANN.