Des drones mettent hors service un troisième datacenter de Yandex, à Vladimir

Des drones ont frappé un troisième datacenter de Yandex, cette fois à Vladimir. Selon CNews, le site est complètement hors service. L'entreprise exploite cinq centres de données : trois sont donc désormais physiquement touchés, soit plus de la moitié de l'infrastructure. La veille, une clause a été ajoutée aux conditions d'utilisation des services de Yandex : l'entreprise y décline toute responsabilité envers ses clients en cas d'indisponibilité des services lors d'attaques de drones.

Ce que l'on sait à ce stade

La source fournit peu de détails, et il faut le garder à l'esprit. Le message ne contient aucune confirmation publique de l'ampleur des dégâts, des délais de remise en service ni de la liste des services touchés. La formule « complètement hors service » vient du média, pas de la documentation technique de l'opérateur. Voici donc uniquement ce que l'on peut considérer comme établi d'après CNews :

• Site : le datacenter de Yandex à Vladimir.
• Statut : complètement hors service.
• Nombre total de centres de données de l'entreprise : 5.
• Déjà touchés par des attaques : 3.
• Modification des conditions d'utilisation : ajout d'une clause d'exonération de responsabilité pour les interruptions de service lors d'attaques de drones.

L'article ne précise ni les dates ni la localisation des deux frappes précédentes. On ignore également quels services tournaient sur le site de Vladimir, or cela détermine si les utilisateurs ont même remarqué la panne.

Une clause du contrat comme signal

L'amendement aux conditions d'utilisation est plus intéressant que la frappe elle-même. Presque tous les services cloud et internet prévoient des clauses de force majeure : catastrophes naturelles, coupures d'électricité, actes de tiers. Mais la mention explicite des drones montre que l'entreprise ne voit plus ces événements comme un risque ponctuel, mais comme un facteur récurrent. Les juristes rédigent ce type de clause lorsque la probabilité d'un événement cesse d'être théorique.

Pour un utilisateur ordinaire de Yandex, cela ne change presque rien : le courrier, les cartes et la recherche ne prévoient de toute façon aucune compensation financière en cas d'indisponibilité. Pour les entreprises, le tableau est différent. Si une société construit son produit sur Yandex Cloud ou d'autres services de plateforme et compte sur un SLA assorti de pénalités, la référence aux attaques de drones peut rendre ces pénalités impossibles à obtenir. Les détails dépendent du contrat concret : les conditions d'utilisation et les conditions pour entreprises ne coïncident pas toujours, et il faut le vérifier.

Pourquoi un datacenter est si vulnérable

Un datacenter est un grand site fixe dont l'adresse est connue. Il a besoin d'une alimentation électrique puissante, d'un système de refroidissement et de liaisons réseau, et chacun de ces éléments peut être neutralisé sans toucher directement les salles de serveurs. La tolérance aux pannes repose pour cela sur la redondance géographique : les données et la charge sont dupliquées entre les sites. Quand trois sites sur cinq sont indisponibles, la marge de sécurité se réduit à deux. Même avec une bonne réplication, la charge sur les capacités restantes augmente, de même que le risque de dégradation et le temps de remise en service après le prochain incident.

Il y a aussi un volet d'ingénierie. Basculer la charge d'un site perdu exige des ressources de calcul et de stockage disponibles, et celles-ci ne sont pas infinies en situation de pénurie de serveurs et de restrictions sur les livraisons de matériel. Remplacer rapidement et à volume égal les capacités perdues est difficile.

Que faire pour les équipes qui dépendent de Yandex

Il faut d'abord lire la version en vigueur des conditions d'utilisation et du contrat entreprise, et vérifier ce qu'elles disent exactement de la force majeure et des compensations. Il faut ensuite passer l'architecture en revue. Les données critiques et les sauvegardes doivent se trouver dans au moins deux zones géographiques indépendantes, et idéalement aussi chez un autre fournisseur.

Les scripts de bascule doivent être testés régulièrement en conditions réelles, et pas rester un simple document. Une entreprise dont chaque heure d'indisponibilité coûte de l'argent a intérêt à calculer à l'avance son délai de reprise acceptable (RTO) et le volume de perte de données tolérable (RPO), puis à les comparer honnêtement à ce que le fournisseur est réellement en mesure de garantir. Si l'écart est important, une architecture multicloud coûtera moins cher qu'une seule mauvaise semaine sans service.