Dépannage PrestaShop de la boutique Sellerie GZ

Dépannage de la boutique Sellerie GZ, sellerie en ligne installée à Entressen, sur la commune d'Istres, qui équipe le cheval, le cavalier et l'écurie.

La boutique devenait inaccessible par périodes de plusieurs minutes à plusieurs heures, sans régularité apparente, entrecoupées de phases de lenteur sévère. L'hébergeur, après analyse de ses propres outils, concluait que « le serveur fonctionne correctement ».

C'était exact — et c'est précisément ce qui rendait le diagnostic difficile. Le serveur n'était ni en panne ni défaillant : il était occupé à traiter du trafic illégitime. Seule l'analyse des journaux d'accès bruts pouvait le démontrer.

L'enquête, phase par phase

Chaque phase correspond à une cause réellement distincte. La résolution de l'une révélait la suivante, jusque-là masquée par la précédente.

Phase 1 — Les robots d'indexation saturent la navigation à facettes

Juin — 68 564 requêtes par jour, dont 2 016 erreurs 503 et 27 849 erreurs 404, soit 41 % du trafic. Le fichier robots.txt répondait 404.

Les erreurs 503 frappaient exclusivement les pages catégorie dotées de filtres — la navigation à facettes, qui génère les requêtes SQL les plus coûteuses de PrestaShop. Un robot d'indexation y consacrait 83 % de ses requêtes, à raison d'une toutes les deux secondes.

Deux causes structurelles aggravaient le tout : aucun fichier robots.txt, ce qui privait les robots de toute consigne d'exploration, et un module d'import défaillant qui fabriquait des milliers d'URL invalides — 4 533 erreurs 404 à lui seul.

Correctif : rédaction d'un robots.txt interdisant l'exploration des URL à paramètres, règles serveur renvoyant 410 Gone sur les URL parasites, neutralisation du module défaillant.

Phase 2 — Un crawler d'IA consomme les deux tiers du serveur

Juillet — 56 480 requêtes par jour, soit 68 % du trafic total, dont 99,7 % dirigées vers les pages à facettes, à 180 requêtes par minute réparties sur 54 adresses IP.

Les 404 avaient chuté de 41 % à 3,5 % : la phase 1 était réglée. Mais les 503 persistaient. Le nouveau responsable était un robot d'entraînement d'intelligence artificielle, qui représentait à lui seul plus des deux tiers du trafic du site et concentrait la quasi-totalité de ses requêtes sur les pages les plus lourdes.

Point décisif pour la boutique : ce robot ne participe pas au référencement. Le bloquer n'affecte ni Google, ni Bing, ni les aperçus de liens sur les réseaux sociaux, qui utilisent des agents distincts — explicitement préservés.

Correctif : blocage ciblé par User-Agent au niveau serveur, avec réponse 403 immédiate, sans exécution de PHP ni requête SQL, doublé d'une directive dans le robots.txt. Le trafic du crawler est tombé à zéro et les erreurs 503 ont disparu.

Phase 3 — Une attaque par épuisement de connexions

29 juillet — 23 458 connexions en 408 Request Timeout, réparties sur 23 417 adresses IP distinctes. Le trafic légitime passe de 2 000 à 13 visites par heure.

Nouvelle panne, cause entièrement différente : des dizaines de milliers de connexions ouvertes n'envoyant jamais de requête HTTP complète, chaque adresse ne frappant qu'une seule fois. C'est la signature d'un botnet distribué menant une attaque par épuisement de ressources, de type Slowloris.

64.145.x.x  - - [29/Jul/2026:00:01:13] "-" 408 5308 "-" "-"
209.101.x.x - - [29/Jul/2026:00:01:21] "-" 408 5308 "-" "-"

Chaque connexion morte immobilisait un processus serveur jusqu'à expiration du délai d'attente. La corrélation est sans appel : à l'heure où l'attaque démarre, la fréquentation réelle s'effondre.

Particularité de cette attaque : les protections applicatives sont totalement inopérantes. Sans requête HTTP, il n'y a ni URL ni User-Agent à filtrer — et avec plus de 23 000 adresses à frappe unique, le blocage par IP est illusoire.

Correctif : mise en place d'un CDN filtrant en amont du serveur, seule réponse structurelle à ce type d'attaque, et réduction des délais d'attente pour libérer les processus plus rapidement.

Phase 4 — Le botnet contourne le CDN par l'adresse d'origine

5 et 6 août — 122 376 requêtes, dont 95,6 % hors CDN, depuis 112 817 adresses IP distinctes, à 98 % sur les pages à facettes.

Le CDN était en place, mais le site retombait. L'analyse a montré que l'essentiel du trafic ne passait pas par lui : l'attaquant avait découvert l'adresse réelle du serveur et s'y connectait directement, court-circuitant intégralement la protection. Un CDN dont l'origine reste joignable ne protège rien.

Le trafic provenait d'un botnet aux User-Agents falsifiés, et grossièrement : des combinaisons techniquement impossibles, comme Internet Explorer 9 sous Windows 98. Son objectif était d'énumérer méthodiquement toutes les combinaisons de filtres du catalogue. Une seule catégorie concentrait 86 % du trafic du site.

Correctif : verrouillage du pare-feu, les ports web n'acceptant plus que les plages d'adresses officielles du CDN. Le trafic direct est passé de 117 027 requêtes à 46. Puis règle de filtrage applicative sur les URL à facettes, laissant passer les moteurs de recherche vérifiés.

Au-delà des attaques : la dette de performance

Le trafic illégitime écarté, restait la lenteur de fond. L'analyse du journal des requêtes lentes a mis au jour trois gisements distincts.

Une inefficacité dans le cœur de PrestaShop d'abord : la récupération des déclinaisons de couleur exécutait deux fois la même requête SQL par produit, sans aucune mise en cache — soit, sur une page catégorie, des dizaines de requêtes évitables. Corrigé par une surcharge de classe avec cache, sans le moindre impact visuel.

Un module de statistiques natif ensuite, qui effectuait des écritures en base de données à chaque clic visiteur.

Des index de recherche et de filtres non entretenus enfin, dont un cache de 92 Mo. Ils ont été reconstruits et non supprimés — la distinction est cruciale, ce sont des index nécessaires, pas des déchets — puis confiés à des tâches planifiées nocturnes.

Résultats

Mesures issues des journaux d'accès, à la date du 6 août 2026.

Le site a retrouvé sa disponibilité, et le durcissement se poursuit : filtrage applicatif des URL à facettes, allègement des modules et maintenance automatisée des index.

Ce que ce cas enseigne

« Le serveur fonctionne » n'est pas un diagnostic. Les outils de l'hébergeur mesuraient la santé de la machine, pas la légitimité du trafic. Seule l'analyse des journaux d'accès a permis d'identifier les causes réelles.

Un CDN sans origine verrouillée est décoratif. Tant que l'adresse du serveur reste joignable, un attaquant contourne la protection. Le verrouillage du pare-feu est indissociable de la mise en place du CDN.

La navigation à facettes est la cible privilégiée. Les URL à filtres combinés génèrent un nombre quasi infini de pages coûteuses. Non encadrées, elles constituent le point de rupture des boutiques en ligne, et un gouffre de budget d'exploration.

Bloquer les robots d'IA ne coûte rien au référencement. Les crawlers d'entraînement sont distincts des moteurs de recherche. Les écarter soulage le serveur sans aucune conséquence sur la visibilité.