Un visiteur tape trois lettres dans votre barre de recherche. Il attend. Cinq secondes. Huit. Parfois dix. Sur mobile, dans le train, il est déjà parti.

Ce scénario n’a rien d’exceptionnel : c’est le comportement normal de la recherche native de PrestaShop dès que le catalogue dépasse quelques dizaines de milliers de références. Le moteur n’est pas cassé, il fait exactement ce pour quoi il a été conçu. Il n’a simplement pas été conçu pour cette taille.

Cet article raconte ce qu’on fait à ce moment-là. Comment on diagnostique le décrochage, pourquoi Elasticsearch règle le problème, ce que ça coûte réellement, et les trois usages qu’on en a tirés sur deux boutiques de 30 000 produits : la recherche, l’affichage des listings, et depuis peu un assistant produit fondé sur un modèle de langage.

La recherche native de PrestaShop décroche pour une raison structurelle, pas par manque d’optimisation. Elle repose sur des tables d’index qui gonflent avec le produit du nombre de références par le nombre de déclinaisons, et sur des recherches textuelles que la base de données ne peut pas indexer efficacement. À 30 000 produits avec des déclinaisons, on passe de la lenteur à l’indisponibilité.

Elasticsearch n’est pas une barre de recherche, c’est une couche d’accès au catalogue. Sur nos deux intégrations, il sert la recherche, mais aussi les pages catégorie et les filtres à facettes. C’est là que se joue l’essentiel du gain, et c’est ce que la plupart des présentations du sujet passent sous silence.

Le même index alimente désormais un assistant produit. Un moteur de recherche bien construit est aussi la source de données dont un modèle de langage a besoin pour répondre correctement. C’est le chantier sur lequel nous sommes en ce moment, et nous en parlons plus bas sans en faire une promesse.

PrestaShop maintient ses propres tables d’index de recherche. À chaque enregistrement de produit, le moteur découpe les textes en mots et alimente ces tables, qui associent chaque mot aux produits où il apparaît. Le principe est sain, et il fonctionne très bien sur un catalogue de quelques centaines ou quelques milliers de références.

Trois choses se dégradent ensemble quand le catalogue grossit.

Le volume de la table d’index explose. Elle ne croît pas avec le nombre de produits, mais avec le nombre de produits multiplié par la richesse textuelle de chacun : nom, descriptions, attributs, caractéristiques, marque. Sur un catalogue mode où chaque modèle existe en huit tailles et six coloris, la combinatoire des déclinaisons fait le reste.

Les requêtes deviennent des jointures lourdes. Pour produire une page de résultats, la base doit croiser l’index de recherche, les produits, leurs déclinaisons, leurs attributs, leurs stocks, leurs prix, leurs catégories et leurs images. Chaque jointure supplémentaire coûte, et ce coût n’est pas linéaire.

La recherche partielle n’est pas indexable. Chercher un mot où qu’il se trouve dans un texte oblige la base à parcourir séquentiellement, sans pouvoir s’appuyer sur ses index. C’est la différence entre chercher un mot dans l’index d’un livre et lire le livre en entier. À faible volume, personne ne le remarque. À 30 000 fiches, la lecture prend dix secondes.

Le symptôme apparaît d’abord sur la recherche, parce que c’est là que les requêtes sont les plus coûteuses. Mais il ne reste pas confiné.

Sur les deux boutiques, les pages catégorie étaient touchées elles aussi. C’est logique : afficher une liste filtrée de produits mobilise les mêmes jointures, avec en plus le calcul des facettes, c’est-à-dire le décompte du nombre de produits restants pour chaque valeur de chaque filtre. Ce calcul doit être refait à chaque changement de sélection.

Le stade suivant, nous l’avons vu : le serveur qui tombe. Des requêtes longues qui s’empilent, un pic de trafic, et la base ne rend plus la main. La boutique renvoie alors une erreur serveur, avec toutes les conséquences que ça implique. Si c’est votre situation actuelle, notre guide de diagnostic des erreurs 500 traite la panne elle-même ; le présent article traite la cause.

Une recherche interne lente n’est donc pas seulement un inconfort de navigation. C’est un facteur de fragilité de l’ensemble de la boutique, et personne ne le formule comme ça parce que le lien de cause à effet n’est pas visible depuis le back-office.

Elasticsearch est un moteur de recherche qui tourne sur son propre serveur, à côté de votre boutique. On lui envoie une copie du catalogue sous une forme qu’il sait interroger très vite, et la boutique vient lui poser des questions au lieu de les poser à sa base de données.

