Des drones mettent hors service un troisième data center de Yandex en quatre jours

Yandex a perdu un troisième grand data center en quatre jours. Dimanche 11 octobre, l'entreprise a indiqué qu'une attaque de drone avait mis hors service son site de la région de Vladimir, à l'est de Moscou. Selon Reuters, il n'y a pas de victimes, mais une partie des services destinés aux utilisateurs ne fonctionne pas actuellement. Pour une entreprise technologique de cette taille, trois sites perdus à la suite constituent un test de résistance auquel aucune architecture de tolérance aux pannes ne prépare.

Ce que l'on sait à ce jour

Les détails publics sont rares. La source est une déclaration de Yandex lui-même, relayée par Reuters puis par TNW. D'après le texte disponible, l'entreprise n'a divulgué ni l'ampleur des dégâts, ni les délais de rétablissement, ni la liste des services touchés.

• Site : data center de la région de Vladimir, à l'est de Moscou.
• Cause de la mise hors service : attaque de drone, selon Yandex.
• Date de l'annonce : dimanche 11 octobre 2026.
• Bilan : troisième grand data center de l'entreprise en quatre jours.
• Victimes : aucune.
• Impact pour les utilisateurs : une partie des services est indisponible, sans que l'on sache lesquels.

Les données disponibles ne donnent aucun détail sur les deux incidents précédents. Il est donc impossible, pour l'instant, de les comparer en termes d'ampleur et de conséquences.

Pourquoi trois sites en quatre jours constituent un cas particulier

L'industrie sait depuis longtemps encaisser la panne d'un seul data center. Elle dispose pour cela de zones de disponibilité, de la réplication des données entre sites et du basculement automatique du trafic. Le calcul repose sur l'indépendance des pannes : un incendie, une coupure d'alimentation ou une erreur de maintenance sur un site ne doit pas coïncider avec un incident équivalent sur un autre.

Avec une série d'attaques, cette hypothèse tombe. Trois sites en quatre jours signifient que la marge de redondance s'épuise plus vite qu'on ne peut la reconstituer. Les nœuds restants absorbent une charge supplémentaire, et toute nouvelle défaillance sur ces nœuds touche d'autant plus durement les utilisateurs. Les ingénieurs parlent de risque en cascade. Ce risque est dangereux moins par la coupure elle-même que parce que le système fonctionne sans filet.

Une question distincte concerne les charges d'IA. Yandex dispose de ses propres modèles de langage et d'un assistant vocal, qui exigent des clusters GPU dotés d'une alimentation et d'un refroidissement puissants. Rien n'indique quelles capacités se trouvaient sur les sites mis hors service. Toute conclusion sur l'effet pour les modèles de l'entreprise relèverait de la conjecture.

En pratique : ce que les équipes et les clients doivent vérifier

Même si vous n'utilisez pas les services de Yandex, cette affaire fournit une liste de contrôle utile pour n'importe quelle infrastructure.

Premier point : examinez comment votre redondance est réellement conçue. Deux « zones » dans une même région ou chez un même fournisseur ne protègent pas contre des événements régionaux. Deuxième point : testez le basculement en conditions réelles. Les exercices de panne montrent combien de minutes ou d'heures la reprise exige, et non ce que promet un document. Troisième point : conservez des copies des données et des configurations critiques en dehors du site principal, de préférence chez un autre fournisseur ou dans une autre juridiction. Quatrième point : déterminez à l'avance les fonctions du produit que l'on peut désactiver pour préserver le cœur du service, et préparez un mode dégradé.

Pour les clients de Yandex, les prochains jours donneront la réponse essentielle : les services indisponibles reviendront-ils en quelques heures, ou le processus va-t-il s'éterniser ? Suivez les pages d'état officielles de l'entreprise et ne planifiez pas de lancements critiques dans les jours à venir, tant que la situation des autres sites n'est pas clarifiée.