Un incendie à Moscou révèle le point de défaillance unique de l’Internet russe

18 août 2026. Un incendie frappe la centrale thermique n° 20 de Moscou. 21 h, heure de Moscou. La perte de courant atteint MMTS-9, à 1,5 kilomètre de là. Mai 2005. Des ingénieurs avertissaient déjà, sur la liste NANOG, que MSK-IX était un point de défaillance unique. Vingt et un ans plus tard, l’incendie leur a donné raison — et Discord, Steam, Telegram et les opérateurs mobiles du pays sont tombés avec le bâtiment.

Un incendie à 1,5 kilomètre coupe l’Internet d’un pays

L’incident commence vers 21 h, heure de Moscou, le 18 août 2026 : une explosion suivie d’un incendie frappe une installation électrique de la rue Vavilova, dans le district Gagarinski, identifiée par les témoins comme la centrale thermique n° 20. En moins d’une heure, la perte de courant se propage à un bâtiment situé à environ 1,5 kilomètre, au 7 rue Butlerova : le central téléphonique longue distance n° 9 de Moscou, universellement connu sous le nom de MMTS-9 ou « M9 ».

Ce détail géographique change tout. MMTS-9 n’est pas un immeuble de bureaux ordinaire : il héberge le cœur de l’infrastructure de commutation de MSK-IX, le principal point d’échange Internet de Russie. Quand M9 a perdu le courant, ce n’est pas un quartier qui s’est éteint — c’est le tissu de routage de l’Internet russe qui s’est effondré en son centre.

MSK-IX, le point de passage obligé du Runet

MSK-IX, le Moscow Internet Exchange, est le point d’échange dominant de Russie. Fondé en 1995, il connecte 549 réseaux et traitait un trafic de pointe de 7,7 Tbit/s en février 2025, ce qui en fait le 17e plus grand IXP du monde et, de loin, le plus grand de Russie. Son infrastructure de commutation centrale vit à MMTS-9.

Le bâtiment cumule deux fonctions critiques. D’abord l’interconnexion : MMTS-9 héberge 41 opérateurs télécoms, plus que n’importe quel autre datacenter moscovite. Ensuite le DNS : MSK-IX exploite aussi les serveurs de noms faisant autorité pour les domaines de premier niveau .RU et .РФ. Une panne prolongée de M9 n’aurait donc pas seulement coupé le routage entre fournisseurs russes — elle aurait empêché la résolution de tout site en .RU pour les utilisateurs du monde entier.

Le canal Telegram ZaTelekom a été parmi les premiers à nommer la cause, et le média spécialisé SecurityLab a confirmé que les hébergeurs annonçaient « ouvertement » l’isolement de leurs baies à M9.

Pourquoi un seul bâtiment fait tomber tout un pays

Pour comprendre la cascade, il faut revenir au rôle d’un IXP. Quand deux fournisseurs — disons Rostelecom et MegaFon — veulent échanger du trafic, ils ont deux options : payer un opérateur de transit, ou se rencontrer sur un IXP partagé et s’échanger le trafic directement, gratuitement. Le mécanisme technique est BGP : chaque fournisseur annonce ses préfixes sur la matrice de commutation, les autres apprennent ces routes et envoient le trafic en conséquence.

Quand M9 a perdu le courant, chaque session BGP passant par MSK-IX est tombée simultanément. Les fournisseurs qui ne se peeraient que via MSK-IX se sont retrouvés sans chemin direct ; le trafic a dû se réacheminer par des liens de transit payants, dimensionnés pour de faibles volumes, ou a simplement échoué. C’est pourquoi la panne a été nationale plutôt que locale.

Les systèmes de redondance que M9 mettait en avant — quatre transformateurs indépendants et des onduleurs — sont conçus pour les pannes internes d’équipement, pas pour une rupture complète du réseau électrique externe comme celle que produit l’explosion d’un poste.

Un avertissement ignoré depuis 2005

