Résumé

  • La Version 3 proposée permet au RIR touché de déclencher une relève temporaire pour ses propres services ; un second parcours associe ICANN et les deux tiers des autres RIR au lancement ou au renouvellement.
  • Le plafond de 90 jours et le droit du RIR concerné de reprendre ses services après rétablissement vérifié sont explicites ; l’autorité qui renouvelle une relève commencée localement l’est moins.

Une nouvelle voie avant même le transfert

Lorsqu’un registre ne peut plus assurer convenablement tout ou partie de ses services, le projet de RIR Governance Document prévoit qu’un Temporary Emergency Operator qualifié puisse les fournir temporairement. Il ne s’agit pas, dans le texte, de remplacer institutionnellement le registre. La mesure porte sur des services déterminés : délégation de ressources numériques, tenue des inscriptions et de l’annuaire, ou prestations techniques associées. Ce périmètre peut être partiel et évoluer.

AFRINIC a relayé le 1er septembre 2026 le projet recommandé par l’ASO AC, son document de comparaison et son rapport explicatif. Le NRO présente la Version 3 comme un projet final ; sa page de suivi indique que l’ASO AC/NRO NC l’a remis au NRO EC le 28 juillet. Au 14 octobre, la finalisation et l’approbation/adoption au quatrième trimestre restent à venir. Il s’agit donc d’une proposition destinée à l’ensemble du système des RIR, pas d’une règle en vigueur. Aucun élément publié ne permet d’affirmer qu’AFRINIC ou un autre RIR ne peut actuellement fournir ses services. L’annonce d’AFRINIC relaie le dossier ; le texte de la Version 3 définit les mécanismes examinés.

Deux voies de déclenchement

Le paragraphe 5.1(a) constitue une nouveauté importante par rapport à la Version 2. Si un RIR est incapable de fournir convenablement tout ou partie de ses services, il peut initier une Temporary Emergency Continuity Arrangement pour ses propres services. Dans la version précédente, l’initiation exigeait l’accord unanime des autres RIR et d’ICANN.

La Version 3 conserve une voie de coordination externe au paragraphe 5.1(b), mais abaisse ce seuil : ICANN et les deux tiers des autres RIR peuvent également initier ou renouveler l’arrangement, après discussion avec le RIR concerné et sa communauté lorsque les circonstances le permettent raisonnablement.

Le rapport explicatif formule l’objectif en termes pratiques. Une activation par le RIR touché pourrait aider lors d’une catastrophe naturelle ; un seuil externe moins élevé pourrait accélérer la réponse. Les rédacteurs maintiennent toutefois la limite de 90 jours afin qu’une solution temporaire ne devienne pas le mode normal de fonctionnement. Cette combinaison se défend : lorsqu’un service essentiel est perturbé, attendre une procédure plus large avant de demander de l’aide peut prolonger l’incertitude sur la personne autorisée à effectuer la tâche.

Mais déclencher et renouveler ne sont pas la même décision. Le point 5.1(a) désigne le RIR touché comme acteur du déclenchement de sa propre relève. Le point 5.1(b) est le seul à préciser qu’un arrangement peut être « initiated or renewed » avec l’accord d’ICANN et des deux tiers des autres RIR. Le point 5.1(c) prévoit qu’un dispositif ne peut dépasser 90 jours sauf renouvellement selon les conditions de la section. Il ne dit pas clairement si un RIR qui a commencé la relève sous (a) peut la renouveler lui-même, ou si le renouvellement doit passer par l’accord prévu en (b).

Deux lectures restent possibles. La mention explicite du renouvellement en (b) peut indiquer que cette voie collective est la seule autorisée. À l’inverse, on peut considérer que le RIR habilité à déclencher l’arrangement sous (a) peut aussi prolonger celui qu’il a lancé. Le point 5.1(f), qui attribue les changements de périmètre à la « partie initiatrice pertinente » ou aux « parties » prévues en (a) ou (b), incite à lire les deux voies ensemble. Il ne tranche pourtant pas la question du renouvellement. Il faut nommer l’ambiguïté et la corriger, sans prétendre qu’une interprétation juridique s’impose déjà.

