Incident Yandex Cloud : les bots ont migré vers d'autres hébergeurs en 24 heures. Qu'est-ce que cela signifie pour le parsing ?

Du 8 au 11 octobre 2026, Yandex a perdu trois centres de données : Sasovo et Vladimir ont été complètement arrêtés, Kaluga a fonctionné avec dégradation. Yandex Cloud est passé en mode d'urgence et a directement conseillé aux clients d'activer leurs propres plans de reprise après sinistre. Le plus intéressant s'est produit ensuite. Cloudflare a analysé ce qui est arrivé aux bots qui vivaient dans ce cloud et a constaté qu'ils n'avaient pas disparu, mais qu'en une journée, ils avaient déménagé chez d'autres hébergeurs. Et ils sont restés reconnaissables par la même empreinte TLS JA4. Pour tous ceux qui s'occupent de parsing et d'automatisation, c'est une expérience rare sur deux questions : que faire lorsque l'infrastructure s'effondre, et pourquoi le changement d'IP et d'hébergement ne change pas l'« identité » du bot.

Que s'est-il passé avec Yandex

Selon BleepingComputer, Yandex a signalé des dommages à trois centres de données causés par des attaques de drones. Yandex lui-même n'a pas nommé de coupable ; les médias, citant la BBC, relient les frappes à l'Ukraine. La chronologie est la suivante :

• 8 octobre — Sasovo (région de Riazan) : incendie, site complètement arrêté ;
• 9 octobre — Kaluga : fonctionnement avec dégradation, pas d'arrêt complet ;
• 11 octobre — Vladimir : complètement arrêté.

Sur la page de statut de Yandex Cloud, une partie des services (console, API, IAM, bases de données, S3, Kubernetes) est restée accessible avec des problèmes de performance, Compute et AI Studio ont fonctionné partiellement. La société a déclaré qu'elle ne pouvait pas donner de délais de récupération fiables, considérant la configuration restante des ressources comme instable et recommandant aux clients d'utiliser des plans de reprise après sinistre alternatifs. Il n'y avait pas de délais de récupération ni de clarté sur la possible perte de données au moment de la publication de BleepingComputer (12 octobre).

Ce que Cloudflare a vu : le trafic a chuté, les bots non

Le 14 octobre, Cloudflare a publié une analyse de l'accident de son côté du réseau. Chiffres clés :

• Le 11 octobre, le trafic du réseau Yandex Search (AS13238) a chuté de 99 % par rapport à la normale, celui de Yandex.Cloud (AS200350) de 90 % ;
• 99,5 % des requêtes de AS13238 avant l'accident étaient automatiques, dont 93,6 % des requêtes de bots étaient des crawlers vérifiés de Yandex. Ce réseau représentait environ 7 % de toutes les requêtes de bots provenant d'IP russes ;
• Dans Yandex.Cloud, environ 95 % des requêtes évaluées étaient des bots, et aucune d'entre elles n'était vérifiée. Cela représente environ 2 % du trafic de bots russes ;
• Le trafic de bots provenant de Yandex.Cloud a diminué d'environ 40 %, le scanning des plugins WordPress depuis ce réseau a chuté de 90 %.

Et ensuite, le principal. Presque toutes les requêtes de bots provenant de Yandex.Cloud étaient dirigées vers un compte client de Cloudflare dans le domaine des jeux d'argent. Immédiatement après la panne du 8 octobre, les requêtes de Yandex.Cloud vers ce compte ont chuté à zéro — et des requêtes identiques sont immédiatement apparues depuis les réseaux d'autres hébergeurs russes, Radist et Selectel. Avec la même empreinte JA4 TLS, les mêmes chemins et en-têtes rares et les mêmes chaînes User-Agent non standard. Au final, en une semaine : le trafic de bots russes vers les comptes de jeux d'argent n'a pas diminué, mais a augmenté — de 167,7 à 170,1 millions de requêtes (+1,4 %).

La conclusion de Cloudflare est claire : l'infrastructure physique est statique, tandis que l'automatisation malveillante est conçue pour se déplacer. La chute du volume de trafic HTTP indique un accident, mais ne signifie pas que les bots se sont arrêtés.

La version bruyante et les données : pourquoi « les bots se sont tus » s'est avéré être une exagération

Parallèlement, le Centre ukrainien de lutte contre la désinformation (CPI) a déclaré qu'après la frappe sur Sasovo, le nombre de messages de comptes suspects sur Facebook et Telegram avait chuté de 83,6 % en une journée — de 4 032 à 660. Mais, comme l'a analysé TechRadar, dès le 10 octobre, l'activité est revenue à 4 585 messages, et le 11 octobre, elle a dépassé le niveau d'avant la frappe. Cloudflare n'a pas trouvé de décalage significatif : le trafic de bots provenant d'IP russes vers les points de terminaison « post, réponse, like » d'un réseau social a seulement diminué de 5,7 %. Graphika n'a pas non plus constaté de perte de comptes actifs dans les communautés suivies. La chercheuse Renée DiResta a déclaré dans Lawfare que l'histoire était belle, mais ressemblait davantage à une fiction qu'à un fait.

Une leçon distincte pour les analystes : le 8 octobre, les banques, le commerce de détail, les opérateurs et les médias ont connu des pannes dans toute la Russie, donc toute chute de « l'activité » ce jour-là ne peut pas être attribuée sans réserve aux bots. Le trafic agrégé peut facilement induire en erreur.

Leçon un : IP et hébergement ne sont pas l'identité du bot

Cloudflare a reconnu le lien « Yandex.Cloud → Radist/Selectel » non pas par les adresses — les adresses et ASN ont complètement changé. Il a été reconnu par le comportement et l'empreinte du client :

