Cloud et IA : trois centres de données de Yandex frappés en quatre jours

Le « cloud » donne l’impression d’un service sans lieu. En quatre jours, trois centres de données exploités par Yandex ont rappelé exactement le contraire. Derrière une plateforme numérique se trouvent des serveurs, des groupes électriques, des circuits de refroidissement, des fibres et des équipes capables — ou non — de déplacer rapidement les charges de travail.

Le 11 octobre, Yandex Cloud a annoncé l’arrêt complet de son infrastructure située dans la région russe de Vladimir après une attaque de drones. L’entreprise a fait état de dommages sur le site, sans blessé, et de l’indisponibilité de certains services. Cet incident suivait l’arrêt d’un centre à Sasovo, dans la région de Riazan, le 8 octobre, puis la mise hors service partielle d’un autre site dans la région de Kalouga le 9 octobre.

Reuters et l’Associated Press décrivent ainsi le troisième centre important de Yandex touché en quelques jours. Cette chronologie est établie à partir des déclarations de l’entreprise et des informations disponibles au 11 octobre. L’étendue complète des dégâts, le coût des interruptions et le délai de remise en service de chaque site n’étaient pas encore publics.

Une panne locale qui devient une question stratégique

Yandex est souvent présenté comme l’équivalent russe de Google, mais ses activités dépassent le moteur de recherche : publicité, cartographie, mobilité, services grand public et infrastructure cloud. Ses centres de données hébergent aussi des ressources utilisées pour entraîner et faire fonctionner des systèmes d’intelligence artificielle.

Le site de Sasovo avait une importance particulière. Reuters rapporte qu’il abritait deux des trois supercalculateurs équipés de processeurs Nvidia A100 que Yandex avait dévoilés en 2021 pour l’entraînement de ses modèles, dont YandexGPT. Cette information décrit l’installation connue avant l’attaque. Elle ne permet pas d’affirmer que ces machines ont été détruites ou même directement touchées : Yandex n’a pas précisé leur état.

Cette distinction est essentielle. Un centre de données peut être interrompu parce qu’une partie électrique, un système de refroidissement ou une liaison réseau est endommagé, sans que tous ses serveurs le soient. À l’inverse, un bâtiment encore debout peut rester inutilisable si une dépendance critique manque. Les informations publiques ne permettent donc pas de transformer l’arrêt du site en bilan matériel définitif.

Trois épisodes, des effets différents

À Sasovo, un incendie provoqué, selon Yandex, par une attaque de drone a conduit à la suspension de l’activité. L’entreprise avait alors indiqué que ses principaux services destinés au grand public continuaient de fonctionner, tandis que des clients de Yandex Cloud étaient invités à utiliser d’autres zones de disponibilité.

Le lendemain, Yandex a annoncé qu’un centre de la région de Kalouga avait été partiellement désactivé après une nouvelle attaque. Reuters a rapporté le cas d’une jeune entreprise dont environ 8 000 utilisateurs ne pouvaient plus accéder au service et qui disait ne pas pouvoir joindre sa base de données de secours. Aucune perte de données n’était confirmée à ce moment-là. Yandex a indiqué travailler avec d’autres fournisseurs de cloud afin d’aider des clients à migrer temporairement leurs systèmes.

Pour Kalouga, le président ukrainien Volodymyr Zelensky a confirmé une frappe présentée comme une réponse aux attaques russes. Pour l’incident de Vladimir, les premières sources citées dans cet article rapportent l’annonce d’une attaque de drones par Yandex, sans fournir le même niveau de confirmation indépendante sur son attribution. Il serait donc prématuré de présenter tous les épisodes comme identiques dans leurs circonstances exactes.

Le contexte général ne fait toutefois guère de doute : la guerre entre la Russie et l’Ukraine s’étend depuis longtemps aux infrastructures énergétiques et numériques. Reuters souligne que les deux camps ont visé des centres de données. Le ministre ukrainien de la Transformation numérique a déclaré que son pays déplaçait une partie de ses infrastructures sous terre après des frappes russes. Ces installations deviennent à la fois des actifs économiques, des nœuds de continuité publique et des ressources stratégiques.

L’intelligence artificielle a une géographie

L’IA générative est souvent décrite par ses modèles et ses logiciels. Mais elle dépend d’une chaîne matérielle beaucoup plus longue : puces spécialisées, capacité électrique, refroidissement, connectivité, stockage et bâtiments sécurisés. Plus les modèles sont lourds, plus cette concentration devient visible.

Une entreprise peut distribuer ses applications sur plusieurs machines tout en conservant un point de fragilité : une même zone électrique, un même réseau, un même fournisseur d’identité ou une même sauvegarde. La répétition des attaques contre Yandex montre aussi qu’un plan conçu pour absorber une panne technique isolée peut être mis à l’épreuve par plusieurs incidents rapprochés.

