Résumé

  • Le projet de septembre 2026 imposerait à chaque RIR de maintenir des procédures de continuité et de redondance, puis de partager régulièrement, sous des garanties de protection, les éléments nécessaires à un opérateur temporaire.
  • Le texte prévoit un périmètre de service, un mécanisme d’activation et de renouvellement, une limite de 90 jours par période et un bilan public. Il s’agit encore d’un projet recommandé ; aucune prise en charge réelle n’est documentée ici.

Une procédure de secours préparée seulement après la panne arrive trop tard. Le projet de l’Organisation de ressources numérotées (NRO) place donc une partie du travail en amont. Chaque registre Internet régional (RIR) devrait conserver des procédures de continuité et de redondance et partager régulièrement les informations et systèmes qui permettraient à un opérateur temporaire de maintenir les services nécessaires.

La disposition centrale est le § 4.1(m) du projet recommandé de document de gouvernance des RIR, version 3. Elle vise les registres, données, procédures d’application des politiques régionales et systèmes, sous réserve de garanties appropriées d’entiercement ou de protection des données. Le partage doit être suffisant pour permettre à un opérateur temporaire d’assurer les services si besoin. Il ne s’agit donc ni d’une publication générale des données, ni d’un transfert automatique de tous les systèmes.

Cette liste dépasse la copie d’une base de données. Les procédures de mise en œuvre des politiques et les systèmes sont également cités. La préparation devient une relation de fonctionnement préexistante, au lieu d’un export improvisé au moment d’une crise. Le texte définit les services des RIR comme comprenant l’attribution de ressources, l’enregistrement, les services d’annuaire et les services techniques associés, afin que les détenteurs puissent utiliser leurs ressources et que les informations restent exactes.

Cette ambition comporte deux risques opposés. Des informations anciennes peuvent empêcher l’opérateur de tenir le registre à jour ; un accès trop vaste peut exposer des renseignements sensibles ou donner une autorité inutile. Le projet mentionne l’entiercement et la protection des données, mais ne fixe pas dans cette disposition la fréquence de rafraîchissement, la durée d’accès, le mécanisme de révocation ni les tests de cohérence. Ces détails devront être rendus vérifiables dans la mise en œuvre.

Une continuité temporaire, pas une succession

Le § 5.1 prévoit l’activation si un RIR ne peut plus fournir tout ou partie de ses services, quelle qu’en soit la cause. Le RIR concerné peut lancer lui-même un arrangement pour ses propres services. Une autre voie permet à l’ICANN et aux deux tiers des autres RIR de l’initier ou de le renouveler, après échange avec le RIR touché et sa communauté lorsque les circonstances le permettent.

Un arrangement ne peut dépasser 90 jours sans renouvellement selon la même disposition. Le rapport de justification de la version 3 explique que la nouvelle version ajoute l’initiative par le RIR concerné, abaisse le seuil externe de l’unanimité à l’ICANN et aux deux tiers des RIR, et conserve les 90 jours pour éviter que la solution provisoire ne devienne la norme. La limite oblige donc à décider de nouveau ; elle ne plafonne pas la durée cumulée si des renouvellements sont accordés.

Après le transfert, le RIR concerné doit coopérer. Il conserve le droit de reprendre les services une fois sa capacité opérationnelle rétablie et vérifiée ; le périmètre confié peut être ajusté en cours d’arrangement ou lors d’un renouvellement. Le texte rend donc possible un retour, mais il laisse des questions pratiques : qui vérifie la capacité retrouvée ? Selon quels tests ? Comment rapprocher les modifications du registre ? Quand les accès du remplaçant prennent-ils fin ?

Le projet prévoit des obligations de publication. L’ICANN doit publier rapidement le motif et le périmètre de l’activation ; un processus d’échange avec toutes les communautés des RIR doit débuter dès que raisonnablement possible. Après la fin, les RIR et l’ICANN doivent examiner conjointement l’événement et publier un rapport sur les circonstances, les services, la durée, le retour, la performance de l’opérateur et les retours des communautés. Ce dossier rendrait une future intervention auditable, à condition que les mesures aient été définies assez précisément.

Il faut distinguer ce mécanisme de la non-reconnaissance. Le § 6 prévoit une procédure distincte, après une non-conformité importante et une possibilité raisonnable de correction. La non-reconnaissance met fin à la responsabilité du RIR et déclenche un transfert conforme à un plan de transition. La continuité d’urgence autorise seulement la fourniture temporaire de services, tandis que le RIR garde une voie de retour. Le § 6.9 relie les deux situations par une obligation de préparation collective, sans les confondre.

Un projet, pas encore une règle adoptée

La version 3 reste un projet recommandé. Le NRO EC a annoncé le 28 juillet que le conseil ASO avait remis le texte à l’exécutif du NRO, chargé de coordonner les étapes vers une version finale. L’annonce d’AFRINIC du 1er septembre publie le projet, le texte comparatif et la justification ; elle renvoie les prochaines possibilités de contribution au NRO EC. Le § 1.3 envisage des procédures d’application communes qui définiraient des exigences minimales.

La preuve utile à venir sera concrète : inventaire des données et services placés sous protection, fréquence de mise à jour, contrôle d’intégrité, accès autorisés et journalisés, critères de retour, expiration des accès et rapprochement des dossiers. Un exercice de simulation pourrait tester ces étapes sans prétendre qu’une panne a eu lieu. Le bilan devrait aussi distinguer les données rendues disponibles de celles réellement utilisées.

La nouveauté de conception est de faire de la préparation une activité ordinaire. Son efficacité dépendra de la manière dont « régulièrement », « suffisant », « garanties appropriées » et « vérifié » seront traduits en contrôles testables.

Sources

Au 15 octobre, le calendrier du NRO indique encore une finalisation en cours : des mises à jour sont prévues à ICANN 87 (17–22 octobre), LACNIC 46 (19–22 octobre), ARIN 58 et RIPE 93 ; l’approbation et l’adoption restent inscrites au quatrième trimestre 2026.