Résumé

  • Le 20 février 2026, une modification de l’Addressing API de Cloudflare a provoqué le retrait d’environ 1 100 préfixes BYOIP appartenant à des clients.
  • Le récit introductif de Cloudflare situe l’expérience de la panne à 17 h 48 UTC et lui attribue une durée de six heures et sept minutes, tandis que la chronologie détaillée indique une période d’impact de 17 h 56 à 23 h 03 UTC. Ces deux formulations internes ne concordent pas et doivent rester distinctes.
  • L’incident n’était ni une attaque, ni un détournement BGP, ni une fuite de routes, ni un échec démontré de validation d’origine.
  • Les droits sur un préfixe, les objets IRR, les ROA et les lettres d’autorisation documentent une permission ; ils ne prouvent ni qu’une route est actuellement annoncée, ni qu’un service est joignable.
  • L’annulation de la modification initiale a arrêté de nouvelles mutations, mais n’a pas recréé tous les enregistrements, rattachements de services et états de configuration déjà modifiés.
  • Cloudflare affirme avoir rétabli environ 800 préfixes vers 20 h 20 UTC ; près de 300 autres ont nécessité des voies de récupération supplémentaires jusqu’à 23 h 03 UTC.
  • Une responsabilité vérifiable exige des simulations exactes, des protections tenant compte des dépendances, des cohortes limitées, des canaris représentatifs, un mécanisme de retour arrière indépendant et une réconciliation entre toutes les couches de preuve.

Une panne de routage provoquée par un contrôle interne du cycle de vie

L’incident du 20 février 2026 concernait le service Bring Your Own IP, ou BYOIP, de Cloudflare. Dans ce modèle, un client conserve l’usage de son propre espace d’adressage tandis que Cloudflare peut annoncer les préfixes correspondants depuis son réseau mondial et acheminer le trafic vers les services auxquels ces adresses sont rattachées. Cette relation associe donc un actif administratif — le préfixe détenu ou contrôlé par le client — à un état opérationnel — l’annonce BGP effectivement exportée par l’infrastructure de Cloudflare.

D’après le compte rendu public de Cloudflare, une modification apportée à la manière dont son réseau gérait les espaces IP de ses clients a déclenché le retrait d’un sous-ensemble de préfixes BYOIP. Le problème n’était pas un conflit avec un acteur extérieur revendiquant les mêmes routes. Cloudflare n’a pas décrit une origine illégitime, un chemin BGP détourné ou une validation RPKI refusant une annonce pourtant souhaitée. Son propre système de contrôle a cessé d’attirer le trafic pour des préfixes légitimes de clients.

Cette distinction est essentielle. Une application peut être en parfait état tout en restant inaccessible si le réseau ne fournit plus de chemin vers son adresse. Lorsqu’un préfixe est retiré, les paquets peuvent ne jamais atteindre le service, le proxy ou le serveur d’origine. Pour les utilisateurs, le résultat peut prendre la forme de délais d’attente ou d’échecs de connexion. Pour l’opérateur, la cause demeure en amont de l’application : elle réside dans la relation entre l’état enregistré du préfixe, son association fonctionnelle et l’annonce présente dans les routeurs.

Cloudflare a explicitement indiqué que l’incident n’avait pas été causé par une attaque. Les éléments publics ne permettent pas non plus de le qualifier de détournement BGP, de fuite de routes ou d’incident de validation d’origine. Il s’agissait d’un retrait de préfixes légitimes provoqué par une modification du système interne chargé de leur cycle de vie.

Ce périmètre précis empêche deux erreurs d’analyse. La première consisterait à fondre l’événement dans une histoire générale des pannes de Cloudflare. Les incidents antérieurs survenus en 2019, 2020, 2022 ou 2025 n’établissent pas le mécanisme de février 2026. La seconde serait d’assimiler tout problème BGP à une attaque ou à une anomalie externe. Ici, le contrôle de l’opérateur sur ses propres annonces est au centre du dossier.

Une chronologie publique qui doit conserver sa contradiction interne