La différence tient à la structure. Une base de données relationnelle est organisée pour garantir l’intégrité des données : une commande ne peut pas exister sans client, un stock ne peut pas être négatif. Cette rigueur a un coût quand il s’agit de fouiller du texte. Un moteur de recherche, lui, est organisé pour répondre vite à la question « où apparaît ce mot », au prix d’une copie des données et d’un décalage de quelques secondes avec la source.

Ce compromis est exactement le bon pour un catalogue produit. Vous n’avez pas besoin que la liste des résultats soit juste à la milliseconde près. Vous avez besoin qu’elle s’affiche avant que le visiteur ne parte.

Point à connaître si la question de l’indépendance vous préoccupe : Elastic a ajouté en septembre 2024 la licence AGPLv3 aux options de licence d’Elasticsearch, ce qui referme le débat ouvert en 2021 sur le caractère open source du projet. Vous pouvez l’installer sur vos propres serveurs, sans abonnement, sans dépendance à un éditeur.

C’est le gain le plus spectaculaire et le plus facile à mesurer. Sur nos deux intégrations, une recherche qui demandait cinq à dix secondes au moteur natif s’exécute désormais en moins d’une seconde, catalogue de 30 000 références inclus.

Ce que le natif ne savait pas faire et que l’index permet : encaisser une faute de frappe sans renvoyer une page vide, traiter les synonymes métier — le vocabulaire du client n’est jamais celui du catalogue —, chercher sur une référence constructeur aussi bien que sur un nom commercial, et proposer une autocomplétion qui affiche des résultats pendant la frappe plutôt qu’après validation.

Un effet secondaire mérite d’être signalé, parce qu’il concerne vos équipes autant que vos clients : la recherche produit du back-office bénéficie du même traitement. Sur un catalogue de cette taille, une gestionnaire qui cherche une référence dix fois par jour récupère un temps qui ne se voit sur aucun tableau de bord mais qui compte.

C’est la partie la plus intéressante techniquement, et la plus rentable en pratique. Vos pages catégorie reçoivent beaucoup plus de visiteurs que votre barre de recherche. Accélérer la recherche seule, c’est optimiser une porte que peu de gens empruntent.

Sur nos deux boutiques, nous avons donc remplacé le module de filtres natif de PrestaShop par un module développé sur mesure. Le principe : la boutique interroge Elasticsearch, qui renvoie un JSON contenant les produits correspondants et les décomptes de facettes, et PrestaShop utilise ce JSON pour générer sa page. Les requêtes SQL lourdes disparaissent du chemin critique.

Une précision d’honnêteté, parce qu’elle compte. Ce module ne fait rien que le natif ne savait pas faire fonctionnellement. Les filtres ne sont pas plus riches, les critères pas plus nombreux. Ce qui change, c’est uniquement la vitesse — et la capacité à encaisser la croissance du catalogue sans que la situation ne se dégrade à nouveau. Si quelqu’un vous vend Elasticsearch en promettant des fonctionnalités inédites côté filtres, demandez-lui lesquelles précisément.

Un catalogue bien indexé est aussi ce dont un modèle de langage a besoin pour répondre correctement. C’est le constat qui nous a menés au troisième usage.

Le montage : un modèle Llama installé sur un VPS que nous administrons, connecté à l’index Elasticsearch de la boutique. Un visiteur pose une question en langage naturel sur un produit ou une catégorie. Le système va chercher dans l’index les fiches pertinentes, les transmet au modèle, et le modèle formule une réponse à partir de ces fiches uniquement. C’est le principe du RAG, la génération augmentée par la récupération : le modèle ne répond pas de mémoire, il répond à partir de votre catalogue.

Ce qui est indexé pour alimenter les réponses : nom du produit, prix, caractéristiques, attributs, marque, description courte, description longue, image. Autrement dit, la qualité des réponses dépend directement de la qualité de vos fiches produit. Une boutique aux descriptifs indigents obtiendra un assistant indigent, et aucune technologie ne comblera ce trou.

L’état réel du chantier. Le dispositif fonctionne, il n’est pas encore en production. Deux difficultés : le modèle est lourd à faire tourner, et il demande un cadrage sérieux pour rester dans les clous du catalogue plutôt que de broder. La latence est perceptible, acceptable pour une consultation, pas encore pour un usage à la volée. Nous sommes en phase de finalisation et il passera vraisemblablement en production.

