Une traffic storm correspond à une montée brutale du volume de requêtes vers un site, une application ou une API, sur quelques minutes ou quelques heures. Les symptômes se ressemblent souvent : latence qui grimpe, erreurs 5xx, timeouts, back office inaccessible, files de messages qui explosent. Mais les causes peuvent être totalement différentes, et la réponse technique ne sera pas la même. Pour un site à fort trafic, l’enjeu est donc d’identifier rapidement si la tempête est organique, accidentelle ou malveillante.
Les pics organiques : la demande réelle qui dépasse la capacité
Le scénario le plus sain est aussi le plus fréquent : une campagne marketing, une mention presse, un passage TV, une notification push, un lancement produit ou une promo e commerce déclenchent un afflux massif d’utilisateurs. Ce trafic se reconnaît souvent à des signaux “humains” : diversité des pages vues, parcours cohérents, taux de rebond variable, progression dans le funnel, et sources identifiables côté analytics.
Le piège, c’est que même un trafic légitime peut provoquer une panne si l’infrastructure n’est pas dimensionnée pour l’effet de pointe. Une base de données sous indexée, un cache insuffisant ou une page “lourde” peuvent transformer un simple pic en incident.
Les tempêtes accidentelles : bugs, retries et “thundering herd”
Certaines tempêtes sont auto infligées. Un bug de déploiement, un cron trop agressif, un job de synchronisation mal cadencé, ou un client API qui “retry” en boucle après des erreurs peut générer une avalanche de requêtes. On parle parfois de retry storm ou de thundering herd, quand de nombreux clients réessaient simultanément, aggravant une panne initiale.
Un autre classique est le cache stampede : un objet expire et des milliers de requêtes recomputent la même ressource au même moment. Ce type de surcharge ressemble à une attaque, mais l’empreinte est différente : les IP et les user agents sont souvent internes ou connus, et les endpoints touchés sont très spécifiques.
Les tempêtes malveillantes : DDoS, bots et abus applicatifs
Quand le trafic est artificiel, l’objectif est rarement “juste” d’augmenter le volume. Il s’agit de saturer la bande passante, d’épuiser des ressources (CPU, RAM, connexions) ou de faire tomber une brique critique (login, search, checkout). Le terme général est l’attaque par déni de service, souvent distribuée, décrite ici : denial of service attack.
Il existe aussi des tempêtes moins visibles, mais très coûteuses : scraping intensif, enumeration de comptes, tests de cartes, abus d’API. Elles ne font pas toujours exploser le débit, mais elles ciblent des opérations “chères” et dégradent l’expérience utilisateur réelle.
Dans ces cas, une protection en amont peut limiter l’impact avant que l’origine ne soit saturée, par exemple via une couche de DDoS protection placée en bordure réseau.
Comment distinguer la cause en pratique
Pour qualifier une tempête, il faut croiser métriques et traces. Quelques repères utiles :
- Répartition des URLs touchées
Un pic organique touche souvent des pages d’entrée et des pages de conversion. Un DDoS ou un abus applicatif cible souvent 1 à 3 endpoints.
2.Qualité des sessions
Trafic humain : navigation variée, assets chargés, temps passé. Trafic bot : répétitif, profondeur faible, patterns mécaniques.
3. Répartition géographique et ASN
Des sources très dispersées et incohérentes, ou des concentrations anormales, peuvent signaler une attaque ou un réseau de bots.
4. Indicateurs réseau
La congestion réseau explique une dégradation même sans attaque. Le concept est bien posé ici : network congestion.
Bonnes pratiques pour réduire l’impact
Stabiliser le service pendant l’analyse est souvent prioritaire. Les mesures les plus efficaces combinent rate limiting, caching, files d’attente, et filtrage en amont. Côté SEO, il est aussi important de préserver une exploration saine par les moteurs et d’éviter les comportements qui perturbent l’indexation lors d’incidents. La documentation officielle sur le crawl budget aide à cadrer ce sujet : Google Search Central crawl budget.
Enfin, pour réduire les risques d’abus applicatif, les bonnes pratiques OWASP sur la protection des APIs et la limitation des abus sont une référence utile : OWASP API Security.
À retenir
Une traffic storm n’est pas une cause, c’est un symptôme. Elle peut venir d’un succès marketing, d’un effet domino entre dépendances, d’un bug de retries, ou d’une attaque organisée. La différence se joue sur les patterns : endpoints ciblés, qualité des sessions, distribution réseau, coût backend par requête. Les équipes qui s’en sortent le mieux sont celles qui instrumentent correctement, automatisent les garde fous, et disposent d’une stratégie de filtrage capable d’absorber la turbulence avant qu’elle n’atteigne l’origine.