La chronologie publiée comporte une divergence qu’une analyse rigoureuse ne doit pas effacer. Dans l’introduction de son compte rendu, Cloudflare indique que la panne a été ressentie à 17 h 48 UTC et qu’elle a duré six heures et sept minutes. Dans sa chronologie détaillée, l’entreprise situe cependant la période d’impact entre 17 h 56 et 23 h 03 UTC.

Ces deux présentations ne produisent pas le même point de départ. Il serait donc incorrect de sélectionner 17 h 48, d’y ajouter mécaniquement six heures et sept minutes, puis de présenter le résultat comme une chronologie unifiée. Il serait tout aussi incorrect de remplacer discrètement l’une des formulations par l’autre. La conclusion prudente est simplement que la source primaire contient deux descriptions temporelles qui ne sont pas arithmétiquement alignées.

Cette divergence ne remet pas à elle seule en cause le mécanisme expliqué par Cloudflare, mais elle affecte la précision avec laquelle les lecteurs, les clients et les observateurs peuvent reconstruire l’incident. Dans un événement de routage, quelques minutes peuvent séparer le début d’une mutation interne, sa première propagation vers les routeurs, son observation par des collecteurs externes et les premiers symptômes visibles. Chacun de ces instants peut être légitime, à condition d’être nommé.

Le compte rendu indique qu’avant l’arrêt de la modification initiale, environ 1 100 préfixes BYOIP avaient été retirés. L’annulation de cette modification a stoppé de nouveaux retraits, mais elle n’a pas rétabli l’ensemble des états déjà altérés. Cloudflare attribue ensuite la restauration d’environ 800 préfixes à une étape atteinte vers 20 h 20 UTC. Les quelque 300 préfixes restants ont nécessité des mécanismes supplémentaires, les opérations de rétablissement se prolongeant jusqu’à 23 h 03 UTC selon la chronologie détaillée.

Ces chiffres doivent rester approximatifs. Ils décrivent des groupes de préfixes, non une liste publique de clients ou une mesure complète du dommage économique. Rien dans le dossier gelé ne justifie d’inventer des identités, des pertes financières, des obligations contractuelles particulières ou des conclusions juridiques. Il permet toutefois de constater que le retour à un état stable ne s’est pas résumé à la désactivation de la modification qui avait lancé l’incident.

Ce que signifie réellement « apporter ses propres adresses IP »

Le modèle BYOIP sépare plusieurs fonctions souvent confondues dans les discussions sur les pannes réseau. Un client peut détenir un préfixe, autoriser Cloudflare à l’annoncer, rattacher les adresses à un service et demander un état BGP annoncé. Ces actes sont liés, mais aucun ne prouve automatiquement que les autres sont corrects à l’instant présent.

La première couche concerne l’autorité sur la ressource numérique. Les registres Internet régionaux consignent l’allocation ou l’enregistrement d’espaces d’adressage. Les objets de route dans une base IRR décrivent notamment l’association attendue entre un préfixe et un système autonome d’origine. Une ROA inscrite dans l’infrastructure RPKI peut autoriser un ASN à être l’origine d’une route donnée, sous certaines limites de longueur. Une lettre d’autorisation formalise la permission donnée à Cloudflare d’annoncer l’espace du client.

Ces éléments répondent principalement à la question : « Qui est autorisé à faire quoi avec ce préfixe ? » Ils ne répondent pas à la question : « Cette route est-elle actuellement exportée vers Internet ? » Une ROA valide ne commande pas un routeur. Elle ne crée ni session BGP, ni politique d’exportation, ni annonce. Elle permet à d’autres réseaux de vérifier si l’origine observée correspond à une autorisation publiée.

La deuxième couche est celle du compte et de la délégation. Le préfixe doit être représenté dans le bon compte Cloudflare. Dans certains scénarios, une délégation peut permettre à un autre compte d’utiliser une partie de l’espace tandis que le compte parent conserve certaines responsabilités de gestion. Cette relation administrative ou commerciale ne garantit toujours pas que le préfixe soit annoncé.