Nous en parlons parce que c’est la direction que prend la recherche e-commerce, et parce que le prérequis est justement celui décrit dans cet article : sans index structuré, pas d’assistant fiable. Si le sujet de l’IA appliquée à vos outils métier vous intéresse au-delà du catalogue, c’est le terrain de notre accompagnement en automatisation.

Cette section décrit le fonctionnement concret de nos intégrations. Si vous êtes dirigeant et que les termes qui suivent ne vous parlent pas, sautez-la : la section suivante reprend au niveau des coûts et des arbitrages.

Un serveur dédié, jamais mutualisé. Elasticsearch tourne sur un VPS distinct de la boutique, avec sa mémoire propre. Le dialogue se fait par API. Une installation sur un hébergement mutualisé n’a aucun sens : le moteur réclame de la RAM en continu et un contrôle du processus que ces offres n’accordent pas.

Une double stratégie de synchronisation. Une réindexation complète du catalogue s’exécute chaque nuit — trente minutes environ pour 30 000 produits. Elle sert de filet de sécurité : quoi qu’il se soit passé dans la journée, l’index repart propre. En complément, un module sur mesure accroche les hooks produit de PrestaShop et pousse les mises à jour à l’unité dès qu’une donnée change. Le stock et le prix, qui bougent en permanence, passent par ce canal. Un produit tombé en rupture disparaît des listings sans attendre la nuit.

Un JSON en sortie, pas une page. Elasticsearch renvoie les produits et les décomptes de facettes sous forme de JSON. C’est PrestaShop qui construit la page à partir de ces données. Le thème, les templates et le fonctionnement du back-office restent inchangés : on remplace la source des données, pas l’affichage. C’est ce qui rend l’intervention réversible.

Un repli automatique sur le natif. Si le serveur Elasticsearch ne répond plus, le module bascule sur la recherche native de PrestaShop. La boutique redevient lente, elle ne devient pas inutilisable. C’est le point à exiger de quiconque vous propose ce type d’intégration : sans repli, vous avez déplacé votre point de défaillance unique, vous ne l’avez pas supprimé.

Deux à trois semaines de développement pour l’ensemble — module d’indexation, hooks de synchronisation, remplacement des facettes, recette. La durée dépend surtout de l’état du thème existant et du nombre d’attributs à cartographier.

Algolia est la référence du marché en solution hébergée. C’est excellent, c’est rapide, et c’est aussi une dépendance : vos données de catalogue partent chez un tiers, la facturation suit le volume de requêtes, et le jour où vous voulez modifier le comportement du moteur, vous faites avec ce qui est prévu. Nous ne l’avons pas retenu pour cette raison, pas pour une raison technique. Sur des projets où l’équipe cliente n’a aucune compétence d’exploitation et veut zéro serveur à gérer, l’arbitrage peut basculer dans l’autre sens.

Les modules de recherche du marché coûtent quelques centaines d’euros et améliorent réellement le natif. Ils restent moins performants sur les gros volumes, parce que la plupart continuent de s’appuyer sur la base de données. En dessous de quelques milliers de références, ils suffisent souvent. Au-delà, ils repoussent le mur sans le supprimer.

Meilisearch et Typesense sont des moteurs plus légers, réputés plus simples à exploiter, et régulièrement cités comme des alternatives crédibles sur des catalogues de taille moyenne. Nous ne les avons pas mis en œuvre et nous ne porterons pas de jugement sur ce que nous n’avons pas éprouvé en production.

OpenSearch, né du fork d’Elasticsearch par AWS en 2021 et placé sous gouvernance de la Linux Foundation en 2024, est très proche fonctionnellement. Le débat de licence qui justifiait historiquement de le préférer s’est en grande partie éteint avec le retour d’Elasticsearch sous licence open source.

Sur le fond, un moteur de recherche externe n’est jamais un mauvais investissement : une fois le système en place, il absorbe la croissance du catalogue sans plafond visible. Passer de 30 000 à 100 000 références ne change pas l’architecture, seulement la taille de l’index.

Mais le critère de décision n’est pas la taille du catalogue, c’est le ressenti mesuré. Si vos pages catégorie s’affichent rapidement, si vos facettes répondent instantanément et si votre recherche rend la main en moins d’une seconde, vous n’avez rien à gagner. Ajouter un serveur, un flux de synchronisation et un module sur mesure à une boutique qui va bien, c’est ajouter trois choses qui peuvent tomber en panne pour résoudre un problème que vous n’avez pas.

