L’ICANN ouvre les téléchargements et ferme l’API : il faut un reçu de transition

Résumé

• L’ICANN fermera après le 31 août sa plateforme Open Data et l’API associée. Les fichiers disponibles sur la nouvelle page peuvent, eux, être téléchargés sans compte.
• Une page de destination ne suffit pas à documenter une migration. Une table de correspondance et un reçu par publication permettraient de relier chaque ancien identifiant aux données actuelles, à leur définition et à leur historique de correction.

Une transition numérique peut être plus ouverte et moins traçable au même moment. C’est précisément le paradoxe que l’ICANN doit gérer à la fin du mois d’août.

Le 15 juin, l’organisation a annoncé une nouvelle page de données publiques sur son site principal. Elle a conservé l’ancienne plateforme pendant plus de deux mois afin que les utilisateurs puissent adapter leurs procédures. Le 27 août, elle a rappelé l’échéance : après le 31 août, la plateforme Open Data ne sera plus disponible ; à compter du 1er septembre, son API cessera elle aussi de répondre et l’ancienne adresse redirigera vers la page Open Data Initiative.

L’ICANN donne trois motifs : simplifier l’accès, et réduire les besoins de maintenance, de stockage et de sauvegarde. Le préavis est public. Rien, dans les sources examinées, ne permet donc de parler d’une fermeture dissimulée.

Mais le préavis n’est pas encore un procès-verbal de migration. Il indique une date et une porte d’entrée. Il ne dit pas, ligne par ligne, ce que devient chaque famille de données, chaque identifiant de catalogue ou chaque capacité d’API.

Le gain d’accès est concret

La nouvelle page met en avant deux ensembles : les indicateurs du marché des noms de domaine (DNMI) et les demandes de dérogation pour intervention de sécurité (SRW). Les fichiers sont accessibles sans authentification.

Le dispositif DNMI Version 1.1 compte 16 indicateurs actifs, répartis entre concurrence robuste, stabilité du marché et confiance des consommateurs. Les pages thématiques distinguent les fichiers mis à jour chaque année des indicateurs archivés issus de la version précédente. La page SRW propose un fichier annuel couvrant cinq mesures, depuis le nombre de demandes reçues jusqu’à leur résultat.

Pour un lecteur occasionnel ou une petite équipe, le bénéfice est évident. Un CSV complet se télécharge avec un navigateur ou un outil standard. Il peut être conservé localement, contrôlé et traité sans créer de compte, gérer une clé ou surveiller un quota.

Les deux fichiers échantillonnés pour cet article répondaient correctement au moment de la vérification. Les réponses HTTP comportaient notamment une date de dernière modification et un identifiant ETag. Ce sont des informations utiles au transport et au cache. Les pages consultées ne les définissent toutefois pas comme l’identité éditoriale d’une publication ni comme l’explication d’une correction.

Le téléchargement répond ainsi à la question la plus immédiate : puis-je obtenir le fichier aujourd’hui ? La reproductibilité pose une autre question : quel état exact ai-je obtenu, avec quelle définition, pour quelle période, et par quelle décision a-t-il ensuite été corrigé ou remplacé ?

L’ancienne plateforme portait aussi des capacités

L’appel d’offres publié par l’ICANN en 2018 ne décrivait pas un simple hébergeur de fichiers. Il visait des données sous licence ouverte et un accès API ouvert, fiables, lisibles par machine et destinées à être téléchargées puis analysées. Le texte parlait d’un système source utilisable par l’organisation et sa communauté.

La page de présentation de l’ancienne plateforme ajoutait plusieurs ambitions : données utilisables, à jour et complètes, comparables, interopérables, utiles à la gouvernance. Avec un compte, il était également possible d’enregistrer des analyses, de recevoir des notifications, de générer des clés d’API et de suivre les quotas.

Toutes ces fonctions n’ont pas à être maintenues éternellement ni dans le même logiciel. Une plateforme externalisée coûte de l’argent. Une institution peut choisir une architecture plus légère. Et, pour un instantané complet, un fichier simple peut être plus durable qu’une requête dont il faut reconstituer les paramètres et le comportement du serveur.

La suppression de l’API change néanmoins la charge de la preuve. L’utilisateur qui s’appuyait sur un identifiant, un filtre, une pagination ou une notification doit découvrir l’équivalent — ou constater honnêtement qu’il n’existe pas. Celui qui télécharge un fichier doit pouvoir différencier une nouvelle édition, une correction et un remplacement effectué à la même adresse.

La question n’est donc pas de sauver un fournisseur. Elle est de conserver la mémoire institutionnelle lorsque le fournisseur et l’interface changent.

Quatre rubriques anciennes, deux lignes visibles aujourd’hui