La troisième couche associe les adresses aux services. Une adresse attirée vers le réseau de Cloudflare doit mener quelque part : vers un service de diffusion, de sécurité, de transport, de sortie dédiée ou de transit. Les rattachements de services et les cartes d’adresses expriment cette destination fonctionnelle. Un préfixe pourrait être correctement annoncé tout en étant mal associé, laissant le réseau recevoir du trafic sans l’acheminer vers le bon traitement.

La quatrième couche est l’intention d’annonce. La documentation BYOIP actuelle décrit un objet de préfixe BGP qui peut être dans un état retiré ou annoncé. Après l’enregistrement et la validation, un préfixe peut initialement rester retiré. Une opération autorisée le fait ensuite passer à l’état annoncé afin que Cloudflare l’exporte depuis son réseau.

La cinquième couche est l’état réellement déployé. Une base de contrôle peut dire « annoncé » alors qu’une configuration n’a pas atteint tous les équipements attendus. À l’inverse, des routeurs pourraient continuer à annoncer un préfixe après que l’intention centrale a changé. Seules des observations de la configuration active et du comportement du réseau peuvent départager ces possibilités.

La sixième couche est l’observation externe. Des collecteurs BGP, des points de mesure distribués et des tests de joignabilité peuvent montrer ce que voient effectivement d’autres réseaux. Cette preuve est indispensable parce qu’une plateforme ne peut pas conclure à la disponibilité mondiale à partir de sa seule base interne.

Le rôle central de l’Addressing API

Cloudflare présente son Addressing API comme la source de référence pour les adresses IP de ses clients. Dans l’incident de février, cette fonction lui conférait un rôle particulièrement sensible : un même ensemble d’enregistrements reliait les préfixes détenus par les clients, leurs rattachements aux services et l’état d’annonce BGP destiné à l’infrastructure de bordure.

Le compte rendu décrit un sous-processus de nettoyage qui a interprété certains enregistrements d’une manière conduisant au retrait de préfixes actifs. Pour une partie des utilisateurs concernés, des paramètres d’adressage ont également été supprimés des serveurs de bordure. La panne ne relevait donc pas uniquement d’un indicateur BGP basculé du mauvais côté. Certaines représentations nécessaires au service avaient déjà disparu ou cessé d’être disponibles là où elles étaient requises.

Ce mécanisme illustre le danger d’une automatisation de cycle de vie qui traite un objet comme orphelin sans examiner toutes ses dépendances. Un préfixe peut sembler inutilisé selon une vue locale tout en restant nécessaire à un service, à une délégation, à une carte d’adresses ou à une configuration active. Une suppression fondée sur un seul indicateur peut alors transformer une incohérence de données en retrait mondial de route.

La difficulté vient aussi du fait que « supprimer », « retirer » et « détacher » ne sont pas des synonymes. Retirer une annonce BGP change la visibilité du préfixe sur Internet. Détacher un service modifie ce que l’opérateur fera du trafic reçu. Supprimer un enregistrement peut priver le système de la matière nécessaire pour reconstituer l’un ou l’autre. Une automatisation sûre doit connaître ces différences et respecter leur ordre.

Une règle de nettoyage doit donc répondre à plusieurs questions avant toute mutation : le client possède-t-il encore le préfixe ? Une délégation existe-t-elle ? Un service utilise-t-il encore une adresse de cet espace ? L’état souhaité est-il annoncé ou retiré ? Des routeurs l’exportent-ils actuellement ? Une suppression modifierait-elle une dépendance qui n’apparaît pas dans la vue locale du processus ?

Le cas de Cloudflare montre que la notion de « source de référence » doit elle-même être qualifiée. Une base peut être la référence pour l’intention sans être l’unique preuve de la réalité. Si son contenu diverge de l’état des routeurs ou de l’observation externe, la responsabilité impose de détecter et résoudre cette divergence, non de supposer que l’un des niveaux reflète forcément tous les autres.

Pourquoi l’annulation de la modification n’a pas suffi

Annuler le changement initial a arrêté l’apparition de nouvelles mutations. Cette action était nécessaire, mais elle n’était pas l’équivalent d’une restauration complète. Lorsqu’une opération a déjà retiré des routes, supprimé des enregistrements ou détaché des services, revenir au code antérieur n’implique pas que les données détruites réapparaissent.