Avant d’engager le chantier, vérifiez aussi que le ralentissement n’a pas une cause plus simple : un hébergement sous-dimensionné, un cache mal configuré, un module tiers qui plombe chaque chargement de page. Un moteur de recherche externe n’effacera pas ces problèmes, il les masquera pendant quelques mois.

La bonne séquence est donc : mesurer, identifier la cause, et seulement ensuite décider. C’est ce que nous faisons en audit, et il nous arrive de conclure que le sujet est ailleurs.

Une erreur 500 signifie que le serveur a bien reçu votre requête, mais que l’exécution du code PHP s’est interrompue avant de produire une page. Le message est volontairement muet : PrestaShop, en mode production, masque les détails techniques pour ne pas exposer votre infrastructure aux curieux.

La méthode tient en trois temps : on rend l’erreur visible (mode debug), on lit ce qu’elle raconte (logs applicatifs et serveur), on corrige la cause identifiée. Sauter la première étape et bricoler au hasard est le meilleur moyen de transformer une panne de dix minutes en week-end perdu.

Dans la pratique, l’écrasante majorité des erreurs 500 sur PrestaShop remonte à un module fraîchement installé ou mis à jour, à un changement de version PHP côté hébergeur, ou à un cache Symfony corrompu. Trois causes, trois corrections rapides.

L’erreur 500 (« Internal Server Error », parfois « HTTP ERROR 500 » selon le navigateur) est une erreur fatale PHP ou une directive serveur invalide. Le code s’est arrêté net.

La page blanche, l’écran totalement vide sans le moindre message, est presque toujours la même chose qu’une 500, à ceci près que l’affichage des erreurs est désactivé et que le serveur renvoie un code 200. Le traitement est identique : mode debug, puis logs.

L’erreur 503 signale un service temporairement indisponible : mode maintenance activé, PHP-FPM saturé, ou serveur en surcharge. Ce n’est pas un bug de code, c’est un problème de disponibilité ou de charge.

Une nuance à connaître si vous passez par Cloudflare ou un CDN : une erreur 520 ou 521 vient de l’intermédiaire, pas de votre boutique. Testez toujours en accédant au site en direct avant de chercher dans le code.

Un point que les guides techniques oublient systématiquement, et qui compte pour un e-commerçant. Googlebot interprète une erreur 500 comme un incident serveur temporaire : il réduit sa fréquence de crawl et repasse plus tard. Sur quelques heures, l’impact SEO est nul. Si la panne dure plusieurs jours, en revanche, les pages concernées commencent à sortir de l’index et le retour en position n’est pas instantané.

Traduction concrète : vous avez le droit de prendre trente minutes pour diagnostiquer proprement plutôt que de paniquer. Vous n’avez pas le droit de laisser traîner une semaine.

Ce classement suit l’ordre dans lequel nous testons en intervention : du plus fréquent et du plus rapide à vérifier, vers le plus rare et le plus lourd. Suivez-le dans l’ordre, vous éviterez de démonter votre serveur pour un module à cinquante euros.

C’est contre-intuitif quand le chiffre d’affaires s’arrête, mais une manipulation ratée sur une boutique en panne peut transformer une erreur 500 en perte de données. Copiez le dossier config/, le dossier override/ et exportez la base. Dix minutes, et vous travaillez sans filet en moins.

Si votre hébergeur propose des snapshots automatiques, notez l’horodatage de la dernière sauvegarde saine avant d’intervenir. C’est votre point de retour.

Une erreur 500 ne surgit jamais de nulle part. Il y a toujours un événement déclencheur, et il s’est produit dans les heures qui précèdent : installation de module, mise à jour PrestaShop, modification de thème, changement de version PHP, migration d’hébergement, import de catalogue, ou pic de trafic.

Reconstituez cette chronologie avant d’ouvrir un seul fichier. Dans la plupart des cas, elle vous donne directement le coupable, et les étapes suivantes ne servent qu’à le confirmer.

Tant que la boutique renvoie une erreur 500, chaque visiteur repart avec une mauvaise impression et chaque passage de Googlebot enregistre un incident. Si vous avez encore accès au back-office, activez le mode maintenance : PrestaShop renvoie alors un code 503 avec un message propre, ce que Google interprète correctement comme une indisponibilité temporaire.

