Introduction
Entre le 8 et le 11 octobre 2026, Yandex a perdu trois datacenters en quatre jours. Résultat : 84 services Yandex Cloud déclarés hors ligne, un trafic réseau effondré à 0,4 % de son niveau habituel selon Cloudflare Radar, et une plateforme contrainte d'activer ce qu'elle appelle elle-même un « mode d'urgence ». L'incident, sans précédent à cette échelle pour un fournisseur cloud majeur, offre une leçon d'architecture dont les DSI et responsables d'infrastructure ne peuvent faire l'économie.
La géographie du désastre
Les trois sites touchés se situent dans des régions distinctes autour de Moscou : Sasovo (région de Riazan), Kalouga et Vladimir. Chacun hébergeait des composants critiques de l'infrastructure Yandex Cloud. Le datacenter de Sasovo abritait deux des trois superordinateurs mobilisés pour les projets d'intelligence artificielle de l'entreprise ; sa mise hors service a entraîné la perte immédiate d'une capacité de calcul considérable. Kalouga a été partiellement désactivé le lendemain, avant que Vladimir ne soit complètement arrêté le 11 octobre.
La plateforme ne s'est pas contentée de ralentir — elle a rompu. Les services Yandex Disk, Yandex Documents, ainsi que des applications tierces hébergées sur Yandex Cloud ont basculé dans l'inaccessible. L'entreprise a reconnu que « la configuration d'infrastructure restante est considérée comme instable ».
Ce que révèle la rupture en cascade
Un fournisseur cloud de cette taille devrait, en théorie, absorber la perte d'un ou deux sites grâce à des mécanismes de basculement automatique. Ce n'est pas ce qui s'est produit. Plusieurs facteurs l'expliquent.
D'abord, la concentration géographique : si les sites sont localisés dans un périmètre régional restreint, une perturbation simultanée dans cette zone annule l'effet de la redondance. Le « multi-site » ne protège réellement que si les nœuds sont suffisamment distants et indépendants — sur le plan des alimentations électriques, des réseaux et des conditions physiques.
Ensuite, la vitesse de propagation des défaillances : perdre un site peut déclencher une surcharge sur les survivants, qui finissent par céder à leur tour. C'est précisément le scénario que décrit le passage en mode d'urgence — le système n'a pas basculé proprement, il a cédé progressivement.
Enfin, la dépendance des services tiers : des organisations qui n'opèrent pas elles-mêmes leurs infrastructures se sont retrouvées en panne sans aucun contrôle sur la situation ni aucun levier de remédiation immédiate.
Les questions que tout DSI devrait se poser
L'incident ne pose pas uniquement une question géopolitique. Il pose des questions d'architecture concrètes à toute organisation qui s'appuie sur un fournisseur cloud :
- Quelle est la distribution géographique réelle des zones de disponibilité sur lesquelles reposent vos charges critiques ? Sont-elles vraiment indépendantes, ou simplement dans des bâtiments différents du même campus ?
- Votre plan de reprise d'activité (PRA) a-t-il été testé dans un scénario de perte simultanée de plusieurs zones, pas seulement d'un seul nœud ?
- Vos dépendances vis-à-vis des services managés sont-elles documentées ? Savez-vous précisément quels services tiers alimentent vos applications, et dans quelle région ils sont hébergés ?
- La concentration chez un seul fournisseur ou dans une seule géographie revient à accepter que leur fragilité devienne la vôtre — quelle que soit la cause de l'incident.
Revoir l'architecture avant que l'événement ne la révèle
Les pannes massives révèlent toujours les mêmes lacunes : une redondance théorique jamais mise à l'épreuve, des plans de bascule conçus pour un scénario de défaillance unique, et une cartographie des dépendances incomplète. L'incident Yandex a rendu visible en quelques heures ce que des années d'architecture auraient dû prévenir. Pour les équipes infrastructure, c'est l'occasion de reprendre leurs schémas de résilience — avant que ce soit leur propre plateforme qui serve de démonstration.