Il faut distinguer le mécanisme qui produit l’erreur de l’état résultant de cette erreur. Le premier peut être désactivé rapidement. Le second peut persister dans une base, une file de configuration, un serveur de bordure, un routeur ou un système de cache. Même si aucune nouvelle ressource n’est affectée, les ressources déjà modifiées restent dans leur état incorrect jusqu’à une action de réparation.

Cloudflare décrit plusieurs voies de récupération. Certains clients ont pu utiliser un mécanisme en libre-service pour demander une nouvelle annonce de leurs préfixes. L’entreprise a également eu recours à la récupération de données, au rétablissement des rattachements de services et à un déploiement mondial de configuration sur des machines.

La coexistence de ces voies est une indication importante sur la nature de l’incident. Si tous les préfixes avaient simplement conservé leurs enregistrements et leurs dépendances avec un unique indicateur d’annonce incorrect, une seule opération homogène aurait probablement suffi. Le recours à des méthodes distinctes suggère, conformément au récit de Cloudflare, que les préfixes affectés n’étaient pas tous dans le même état après l’arrêt de la mutation.

Le libre-service client peut accélérer le rétablissement lorsqu’un client sait que son préfixe doit être annoncé et dispose encore d’un objet exploitable. Il ne doit cependant pas devenir le mécanisme principal de cohérence. Le fournisseur contrôle la plateforme qui a réalisé la mutation, possède la vue la plus large des dépendances et peut comparer les états internes aux configurations déployées. Il lui revient donc de rechercher systématiquement les préfixes affectés, y compris ceux dont les clients ne se manifestent pas immédiatement.

Un retour arrière robuste doit comporter une voie de restauration indépendante de la donnée qu’il risque de détruire. Si la seule procédure de retour dépend de l’enregistrement supprimé par le changement, elle ne constitue pas une véritable protection. Des journaux immuables, des instantanés, des manifestes de mutation et une cartographie des dépendances peuvent permettre de reconstituer l’état antérieur sans se fier à la couche endommagée.

L’impact : une perte de chemin avant l’application

Pour les services dépendant des préfixes retirés, Cloudflare a cessé d’attirer le trafic. L’effet visible pour les utilisateurs pouvait être un échec de connexion ou un délai d’attente plutôt qu’une page d’erreur générée par l’application. Le paquet n’atteignait pas nécessairement un composant capable de répondre.

Le périmètre décrit comprend des configurations liées à des services de diffusion et de sécurité, à Spectrum, à Dedicated Egress et à Magic Transit. Il ne faut pas en déduire que tous les clients de ces produits ont été touchés, ni que chaque préfixe affecté utilisait toutes ces fonctions. La formulation prudente est que l’incident a concerné des configurations dépendant de l’annonce des préfixes retirés.

Un point particulier concerne 1.1.1.1. Le site web public associé a rencontré des erreurs, tandis que le service de résolution DNS continuait à répondre aux requêtes. Cette distinction empêche de transformer l’incident en panne générale du résolveur. Une page web et un service DNS peuvent partager une marque sans dépendre exactement des mêmes préfixes, chemins ou composants.

Elle rappelle également qu’une mesure fondée sur un seul point de terminaison peut produire un diagnostic trompeur. Tester la page de présentation d’un service ne prouve pas que le protocole principal est indisponible. Inversement, recevoir une réponse du résolveur ne prouve pas que les autres services de la plateforme sont joignables.

Le dossier public ne chiffre pas les pertes commerciales, les volumes de trafic abandonnés ou le nombre de personnes touchées. Il ne nomme pas les clients concernés. Une analyse responsable doit s’arrêter à cette limite. Elle peut expliquer que le retrait d’un préfixe interrompt la joignabilité de services dépendants ; elle ne peut attribuer un préjudice financier précis sans données supplémentaires.

Six couches de preuve qui ne doivent jamais être confondues

Le principal enseignement de l’incident est qu’un préfixe possède plusieurs vérités opérationnelles. Elles peuvent concorder pendant des années, puis diverger en quelques secondes sous l’effet d’une automatisation.