Si le back-office est lui aussi hors service, un .htaccess de redirection vers une page statique fait l’affaire, à condition de ne pas oublier de le retirer après réparation.

Par défaut, PrestaShop masque le détail des erreurs en production. C’est un choix de sécurité parfaitement justifié : une stack trace expose vos chemins serveur, vos versions de bibliothèques et parfois vos identifiants. Mais tant qu’il est actif, vous cherchez une aiguille dans le noir.

Le mode debug bascule une constante, _PS_MODE_DEV_, de false à true. Le message générique laisse alors place au fichier fautif, au numéro de ligne et à la chaîne d’appels qui a mené à l’erreur.

Si l’administration répond, c’est la voie la plus sûre. Rendez-vous dans Paramètres avancés > Performances, section Mode debug, et basculez l’interrupteur sur Oui. Rechargez ensuite la page en erreur.

Si le back-office est bloqué, connectez-vous en FTP ou SSH et ouvrez le fichier config/defines.inc.php à la racine de votre boutique. Cherchez, généralement dans les trente premières lignes, la déclaration define('_PS_MODE_DEV_', false); puis remplacez false par true, enregistrez et rechargez la page en erreur.

Ce chemin est identique de PrestaShop 1.5 à PrestaShop 9. Sur une installation 1.4 ou antérieure (cela existe encore), le fichier concerné est config/config.inc.php.

Activer le debug sur une boutique en production, c’est afficher vos entrailles techniques à tous les visiteurs, y compris à ceux qui scannent le web à la recherche de sites vulnérables. La parade consiste à conditionner la constante à votre adresse IP : au lieu de false, écrivez $_SERVER['REMOTE_ADDR'] === '203.0.113.42' en remplaçant l’adresse par la vôtre. Un service comme « quelle est mon IP » vous la donne en une seconde.

Les visiteurs continuent de voir la page d’erreur générique, vous seul voyez la stack trace.

Soit le cache n’a pas été vidé et PrestaShop sert une page compilée antérieure : supprimez le contenu de var/cache/prod/ (PrestaShop 1.7 et supérieur) ou de cache/smarty/compile/ et cache/smarty/cache/ (PrestaShop 1.6).

Soit l’erreur se produit avant le chargement de defines.inc.php, typiquement une directive .htaccess invalide ou un problème de connexion à la base.

Soit votre hébergeur force display_errors à off au niveau serveur, et il faut alors passer par les logs. Dans ces trois cas, direction l’étape 2.

Le mode debug affiche l’erreur à l’écran. Les logs, eux, la conservent, y compris celles survenues cette nuit à trois heures pendant un cron d’import. Sur une panne intermittente, ils sont votre seule source fiable.

Sur PrestaShop 1.7, 8 et 9, tout se trouve dans var/logs/. Vous y verrez des fichiers nommés selon l’environnement et la date, du type prod-2026-08-06.log. Ouvrez le plus récent et allez directement à la fin : les dernières lignes correspondent à l’erreur que vous venez de déclencher en rechargeant la page. Sur PrestaShop 1.6, le dossier est simplement log/, avec des fichiers d’exception horodatés.

En SSH, tail -n 50 var/logs/prod-$(date +%Y-%m-%d).log vous affiche les cinquante dernières lignes.

Ce sont eux qui capturent les erreurs survenues avant que PrestaShop ne démarre : .htaccess invalide, PHP-FPM qui refuse de se lancer, extension manquante. Une erreur 500 absente des logs PrestaShop mais présente dans les logs serveur pointe presque toujours vers la configuration, pas vers le code.

Leur emplacement dépend entièrement de l’hébergeur. Sur un serveur dédié ou un VPS, le chemin classique est /var/log/apache2/error.log sous Apache, /var/log/nginx/error.log sous Nginx. Pensez aussi à /var/log/php8.x-fpm.log : les erreurs de démarrage de PHP-FPM n’apparaissent nulle part ailleurs.

Enfin, quel que soit l’hébergeur, certaines configurations déposent un fichier error_log directement dans le répertoire où l’erreur s’est produite. Cherchez-le à la racine du site et dans le dossier admin/.

Sur un hébergement mutualisé OVH. Connectez-vous en FTP : à la racine du compte, à côté du dossier www/, se trouve un dossier logs/. Il contient les journaux classés par mois, sous la forme <votredomaine>.log et surtout <votredomaine>-errors.log. C’est ce second fichier qui vous intéresse. Le même contenu est consultable depuis l’espace client OVH, rubrique Hébergements > Statistiques et logs, avec un accès sécurisé par mot de passe distinct de vos identifiants FTP.