La fragilité n’était pas inconnue : elle était documentée noir sur blanc. En mai 2005, une panne de courant à Moscou avait déjà perturbé MSK-IX, et Michael Dillon, de Radianz, avait écrit sur la liste NANOG que « 80 % du trafic Internet russe passe par MSK-IX » et qu’il n’existait « aucune alternative d’échange à Moscou ». Sa conclusion tenait en une phrase : un point de défaillance unique, « c’est tout simplement une mauvaise conception, qui finira par mordre quelqu’un ».

Vingt et un ans se sont écoulés. En 2024, M9 annonçait avoir épuisé tout son espace de baies et ne plus accepter d’équipement. En mai 2025, IXcellerate et MSK-IX ont lancé un partenariat pour construire un hub télécom distribué, présenté comme une « vraie alternative » — infrastructure qui n’était pas encore opérationnelle au moment de l’incendie.

La logique économique explique l’immobilisme : la concentration sur un IXP est auto-entretenue. Plus il y a d’opérateurs au même endroit, plus il devient avantageux d’y ajouter le sien, ce qui concentre encore le trafic. Le résultat est une architecture en étoile qui accumule des dépendances massives dans un bâtiment vieillissant.

La leçon pour tout architecte réseau

La panne a été visible en quelques minutes : Downdetector a enregistré plus de 1 000 signalements en une heure, concentrés sur Moscou et Saint-Pétersbourg, pour Discord, Steam, Telegram et les opérateurs MegaFon, Beeline, Rostelecom et Lovit. Le registraire Reg.ru a confirmé à TASS que les perturbations du Runet étaient liées à une coupure de courant sur un nœud de communication majeur.

La leçon dépasse largement la Russie. Tout opérateur critique qui concentre l’interconnexion en un seul lieu reproduit le même schéma : un datacenter unique, un IXP unique, une alimentation unique. La résilience ne se décrète pas dans un datacenter — elle se construit par la diversité géographique des points d’échange, des alimentations et des chemins. Les pannes de ce type ne se prévoient pas à l’avance ; elles se paient le jour où l’on découvre qu’on aurait dû les anticiper.

Ce que la résilience exige

La parade n’est pas mystérieuse, elle est juste rarement financée avant l’incident. Elle tient en trois axes.

• Deux points d’échange géographiquement séparés. Un IXP de secours dans une autre ville, ou au moins dans un autre bâtiment avec une alimentation et une connectivité indépendantes, transforme une panne nationale en un simple reroutage.
• Des annonces DNS distribuées. Le fait que MSK-IX cumule l’interconnexion et les serveurs de noms des .RU et .РФ double la surface du point de défaillance. L’anycast sur des sites séparés aurait contenu la panne au seul routage.
• Des chemins de secours testés. Le transit de repli ne sert à rien s’il n’est pas dimensionné pour le trafic national et exercé régulièrement. La redondance se prouve en conditions réelles, pas sur le papier.

Le coût de ces mesures est une fraction du coût d’une heure de panne nationale. Ce qui a manqué au Runet n’est pas la technologie — c’est la décision d’investir dans une redondance dont personne ne voyait l’urgence tant que l’incendie n’était pas allumé.

Verdict

Si vous exploitez une interconnexion critique, ne laissez pas l’économie de réseau décider de la résilience : construisez la diversité géographique avant d’en avoir besoin, avec des points d’échange physiquement séparés, des alimentations indépendantes et des chemins de secours testés.

Si vous dépendez d’un service routé via un IXP unique, cartographiez votre exposition : identifiez le bâtiment, le point d’échange et l’alimentation dont dépend votre trafic, et chiffrez ce qu’une coupure d’une heure ou d’une journée vous coûterait. Le coût d’une redondance est dérisoire face à celui d’une panne nationale.

Références

• Moscow Fire Knocked Russia Offline: One Building Was Russia’s Runet Backbone — TechTimes, 19 août 2026
• Fire and blackouts near a Moscow telecom hub knock Discord, Steam and Telegram offline across Russia — Meduza, 18 août 2026
• Moscow Internet Exchange — Wikipédia
• Archive de la discussion NANOG de 2005 sur MSK-IX
• Transnet 2025 : perspectives sur l’infrastructure télécom russe — IXcellerate