1. L’autorité enregistrée. Les informations du registre établissent la relation officielle avec la ressource. Elles sont indispensables pour empêcher l’appropriation arbitraire d’un espace d’adressage, mais elles ne disent rien sur sa visibilité actuelle.

2. L’autorisation de routage. Les objets IRR, les ROA et la lettre d’autorisation donnent des indications sur l’origine attendue et la permission accordée à l’opérateur. Une autorisation correcte peut coexister avec l’absence totale d’annonce.

3. Le rattachement au compte et au service. Le fournisseur doit savoir quel compte contrôle le préfixe, quelles délégations s’appliquent et quel service doit recevoir le trafic. Une route visible sans rattachement correct peut attirer des paquets sans produire le résultat attendu.

4. L’intention d’annonce. Le système de contrôle conserve un état souhaité : annoncé ou retiré. Cet état sert à piloter l’infrastructure, mais il n’est qu’une instruction tant que son déploiement n’a pas été vérifié.

5. L’état des routeurs et de la bordure. Les configurations actives montrent ce que les équipements sont censés exporter ou accepter. Elles doivent être examinées sur un ensemble suffisamment représentatif, car un déploiement partiel peut créer des différences géographiques.

6. L’observation extérieure. Internet voit des routes, des chemins et des changements de joignabilité. Les collecteurs externes et les sondes distribuées fournissent une preuve indépendante de l’effet réel. Ils ne révèlent pas nécessairement toute la configuration interne, mais ils empêchent qu’un état déclaré soit confondu avec un résultat mondial.

Une opération peut passer les contrôles d’une couche tout en échouant sur une autre. Une ROA peut rester valide alors que la route disparaît. Une route peut rester visible alors que le service associé a été détaché. Une base peut afficher « annoncé » tandis qu’un groupe de routeurs a reçu une configuration de retrait. Un test local peut réussir alors qu’une partie d’Internet ne dispose plus de chemin.

La responsabilité commence par le refus de réduire cette chaîne à un indicateur unique. Elle exige une preuve de concordance et un traitement explicite des exceptions.

Ce que la documentation actuelle permet — et ne permet pas — d’affirmer

La documentation actuelle de Cloudflare décrit le vocabulaire public de BYOIP : enregistrement d’un préfixe, validation de propriété, objets IRR, état RPKI, ASN d’origine, lettre d’autorisation, rattachements de services, cartes d’adresses, délégations et état annoncé ou retiré d’un objet de préfixe BGP.

Ce vocabulaire aide à comprendre les contrôles qui devraient entourer le cycle de vie d’un préfixe. Il ne constitue pas une preuve du fonctionnement exact du sous-processus de février 2026. Une documentation actuelle peut avoir évolué depuis l’incident ; elle peut aussi présenter une interface stable sans exposer les traitements internes, les bases utilisées, les files de déploiement ou les mécanismes de récupération.

Il serait donc imprudent d’en déduire une technologie de base de données, un fournisseur de routeurs, une séquence précise de commandes ou l’identité des équipes intervenues. Ces éléments ne figurent pas dans le dossier. Ils ne sont d’ailleurs pas nécessaires pour évaluer le problème de contrôle : quelle que soit la technologie, une suppression automatisée doit vérifier les dépendances et disposer d’une voie de restauration.

La documentation sur l’annonce dynamique explique qu’un retrait met fin à l’annonce de Cloudflare et que l’acheminement dépend alors de l’existence éventuelle d’une autre route. Cette description clarifie pourquoi certains préfixes peuvent devenir injoignables : retirer Cloudflare ne fait pas apparaître automatiquement un autre chemin.

La documentation consacrée au retrait sûr recommande une séquence ordonnée : établir une annonce native de même longueur, observer la convergence, puis retirer l’annonce Cloudflare. Cette procédure s’adresse à une opération contrôlée du client et ne prouve pas le détail de l’incident interne. Elle fournit néanmoins un principe utile : une mutation de routage doit être précédée par la vérification d’un chemin de remplacement et suivie par l’observation de la convergence réelle.

Ce que les RFC établissent

Les RFC de l’IETF définissent les limites du protocole, non la configuration privée de Cloudflare.