Particularité OVH à connaître absolument : la version PHP n’est pas seulement définie dans l’espace client, elle peut être forcée par un fichier .ovhconfig placé à la racine du site, via la directive app.engine.version. Un fichier .ovhconfig oublié ou hérité d’une ancienne installation surcharge silencieusement le réglage du panneau. Nous avons vu plus d’une boutique rester bloquée sur une version PHP obsolète pour cette raison, alors que le client était persuadé d’avoir changé de version.

Sur un hébergement Infomaniak. Les journaux se consultent depuis le Manager, dans la section de votre hébergement web, rubrique Logs : erreurs et accès y sont téléchargeables directement. La version PHP se règle par site dans les paramètres avancés de l’hébergement, et non globalement. Un détail qui compte si vous hébergez plusieurs domaines sur la même offre, puisqu’un changement appliqué au mauvais site ne produira évidemment aucun effet sur la boutique en panne.

Le message d’erreur en tête, puis le fichier et la ligne concernés, puis la chaîne d’appels qui remonte jusqu’à l’origine. Vous cherchez deux choses : la nature de l’erreur, et un chemin de fichier contenant modules/ ou override/, parce que c’est là que se cachent 80 % des coupables.

Allowed memory size of X bytes exhausted : le script a dépassé la mémoire allouée. Cause n° 4.

Class 'X' not found ou Call to undefined method : un module appelle du code qui n’existe pas ou plus. Typiquement un module conçu pour PrestaShop 1.7 installé sur une version 8, ou l’inverse. Causes n° 1 et 6.

syntax error, unexpected... : du code PHP invalide. Soit un fichier corrompu pendant un transfert FTP, soit, bien plus fréquent, du code écrit pour une version PHP différente de celle qui tourne. Cause n° 2.

Cannot redeclare class : deux overrides déclarent la même classe. Deux modules se marchent dessus. Cause n° 6.

Invalid command 'php_value' dans les logs Apache : une directive PHP dans le .htaccess que le serveur refuse, cas classique quand l’hébergeur bascule de mod_php vers PHP-FPM. Cause n° 5.

SQLSTATE[HY000] [2002] ou Link to database cannot be established : la base ne répond pas ou les identifiants sont faux. Cause n° 10.

Uncaught Error: Call to undefined function intl_... : une extension PHP manque à l’appel. Cause n° 9.

C’est le suspect numéro un, et de loin. Un module mal codé, incompatible avec votre version de PrestaShop ou de PHP, suffit à mettre toute la boutique à terre. Le scénario type : vous installez ou mettez à jour un module, vous rechargez, écran d’erreur.

La correction. Connectez-vous en FTP, ouvrez modules/ et renommez le dossier du module suspect en lui ajoutant un suffixe, par exemple monmodule_off. PrestaShop ne le trouve plus et cesse de le charger. Videz ensuite var/cache/prod/ et rechargez.

Si vous ignorez quel module accuser, triez le dossier modules/ par date de modification : le plus récent est votre premier suspect. En SSH, ls -lt modules/ | head -20 vous le donne. Si la panne persiste, procédez par dichotomie : renommez modules/ entier en modules_off, créez un dossier modules/ vide, et vérifiez que le site remonte. Il ne remontera pas complètement, puisque PrestaShop a besoin de ses modules natifs, mais vous saurez si le problème vient bien de là. Réintroduisez ensuite les dossiers par moitiés successives.

Attention. Renommer un dossier ne désactive pas le module en base : PrestaShop le considère toujours comme actif. Une fois le site rétabli, désinstallez-le proprement depuis le back-office avant de supprimer les fichiers, sinon vous laissez des entrées orphelines dans la table ps_module et des hooks qui pointent dans le vide.

Deuxième cause la plus fréquente. Ce qui a changé, c’est la version PHP de votre serveur, modifiée par l’hébergeur au cours d’une maintenance ou par vous-même en cherchant à gagner en performance.

Chaque version de PrestaShop ne fonctionne que dans une plage PHP précise. PrestaShop 1.6 couvre PHP 5.4 à 7.1 ; les versions 1.7.0 à 1.7.6, de PHP 5.6 à 7.2 selon la sous-version ; la 1.7.7, de PHP 7.1 à 7.3 ; la 1.7.8, de PHP 7.1 à 7.4 ; les versions 8.0 et 8.1, de PHP 7.2.5 à 8.1 ; la 8.2, de PHP 8.1 à 8.2 ; et PrestaShop 9, de PHP 8.1 à 8.4.

