Résumé

  • Le 6 septembre, le Conseil de l’ICANN a autorisé un contrat de développement et d’assistance pour la série 2026. La décision publiée le 9 septembre cite les fonctionnalités, la réponse aux incidents, la stabilité et les processus métiers critiques, tout en masquant le prestataire, le montant et une grande partie des motifs.
  • Le 3 mai, une précédente autorisation présentait l’astreinte renforcée comme un dispositif de six mois, de l’ouverture des candidatures jusqu’à la confirmation des chaînes alors attendue le 30 octobre, avant une réduction aux heures ouvrables.
  • Rien dans le dossier public ne prouve que les deux décisions visent le même contrat, le même périmètre ou le même fournisseur. Elles créent néanmoins une borne temporelle dont l’issue doit pouvoir être observée.
  • Une fiche de sortie peut publier, sans secret commercial ou technique, les fonctions revenues au régime normal, leur responsable interne, les exceptions, la date de décision et le prochain examen.

L’échéance annoncée approche, mais le critère manque

Les résolutions du 6 septembre donnent au président-directeur général de l’ICANN, ou à ses délégataires, le pouvoir de conclure et de payer un contrat destiné au « développement des systèmes et à l’assistance » de la série 2026. Les considérants publics invoquent des fonctionnalités suffisantes, une réponse rapide aux incidents, la stabilité des systèmes et le soutien des processus métiers critiques. La dépense est annoncée comme déjà intégrée au budget de l’exercice 2027 et aux budgets futurs.

Le texte n’indique ni le catalogue des services, ni les plages horaires, ni les classes d’incident, ni la durée, ni le prix, ni le prestataire. Plusieurs passages sont masqués pour protéger la négociation. Le Conseil qualifie l’acte de fonction administrative de l’organisation ne nécessitant pas de consultation publique.

Ces réserves ne suffisent pas à produire un soupçon. Une organisation responsable protège une négociation en cours et ne publie pas le plan précis de défense de ses systèmes. Surtout, la série 2026 entre dans une phase de traitement où l’assistance ne s’arrête pas avec le formulaire de candidature. Le problème apparaît seulement lorsqu’on rapproche cette décision de celle prise quatre mois auparavant.

Le 3 mai, le Conseil avait prolongé des contrats pour un modèle d’astreinte renforcée. La justification était exceptionnellement précise sur le temps : six mois de demande et de complexité accrues, entre l’ouverture du guichet le 30 avril et la confirmation des chaînes alors prévue le 30 octobre. La couverture élargie devait permettre de traiter les incidents en dehors des heures normales. Au terme de la période, l’équipe d’assistance devait diminuer et revenir aux heures ouvrables.

Ce passage n’est pas une garantie de service opposable. Il donne néanmoins au public un état initial, une période d’exception et un état final attendu. La décision de septembre fait donc naître une question vérifiable : selon quelle preuve l’ICANN décidera-t-elle que la couverture élargie peut être réduite, maintenue pour certaines fonctions ou redéfinie ?

Il serait imprudent d’inventer le lien contractuel. La motivation de mai mentionne un fournisseur issu d’un appel d’offres d’octobre 2023 et son travail sur les systèmes RSP, ASP et TAMS. Le texte de septembre ne dit pas qu’il s’agit du même prestataire, d’une nouvelle prolongation ou du même périmètre. Le test de sortie ne dépend justement pas de cette supposition. Il doit suivre les fonctions dont l’ICANN assume la continuité, quel que soit celui qui les fournit.

Après le dépôt commence une chaîne plus longue

Le guichet a fermé le 12 août. L’ICANN a annoncé plus de 1 600 candidatures principales, dont plus de 1 100 accompagnaient une proposition de chaîne de remplacement. Ce total ne mesure ni les requêtes informatiques, ni les pics d’utilisation, ni les incidents. Il confirme seulement qu’un volume considérable doit maintenant traverser l’examen administratif et les étapes suivantes.

Le parcours des candidats énumère ces étapes : publication des dossiers, contributions de la communauté, objections et appels, évaluations des chaînes, des organisations et des candidatures, résolution des contentions, contractualisation, intégration technique et délégation. Le système n’a donc pas fini son travail quand il cesse d’accepter de nouveaux dépôts. Il change de travail.