La spécification BGP décrit notamment l’annonce et le retrait d’informations de joignabilité. Elle permet d’expliquer comment la disparition d’une route peut supprimer un chemin vers un préfixe. Elle ne peut pas établir pourquoi une plateforme privée a choisi cet état ni quelles machines ont reçu une configuration donnée.

L’architecture RPKI fournit un cadre de certification pour les ressources de numérotation. La validation de l’origine permet à un réseau de comparer l’origine observée d’une route avec l’autorisation publiée. Le protocole entre caches RPKI et routeurs décrit comment les données de validation peuvent être distribuées. Aucun de ces mécanismes n’oblige un opérateur autorisé à continuer d’annoncer un préfixe.

Cette limite est décisive dans le cas présent. Un préfixe peut conserver une ROA parfaitement valide tout en disparaissant des tables de routage mondiales si l’opérateur cesse de l’annoncer. La validation d’origine répond à la question de la légitimité de l’origine observée ; elle ne garantit pas l’existence de l’annonce.

Les RFC relatives aux fuites de routes classent des situations où des annonces sont propagées au-delà de relations prévues. Les rôles BGP et le mécanisme Only-to-Customer visent à renforcer les politiques destinées à prévenir de telles fuites. Le récit de Cloudflare ne décrit pas ce scénario. Il fait état du retrait de préfixes légitimes par le propre système de contrôle de l’entreprise. Employer l’étiquette « fuite de routes » masquerait donc le mécanisme réel.

Les RFC ne prouvent pas davantage l’efficacité des mesures correctives annoncées. Elles offrent des définitions communes pour examiner les annonces, retraits, origines et politiques. Vérifier une amélioration interne nécessite des preuves spécifiques au déploiement et aux exercices réalisés par l’opérateur.

La réconciliation comme obligation centrale

Une plateforme BYOIP devrait pouvoir répondre, pour chaque préfixe, à une série de questions simples mais reliées :

  • Quelle entité détient ou contrôle la ressource ?
  • Quelle autorisation permet à l’opérateur de l’annoncer ?
  • Quel compte et quelles délégations s’appliquent ?
  • Quels services et quelles cartes d’adresses dépendent du préfixe ?
  • L’état voulu est-il annoncé ou retiré ?
  • Quels équipements ont reçu la configuration correspondante ?
  • Quelles annonces des routeurs sont réellement visibles ?
  • Que voient les collecteurs et les utilisateurs depuis l’extérieur ?
  • Le mécanisme de retour peut-il restaurer chaque couche, y compris après une suppression ?

La valeur de ce contrôle réside moins dans la réponse isolée à chaque question que dans la comparaison entre les réponses. Si l’intention est « annoncé » mais qu’aucune route n’est observée, le système doit ouvrir une exception. Si les routeurs exportent le préfixe alors qu’aucun service n’y est rattaché, une autre exception est nécessaire. Si une suppression est demandée alors qu’une dépendance active subsiste, la mutation doit être bloquée.

Cette réconciliation doit également être temporelle. Un état cohérent hier ne garantit rien après une modification. Les preuves doivent être associées à l’opération, à son heure, à son groupe de ressources et à la version de configuration réellement déployée. Sans cet ancrage, un opérateur peut montrer des enregistrements exacts qui ne correspondent pas au moment où le service a échoué.

Des simulations exactes, et non des estimations globales

Avant une mutation susceptible de retirer ou supprimer des préfixes, une simulation doit énumérer les objets concernés. Elle ne devrait pas se limiter à annoncer qu’un certain nombre d’enregistrements seront modifiés. Pour chaque préfixe, elle doit préciser la raison de son éligibilité, ses dépendances, son état voulu, son état observé et l’action prévue.

Une simulation « exacte » est particulièrement importante pour les opérations de nettoyage. Les erreurs de classification surviennent souvent dans les cas minoritaires : délégations, rattachements indirects, migrations incomplètes, objets anciens encore actifs ou divergences entre la base centrale et les équipements. Un simple total peut sembler raisonnable tout en dissimulant quelques suppressions catastrophiques.

