Panne Yandex : moins de trafic ne signifie pas moins de bots malveillants

ParKelvin Carretero-Corrales

Une courbe de trafic qui s’effondre n’est pas un certificat de sécurité. Dans une analyse publiée le 14 octobre 2026, Cloudflare examine les perturbations des réseaux Yandex, notamment sur la période du 7 au 13 octobre. Son constat invite à regarder ce que font les requêtes, pas seulement leur provenance.

Ce que Cloudflare a réellement observé

Cloudflare distingue le réseau du moteur de recherche Yandex de celui de Yandex.Cloud. Sur le premier, la baisse concernait surtout des robots d’indexation vérifiés. Sur le second, certaines activités de scan ont diminué, mais l’analyse décrit aussi un cas de requêtes identiques réapparaissant depuis d’autres hébergeurs après une interruption le 8 octobre.

Ces observations proviennent de Cloudflare Radar et de ses outils de détection. Elles ne constituent pas une mesure exhaustive de tous les bots sur Internet et ne permettent pas d’attribuer une opération à une personne sur la seule base d’un hébergeur. Le périmètre compte autant que la courbe.

La réponse pratique pour une petite entreprise

La conséquence à en tirer est une recommandation de conception, pas une nouvelle conclusion statistique : pour protéger un outil en ligne, surveillez les opérations sensibles, limitez leur consommation et prévoyez une réaction aux anomalies. Une liste d’adresses bloquées ne doit pas être votre unique indicateur de protection.

Les exemples ci-dessous sont des situations de conception, pas des incidents constatés chez des clients.

Automatisé ne veut pas forcément dire malveillant

Un robot peut indexer une page, contrôler la disponibilité d’un site ou synchroniser des informations entre deux outils. Le bon objectif n’est donc pas de supprimer toute automatisation, mais de distinguer l’usage attendu de l’abus.

La documentation Cloudflare décrit son score de bot comme un indicateur de probabilité d’automatisation, de 1 à 99. Ce n’est pas une preuve d’intention malveillante. Elle distingue aussi les robots vérifiés et les requêtes non évaluées. Un score non calculé ne signifie pas « sûr » ou « humain ».

Il faut également vérifier les fonctions réellement incluses dans son offre : Cloudflare réserve les scores détaillés à ses clients Enterprise ayant souscrit Bot Management. Un conseil qui suppose l’accès à cette donnée n’est donc pas applicable à tous les sites.

1. Journaliser les événements utiles, pas toutes les données

Pour un petit outil métier, les journaux doivent permettre de comprendre une action : quand elle a eu lieu, quelle fonction a été appelée et avec quel résultat. OWASP recommande d’inclure les informations nécessaires sur le moment, le contexte, l’acteur connu et l’événement.

  • Repérer les échecs d’authentification, les refus d’accès et les opérations inhabituelles.
  • Relier les étapes d’un même traitement avec un identifiant d’interaction.
  • Noter le résultat de l’action, sans confondre une réponse technique avec une réussite métier.
  • Prévoir qui reçoit une alerte et qui peut examiner les journaux.

Ne transformez pas les logs en coffre à secrets. Mots de passe, jetons d’accès et clés de chiffrement ne doivent pas y apparaître en clair. Limitez aussi les données personnelles et l’accès aux journaux. L’objectif est un diagnostic exploitable, pas l’enregistrement systématique du contenu des formulaires ou des documents.

2. Limiter le coût d’une requête, pas seulement leur nombre

Le risque n’est pas uniquement une page indisponible. Une fonction qui envoie des messages, traite des fichiers ou appelle un service facturé à l’usage peut consommer des ressources et générer des frais. OWASP classe cette consommation non maîtrisée parmi les risques des API.

Les limites doivent correspondre aux fonctions et au besoin métier :

  • Nombre d’appels autorisés sur une période.
  • Taille des fichiers et des données reçues.
  • Durée maximale d’un traitement et ressources disponibles.
  • Nombre d’opérations exécutées dans une seule requête.
  • Plafonds de dépenses chez les fournisseurs ; à défaut, alertes de consommation.

La limitation de débit seule ne suffit pas si un appel peut déclencher un très gros travail. À l’inverse, un seuil trop strict peut interrompre une synchronisation légitime. Il faut tester le fonctionnement normal et les dépassements, sans lancer de test de charge sur un service tiers non autorisé.

3. Protéger les comptes sans enfermer les utilisateurs

Pour les connexions, OWASP recommande des mesures complémentaires : authentification multifacteur lorsque possible, limitation des tentatives et suivi des échecs par compte plutôt que par seule adresse IP.

Un verrouillage doit néanmoins être étudié avec soin : un tiers pourrait tenter de bloquer le compte d’un véritable utilisateur. Le seuil, la période d’observation et la durée du blocage doivent être cohérents avec le risque et les moyens de récupération.

Un CAPTCHA peut ajouter une difficulté aux tentatives automatisées, mais il n’est pas une garantie. OWASP le présente comme une couche de défense supplémentaire. Il ne remplace ni une authentification adaptée ni les contrôles côté application.

Exemple : un formulaire qui prépare des documents

Imaginons un outil qui reçoit une demande, génère un PDF puis prépare un e-mail. Pour le cadrer, trois questions sont plus utiles que « avons-nous bloqué beaucoup de bots ? » :

  • Qui est autorisé à demander une génération et dans quelles limites ?
  • Quel volume de travail et quel coût un seul envoi du formulaire peut-il provoquer ?
  • Comment l’utilisateur saura-t-il qu’une demande a été refusée, reportée ou terminée ?

La réponse attendue est un fonctionnement compréhensible : un état visible, des limites documentées et une personne capable d’intervenir. Les valeurs exactes doivent venir des essais et des besoins du projet, pas d’un chiffre copié sur Internet.

Le lien avec les projets présentés par FuretSplick

La page de services FuretSplick présente le diagnostic de processus, les automatisations entre outils et les petites applications métier. Ce sont précisément des projets où il faut définir les entrées acceptées, les actions autorisées, les limites et le comportement en cas d’échec.

Ce lien ne signifie pas qu’une prestation spécialisée de défense contre les bots est proposée. Il s’agit d’intégrer ces questions au cadrage d’un outil et d’identifier les besoins qui dépassent son périmètre.

Pour préparer un projet, consultez les périmètres d’automatisation présentés par FuretSplick. Le site indique que l’activité est en préparation : disponibilité, conditions et périmètre restent à confirmer avant tout engagement.

Conclusion : mesurer ce qui protège vraiment l’activité

Un tableau de bord utile doit aider à décider : une action sensible est-elle maîtrisée, un compte est-il protégé, un coût peut-il s’emballer ? Pour un petit outil, commencez par des événements lisibles, des limites adaptées et une marche à suivre en cas d’alerte. La sécurité se juge sur ces contrôles, pas sur une courbe isolée.

Sources

Publications similaires