PrestaShop 9, sorti en juin 2025, repose sur Symfony 6.4 LTS et réclame PHP 8.1 au minimum. À l’inverse, PrestaShop 1.7 plafonne à PHP 7.4 et ne peut pas fonctionner avec PHP 8.x. Le point est critique, puisque PHP 7.4 n’est plus maintenu depuis novembre 2022. Vérifiez toujours ces plages sur la documentation officielle avant une migration : elles évoluent avec les sous-versions.

La correction immédiate. Revenez à la version PHP qui fonctionnait. Chez OVH, cela se joue dans l’espace client Hébergements > Multisite, mais vérifiez d’abord qu’aucun fichier .ovhconfig à la racine ne surcharge ce réglage. Chez Infomaniak, la version se définit site par site dans les paramètres avancés. Sur un cPanel, la rubrique s’appelle « Select PHP Version ». Le site remonte en quelques secondes.

Si votre boutique tourne sous PrestaShop 1.7.8, vous êtes plafonné à PHP 7.4. Or PHP 7.4 n’a plus reçu le moindre correctif de sécurité depuis fin 2022. Le jour où votre hébergeur retire cette version de son catalogue, ce qui arrive sans préavis particulier, votre boutique tombe en erreur 500 et il n’existe aucun retour en arrière possible. Vous vous retrouvez alors à devoir migrer vers PrestaShop 8 dans l’urgence, boutique à l’arrêt, avec des modules à mettre à jour un par un. C’est le pire moment pour faire une migration, et c’est pourtant le scénario le plus courant que nous voyons arriver.

Si vous lisez ces lignes sans être en panne : vérifiez dès maintenant votre version dans Paramètres avancés > Informations. Une migration planifiée se mène en quelques jours sur un environnement de test. Une migration subie coûte plusieurs fois ce prix, en développement comme en chiffre d’affaires perdu.

Si vous êtes bloqué sur PHP 7.4 ou plus ancien, vous ne tournez pas seulement sur une configuration fragile : vous tournez sur une version PHP sans correctifs de sécurité depuis des années, sur un site qui traite des paiements. C’est un sujet de migration, pas de dépannage, et c’est exactement le genre de chantier que nous prenons en charge dans notre accompagnement PrestaShop.

Depuis PrestaShop 1.7, une partie du back-office et du routage repose sur Symfony, qui compile sa configuration dans un cache. Quand cette configuration change (mise à jour, nouveau module, changement de version PHP) et que le cache reste sur l’ancienne version, le décalage produit une erreur fatale.