Le manifeste de simulation doit être figé avant l’exécution. Si la requête qui sélectionne les objets est recalculée pendant le déploiement, la cohorte peut changer sous l’effet des mutations précédentes. L’opérateur ne sait alors plus si l’ensemble exécuté correspond à celui qu’il a examiné.

Les critères de sélection doivent également être expliquables. Pour chaque préfixe, le système devrait pouvoir montrer quelle condition l’a placé dans la cohorte. Cette explication permet aux spécialistes du routage, aux responsables du service et aux équipes d’assistance de repérer des hypothèses incorrectes avant qu’elles atteignent le réseau.

Protéger les suppressions en comprenant les dépendances

Une protection efficace contre la suppression ne se résume pas à une confirmation manuelle. Elle doit interroger le graphe de dépendances.

Un préfixe ne devrait pas être supprimé ou retiré si un service actif, une délégation, une carte d’adresses, une configuration de transit ou une intention d’annonce le référence encore. La règle doit aussi examiner les dépendances dérivées, pas seulement les liens directs. Une adresse rattachée à un service peut dépendre d’un préfixe sans que la table consultée par le processus de nettoyage ne contienne ce lien sous une forme évidente.

Les opérations destructrices méritent une séparation des pouvoirs techniques. Le composant qui classe un objet comme obsolète ne devrait pas être le seul à autoriser sa suppression et à confirmer le succès. Une seconde vue, construite à partir de données différentes ou d’un calcul indépendant, peut bloquer une mutation lorsque les deux interprétations ne concordent pas.

La suppression définitive devrait suivre une période de quarantaine. Pendant cette période, l’objet peut être marqué comme candidat au retrait sans perdre ses dépendances ni ses informations de restauration. Une alerte peut être envoyée, les annonces externes observées et le service vérifié. Si un conflit apparaît, l’opération est annulée sans reconstruction complexe.

Cohortes limitées et canaris représentatifs

Les changements touchant les ressources de numérotation ne devraient pas être déployés d’un seul mouvement sur une population importante. Une cohorte limitée réduit le rayon d’impact, mais sa taille ne suffit pas : elle doit être représentative.

Un canari composé uniquement de préfixes simples, récemment créés et sans délégation ne teste pas les cas les plus risqués. L’échantillon devrait comprendre différentes longueurs de préfixes, divers services, des délégations, plusieurs états antérieurs, des objets anciens et des configurations dont les dépendances ont évolué.

Le passage d’une cohorte à la suivante doit dépendre de critères objectifs : aucun retrait inattendu, aucune disparition de rattachement, conformité entre l’intention et les routeurs, observation externe correcte et absence d’augmentation anormale des demandes de rétablissement. Un simple délai sans alerte ne constitue pas une preuve suffisante.

Il faut aussi prévoir un budget maximal de mutations. Si une opération censée ne concerner que quelques objets commence à produire des centaines de changements, elle doit s’arrêter automatiquement. Le fait qu’environ 1 100 préfixes aient été retirés avant l’arrêt de la modification souligne l’importance d’une limite indépendante du processus initiateur.

Un retour arrière indépendant et complet

Le retour arrière doit être conçu avant l’exécution. Il ne doit pas seulement remettre en place l’ancienne version du programme ; il doit restaurer les données et l’état réseau.

Pour chaque mutation, un journal devrait conserver l’ancien état du préfixe, ses rattachements, son intention d’annonce et les versions de configuration déployées. Ce journal doit rester accessible même si le composant principal ou son modèle de données est endommagé.

Une restauration complète exige ensuite plusieurs vérifications : l’enregistrement existe de nouveau, le service est rattaché, l’intention est « annoncé », la configuration a atteint les équipements, l’annonce est exportée et des observateurs externes voient le préfixe. Le succès d’une requête interne ne suffit pas.

Le retour arrière doit enfin être exercé. Une procédure non testée peut échouer précisément dans le cas qu’elle est censée traiter, notamment si elle dépend d’identifiants supprimés ou d’un ordre de restauration non documenté. Les exercices doivent inclure la perte partielle d’état, pas seulement l’annulation propre d’une transaction intacte.

