Des frappes de drones ferment deux centres de données Yandex et dégradent le cloud russe

8, 9 et 11 octobre 2026. Trois centres de données Yandex sont frappés par des drones en trois nuits : Sasovo le 8, Kaluga le 9, Vladimir le 11. Deux à l’arrêt. Les sites de Sasovo et de Vladimir sont complètement arrêtés, celui de Kaluga fonctionne en mode dégradé. « Mode urgence ». La page de statut de Yandex qualifie la situation de « mode urgence » et recommande à ses clients d’utiliser « tout autre plan de reprise d’activité alternatif ». Pourquoi c’est important : pour la première fois à cette échelle, la disponibilité d’un grand cloud est interrompue non par une panne logicielle ou une cyberattaque, mais par des frappes physiques sur ses bâtiments.

Une panne qui n’a rien d’un incident classique

Le scénario ne ressemble à aucun des incidents cloud habituels. Pas de mauvaise configuration, pas de cascade de dépendances, pas de ransomware : des drones ont physiquement endommagé des data centers. Yandex confirme trois sites touchés, aucun blessé, et des coupures de service pour ses clients, dont certains ne parviennent plus à accéder à leurs fichiers stockés sur Yandex Disk. Les attaques sont attribuées par la BBC aux forces ukrainiennes, dans le cadre d’un conflit où l’infrastructure numérique est devenue une cible militaire à part entière.

Les symptômes côté client sont ceux d’une panne de stockage : des utilisateurs signalent depuis le 8 octobre des vignettes manquantes sur leurs sauvegardes, des erreurs HTTP 302, 504 et 500 au téléchargement de fichiers déposés auparavant. La page de statut liste Console, API, IAM, Container Registry, les bases de données, le stockage S3 et Kubernetes comme disponibles avec des problèmes de performance ou de disponibilité ; Compute, AI Studio et les services de sécurité sont « partiellement disponibles », et Monium reste hors ligne. Yandex ne donne pas de calendrier de rétablissement fiable et ne précise pas si des données ont été irrémédiablement perdues.

Ce que ça change pour l’architecture cloud

La résilience cloud a longtemps été pensée en termes de redondance logique : plusieurs zones de disponibilité dans une même région, de la réplication synchrone, des bascules automatiques. L’épisode Yandex rappelle que cette redondance ne protège pas contre une menace qui frappe le bâti — le bâtiment, l’alimentation, le refroidissement — ni contre une menace qui vise plusieurs sites d’une même région en quelques jours.

Yandex étant surnommé « le Google russe », une large part de l’infrastructure Internet du pays — services publics et entreprises comprises — repose sur ses services. Quand deux de ses trois centres de données d’une région tombent, la « redondance » interne ne suffit plus : c’est la capacité du client à basculer hors de la région, voire hors du fournisseur, qui fait la différence. La recommandation de Yandex elle-même l’admet : « nous considérons la configuration de ressources restante comme instable » et invitons à utiliser « d’autres plans de reprise d’activité ».

La leçon architecturale tient en trois points. La géographie est un paramètre de disponibilité : répliquer sur plusieurs régions éloignées, pas seulement sur plusieurs zones d’une même région. Le fournisseur est un point de défaillance unique : une stratégie multi-cloud, même minimale, évite qu’une seule enseigne emporte tout un périmètre. Le test de reprise doit inclure le physique : un plan de reprise d’activité qui suppose que le fournisseur reste joignable et que ses équipes restent opérationnelles ne tient pas face à une crise qui frappe aussi ses bâtiments et ses équipes.

Ce que trois centres de données qui tombent veulent dire, concrètement

Les trois sites touchés ne sont pas des salles annexes. Yandex est le premier fournisseur cloud de Russie, et ses data centers hébergent à la fois les services grand public — Yandex Disk, la messagerie, la cartographie — et des charges d’entreprise. Quand Sasovo et Vladimir s’arrêtent et que Kaluga tourne en mode dégradé, c’est la capacité de calcul d’une région entière qui disparaît d’un coup. Les symptômes remontés par les clients le montrent : dès le 8 octobre, des sauvegardes perdent leurs vignettes, des téléchargements échouent en HTTP 500, et des services comme Monium restent hors ligne plusieurs jours.

La comparaison avec des incidents physiques passés est instructive. En mars 2021, l’incendie du centre de données OVHcloud de Strasbourg a détruit un site entier et une partie de ses données, rappelant que la redondance « logique » ne survit pas toujours à la perte du bâti. La différence avec Yandex est de degré, pas de nature : ici, ce n’est pas un accident, mais des frappes ciblées répétées sur plusieurs sites d’une même région en l’espace de quatre jours. Un plan de reprise qui réplique dans la même région — ou qui suppose que le fournisseur reste opérationnel — ne couvre pas ce scénario. La seule parade qui tient est la dispersion géographique et la capacité à basculer vers un fournisseur ou une infrastructure hors de portée du même événement.

Pourquoi la « guerre des data centers » ne restera pas un cas isolé

L’épisode s’inscrit dans un basculement plus large. Depuis le début du conflit, les infrastructures numériques — câbles, centrales, data centers — sont passées du statut de « cible d’opportunité » à celui de cible stratégique. Ars Technica publie le même jour un article au titre explicite : « La Russie n’était pas prête pour la guerre des data centers qu’elle a lancée avec l’Ukraine ». La conclusion dépasse le conflit : les data centers sont devenus des infrastructures critiques au même titre que les réseaux électriques, et leur protection physique relève désormais de la politique de disponibilité, pas de la simple logistique immobilière.

Pour un RSSI ou un SRE hors zone de conflit, la conséquence est plus sobre mais réelle : les scénarios de perte de site — incendie, inondation, dégât physique, sabotage — doivent être réintégrés dans les plans de continuité, avec des seuils de bascule testés, des sauvegardes hors région et une dépendance assumée envers plusieurs fournisseurs. La panne Yandex est le rappel le plus net depuis des années que le « cloud » est d’abord du béton, des kilowatts et des hommes, avant d’être des API.

Verdict

Si vous exploitez des charges en production sur un cloud unique — et surtout si vos données de sauvegarde vivent dans le même fournisseur que vos charges — réévaluez dès maintenant votre exposition : une réplication vers une région éloignée ou un second fournisseur, même partielle, change radicalement l’issue d’une perte de site. Si vous opérez un service critique, testez un scénario où votre fournisseur est lui-même indisponible, pas seulement une de ses zones : c’est le scénario que Yandex vient de vivre, et la plupart des plans de reprise ne le couvrent pas. Si vous dépendez d’un fournisseur national ou régional, interrogez sa résilience physique — redondance géographique, autonomie énergétique, plans de crise — comme vous interrogeriez ses SLA logiques. La leçon tient en une phrase : un cloud n’est jamais plus fiable que le bâtiment qui l’héberge, et un bâtiment se frappe.

Références

• BleepingComputer — Yandex confirms service outage as users lose access to cloud files (12 octobre 2026)
• The Record — Ukraine strikes third Yandex data center, disrupting digital services across Russia (12 octobre 2026)
• Ars Technica — Russia was not ready for the data center war it started with Ukraine (octobre 2026)
• BBC News — coverage of the Yandex data center attacks (octobre 2026)