Résumé

  • Une commande de maintenance a coupé les liaisons du réseau central. Les serveurs DNS fonctionnaient toujours, mais n'étaient plus joignables depuis internet.
  • La remise en service a demandé de retrouver l'accès aux équipements, puis de maîtriser le redémarrage. Les horaires observés de l'extérieur ne racontent pas toute cette opération.

Le réseau revient. Peut-on aussitôt tout rallumer ? Pour Facebook, le 4 octobre 2021, la réponse était non. Après avoir rétabli ses liaisons, l'entreprise devait encore éviter qu'un afflux brutal de trafic et de demande électrique transforme le redémarrage en nouvelle difficulté. La panne avait une seconde épreuve : la sortie de panne.

Ce détail, tiré du récit publié par les ingénieurs, change la lecture d'un incident souvent résumé à quelques heures d'indisponibilité. Entre « le réseau répond » et « le service fonctionne », il restait du travail.

Des serveurs en état de marche, mais hors d'atteinte

Au départ, une opération de maintenance devait mesurer la capacité disponible sur le réseau central reliant les centres de données. Selon l'entreprise, la commande a au contraire coupé ces liaisons. Un outil de contrôle aurait dû l'arrêter ; un défaut logiciel l'en a empêché.

La suite explique pourquoi un problème interne a pu rendre les services si difficiles à trouver. Les serveurs DNS traduisent les noms des services en adresses utilisables. Quand ils n'ont plus pu joindre les centres de données par le réseau central, ils ont retiré leurs annonces BGP : les indications de route que les réseaux échangent pour acheminer le trafic.

Les serveurs DNS n'étaient pas nécessairement à réparer. Ils continuaient à fonctionner. C'était le chemin pour les atteindre qui avait disparu. Pour l'internaute dont l'application ne s'ouvre plus, la nuance est invisible ; pour comprendre le rétablissement, elle est essentielle.

Il fallait aussi retrouver la porte d'entrée

Les ingénieurs ne disposaient plus de leurs accès habituels ni de l'accès de gestion séparé, dit « hors bande ». L'absence de DNS a également perturbé des outils internes d'investigation. Il ne faut pas raccorder ces deux faits par une cause que le rapport ne donne pas : il ne démontre pas que le DNS a, à lui seul, fait tomber l'accès hors bande.

Des équipes ont été envoyées sur place pour rétablir l'accès. Les protections physiques et informatiques ont compliqué l'entrée et les interventions, explique l'entreprise. Le récit ne permet toutefois ni d'isoler un temps de trajet ni de réduire toute la réparation à l'arrivée d'un technicien devant une armoire.

Une fois les liaisons rétablies, les services ont dû revenir avec précaution. Les exercices de perturbation déjà menés ont aidé, même si la perte complète du réseau central mondial n'avait pas été répétée. La capacité à redémarrer se jouait donc aussi après le retour de la connexion.

Ce que voit l'horloge extérieure

Cloudflare a observé une forte activité de routage vers 15 h 40 UTC, puis le retrait des routes des préfixes DNS à 15 h 58. D'autres préfixes Facebook restaient annoncés. Ce constat décrit une disparition ciblée de routes cruciales, pas celle de toutes les adresses de l'entreprise.

Vers 21 heures, les annonces BGP ont repris ; leur activité a culminé à 21 h 17. À 21 h 28, la reconnexion mondiale et la résolution DNS semblaient rétablies. Les applications pouvaient encore avoir besoin de temps.

Entre 15 h 58 et 21 h 28, il s'écoule 330 minutes. Cette soustraction ne mesure ni le déplacement des équipes ni l'indisponibilité exacte de chaque service pour chaque utilisateur. De même, les dix-huit minutes séparant les deux premiers repères ne constituent pas une fenêtre de détection interne démontrée. Cloudflare voyait les effets sur internet, pas les écrans des ingénieurs de Facebook.

Les tentatives répétées des applications et des résolveurs ont accru la charge DNS ailleurs. Cela n'a pas arrêté tout internet : la plupart des requêtes du résolveur 1.1.1.1 de Cloudflare restaient traitées en moins de dix millisecondes, malgré un allongement des réponses les plus lentes.

La panne laisse ainsi une image moins spectaculaire, mais plus instructive, que celle d'un interrupteur mondial. Il fallait retrouver le chemin vers des machines, rétablir leurs liaisons, puis remettre les services à la portée des utilisateurs. Ces sources expliquent l'incident de 2021 ; elles ne décrivent pas à elles seules l'architecture actuelle de Meta Platforms ni l'exécution de ses changements ultérieurs.

Rectification du 21 octobre 2026 : les liens de causalité entre DNS et accès de gestion ont été précisés. Les horaires extérieurs ne sont plus assimilés à un temps de trajet ou à une durée universelle de panne ; les conclusions non étayées sur l'architecture actuelle ont été retirées.