La correction. En FTP, supprimez le dossier var/cache/prod/ dans son intégralité (le dossier prod, pas var/cache/ lui-même). PrestaShop le régénère à la requête suivante. En SSH, rm -rf var/cache/prod/* fait le travail.

Sur PrestaShop 1.6, l’équivalent consiste à vider cache/smarty/compile/ et cache/smarty/cache/, en conservant le fichier index.php de chaque dossier. Le premier chargement après purge sera lent, c’est normal : le cache se reconstruit.

Symptôme caractéristique : la régénération des vignettes, un import CSV volumineux, l’export de commandes, ou une page catégorie contenant des centaines de produits tombent en erreur, alors que le reste fonctionne. PrestaShop recommande d’allouer au minimum 256 Mo de mémoire par script. Beaucoup d’hébergements mutualisés livrent par défaut 128 Mo, voire 64.

La correction. Selon votre configuration, créez ou éditez un fichier .user.ini à la racine du site en y déclarant memory_limit = 512M et max_execution_time = 300. Sur un serveur avec php.ini accessible, modifiez-y directement les mêmes directives. Sur un mutualisé qui ne l’autorise pas, le panneau d’hébergement propose généralement ces réglages, ou il faut passer par le support.

Un avertissement : passer memory_limit à -1 ou à 4 Go n’est pas une solution, c’est un pansement. Si une page consomme 2 Go, il y a un module qui fuit ou une requête SQL non optimisée, et le problème reviendra avec les intérêts.

Le .htaccess est lu par Apache avant même que PHP ne démarre. Une seule directive qu’il ne comprend pas, et tout le site renvoie une 500, y compris les images et les fichiers CSS, ce qui est un excellent indice de diagnostic.

Le cas le plus courant : votre hébergeur bascule de mod_php vers PHP-FPM, et les directives php_value ou php_flag présentes dans le fichier deviennent illégales. Apache log alors Invalid command 'php_value'.

La correction. Renommez .htaccess en .htaccess_old et rechargez. Si le site remonte, vous tenez le coupable. Régénérez ensuite un fichier propre depuis le back-office : Paramètres de la boutique > SEO & URLs, puis enregistrez le formulaire sans rien modifier : PrestaShop réécrit le .htaccess à cette occasion.

Attention : si vous aviez des redirections 301 personnalisées dans l’ancien fichier, elles disparaissent. Ouvrez .htaccess_old et reportez-les manuellement à l’extérieur des blocs délimités par les commentaires de PrestaShop, qui sont écrasés à chaque régénération.

Le système d’override permet de modifier le comportement d’une classe PrestaShop sans toucher au cœur. Excellent principe, jusqu’au jour où deux modules décident de surcharger la même classe. PHP refuse alors de déclarer deux fois le même nom, et lève une erreur fatale.

La correction. Ouvrez le dossier override/ et repérez les fichiers récemment modifiés. Le message d’erreur vous indique généralement la classe concernée. Renommez ou déplacez le fichier fautif hors du dossier.

Point crucial que beaucoup oublient : PrestaShop maintient un index des overrides. Après toute modification du dossier, supprimez-le pour forcer sa reconstruction. Il se trouve dans var/cache/prod/class_index.php sur PrestaShop 1.7 et supérieur, dans cache/class_index.php sur PrestaShop 1.6. Sans cette suppression, votre correction ne prendra pas effet et vous conclurez à tort qu’elle n’a rien changé.

Après une restauration de sauvegarde, une migration de serveur ou un transfert FTP interrompu, les droits d’accès peuvent se retrouver dans un état que le serveur refuse. Apache et PHP-FPM rejettent notamment les fichiers accessibles en écriture à tous.

La correction. La règle est simple : 644 pour les fichiers, 755 pour les dossiers. En SSH, un find sur -type f avec -exec chmod 644, puis le même sur -type d avec -exec chmod 755, rétablissent l’ensemble en une passe.

Ne mettez jamais 777, sur aucun dossier, sous aucun prétexte. C’est un conseil qu’on lit encore sur des forums, et c’est une invitation ouverte à l’injection de fichiers malveillants. Sur une boutique qui manipule des paiements, le risque n’a aucune commune mesure avec le confort gagné.

Quand le disque est plein, PHP ne peut plus écrire ses fichiers de session ni son cache, et le serveur renvoie une 500. Indice révélateur : les logs eux-mêmes cessent de s’alimenter, ce qui rend le diagnostic déroutant.

La correction. Vérifiez l’espace disponible dans votre panneau d’hébergement, ou en SSH avec df -h. Les trois gisements classiques sur une boutique PrestaShop : le dossier var/logs/ quand personne n’a jamais fait de rotation, le dossier img/ rempli de vignettes de tous les formats jamais utilisés, et les sauvegardes générées depuis le back-office qui s’accumulent dans admin/backups/.

Une extension attendue par PrestaShop peut manquer à l’appel. Les indispensables sont intl, gd, curl, zip, mbstring, dom, fileinfo, iconv, simplexml, json, openssl et pdo_mysql.

La correction. Si le back-office répond, la page Paramètres avancés > Informations liste les extensions détectées et signale les manquantes. Sinon, déposez à la racine un fichier temporaire appelant phpinfo(), que vous supprimerez immédiatement après consultation, car il expose votre configuration serveur. L’activation se fait ensuite depuis le gestionnaire PHP de l’hébergement, ou via le support pour un mutualisé.

Plus rien ne répond, ni le front, ni le back, ni même l’installateur. Le message mentionne une connexion impossible ou un SQLSTATE.

La correction. Les identifiants se trouvent dans app/config/parameters.php sur PrestaShop 1.7 et supérieur, dans config/settings.inc.php sur PrestaShop 1.6. Vérifiez hôte, base, utilisateur et mot de passe contre ceux fournis par votre hébergeur. Ils changent lors d’une migration, et c’est le premier réflexe à avoir dans ce contexte.

Si les identifiants sont bons, le serveur MySQL est peut-être arrêté, ou vous avez atteint la limite de connexions simultanées de votre offre. Contactez l’hébergeur : ce n’est plus de votre ressort.