Cet été, la boutique Sellerie GZ devenait injoignable plusieurs heures par jour. Pas en panne franche — c'eût été plus simple — mais par intermittence, sans régularité, entrecoupée de phases où tout ramait sans raison apparente.
L'hébergeur avait regardé ses outils et conclu que le serveur fonctionnait correctement. Il avait raison. C'est précisément ce qui a rendu le diagnostic long : la machine n'était pas défaillante, elle était occupée à traiter du trafic qui n'avait rien à faire là.
Il a fallu trois mois et plus de 500 000 lignes de journaux d'accès pour comprendre. Et le résultat n'a pas été celui qu'on attend : il n'y avait pas un problème, mais quatre, sans rapport entre eux, dont chacun ne s'est révélé qu'une fois le précédent réglé.
Une enquête à quatre étages
En juin, les erreurs frappaient exclusivement les pages catégorie dotées de
filtres. Un robot d'indexation y consacrait l'essentiel de ses requêtes, à raison
d'une toutes les deux secondes, et le site n'avait tout simplement aucun
fichier robots.txt — il répondait 404, ce qui revenait à laisser la porte
ouverte sans consigne. Un module d'import
défaillant fabriquait par
ailleurs des milliers d'URL invalides. À elles deux, ces causes produisaient 41 % de requêtes
en erreur.
En juillet, une fois cela réglé, les erreurs 404 étaient tombées de 41 % à 3,5 %. Mais les coupures continuaient. Le responsable était cette fois un robot d'entraînement d'intelligence artificielle qui représentait à lui seul 68 % du trafic total du site, et dirigeait 99,7 % de ses requêtes vers les pages les plus lourdes à produire. C'est un phénomène de fond, que j'ai détaillé dans un article à part.
Le 29 juillet, nouvelle panne, cause entièrement différente : plus de 23 000 connexions ouvertes sans jamais envoyer de requête complète, chacune depuis une adresse distincte ne frappant qu'une seule fois. Une attaque par épuisement de ressources, menée par un botnet. Pendant qu'elle durait, la fréquentation réelle est tombée de 2 000 à 13 visites par heure.
Les 5 et 6 août, enfin, alors qu'un CDN venait d'être mis en place pour filtrer le trafic en amont, le site est retombé. L'attaquant avait trouvé l'adresse réelle du serveur et s'y connectait directement, contournant intégralement la protection : 95,6 % du trafic ne passait plus par le filtre.
Trois enseignements qui dépassent ce cas
« Le serveur fonctionne » n'est pas un diagnostic. Les tableaux de bord des hébergeurs mesurent la santé de la machine : processeur, mémoire, disques. Aucun ne distingue une requête légitime d'une requête parasite. Cette réponse est sincère et techniquement exacte — elle ne dit simplement rien du problème.
Un CDN dont l'origine reste joignable ne protège rien. C'est l'erreur la plus répandue, et elle est invisible tant que personne ne cherche. Mettre un filtre devant son serveur ne sert à rien si le serveur reste accessible en direct : il suffit de connaître son adresse. Le verrouillage du pare-feu est indissociable de la mise en place du CDN, pas une option à traiter plus tard. Une fois fait, le trafic direct est passé de 117 027 requêtes à 46.
La navigation à facettes est le point de rupture des boutiques en ligne. Les filtres par taille, couleur ou marque produisent en se combinant un nombre quasi infini d'URL, toutes uniques aux yeux d'un robot, et toutes coûteuses à produire. Non encadrées, elles transforment n'importe quel visiteur automatique en charge ingérable. Sur Sellerie GZ, une seule catégorie concentrait 86 % du trafic du site.
Ce qui restait une fois le calme revenu
Le trafic illégitime écarté, la lenteur de fond était toujours là — et elle n'avait rien à voir avec les attaques.
Le cœur de PrestaShop exécutait deux fois la même requête SQL par produit pour récupérer les déclinaisons de couleur, sans aucune mise en cache : sur une page catégorie, des dizaines de requêtes évitables. Un module de statistiques natif écrivait en base de données à chaque clic de visiteur. Et les index de recherche, jamais entretenus, avaient accumulé un cache de 92 Mo.
Ces trois-là ne provoquaient aucune panne. Ils rendaient simplement le site lent en permanence, ce qui est plus difficile à voir et plus coûteux à long terme.
Un site lent, ou indisponible par intermittence ?
Si votre boutique subit des ralentissements inexpliqués, des erreurs 503 ou une charge serveur qui ne retombe pas la nuit, la cause se trouve dans les journaux, pas dans les suppositions. Elle est souvent très éloignée de celle que l'on soupçonne.
Le détail technique complet de cette intervention — les quatre phases, les mesures et les correctifs — est publié dans la réalisation correspondante.