La page d’accueil de l’ancienne plateforme regroupait visiblement quatre thèmes : DNMI, ITHI, rapports d’activité des registres et rapports de transactions par bureau d’enregistrement. La page actuelle Open Data en affiche deux : DNMI et SRW, tout en précisant que d’autres jeux seront ajoutés lorsqu’ils seront disponibles.

Il serait faux d’en déduire que deux familles ont disparu. Les rapports mensuels des registres sont accessibles sur une page distincte du site principal de l’ICANN, classés par domaine de premier niveau. Le tableau de bord ITHI reste lui aussi accessible et présente des mesures actuelles et historiques.

Ce que l’observation établit est plus précis : la page de transition ne fournit pas, à elle seule, la correspondance entre l’ancien catalogue et ces différentes destinations.

L’histoire des rapports de registres montre pourquoi cette correspondance est utile. En 2021, l’ICANN avait demandé aux exploitants de scripts de téléchargement de les modifier pour utiliser l’API Open Data. Les utilisateurs qui avaient suivi cette consigne doivent désormais modifier de nouveau leurs processus. Il ne s’agit pas d’un dommage démontré, mais d’une dépendance expressément reconnue par les propres avis de l’ICANN.

Une table publique pourrait indiquer qu’une famille est transférée vers les nouveaux CSV, qu’une autre reste dans un tableau de bord spécialisé, qu’une troisième revient dans les archives du site principal, et qu’une fonction de requête n’a pas d’équivalent. Chacune de ces décisions peut être défendable. C’est leur statut non explicité qui fragilise la continuité.

La redirection ne peut pas porter toute la provenance

Une redirection aide un humain à retrouver une page. Elle ne décrit pas le sens d’une ancienne requête et ne désigne pas une édition précise.

Un analyste qui cite aujourd’hui le fichier RC 2.1 devrait pouvoir préciser la période couverte, la version de la méthode, l’heure de publication, l’empreinte attendue, le nombre de lignes et le lien vers une éventuelle correction. S’il calcule lui-même une empreinte, il peut prouver ce qu’il a conservé. Il ne peut pas créer, à la place de l’ICANN, le lien institutionnel entre ces octets et la publication officielle correspondante.

Le mécanisme nécessaire peut rester minimal : une table de transition et un registre de publications.

Élément public	Fonction
Ancienne famille, identifiant et route d’API	Nommer la dépendance d’origine
Adresse actuelle et responsable	Identifier le lieu et l’autorité de maintenance
Sort et différence de capacités	Dire si l’objet est migré, maintenu ailleurs, fusionné, archivé ou arrêté
Période, fréquence et version des définitions	Fixer le sens des valeurs
Date, empreinte attendue et nombre de lignes	Identifier exactement la publication
Correction et remplacement	Préserver l’ancien état tout en expliquant le nouveau
Licence, limites d’agrégation et contact	Encadrer la réutilisation et la contestation

Cette couche ne recrée ni un moteur de requêtes ni un espace personnel. Elle préserve les relations que seule l’institution peut certifier.

Une mémoire indépendante de l’interface

La fermeture de l’ancienne plateforme n’est pas, en soi, un recul de la transparence. Le téléchargement sans compte est un progrès. La réduction de coûts peut être raisonnable. Et aucune source examinée ne prouve qu’un jeu de données a disparu ou qu’un fichier actuel est erroné.

Le test est ailleurs : l’identité publique des données survit-elle au changement de produit ?

Avec un reçu portable, l’ICANN pourrait déplacer demain un fichier, remplacer un système de stockage ou réintroduire une API sans rompre la chaîne de preuve. Les utilisateurs sauraient quel ancien identifiant correspond à quelle destination. Deux analyses pourraient être comparées à partir d’une édition nommée, plutôt qu’à partir d’une adresse dont le contenu peut évoluer.

L’ICANN a fourni la date, le nouvel accès et la justification générale. Il lui reste à rendre la transmission vérifiable. Un reçu de transition ferait de la fermeture non pas une perte supposée, mais un événement de continuité documenté.

Sources

1. Mise à jour de la page de données publiques de l’ICANN, 27 août 2026
2. Lancement de la nouvelle page, 15 juin 2026
3. Initiative Open Data de l’ICANN
4. Indicateurs du marché des noms de domaine
5. DNMI : concurrence robuste
6. DNMI : stabilité du marché
7. DNMI : confiance des consommateurs
8. Demandes de dérogation pour intervention de sécurité
9. Ancienne page d’accueil Open Data
10. Présentation de l’ancienne plateforme
11. Annonce de l’appel d’offres de 2018
12. Annonce de migration des rapports de registres en 2021
13. Rapports mensuels actuels des registres
14. Tableau de bord ITHI
15. Exemple de fichier DNMI RC 2.1
16. Exemple de fichier SRW M1-M5