Le rapport préparatoire à ICANN85 montre aussi que « le système » n’est pas un bloc. En février, le build 5 de TAMS et les tests d’acceptation utilisateur étaient terminés ; les tests d’intégration de bout en bout commençaient ; les builds 6, 7 et 8 devaient encore fournir des fonctions d’évaluation et de contractualisation. Le rapport distingue la gouvernance du programme, l’infrastructure, l’opérationnalisation, la préparation des personnels et prestataires, ainsi que les fonctions de soutien.

Une même date ne rendra pas nécessairement toutes ces composantes autonomes. L’assistance de nuit peut devenir inutile pour une fonction et rester justifiée pour une autre. Le développement peut continuer alors que l’exploitation courante est stabilisée. Une exception peut suivre un jalon décalé. C’est pourquoi un simple « contrat terminé » ou « contrat renouvelé » renseigne moins qu’une décision ventilée par classe de service.

Une fiche sobre, six réponses

Le test de sortie pourrait prendre la forme d’une page datée, liée aux résolutions concernées. Pour chaque grande fonction, elle répondrait à six questions.

  1. Quel niveau de couverture constituait l’exception, et quel est le régime normal visé ?
  2. Quel rôle interne de l’ICANN accepte le service et décide de réduire, prolonger ou modifier l’assistance ?
  3. Quelles catégories de preuves ont été examinées : reprise testée, charge prévue, défauts encore ouverts, transfert des procédures ou données d’astreinte convenablement définies ?
  4. Quelles fonctions ont atteint leur état stable, et à quelle date ?
  5. Quelles exceptions demeurent, pour quelle raison et jusqu’à quel nouvel examen ?
  6. À quel moment une nouvelle décision publique sera-t-elle prise ?

Cette fiche ne serait pas un palmarès de disponibilité. Une moyenne annuelle peut cacher la période brève où un délai est irréversible. Un nombre de tickets, sans taxonomie, mélange facilement incident, demande, défaut et changement programmé. L’ICANN devrait définir l’unité avant de publier le chiffre.

Le test n’oblige pas à arrêter l’assistance. Il peut conclure à un retour complet aux heures normales, à une prolongation temporaire et limitée, à un transfert réussi avec renfort mobilisable, ou à l’adoption assumée d’un nouveau régime permanent. Le mot « sortie » désigne la sortie de l’indécision, non la rupture automatique du contrat.

Publier l’état, protéger les secrets

La politique de divulgation documentaire affirme que les documents détenus par l’ICANN doivent être accessibles sauf motif impérieux de confidentialité. Elle protège notamment ce qui risquerait de léser des intérêts commerciaux. Les pratiques de publication expliquent de leur côté comment les résolutions, rapports préliminaires et procès-verbaux sont rendus publics sous réserve des exclusions prévues par les statuts.

On peut donc séparer proprement deux couches. Restent confidentiels le fournisseur, le tarif, les vulnérabilités, les identifiants, la composition des équipes et les consignes d’escalade en temps réel. Deviennent publics l’état d’une fonction, le rôle responsable, la date d’acceptation, la catégorie d’éléments examinés et l’échéance suivante.

La politique de passation et de décaissement impose l’aval du Conseil au-delà de 750 000 dollars et prévoit des rapports périodiques du directeur financier sur les décaissements importants. Comme le montant de septembre est masqué, ce seuil ne permet aucune estimation. Il rappelle surtout qu’une bonne autorisation financière n’est pas une recette d’acceptation opérationnelle. Les deux contrôles se complètent sans se remplacer.

Ce que le dossier ne permet pas de dire

Aucune source citée ne signale de panne, de délai de réponse manqué, de brèche, de mauvaise prestation, de surcoût ou de dépendance irréversible. Le volume de candidatures ne renseigne pas la charge technique. Le vocabulaire de septembre peut couvrir d’autres services que ceux nommés en mai.

La nouvelle autorisation ne prouve pas davantage que l’ICANN a renoncé à la réduction annoncée. Il peut s’agir d’une autre phase, d’un périmètre différent, d’une préparation normale ou d’une transition déjà maîtrisée. L’incertitude est précisément la raison de publier un résultat minimal plutôt que de tirer une conclusion de passages expurgés.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — Résolutions approuvées le 6 septembre 2026
  5. ICANN — Résolutions approuvées le 3 mai 2026
  6. ICANN — État d’avancement de la série 2026 avant ICANN85
  7. ICANN — Plus de 1 600 candidatures à la clôture
  8. Programme des nouveaux gTLD — Parcours des candidats
  9. ICANN — Politique de divulgation documentaire
  10. ICANN — Pratiques de publication
  11. ICANN — Politique de passation de contrats et de décaissement