À Kalouga, un datacenter de Yandex à l'arrêt : certains services peuvent être indisponibles

Le 9 octobre 2026, Yandex a averti ses utilisateurs qu'une partie de ses services pouvait être indisponible à la suite d'un incident dans son datacenter de Kalouga. Le service de presse de l'entreprise l'a indiqué à Russian Business. Les services d'urgence sont sur place. Yandex n'a communiqué ni la cause, ni l'ampleur des conséquences, ni les délais de rétablissement.

Dans son titre, RB.RU présente le site de Kalouga comme « encore un » datacenter de l'entreprise dont l'activité est suspendue. Le message ne précise pas ce qui s'est passé lors de l'épisode précédent. Il est donc impossible, pour l'instant, de comparer les deux incidents ou de chercher un lien entre eux : les données manquent.

Ce que l'on sait à ce stade

Les faits sont peu nombreux, et il faut les distinguer strictement.

• Source : le service de presse de Yandex, cité par Russian Business
• Lieu : le datacenter de l'entreprise à Kalouga
• Statut : activité suspendue
• Sur le site : les services d'urgence
• Impact : une partie des services peut être temporairement indisponible, sans précision sur lesquels
• Non communiqué : la cause, l'existence éventuelle de victimes, une estimation des délais de rétablissement

La mention des services d'urgence indique un incident physique plutôt qu'une panne logicielle. Le message ne permet pas de savoir de quel incident il s'agit. Il pourrait s'agir d'un incendie, d'un problème d'alimentation électrique ou d'autre chose. Tant que l'entreprise ne les a pas confirmées, ces hypothèses restent des conjectures, et il vaut mieux ne pas en tirer de conclusions.

En quoi un incident physique diffère d'une panne logicielle

Une erreur logicielle se corrige généralement par un retour arrière : on rétablit la version précédente, on redémarre les nœuds, on redirige le trafic. Un incident physique obéit à une autre logique. Tant que les services d'urgence interviennent sur le site, l'accès des ingénieurs aux salles est restreint. L'alimentation ou le refroidissement peuvent être coupés volontairement pour éviter des conséquences plus graves. Viennent ensuite la vérification du matériel et un redémarrage par étapes, qui prennent du temps même lorsque les machines n'ont pas souffert.

Chez les grands opérateurs, ces risques sont intégrés à l'architecture. Les services sont répartis sur plusieurs sites, et le trafic bascule vers les autres lorsqu'un site tombe. Mais la redondance ne fonctionne pas de la même façon pour tous les composants. Les frontends et les services stateless migrent rapidement. Les stockages et les bases de données posent plus de difficultés : ils exigent une réplication entre les sites, synchrone ou asynchrone, et c'est elle qui détermine si l'utilisateur est touché ou non. La formule de Yandex, « une partie des services peut être indisponible », n'a donc rien de surprenant. Certains produits survivront à la perte d'un site sans que l'on s'en aperçoive, d'autres non.

Ce qu'il faut surveiller ensuite

Les prochaines heures éclaireront trois points.

• La liste des services touchés. Si la panne n'affecte que certains produits, c'est que les autres ont été transférés avec succès vers d'autres sites.
• La cause de l'incident. Elle déterminera s'il s'agit d'un événement isolé ou d'une raison de revoir les exigences de sécurité physique des sites.
• Le délai de remise en service du site. Si le matériel doit être vérifié ou remplacé, il peut s'agir de jours, et non d'heures.

Il faut aussi attendre une analyse de la part de Yandex lui-même. Pour une grande entreprise d'infrastructure, un post-mortem public avec chronologie et enseignements est généralement plus important que les premières déclarations.

Mesures pratiques pour les utilisateurs et les entreprises

Les particuliers n'ont qu'à patienter : relancer la connexion ou redémarrer les applications change peu de choses si le problème vient du site lui-même. Les entreprises dont les processus métier dépendent des services de Yandex, y compris de sa plateforme cloud, ont intérêt à faire plusieurs choses.

• Consulter les pages de statut et les canaux officiels de l'entreprise, plutôt que de se fier aux rumeurs sur les réseaux sociaux
• Identifier les zones de disponibilité qui hébergent vos ressources, et vérifier si vous disposez d'une copie dans une autre zone
• Ne pas lancer de redémarrages massifs ni de requêtes répétées de façon agressive : ils ajoutent de la charge pendant la reprise
• S'assurer que des sauvegardes à jour sont stockées en dehors du site touché
• Préparer à l'avance un message pour les clients, au cas où l'arrêt se prolongerait

Tout incident dans un datacenter rappelle que la fiabilité d'un service ne dépend pas seulement de son éditeur, mais aussi de la façon dont le client a construit sa propre architecture. Une architecture multizone a un coût, mais elle revient généralement moins cher qu'un arrêt de service.