• JA4 — hachage TLS ClientHello : ensemble de chiffrements, d'extensions, de versions de protocole. Il décrit le programme, pas le réseau. Le même script Python sur un nouveau serveur donne le même JA4 ;
• chemins et en-têtes rares — ordre et ensemble d'en-têtes HTTP qui ne se rencontrent pas chez les navigateurs ordinaires ;
• User-Agent propre — chaîne unique qui sert de marque.

Conclusion pratique pour le parsing légal : changer de centre de données ou de pool d'IP ne vous rend pas « nouveau » pour l'anti-bot, si toute la pile client reste la même. Et inversement : si votre crawler se présente honnêtement, se comporte prudemment et ne frappe pas les points de terminaison sensibles, une empreinte stable n'est pas un problème. Le problème survient lorsque la pile ressemble à quelque chose qui n'existe pas chez de vrais utilisateurs : un Chrome déclaré avec une empreinte TLS de la bibliothèque requests, un UA exotique, des en-têtes non standard. Nous avons détaillé comment fonctionne cette couche de détection dans notre analyse JA4 et le fingerprinting TLS lors du scraping.

Remarquez encore un détail : les bots ont déménagé d'un centre de données à d'autres centres de données. Pour Cloudflare, c'est toujours la même catégorie d'ASN d'hébergement, à laquelle de nombreux sites ont a priori une méfiance accrue. Le réseau est différent — le profil de risque est le même.

Leçon deux : l'infrastructure doit pouvoir être déplacée en quelques heures

Les malfaiteurs ont déménagé en une journée, car leur automatisation est initialement portable. Les équipes honnêtes qui collectent des prix, surveillent les résultats ou réalisent des analyses ont également besoin de cette portabilité. La recommandation de Yandex Cloud « utilisez des plans de reprise après sinistre alternatifs » est valable uniquement si un tel plan existe déjà. Liste de contrôle minimale :

1. Code et configurations — hors du cloud. Le dépôt, les images de conteneurs, les variables d'environnement doivent être stockés de manière à ce qu'un parser puisse être déployé chez un autre hébergeur en une seule commande.
2. Deuxième hébergeur à l'avance. Un compte, un paiement et un serveur de test chez un fournisseur alternatif dans une autre juridiction et une autre région. S'inscrire et passer la vérification le jour de l'accident — c'est trop tard.
3. Couche de sortie séparée des calculs. Si les requêtes vers les sites cibles passent par un fournisseur de proxy, et non directement depuis l'IP du serveur, le déménagement des calculs ne change ni la géo, ni le type d'IP, ni l'historique des sessions. Le serveur peut être déplacé, mais pour le site, vous restez le même client.
4. Données et files d'attente — avec réplication. Les résultats du parsing et l'état des tâches sont copiés dans un autre stockage, sinon après un accident, il faudra recommencer le parcours depuis le début.
5. Fournisseur de secours — vraiment différent. L'hébergement de secours ou le fournisseur de proxy ne doit pas être la même infrastructure sous une autre marque. Comment vérifier cela sur les proxies, nous l'avons analysé dans notre article sur pourquoi un fournisseur de proxy de secours peut s'avérer être le même pool.
6. Alarme d'entraînement. Une fois par trimestre, déployez le parser sur un site de secours et exécutez une tâche réelle. Un plan qui n'a jamais été testé ne fonctionne généralement pas en pratique.

Quel type de proxy résout quoi dans une telle situation

Les proxies ne sauvent pas d'une mauvaise empreinte — cela se voit dans l'exemple de l'analyse de Cloudflare. Cependant, ils détachent « l'identité » de vos requêtes de l'endroit où le code tourne physiquement :

• Proxies résidentiels — pour les sites où les ASN d'hébergement sont bloqués à l'avance ou reçoivent un captcha. Lors du déménagement du serveur, la sortie reste sur des IP domestiques du pays souhaité.
• Proxies de centres de données — pour les API et les sites loyaux, où la vitesse et le prix sont importants. Ils doivent également être détenus par un fournisseur indépendant de votre cloud, afin qu'un accident d'hébergement n'emporte pas non plus les IP de sortie.

En même temps, les proxies ne sont qu'une seule couche. Si la pile TLS, les en-têtes et le comportement de votre client se distinguent, ils seront reconnus sur n'importe quelle IP, comme les bots qui ont déménagé chez Radist et Selectel.

Ce que cela signifie pour les propriétaires de sites

Cloudflare tire également une conclusion inverse : ASN et volume de trafic ne sont pas des indicateurs fiables de bots. Le blocage d'un réseau « mauvais » fonctionne jusqu'au premier déménagement. Il est plus fiable de se concentrer sur le comportement : empreintes JA4 communes entre différents réseaux, fréquence anormale des requêtes et règles WAF sur des points de terminaison sensibles, peu importe d'où provient la requête. Il y a aussi un revers à la médaille : 40,5 % des clients de Cloudflare ont répondu au crawler de Yandex avec un code 403, et le trafic des réseaux de Yandex vers les sites d'actualités a chuté de 44 % pendant l'accident — ce qui signifie que l'indexation légitime a été principalement affectée.

Conclusion

L'accident de Yandex a été une vérification vivante de deux vérités simples. Première : l'infrastructure peut disparaître en un jour, et celui qui sait la déplacer en quelques heures gagne — avec le code hors du cloud, un deuxième hébergeur et une couche de sortie non liée au serveur. Deuxième : pour l'anti-bot, vous êtes votre pile client, et non votre IP. Un nouveau centre de données avec le même JA4 et le même User-Agent est le même bot à une nouvelle adresse. Construisez le parsing de manière à ce qu'il survive à un changement de plateforme tout en ayant l'air tout aussi soigné sur n'importe quelle IP.