Le périmètre des services est une question d’autorité

Le périmètre n’est pas figé au premier jour. Le point 5.1(f) autorise son augmentation ou sa réduction pendant l’arrangement ou lors du renouvellement, selon ce que la partie initiatrice pertinente juge nécessaire. Si le RIR touché a engagé la relève et que le groupe externe autorise ensuite son renouvellement, le texte devrait préciser qui peut ajouter une fonction, limiter le rôle de l’opérateur temporaire ou décider que les circonstances justifient une nouvelle répartition.

Ce n’est pas un détail administratif. Chaque service confié à l’opérateur temporaire modifie ce que le RIR exerce encore directement ; chaque service retiré impose une étape de retour et des preuves permettant de vérifier que le registre peut le reprendre. Le critère d’ouverture — l’incapacité à fournir convenablement tout ou partie des services — suppose lui aussi un jugement opérationnel. La décision devrait indiquer quel service ne répond plus au critère et ce qui démontrera son rétablissement, sans exposer identifiants ni éléments de sécurité.

Les garanties du projet comptent. Le point 5.1(d) oblige ICANN à publier rapidement la décision, ses motifs et son périmètre. Il prévoit un processus d’engagement de l’ensemble des communautés des RIR après le déclenchement ; des échanges supplémentaires après le renouvellement restent facultatifs pour les RIR. Le RIR concerné doit coopérer au transfert et conserve le droit de reprendre les services pertinents une fois sa capacité restaurée et vérifiée.

Le point 5.2 impose ensuite un examen commun et un rapport public sur les circonstances, les services fournis, la durée et le retour, ainsi qu’une évaluation de l’opérateur, des retours de la communauté et des recommandations.

Ces éléments rendent le dispositif visible et limitent le rôle de l’opérateur à une mission définie. Ils ne désignent pas pour autant l’autorité qui renouvelle une relève initiée localement. Les échanges communautaires apportent témoignages, expertise et alertes ; ils ne remplacent pas l’autorité institutionnelle que le texte attribue aux acteurs nommés.

Des procédures doivent rendre le transfert vérifiable

Le point 1.3 prévoit la possibilité d’adopter des procédures de mise en œuvre conjointes, mais précise que leur absence n’empêche pas l’application des dispositions du document. Chaque RIR conserve une marge sur sa manière de se conformer aux obligations générales. Le point 1.4 renvoie les décisions aux procédures propres à l’entité concernée, y compris les recours ou contestations prévus. Un manuel commun peut donc préciser les gestes opérationnels sans laisser la répartition fondamentale des pouvoirs à reconstruire en pleine crise.

Un relevé compact de la voie d’autorité aiderait à tester le mécanisme : paragraphe invoqué et décideur ; services concernés et date de début ; échéance des 90 jours ; acteur du renouvellement et parties approbatrices ; changements de périmètre et auteur de ces changements ; trace des discussions et de la publication ; test de capacité permettant le retour ; responsable et date de l’examen après l’événement. Il ne s’agit pas d’ajouter une autorisation à chaque étape. Il s’agit de pouvoir distinguer une demande locale d’assistance d’une décision collective de maintenir ou d’élargir le transfert.

Selon le calendrier du NRO, la finalisation est encore en cours, avec des mises à jour prévues lors de réunions des RIR et d’ICANN avant une approbation/adoption au quatrième trimestre. Le prochain texte devrait répondre à trois questions précises : le RIR qui invoque 5.1(a) peut-il renouveler ? Si non, quelle décision exacte de 5.1(b) faut-il obtenir ? Qui contrôle le périmètre si la voie d’initiative change ? Des réponses explicites conserveraient la rapidité recherchée par la Version 3 tout en rendant la responsabilité lisible à l’expiration des 90 jours.

Sources