Les améliorations annoncées et la question de leur efficacité

Le compte rendu de Cloudflare présente des mesures d’amélioration. Elles doivent être attribuées à l’entreprise comme des engagements ou des changements annoncés, et non décrites comme une efficacité déjà démontrée de manière indépendante.

Une mesure corrective est crédible lorsque l’opérateur peut montrer le risque précis qu’elle réduit, la façon dont elle aurait interrompu l’incident observé et les résultats d’un test représentatif. Par exemple, une protection contre la suppression devrait démontrer qu’un préfixe encore lié à un service ne peut pas être classé comme inutilisé. Un mécanisme de cohorte devrait montrer qu’un retrait inattendu bloque automatiquement l’étape suivante.

La distinction entre annonce et preuve est importante. Publier une liste d’actions améliore la transparence, mais ne permet pas à un observateur extérieur de savoir si les protections couvrent toutes les dépendances, si les canaris représentent les cas complexes ou si un retour arrière restaure les états supprimés.

Une vérification actuelle demanderait donc des éléments postérieurs à l’incident : résultats d’exercices, alertes déclenchées, écarts détectés, temps de restauration et exemples de réconciliation. En leur absence, la conclusion doit rester bornée : les contrôles ont échoué pendant cet incident ; Cloudflare a décrit des améliorations ; leur efficacité présente n’est pas établie par les seules sources disponibles.

Communication et preuve de rétablissement pour les clients

Dans une panne de routage, le message « service rétabli » peut recouvrir des réalités différentes. Certains préfixes peuvent être de nouveau annoncés alors que leurs services restent mal associés. D’autres peuvent fonctionner depuis certaines régions sans être visibles partout. Une communication utile doit préciser le niveau de rétablissement.

Pour chaque client affecté, une preuve de récupération pourrait inclure le préfixe concerné, l’heure de la nouvelle annonce, l’état de la ROA, l’ASN d’origine observé, le rattachement de service rétabli, la portée géographique des observations et les éventuelles actions encore requises.

Le libre-service est utile lorsque le client peut relancer une annonce, mais il crée aussi un risque de transfert implicite de responsabilité. Un client ne devrait pas avoir à découvrir seul qu’une automatisation du fournisseur a retiré sa route. L’opérateur doit identifier la cohorte complète et confirmer la restauration de ceux qui n’ont pas utilisé le canal de récupération.

La transparence temporelle compte également. La divergence entre 17 h 48 et 17 h 56 montre pourquoi les jalons doivent distinguer la première mutation, le début de l’impact confirmé, la détection, l’arrêt des nouvelles mutations, la première restauration massive et la récupération du dernier groupe connu.

Une grille de responsabilité pour le cycle de vie des préfixes

Une évaluation pratique peut s’appuyer sur dix contrôles.

  1. Inventaire vérifiable. Chaque préfixe possède une identité stable reliant registre, compte, délégation, autorisation, services et annonce.

  2. Intention explicite. L’état annoncé ou retiré est enregistré séparément de l’autorité administrative.

  3. Dépendances consultables. Toute opération destructive énumère les services, adresses et configurations qui dépendent du préfixe.

  4. Simulation précise. La cohorte et les mutations prévues sont figées et examinables avant exécution.

  5. Limite d’impact. Un plafond indépendant arrête l’opération si le nombre ou le rythme des mutations dépasse les attentes.

  6. Canaris représentatifs. Les cas complexes sont inclus avant tout élargissement.

  7. Observation du déploiement. La plateforme vérifie que l’intention centrale correspond à l’état des routeurs et de la bordure.

  8. Observation extérieure. Des mesures indépendantes confirment la visibilité du préfixe et la joignabilité du service.

  9. Restauration autonome. Les données nécessaires au retour arrière survivent à la suppression qu’elles doivent réparer.

  10. Preuve de clôture. Le rétablissement n’est déclaré qu’après réconciliation de l’autorité, du rattachement, de l’intention, du déploiement et de l’observation.

Cette grille ne présume ni faute juridique ni négligence. Elle transforme simplement une promesse de fiabilité en questions dont les réponses peuvent être vérifiées.