Centres de données : la fragilité numérique russe
Les frappes visant Yandex révèlent les risques d’une économie numérique centralisée. Découvrez les enjeux des centres de données et les leçons pour l’Europe.
La guerre des centres de données révèle la fragilité du modèle numérique russe
Une économie numérique peut sembler dématérialisée. Pourtant, derrière chaque moteur de recherche, service de cartographie ou modèle d'intelligence artificielle, il y a des bâtiments, des serveurs, des réseaux électriques et des liaisons télécoms. Quand ces infrastructures sont regroupées, leur efficacité « en temps normal » peut devenir un point de faiblesse en période de conflit.
C'est le risque que pointent des blogueurs pro-Kremlin après des frappes ukrainiennes visant des centres de données de Yandex, le géant technologique russe. D'après les informations relayées par Ars Technica, ces attaques ont entraîné des perturbations de services numériques et touché plusieurs grands sites en quelques jours. Pour autant, on ne dispose pas d'un bilan technique complet pour chaque installation.
L'épisode s'inscrit aussi dans une escalade plus large : la Russie a d'abord ciblé des infrastructures numériques ukrainiennes, notamment des centres de données et des réseaux mobiles. La riposte rappelle une question qui dépasse largement le cas russe : dans quelle mesure les services numériques tiennent-ils quand leurs infrastructures physiques sont abîmées ? Voilà ce que cet épisode permet de comprendre, et ce que les organisations européennes peuvent en tirer.
Une infrastructure numérique est aussi une cible physique
Le terme « cloud » donne parfois l'impression que les données et les applications « flottent » dans un espace abstrait. Dans la réalité, le cloud repose sur des centres de données : des sites physiques avec des serveurs, des équipements réseau, des systèmes de refroidissement et des dispositifs d'alimentation électrique. Et les télécoms, elles aussi, dépendent d'infrastructures matérielles réparties sur le territoire.
Une frappe contre un centre de données n'a donc pas besoin d'effacer définitivement les données pour créer des dégâts. Elle peut rendre des équipements indisponibles, perturber des connexions, couper l'alimentation ou rendre l'accès plus compliqué aux services hébergés sur place. L'ampleur des effets dépend de l'architecture technique, des mécanismes de secours et du temps que l'opérateur met à remettre ses systèmes en état.
Une escalade qui vise les services du quotidien
D'après le récit d'Ars Technica, la Russie a lancé fin septembre une campagne de frappes contre des centres de données et des réseaux de téléphonie mobile en Ukraine. Les attaques auraient temporairement perturbé l'accès à Internet et aux services mobiles pour jusqu'à 100 000 foyers à Kyiv. Elles s'inscrivaient dans une campagne plus large qui visait aussi le réseau électrique, des infrastructures de transport et des zones résidentielles.
L'Ukraine a ensuite ciblé des installations de Yandex. Le président Volodymyr Zelenskyy a présenté ces attaques comme une « réponse symétrique ». Sur le plan politique, l'expression décrit une logique de riposte. Mais, concrètement, elle ne change pas l'essentiel : les infrastructures numériques font désormais partie des opérations militaires, comme d'autres systèmes considérés indispensables.
Les conséquences ne se limitent pas aux applications hébergées directement sur les sites touchés. Un service peut s'appuyer sur un centre de données pour ses bases de données, sur un autre pour ses sauvegardes, sur un réseau télécom pour acheminer les requêtes, ou encore sur un fournisseur d'électricité pour rester opérationnel. Résultat : une panne locale peut se propager si plusieurs dépendances sont communes, ou si les mécanismes de bascule n'ont jamais été testés.
Disponibilité et intégrité : deux problèmes différents
Le premier symptôme est souvent la disponibilité : un service ne répond plus, ou répond de manière dégradée. Ensuite, d'autres questions deviennent centrales. Les équipes doivent vérifier si les données sont intactes, si les sauvegardes restent accessibles, et si les systèmes de secours reposent sur des dépendances identiques à celles de l'infrastructure principale.
On peut distinguer plusieurs situations :
- La panne : l'équipement ou le réseau ne fonctionne plus, sans que les données soient forcément perdues.
- La perte de capacité : le service répond encore, mais avec des performances réduites ou une capacité insuffisante.
- La perte de données : les copies disponibles sont incomplètes, endommagées ou trop anciennes.
- La compromission : un acteur a pu modifier ou consulter des informations, ce qui exige une réponse différente d'un simple redémarrage.
Ces scénarios appellent des plans différents. Autrement dit : redémarrer vite ne suffit pas si l'on ne sait pas si les données restent correctes, ni si elles ont été altérées.
Yandex : pourquoi quelques sites peuvent compter autant
Yandex est souvent présenté comme le « Google russe », mais l'entreprise ne se limite pas à la recherche en ligne. Comme d'autres grands groupes tech, elle opère plusieurs catégories de services et d'infrastructures. Un incident dans un centre de données peut avoir des effets directs sur certains produits, et indirects sur des systèmes qui dépendent de ces mêmes ressources.
Le premier site mentionné dans les informations disponibles se trouve dans la région de Sasovo, au sud-est de Moscou. Le 8 octobre, une attaque de drone aurait endommagé un centre de données qui héberge deux des trois supercalculateurs utilisés par Yandex pour entraîner son modèle d'intelligence artificielle, YandexGPT.
Des supercalculateurs touchés, mais des dégâts encore incertains
Ces machines s'appuient sur des processeurs graphiques Nvidia A100. Le supercalculateur Chervonenkis serait donné pour une puissance de 29,42 pétaflops et occuperait la 101e place du classement Top500 cité par l'article. Le système Lyapunov atteindrait 20,03 pétaflops et serait à la 161e place.
Ces chiffres traduisent une forte capacité de calcul, mais ils ne disent pas, à eux seuls, ce qui s'est réellement passé. Au moment des informations rapportées, on ne savait pas dans quelle mesure les supercalculateurs avaient été affectés. Un site peut être visé sans que tout soit détruit : une atteinte aux systèmes d'alimentation, de refroidissement ou de réseau peut aussi rendre des machines inutilisables, au moins temporairement.
Autrement dit, il faut éviter de mélanger trois choses : le fait qu'un site ait été touché, l'état physique des équipements, et l'impact mesuré sur les services. Les comptes rendus parlent de frappes contre plusieurs centres de données de Yandex et de perturbations de services, mais ils ne donnent pas un diagnostic technique complet pour chaque site.
L'entraînement d'un modèle d'IA n'est pas un service « isolé »
Entraîner un modèle d'IA, ce n'est pas seulement du calcul. Il faut des ressources, des données, des logiciels et des équipes. Une interruption peut retarder un entraînement, ou réduire la capacité disponible, sans forcément couper immédiatement un service accessible au public. L'impact dépend aussi de la manière dont les travaux sont répartis entre les machines et de la facilité à reprendre ailleurs.
Cette distinction compte pour toute organisation qui investit dans l'IA. Avoir un modèle en production, et maintenir la continuité nécessaire à l'entraînement ou aux mises à jour, ne renvoient pas au même sujet. Les entreprises doivent savoir quelles fonctions sont réellement critiques, combien de temps elles peuvent être indisponibles, et quelles parties du travail peuvent être transférées vers un autre environnement.
Une capacité de calcul impressionnante n'est pas, à elle seule, une stratégie de résilience. Si des systèmes essentiels sont regroupés dans une même zone, ou s'ils dépendent de fournisseurs identiques, le « gain » d'efficacité peut venir avec un point de défaillance commun.
Centralisation et décentralisation : deux modèles, deux types de risques
Les blogueurs pro-Kremlin cités par le chercheur indépendant ChrisO_wiki mettent en garde contre la concentration de l'économie numérique russe. Leur inquiétude tient à un modèle où un petit nombre d'acteurs et de sites pèsent fortement sur les services utilisés par le pays. Ils avancent aussi que des services ukrainiens plus décentralisés résisteraient mieux à des attaques répétées.
Cette comparaison mérite d'être prise avec prudence. Les informations disponibles ne suffisent pas à démontrer que l'ensemble des services ukrainiens serait plus résilient, ni à établir un comparatif complet des infrastructures des deux pays. En revanche, l'idée de base reste utile : la concentration peut améliorer l'efficacité, mais elle peut aussi concentrer le risque.
La centralisation n'est pas automatiquement une erreur
Centraliser peut simplifier l'exploitation. Les équipes standardisent les équipements, mutualisent des compétences, cadrent les mises à jour et réduisent certains coûts. Pour un opérateur, quelques grandes installations peuvent être plus faciles à gérer que beaucoup de petits sites dispersés.
Le problème surgit quand la concentration n'est pas compensée par des mécanismes de secours vraiment indépendants. Deux centres de données « distincts » sur le papier peuvent, en pratique, partager la même alimentation régionale, le même réseau de télécommunications, le même fournisseur ou le même plan de reprise. La redondance existe alors dans le schéma, mais pas forcément face à un incident qui touche une dépendance commune.
La bonne question n'est donc pas : « centraliser ou décentraliser ? » Elle ressemble plutôt à : « quelles défaillances notre architecture peut-elle encaisser, et en combien de temps revient-on à un niveau de service acceptable ? »
La décentralisation a aussi un coût
Répartir davantage les services peut limiter l'impact d'un incident local et rapprocher certaines capacités des utilisateurs. Mais chaque site supplémentaire ajoute des contraintes : exploitation, sécurité, mises à jour, surveillance, équipes sur place et cohérence des données. Une infrastructure distribuée, si elle n'est pas correctement gérée, peut au final être plus fragile qu'une plateforme centralisée bien conçue.
Il faut aussi distinguer la distribution des équipements de la distribution du contrôle. Un système peut s'appuyer sur plusieurs centres de données tout en dépendant d'un même plan de gestion, d'un même service d'identité ou d'un fournisseur unique. La diversité géographique ne suffit pas si les leviers de contrôle et de restauration restent concentrés.
Au fond, la résilience tient moins à une étiquette d'architecture qu'à la capacité de continuer à fournir les fonctions essentielles quand une partie de l'environnement ne répond plus. Cette capacité se vérifie par des scénarios et des exercices, pas seulement par le nombre de sites mis en avant dans une présentation.
Les leçons de résilience pour les entreprises européennes
Les organisations françaises et européennes ne vivent pas la même réalité militaire que les entreprises directement visées. Mais le raisonnement opérationnel reste pertinent : les services numériques reposent sur des dépendances physiques et contractuelles, et une panne majeure peut rapidement frapper la production, la relation client ou la conformité.
Le RGPD encadre le traitement des données personnelles et impose des obligations de sécurité, mais il ne remplace pas un plan de continuité d'activité. De même, le fait d'utiliser un fournisseur cloud reconnu n'assure pas que chaque application se rétablira dans le délai attendu. En externalisant, on ne se débarrasse pas du travail : il faut comprendre ses dépendances et fixer ses objectifs de reprise.
Cartographier les dépendances avant de choisir une solution
Commencez par identifier ce qui doit continuer à fonctionner, puis remontez les dépendances techniques et opérationnelles. Pour chaque service, posez des questions très concrètes :
- Où sont hébergées les données et les sauvegardes ?
- Le service dépend-il d'une seule région, d'un seul opérateur réseau ou d'un fournisseur d'identité unique ?
- Qui peut déclencher la bascule, et avec quels accès ?
- Quel délai est acceptable avant la reprise, et quelle quantité de données peut être perdue ?
- Les procédures de restauration ont-elles été testées récemment, dans des conditions réalistes ?
Cette cartographie révèle souvent un écart entre l'architecture décrite et la réalité du terrain. Une sauvegarde jamais restaurée reste une hypothèse, pas une garantie. Et une région de secours qui exige une intervention manuelle peu documentée peut se révéler inutilisable quand les équipes sont sous pression.
Concevoir des secours qui collent à un scénario réel
La redondance coûte de l'argent et ajoute de la complexité. Dupliquer chaque composant à l'identique n'est généralement pas utile. En revanche, il faut décider clairement quelles fonctions méritent un secours, et à quel niveau.
Une approche pragmatique peut suivre ce fil :
- Classer les services par criticité. Une application de facturation, un outil interne et une fonction de sécurité n'ont pas les mêmes exigences.
- Définir des objectifs de reprise. Le délai maximal d'interruption et le volume de données récupérable doivent être fixés avec le métier.
- Repérer les dépendances communes. Vérifiez régions, réseaux, identités, clés de chiffrement, fournisseurs et procédures partagés entre le site principal et le secours.
- Tester la restauration. Reconstituez un service à partir des sauvegardes et mesurez le temps réel.
- Prévoir le mode dégradé. Certaines activités peuvent continuer avec des fonctions réduites si l'option a été préparée et expliquée.
La résilience parfaite n'existe pas. Le but est de rendre les défaillances prévisibles, d'en limiter l'impact, et d'éviter qu'un seul incident mette simultanément hors service des composants censés se secourir.
Mesurer le coût d'une panne, pas seulement le prix du cloud
Dans les arbitrages budgétaires, la redondance ressemble parfois à une dépense difficile à justifier tant qu'aucune interruption majeure n'arrive. Pourtant, il faut comparer son coût au coût plausible d'une indisponibilité : ventes perdues, retards, pénalités, temps passé en interne, impact sur la confiance et coût du redémarrage.
Cela ne veut pas dire qu'il faut acheter le niveau de disponibilité le plus élevé du catalogue. Une architecture techniquement sophistiquée peut échouer si l'équipe n'arrive pas à l'exploiter et à la maintenir. À l'inverse, un dispositif plus simple, testé régulièrement et bien documenté, peut offrir une meilleure continuité pour un coût comparable.
Pour les entreprises de la French Tech comme pour les grands groupes, la question clé reste celle de la proportion : quelles pannes peut-on tolérer, lesquelles ne le peuvent pas, et quel investissement réduit vraiment le risque ? C'est une décision de produit et de gestion, autant qu'une décision d'infrastructure.
Conclusion : la continuité se conçoit avant la crise
Les frappes visant des infrastructures russes et ukrainiennes rappellent un fait simple : l'économie numérique reste dépendante de sites physiques, de réseaux et d'énergie. Le cas de Yandex ne suffit pas à conclure que toute architecture centralisée est condamnée, ni que toute architecture distribuée résistera mieux. Il montre surtout ce qui se passe quand une concentration n'est pas accompagnée de mécanismes de reprise suffisamment indépendants et testés.
Pour une organisation, le travail utile consiste à identifier ses fonctions critiques, comprendre ses dépendances et vérifier que sauvegardes et plans de secours marchent réellement. Ne partez pas du principe que votre service est résilient parce qu'il est « dans le cloud » : testez ce qui arrive quand une partie de ce cloud disparaît. Faites d'abord un exercice de restauration sur votre service le plus critique, puis transformez les écarts constatés en priorités concrètes.