Après l'attaque d'un drone sur son troisième datacenter, Yandex bloque une partie des fonctions de 360 et de Disk

Yandex a restreint une partie des fonctions clés de la plateforme Yandex 360 et du stockage cloud Disk. Le déclencheur : l'attaque d'un drone sur le troisième datacenter de l'entreprise. RBC rapporte une décision d'urgence de la direction, dont le but est de protéger l'infrastructure informatique d'une surcharge critique. Les matériaux disponibles ne contiennent ni la liste des fonctions désactivées ni données sur d'éventuels dégâts physiques : une partie des conclusions ci-dessous reste donc au stade d'hypothèses de travail.

Ce que l'on sait à ce stade

Les faits sont peu nombreux et tiennent en une courte liste :

• Produits concernés : Yandex 360 (la plateforme de travail de l'entreprise) et le stockage cloud Disk.
• Nature des mesures : blocage d'une partie des fonctions clés, et non coupure complète des services.
• Motif : prévenir une surcharge critique de l'infrastructure.
• Source : RBC, reprise par Hi-Tech le 12 octobre 2026.
• Numéro de l'incident : le titre évoque le troisième datacenter, ce qui signifie qu'il ne s'agit pas d'un épisode isolé.

On ignore quelle part des capacités a été perdue, si la réplication des données a été perturbée et quand les restrictions seront levées.

Pourquoi la surcharge est aussi dangereuse que la frappe elle-même

Quand une partie des capacités tombe, la charge se reporte sur les sites restants. Les clients, eux, ne restent pas passifs. Les applications relancent les requêtes échouées, les clients de bureau de Disk tentent de synchroniser les fichiers, les services de messagerie et de bureautique sollicitent les mêmes backends. Une avalanche se forme, et même des nœuds intacts peuvent s'effondrer sous son poids.

C'est pourquoi les ingénieurs recourent au load shedding : ils coupent délibérément les fonctions les moins critiques et les plus coûteuses afin de préserver un fonctionnement de base. Ce sont généralement les lourdes opérations d'arrière-plan qui sautent en premier : synchronisation de masse, génération d'aperçus, indexation ou téléversement de gros volumes. C'est une pratique courante dans l'industrie. Dans les matériaux cités, l'entreprise ne précise pas quelles options Yandex a désactivées.

Pour le stockage, l'enjeu est encore plus aigu. Si une partie des réplicas a été touchée, le système consacre ses ressources à reconstituer la redondance des données, et chaque requête utilisateur superflue détourne ces ressources de la tâche la plus critique : la préservation des fichiers. Dans ce mode, la restriction des fonctions ressemble davantage à une mesure de précaution pour les données qu'à une gêne pour les utilisateurs.

Ce qui manque encore pour une vision complète

Les principales questions restent ouvertes. Combien de sites et quelle part de la capacité totale ont été touchés ? Les services cloud destinés aux clients sont-ils affectés, ou seulement les produits grand public ? L'entreprise dispose-t-elle de régions de secours avec une marge de capacité suffisante pour un remplacement complet ? Un troisième incident d'affilée, si l'on en croit le titre, fait passer le sujet de la panne ponctuelle au problème de conception : la protection physique et la répartition géographique des datacenters deviennent une composante de l'architecture au même titre que la redondance électrique.

Il faudra aussi surveiller l'effet de la contraction des capacités sur les autres charges de l'entreprise, y compris le cloud et les services ML hébergés sur des sites partagés. Rien ne le confirme directement, mais en cas de pénurie de calcul, les priorités se réordonnent inévitablement.

Que faire pour les utilisateurs et les entreprises

Tant que Yandex n'a pas publié de détails, il est raisonnable de s'en tenir à l'hygiène de base :

• Faites une copie locale ou externe des fichiers critiques de Disk, si la synchronisation fonctionne encore. Ne lancez pas un export massif de tout le contenu : vous ajouteriez de la charge au système.
• Identifiez les processus métier qui dépendent de Yandex 360 : agenda, messagerie, documents partagés. Préparez des canaux de communication de secours pour l'équipe.
• Étudiez les conditions du SLA et la procédure de compensation, si les services sont utilisés dans le cadre d'un contrat d'entreprise.
• Suivez les communications officielles de l'entreprise : ce sont elles qui détermineront quand et dans quel ordre les fonctions reviendront.

Pour les responsables informatiques, la leçon est concrète : une dépendance unique à un cloud, sans plan de dégradation, devient un point de défaillance unique, même si le fournisseur exploite plusieurs datacenters.