La résilience ne consiste donc pas seulement à posséder une copie des données. Il faut pouvoir l’utiliser depuis une infrastructure indépendante, avec des identifiants encore accessibles, un réseau disponible et une procédure connue des équipes. Le témoignage du client de Kalouga est révélateur : une base annoncée comme sauvegarde n’apporte pas de continuité si elle devient inaccessible au moment de l’incident.

Ce que garantit — et ne garantit pas — le « multi-zone »

Dans sa propre documentation, Yandex Cloud recommande de répartir les ressources entre plusieurs zones de disponibilité. Son exemple d’architecture tolérante aux pannes place des machines et des sous-réseaux dans deux zones et distribue la base de données entre celles-ci. Le principe est standard : si une zone cesse de répondre, une autre doit pouvoir reprendre la charge.

Cette architecture réduit certains risques, mais elle ne les efface pas. Deux zones peuvent partager des dépendances physiques ou opérationnelles. Une attaque simultanée, une panne régionale d’électricité, une erreur de configuration reproduite partout ou la compromission d’un compte central peuvent toucher plusieurs environnements. Passer à un second fournisseur ajoute une séparation possible, mais aussi de la complexité, des coûts et des différences techniques qu’il faut tester avant la crise.

Le National Cyber Security Centre britannique recommande d’examiner la résilience non seulement du centre de données, mais aussi de la zone et de la région, ainsi que les dépendances en énergie, refroidissement et réseau. Il conseille des sauvegardes, une haute disponibilité répartie géographiquement et des exercices réguliers de bascule. Ces recommandations ne concernent pas spécifiquement Yandex ; elles fournissent un cadre utile pour comprendre pourquoi la simple étiquette « cloud » ne suffit pas.

Une leçon pour les organisations africaines

Pour une banque, un média, une administration ou une jeune entreprise africaine, le premier enseignement n’est pas de construire immédiatement plusieurs centres de données. Il est de savoir précisément ce qui se passe lorsque le fournisseur principal devient indisponible.

Un plan réaliste devrait répondre à quelques questions concrètes : où se trouvent les données et leurs copies ? Les sauvegardes sont-elles isolées du compte principal ? Combien de temps l’organisation peut-elle rester à l’arrêt ? Peut-elle restaurer le service ailleurs, et la procédure a-t-elle été testée récemment ? Les contrats précisent-ils le délai de reprise, la restitution des données et la notification d’un incident ?

Pour les systèmes d’IA, il faut ajouter les modèles, les données d’entraînement, les index documentaires et les clés d’accès aux composants à protéger. Un assistant peut paraître disponible alors que sa base documentaire ou son service d’authentification est hors ligne. À l’inverse, maintenir une copie complète de données sensibles dans plusieurs juridictions peut créer de nouveaux risques juridiques et de confidentialité.

Ces pistes sont une analyse éditoriale de MIND AI MEDIA, non l’annonce d’une politique publique africaine. Le bon niveau de redondance dépend de la criticité du service et des moyens disponibles. Une petite structure peut commencer par des sauvegardes indépendantes et des exercices de restauration ; une infrastructure essentielle devra envisager plusieurs zones, plusieurs réseaux et, dans certains cas, plusieurs fournisseurs.

La continuité se vérifie avant la crise

Les trois incidents ne prouvent pas que le cloud serait intrinsèquement fragile ni qu’une architecture particulière aurait échoué dans son ensemble. Ils montrent qu’une plateforme centralisée peut être soumise à des événements physiques répétés et que les conséquences se propagent alors jusqu’aux utilisateurs de ses clients.

La question décisive n’est pas de savoir si une panne surviendra un jour, mais ce que l’organisation peut encore faire lorsqu’elle survient : communiquer, authentifier ses équipes, retrouver une copie, relancer un service et mesurer les données éventuellement perdues.

Les promesses de disponibilité restent nécessaires. Les tests de restauration le sont davantage. L’IA n’échappe pas à cette règle : avant d’être un service abstrait, elle est une infrastructure située quelque part — et donc exposée au monde réel.

Sources et limites

Reuters — arrêt complet du centre de Vladimir après une attaque de drones, 11 octobre 2026.

Associated Press — troisième centre de données de Yandex touché en quelques jours, 11 octobre 2026.

Reuters — arrêt du centre de Sasovo et rôle connu de ses supercalculateurs, 8 octobre 2026.

Reuters — mise hors service partielle du centre de Kalouga et effets sur les clients, 9 octobre 2026.

Yandex Cloud — état de l’incident de Vladimir.

Yandex Cloud — exemple d’architecture tolérante aux pannes.

National Cyber Security Centre — protection et résilience des actifs dans le cloud.

Sources consultées le 11 octobre 2026. Les bilans détaillés, la durée des interruptions et l’état précis des équipements d’IA n’étaient pas publics au moment de la rédaction. Aucun entretien n’a été réalisé pour cet article.