Pendant plusieurs mois, un site e-commerce B2B tombait en panne 4 à 5 fois par jour. Chaque panne nécessitait un redémarrage serveur. Chaque redémarrage coûtait du temps, de l'argent, et de la crédibilité vis-à-vis des clients.
Deux équipes étaient impliquées : celle qui développait le site, et celle qui l'hébergeait. Et depuis des mois, chacune pointait l'autre du doigt.
- L'équipe de développement : "Le code est sain, ce n'est pas notre problème."
- L'hébergeur : "Le serveur est surdimensionné, il n'y a aucune raison qu'il sature."
Les deux avaient raison. C'est là que l'histoire devient intéressante.
L'enquête
La première chose que j'ai faite : regarder les logs.
Pas pour chercher un bug. Pas pour vérifier une config serveur. Pour comprendre comment le site était utilisé.
Ce site permettait de filtrer un catalogue de produits techniques par plusieurs critères. Chaque filtre déclenchait un rechargement de page — et ce rechargement prenait environ une minute. Une minute à chaque clic. Ce n'est pas agréable, mais pour un professionnel B2B qui sait exactement ce qu'il cherche, 2 ou 3 filtres suffisent amplement.
Dans les logs, j'ai vu autre chose.
Des sessions avec 50 filtres activés simultanément. Parfois la totalité des filtres disponibles, en même temps.
Aucun humain ne fait ça.
Le diagnostic
J'ai échangé avec l'équipe métier — ceux qui connaissent les vrais utilisateurs. Leur réponse : "Nos clients ne filtrent jamais à plus de 5. Ce serait absurde."
Le problème était clair : le site était attaqué — pas au sens malveillant du terme, mais structurellement — par des bots, des scrapers, des crawlers automatisés. Ces agents n'ont aucune notion de la durée de chargement. Ils ne s'impatientent pas. Ils enchaînent les requêtes sans limite.
Et techniquement, rien ne les en empêchait.
Le site n'avait pas d'optimisation sur ses requêtes en base de données. Chaque combinaison de filtres générait des appels lourds. Quand ces appels se multipliaient par 50 filtres simultanés, la base de données saturait, ce qui impactait les appels serveur, ce qui finissait par faire tomber le site. Le tout 4 à 5 fois par jour.
La solution
Deux actions complémentaires :
- Limite métier : maximum 5 filtres actifs simultanément — cohérent avec l'usage réel, imperceptible pour les vrais utilisateurs
- Rate limiting : restriction du nombre de requêtes par session sur les endpoints de filtrage — pour que même des requêtes légères ne puissent pas être enchaînées sans limite
Pas une liste noire d'IPs. Pas un système anti-bot complexe. Pas une refonte technique.
Résultat immédiat :
- Les pannes ont disparu
- Les pages de filtre sont passées d'une minute de chargement à quelques secondes
- Aucun utilisateur humain ne s'est plaint — parce qu'aucun n'utilisait plus de 5 filtres
Ce que ça m'a appris
Un audit technique ne se limite pas à lire du code.
Avant de chercher le bug, il faut comprendre qui utilise le système et comment. Les logs ne racontent pas seulement ce qui s'est passé — ils révèlent qui était là.
Dans ce cas, les deux équipes techniques avaient raison sur les faits. Le code était propre. Le serveur était bien dimensionné. Mais personne n'avait regardé les logs avec les yeux d'un utilisateur.
Bloquer les bots par IP est un jeu sans fin. Les protéger avec des règles métier et du rate limiting — des contraintes qui correspondent à l'usage humain réel — c'est une solution durable, simple, et que les vrais utilisateurs ne ressentent même pas.
On crée du code pour des besoins métier. L'audit sert à s'en souvenir.
