Tout dépend de votre point de départ. Que vous vouliez passer de PrestaShop 8 à 9 ou monter depuis la 1.7, la réponse honnête est : seulement avec une raison, et toujours après un test sur une copie.

Si votre boutique tourne bien et que vos modules sont compatibles, rien ne presse. Rester sur votre version est un choix valable. Les versions récentes apportent de vrais gains : rendu de page plus rapide, back-office modernisé et socle technique mis à jour. Le revers : la migration n'a rien d'un clic unique. Elle demande une vérification de la compatibilité des modules, une copie de préproduction de votre boutique et un test complet du tunnel de commande, des paiements et de vos modules clés avant de toucher à la production.

Notre règle : mettre à niveau quand vous avez besoin d'une fonction ou d'un correctif propre à la version récente, ou quand votre version approche de la fin de support, pas seulement pour afficher le dernier numéro. Quel que soit votre choix, ne lancez jamais la mise à niveau directement sur la boutique en ligne.

Pour la marche à suivre complète, lisez notre guide de migration vers PrestaShop 9.

PrestaShop 9 a besoin de PHP 8.1 comme minimum absolu ; la plage supportée va jusqu’aux dernières versions 8.x, avec la plus récente 8.x stable recommandée pour les nouvelles installations. Toute version antérieure à PHP 8.1 refusera de s’installer.

Si vous venez d’un ancien PrestaShop sous PHP 7.x, vous augmenterez presque toujours PHP en même temps. Avant de changer la version PHP sur votre hébergement :

• Vérifiez que chaque module installé déclare une compatibilité PHP 8.x. Les anciens modules tiers utilisant une syntaxe de l’ère PHP 7 (accès tableau par accolades, each(), nullables implicites) provoquent des erreurs fatales sur PHP 8.1+.
• Testez votre thème, les plugins Smarty dépréciés et les anciens appels create_function() échouent sur les PHP modernes.
• Augmentez memory_limit à au moins 512 MB pour le back-office et le processus de mise à niveau.

Assurez-vous que les extensions habituelles sont présentes : curl, dom, fileinfo, gd, iconv, intl, json, mbstring, openssl, pdo_mysql, simplexml et zip. Gardez allow_url_fopen activé pour les modules de paiement.

Pour le chemin complet, consultez notre guide de migration PrestaShop 9.

D’après la documentation officielle PrestaShop 9, PrestaShop 9.0 supporte PHP 8.1, 8.2 et 8.3 et recommande 8.4 ; PrestaShop 9.1 supporte PHP 8.1 à 8.4 et recommande 8.5. PHP 8.1 est donc le plancher, mais la meilleure cible dépend de la version exacte 9.x et des modules que vous utilisez. Pour une nouvelle boutique, choisissez la version mineure recommandée pour votre release PrestaShop au lieu d’installer le minimum simplement parce qu’il démarre.

Vérifications serveur rapides avant une migration :

php -v
php -m | egrep 'curl|dom|fileinfo|gd|intl|mbstring|openssl|pdo_mysql|simplexml|zip'
php -i | grep memory_limit

Faites le changement en staging d’abord, puis exécutez l’installateur ou l’upgrade, ouvrez le back-office, ouvrez les pages produit/catégorie/checkout, et lisez le log d’erreurs PHP. Une boutique peut respecter l’exigence PHP du cœur et quand même échouer parce qu’un ancien module de paiement, override de thème ou module personnalisé n’est pas compatible PHP 8.

Pour vider correctement le cache PrestaShop, commencez dans le back-office : Advanced Parameters > Performance, puis cliquez sur Clear cache. Cela suffit pour la plupart des changements de templates, traductions et configuration.

Lorsqu'un changement n'apparaît toujours pas, videz les couches plus profondes dans le bon ordre : les fichiers PrestaShop d'abord, puis OPcache, puis tout CDN, Varnish ou cache pleine page placé devant la boutique.

# Run from the PrestaShop root. This deletes cache contents, not the cache directories themselves.
find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +
find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

# Older PS 1.6-style installs may also use these Smarty paths:
find cache/smarty/compile -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +
find cache/smarty/cache -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

# Reset web OPcache by reloading the PHP service:
sudo systemctl reload php8.2-fpm

# Apache/mod_php alternative:
sudo systemctl reload apache2

Ne vous fiez pas à une commande opcache_reset() lancée uniquement en CLI, sauf si vous savez que PHP CLI et PHP web partagent le même pool OPcache. Sur un hébergement PHP-FPM normal, recharger PHP-FPM est la réinitialisation fiable. Après un nettoyage au niveau serveur, assurez-vous que l'utilisateur du serveur web peut encore écrire dans les répertoires de cache ; une mauvaise propriété après un nettoyage en root est une cause fréquente de nouvelles erreurs 500.

L'erreur courante consiste à vider uniquement le cache du back-office et à supposer qu'OPcache ou un proxy inverse a suivi. Ce n'est pas le cas. Si vous voulez automatiser le préchauffage du cache et la purge CDN au lieu de le faire à la main, Performance Revolution inclut une logique de préchauffage de cache et de purge CDN, et Redis Cache Manager & Monitor aide à gérer un backend de cache Redis.

Réponse courte : PrestaShop 8 est la génération la plus prudente pour les boutiques existantes. PrestaShop 9 est la génération de modernisation : Symfony plus récent, meilleur support PHP, orientation Admin API plus forte et front office qui évolue vers Hummingbird plutôt que l’écosystème centré sur Classic.

Faut-il choisir PrestaShop 8 ou 9 ?

Restez sur PrestaShop 8 si la boutique est déjà en production, fortement personnalisée ou dépend de modules qui n’ont pas encore été validés pour PrestaShop 9. Choisissez PrestaShop 9 pour une nouvelle boutique, une refonte préparée ou un projet où le thème, le checkout, les paiements et les intégrations sont déjà confirmés compatibles.

La bonne question n’est pas seulement « PrestaShop 9 est-il meilleur ? ». La vraie question est : « Cette boutique précise est-elle prête pour le saut architectural ? » Vérifiez les overrides de thème, modules de paiement, transporteurs, checkout, tâches cron, intégrations ERP/API et hooks personnalisés.

Pour continuer : consultez notre guide de migration PrestaShop 9, la couche de compatibilité modules, le guide des thèmes enfants et l’article sur PrestaShop 9.1, Hummingbird et le multi-transporteur.

Pour la plupart des boutiques, le meilleur hébergement pour PrestaShop est un serveur qui couvre confortablement les prérequis de la plateforme, PHP 8.1+, MySQL 5.7+ (ou équivalent MariaDB) et au moins 256 Mo de mémoire PHP, sur stockage SSD plutôt que sur l'offre mutualisée la moins chère et survendue.

• Petites et moyennes boutiques : un hébergement mutualisé ou infogéré correct avec ces caractéristiques suffit.
• Boutiques plus grandes (milliers de produits, trafic régulier) : un VPS ou serveur dédié où vous contrôlez PHP-FPM, OPcache et Redis devient rentable, car vous ajustez mémoire et workers à votre catalogue.

Évitez les hébergeurs ultra-bon marché qui survendent CPU et RAM, c'est la cause la plus fréquente des back offices lents et des timeouts. L'hébergeur exact dépend de votre région et de votre budget ; décrivez-nous votre configuration, nous vous conseillerons volontiers. Une fois le serveur en place, vous en tirez davantage avec le cache Redis et OPcache via Performance Revolution.

Pour les prérequis complets et le réglage, lisez notre guide d'hébergement PrestaShop.

Il y a deux chiffres distincts ici, et les confondre est l’erreur la plus fréquente.

PHP memory_limit (par requête), c’est ce que PrestaShop consomme réellement par chargement de page ou action admin. La documentation officielle PrestaShop 9 recommande au moins 512 MB. PrestaShop 8 se contentait de 256 MB ; l’augmentation dans PS 9 reflète le stack Symfony plus lourd du back-office. Import/export, installations de modules, mises à jour massives de produits et assistant de migration ont tous besoin de ce plafond plus élevé, mettez moins et vous aurez des écrans blancs ou des fatals "Allowed memory size exhausted".

RAM serveur (hôte), c’est la mémoire totale du VPS ou serveur dédié, partagée entre les workers PHP-FPM, MySQL/MariaDB, serveur web, Redis ou Memcached, tâches cron et OS. Bases pratiques :

• Moins de 1 000 SKU, trafic léger : 2 GB est le plancher réaliste.
• Catalogue moyen (1 000 à 20 000 SKU), cache activé : 4 GB est confortable.
• Grand catalogue (50 000+ SKU) ou multiboutique : 8 GB+ et une vraie passe de tuning MariaDB.
• Imports massifs, régénération d’images, gros jobs de migration : ajoutez de la marge ou déplacez les tâches lourdes en cron CLI.

Si la boutique semble lente, la RAM est rarement la première chose à corriger, commencez par le full-page cache, Redis, OPcache et un thème plus léger. Voir notre guide de tuning performance PrestaShop pour le vrai ordre des opérations.

Une vérification de capacité utile n’est pas simplement memory_limit x max_children, car tous les workers n’atteignent pas la limite en même temps, mais la formule indique si l’hôte est impossible sur le papier :

PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroom

Par exemple, dix workers PHP occupés avec un plafond de 512 MB demandent plus qu’un VPS de 2 GB une fois MariaDB inclus, même si la plupart des requêtes utilisent moins que le plafond. Gardez des limites CLI hautes pour la régénération d’images et les imports, mais évitez de laisser trop de workers PHP-FPM tourner sur un petit serveur. Si le Linux OOM killer commence à tuer PHP ou MariaDB, réduire le nombre de workers et corriger la pression cache/base de données est généralement mieux que seulement augmenter memory_limit.

Oui, pour le bon cas d'usage. PrestaShop convient bien si vous voulez un contrôle total sur votre boutique : auto-hébergée, open source et sans frais de plateforme récurrents sur vos ventes. Il est largement utilisé en Europe (notamment France, Espagne, Pologne et Italie) et dispose d'un large écosystème de modules et de développeurs.

Ce n'est pas le bon choix si vous voulez zéro implication technique. Dans ce cas, une plateforme hébergée comme Shopify est plus simple. PrestaShop suppose un minimum de connaissances techniques ou un développeur fiable. La contrepartie, c'est la propriété : vous maîtrisez les données, le code et les coûts. Si vous choisissez cette voie, garder la boutique rapide et propre compte, c'est précisément l'objet de notre module Performance Revolution.

Sauvegardez deux choses, à chaque fois : vos fichiers et votre base de données. S'il en manque une, vous ne pourrez pas restaurer la boutique.

• Fichiers, l'intégralité de votre répertoire PrestaShop, y compris les modules, les thèmes, les fichiers envoyés et la configuration. Copiez-le via FTP, SSH ou le gestionnaire de fichiers de votre hébergeur.
• Base de données, exportez la base MySQL avec phpMyAdmin, la ligne de commande (mysqldump) ou votre panneau d'hébergement.

Faites les deux régulièrement, et toujours juste avant d'installer ou de mettre à jour un module. Pour une boutique en production, une sauvegarde automatique vous évite d'y penser.

Pas à pas : notre guide de sauvegarde PrestaShop.

Performance Revolution permet à Cloudflare de mettre en cache vos pages HTML complètes pour les visiteurs anonymes : une fois qu'une page a été placée dans le cache edge, les requêtes suivantes peuvent être servies directement depuis Cloudflare. Les défauts de cache, la première requête, les entrées expirées et tout le trafic connecté ou avec panier, atteignent toujours votre origine ; c'est donc une couche edge devant PHP, pas une garantie que les requêtes ne l'atteignent jamais. Tout se passe côté serveur, sans astuces JavaScript.

Ce qu'il fait à chaque requête :

• Pour un visiteur anonyme sur une page cacheable (accueil, catégorie, produit, CMS, recherche et similaires), il envoie les en-têtes qui indiquent à Cloudflare de garder le HTML pendant la TTL que vous fixez.
• Les visiteurs connectés et toute personne avec un panier reçoivent des en-têtes de contournement, afin que les pages personnalisées arrivent toujours fraîches depuis l'origine.
• Il retire Set-Cookie des réponses anonymes, car un CDN refuse de mettre en cache une page qui pose un cookie.
• Il attache des en-têtes Cache-Tag / Surrogate-Key : quand vous modifiez un produit ou une catégorie, il peut purger uniquement les pages concernées au lieu de tout le site.

La purge s'adapte automatiquement à votre offre Cloudflare : les zones Business et Enterprise purgent directement par tag en un appel, tandis que les zones free et Pro (qui ne gèrent que la purge par URL) voient les tags résolus en URL exactes, purgées par lots de 30 URL imposés par Cloudflare. Il existe aussi une vérification d'état de zone qui lit vos réglages Cloudflare, Rocket Loader, Brotli, HTTP/3, Always Online, mode SSL, TTL du cache navigateur, et signale toute mauvaise configuration.

Deux limites honnêtes. D'abord, vous devez fournir un zone ID et un token API Cloudflare pour que la purge par API fonctionne ; sans eux, le module envoie toujours les en-têtes de cache mais ne peut pas purger activement. Ensuite, le cache edge est désactivé par défaut et ne concerne que le trafic anonyme, c'est volontaire, pour ne jamais servir le panier d'un client à un autre.

PrestaShop ne fixe aucune limite officielle de produits et ne vous arrête à aucune taille de catalogue. En pratique, la capacité dépend de vos données et de votre infrastructure, bien plus que du nombre brut de produits.

• Déclinaisons et volume de données : de nombreux attributs, déclinaisons et caractéristiques multiplient les enregistrements bien au-delà du nombre de produits. C'est cette volumétrie que la base de données doit porter.
• Base de données et recherche : la navigation à facettes, les tris et l'index de recherche grandissent avec le catalogue ; les requêtes lentes et la réindexation sont généralement le premier goulot d'étranglement.
• Imports et exports : les gros flux demandent des imports planifiés et découpés en lots ; un import complet du catalogue sollicite la boutique bien plus que la navigation quotidienne.
• Hébergement et ressources : processeur, mémoire, vitesse des disques et configuration de la base fixent le plafond ; un grand catalogue sur un hébergement sous-dimensionné restera lent, quelle que soit la plateforme.
• Cache, thème et modules : un cache efficace absorbe l'essentiel de l'effet de taille, mais un thème lourd ou un module mal écrit peut l'annuler.

La vraie réponse pour votre boutique vient de la mesure : testez en charge une copie de préproduction avec votre catalogue et votre trafic réels. Pour les optimisations concrètes, consultez notre guide de performance PrestaShop.

Oui. Blog Revolution embarque un système de commentaires natif et enregistre les trois hooks GDPR de PrestaShop, afin que vous puissiez laisser les lecteurs discuter vos articles sans ajouter un service tiers ni vous inquiéter des demandes de personnes concernées.

Côté commentaires, vous obtenez :

• Commentaires de clients connectés ou d’invités (nom + email), envoyés via un endpoint AJAX pour que la page ne se recharge pas.
• Réponses imbriquées, notes par étoiles et file de modération, approuver, rejeter ou marquer comme spam, ou activer l’approbation automatique si vous faites confiance à votre audience.
• Google reCAPTCHA optionnel et emails de notification de réponse, tous activables depuis le back-office.

Côté confidentialité, lorsque vous activez l’option GDPR, le module répond aux hooks de données intégrés de PrestaShop : il déclare les données de commentaire stockées (nom, email, IP), exporte les commentaires d’un client lors d’une demande d’accès aux données, et supprime ses commentaires lors d’une demande d’effacement, en recalculant ensuite les notes des articles concernés.

Note honnête : ces hooks couvrent les données de commentaire détenues par ce module. Ce n’est pas un outil de confidentialité global pour toute la boutique ni un conseil juridique, votre posture GDPR globale nécessite encore une politique et, idéalement, un DPO.

Le chemin natif stocke le statut de commentaire comme pending, approved, spam ou rejected, et les actions de modération recalculent la note de l’article lorsque les notes sont activées. Les nouveaux commentaires sont vérifiés pour l’indicateur comments-enabled, le honeypot, le consentement, la longueur et le reCAPTCHA optionnel avant d’être enregistrés. L’approbation automatique est désactivée par défaut, ce qui est le réglage le plus sûr pour un blog public ; activez-la seulement si vous êtes prêt à nettoyer le spam après coup.

Blog Revolution peut aussi basculer le fournisseur visible vers native, Disqus, Facebook ou des combinaisons tabbed/social. Les hooks GDPR décrits ci-dessus couvrent les enregistrements de commentaires natifs du module, y compris nom/email invité et IP lorsqu’ils sont stockés. Ils n’exportent ni ne suppriment les données détenues par Disqus, Facebook ou un autre fournisseur externe, donc ces services exigent toujours leur propre revue confidentialité et wording de politique.

Pour activer SSL dans PrestaShop, installez d’abord un certificat sur votre serveur (la plupart des hébergeurs proposent des certificats Let’s Encrypt gratuits), puis dans Shop Parameters → General, activez Enable SSL et Enable SSL on all pages, puis videz le cache.

Quelques points qui piègent souvent :

• Les avertissements de contenu mixte signifient que certaines ressources se chargent encore en HTTP, vérifiez votre thème et vos modules pour des URL http:// codées en dur.
• Ne touchez pas à PS_SHOP_DOMAIN ou PS_SHOP_DOMAIN_SSL sauf si vous savez exactement pourquoi. Une erreur peut vous bloquer l’accès au back-office.

Une fois HTTPS actif, vous pouvez le renforcer. MPR Security Revolution peut ajouter un en-tête HSTS (Strict-Transport-Security) pour que les navigateurs refusent de revenir en HTTP, et une politique upgrade-insecure-requests pour aider à nettoyer le contenu mixte. Il n’active pas SSL pour vous, c’est le réglage PrestaShop ci-dessus, il sécurise la connexion après activation.

HSTS a un bord tranchant : le module envoie Strict-Transport-Security seulement quand la requête est HTTPS, et les navigateurs s’en souviendront pendant le max age configuré. Commencez sans includeSubDomains ni preload tant que chaque sous-domaine, hostname CDN et ancienne redirection n’est pas confirmé en HTTPS. La configuration par défaut des security headers du module laisse HSTS et CSP désactivés jusqu’à ce que vous les activiez, avec CSP report-only disponible pour tester avant l’application.

Pour vérifier le changement, contrôlez les deux schémas depuis l’extérieur du serveur :

curl -I https://example.com
curl -I http://example.com

La réponse HTTPS doit afficher les en-têtes de sécurité attendus, et la réponse HTTP doit rediriger proprement vers HTTPS. S’il reste du contenu mixte, corrigez les URL d’assets codées en dur au niveau du thème/module ; les en-têtes de sécurité peuvent aider, mais ils ne remplacent pas la correction des URL de ressources cassées.

Oui. Quand vous activez le profiler front-office dans MPR Performance Revolution, vous décidez qui peut le voir : laissez le panneau entièrement désactivé, ou affichez-le en le limitant aux employés connectés afin que les clients ne voient jamais vos timings.

L’un des conseils performance PrestaShop les plus utiles est de profiler la boutique live, pas une copie de test propre, vrai trafic, vrais modules, vraies données. Le profiler ajoute une petite barre qui affiche le nombre de requêtes SQL et le temps de chaque page, et liste les requêtes les plus lentes ainsi que les hooks de modules les plus lents, afin que vous voyiez exactement où une page passe son temps avant de modifier quoi que ce soit.

L’erreur fréquente est de laisser un profiler visible publiquement : il divulgue des détails internes et ajoute de l’overhead à chaque requête. Gardez-le réservé aux employés, désactivez-le une fois le goulot trouvé, et agissez sur ce qu’il montre, souvent un hook de module lourd ou une requête non indexée. Le module gère aussi le cache objet Redis, le report des assets et le warming du cache OPcache/Smarty, donc les corrections vivent au même endroit que le diagnostic.

Les réglages concernés sont deux interrupteurs : profiler_panel_enabled active le panneau front-office, et profiler_employees_only le garde derrière une session employé back-office active. Le réglage employees-only est activé par défaut, tandis que le panneau lui-même est désactivé par défaut. Quand le profiling commence, le module initialise l’instrumentation tôt dans la requête puis injecte le panneau avant </body> seulement si le collecteur est activé et que la porte employé est passée.

Pour une attribution SQL et hooks plus profonde, le module inclut des overrides optionnels qui enregistrent chaque requête base de données et le timing de hook par module, et le query profiler journalise les requêtes lentes au-dessus du seuil configuré, par défaut 0.1 seconde. Installez-les seulement quand vous avez besoin de ce niveau de visibilité, car ils ajoutent volontairement de l’overhead d’instrumentation. Un bon workflow : activer le profiler réservé aux employés, reproduire une URL lente, capturer les totaux requêtes/hooks, le désactiver, puis effectuer la plus petite correction de cache, index ou module qui répond au goulot mesuré.

Un thème enfant hérite d'un thème parent : vous modifiez les templates et le CSS sans jamais toucher aux fichiers du parent, lors d'une mise à jour du parent, votre travail reste intact. Sur les versions actuelles de PrestaShop, la marche à suivre est la même :

• Créez un nouveau dossier dans /themes/ (par exemple my-child/).
• Ajoutez config/theme.yml avec une ligne parent: pointant vers le parent (classic ou hummingbird) et use_parent_assets: true pour que le style du parent continue de se charger.
• Placez vos surcharges dans assets/css/custom.css et assets/js/custom.js, et ne copiez que les templates à modifier, avec {extends file='parent:...'} pour surcharger des blocs précis plutôt que des fichiers entiers.
• Activez-le dans Apparence > Thème et logo.

Erreur fréquente : modifier directement le thème parent, puis tout perdre à la mise à jour suivante. Si vous préférez ne pas construire l'ossature à la main, notre générateur de thème enfant gratuit produit un ZIP prêt à installer (Classic, Hummingbird ou Warehouse) avec le theme.yml, les fichiers d'assets et des exemples de surcharges déjà câblés. Pour le tutoriel complet, consultez notre guide des thèmes enfants PrestaShop.

Oui, traitez cela comme une priorité. PHP 7.4 est arrivé en fin de vie en novembre 2022, donc il ne reçoit plus de correctifs de sécurité ; rester dessus signifie faire tourner votre boutique sur un logiciel avec des failles connues non corrigées. Passez de PHP 7.4 à une version PHP 8 actuellement supportée, et vérifiez la version PHP cible exacte par rapport à votre stack PrestaShop, thème et modules. La bonne nouvelle est qu’une mise à niveau PHP est généralement un changement côté serveur, pas une reconstruction complète de boutique. Vos fichiers restent où ils sont.

Ne basculez pas d’abord la version sur votre serveur live. L’ordre sûr est : copiez votre boutique dans un environnement staging, changez PHP là-bas, puis parcourez le front-office et le back-office à la recherche d’erreurs. Vérifiez chaque module et votre thème avec la nouvelle version PHP avant de valider. Les éléments les plus susceptibles de casser sont un ancien thème ou un module non maintenu, pas le cœur de la boutique. Une fois le staging propre, changez la version PHP en production via votre panneau d’hébergement et retestez.

Si un module ou un thème ne peut pas tourner sur PHP 8, c’est le signal qu’il doit être mis à jour ou remplacé. Pour planifier une migration plus large avec le changement PHP, consultez notre guide de migration PrestaShop.

D’après le tableau de support de PHP, PHP 7.4 a cessé d’être supporté le 28 novembre 2022 et les branches actuellement supportées sont PHP 8.x. Pour PrestaShop en particulier, ne sautez pas sur une version PHP arbitraire juste parce que l’hébergeur la propose : PrestaShop 8 et 9 ont des plages de compatibilité différentes, et certains modules peuvent être plus stricts que le cœur.

Sur staging, vérifiez ces points avant production : commande complète, connexion, inscription, réinitialisation de mot de passe, sauvegarde produit admin, sauvegarde de configuration module, upload d’image et tâche cron/import. Parcourez ensuite le log PHP pour repérer les dépréciations qui peuvent devenir fatales au prochain upgrade. Gardez l’ancienne version PHP disponible jusqu’à la fin de la fenêtre de rollback, car le rollback le plus rapide consiste souvent à remettre le sélecteur PHP précédent pendant que vous remplacez le module incompatible.

PrestaShop utilise MySQL ou MariaDB comme moteur de base de données. Selon les exigences système officielles actuelles de PrestaShop 8 et PrestaShop 9, les deux listent un support SQL minimum MySQL 5.7 ou MariaDB 10.2, avec une version récente recommandée.

Pour une boutique de production neuve ou mise à niveau, considérez ces versions comme des minimums, pas des cibles idéales. MySQL 8.0 ou une version MariaDB LTS actuelle est un meilleur choix qu’un vieil hébergement MySQL 5.7, surtout pour les gros catalogues, tables de recherche, déclinaisons, paniers et historique de commandes. Utilisez des tables InnoDB, gardez assez de mémoire buffer pool disponible, et assurez-vous que les sauvegardes et tests de restauration font partie du plan d’hébergement.

PrestaShop 9 a aussi des attentes plateforme plus élevées que les anciennes installations ; les exigences officielles recommandent plus de mémoire PHP par script que PrestaShop 8. La compatibilité base de données seule ne suffit pas : version PHP, extensions, memory limit, permissions fichier et compatibilité module doivent encore être vérifiées avant mise à niveau.

Si vous êtes sur hébergement mutualisé, demandez à l’hébergeur la version exacte MySQL/MariaDB et si vous pouvez activer le slow query log ou obtenir des rapports de requêtes lentes. Cela compte plus dans la performance quotidienne PrestaShop que le nom de marque du serveur de base de données.

Sur un nouvel hébergement, demandez le moteur et la version exacts, pas seulement "compatible MySQL". Certains hébergeurs managés exécutent MariaDB derrière un label MySQL, et c’est normalement très bien, mais vous avez quand même besoin d’une version qui respecte l’exigence PrestaShop et d’une configuration capable de gérer votre catalogue. Pour la performance, les réglages importants sont généralement la taille de l’InnoDB buffer pool, la latence disque, les index, la visibilité des requêtes lentes et le fait que la base de données partage ou non un tout petit serveur avec PHP.

Pendant la migration, exportez et importez avec le bon jeu de caractères, gardez le même préfixe de table sauf si vous le changez volontairement, et testez recherche, sauvegarde produit, création de commande et grilles back-office après import. Les anciennes boutiques peuvent contenir des tables MyISAM ou des index obsolètes venant de très vieilles versions PrestaShop ; convertir en InnoDB et nettoyer les index doit être fait volontairement avec une sauvegarde, pas via un bouton aveugle du panneau d’hébergement.

Une copie de staging est un duplicata privé de votre boutique en ligne où vous pouvez tester modules, mises à jour et modifications sans toucher à la production. Voici comment la créer : (1) Copiez tous les fichiers vers un emplacement séparé, par ex. un sous-domaine comme staging.example.com. (2) Créez une nouvelle base de données et importez un dump de votre base de production. (3) Mettez à jour /config/parameters.php avec les nouveaux identifiants de base de données. (4) Dans la base, mettez à jour la table ps_shop_url et les entrées domaine/SSL de ps_configuration pour correspondre au domaine de staging. (5) Videz le cache.

Deux choses souvent oubliées : empêchez la copie de staging d'envoyer de vrais e-mails clients (désactivez les e-mails transactionnels ou pointez-les vers une boîte de test), et bloquez le duplicata via robots.txt ou un mot de passe pour que les moteurs ne l'indexent jamais. Vous obtenez ainsi un environnement indépendant pour tester en sécurité avant toute mise en ligne.

Pour le guide complet, consultez notre article sur la création d'un site de staging PrestaShop.

En général oui, mais désinstallez d’abord, ne supprimez pas simplement le dossier. Désactiver un module le coupe seulement ; ses tables de base de données, hooks et lignes de configuration restent en place. Le bon ordre est :

Le chemin habituel est Modules > Module Manager, puis recherchez le module, ouvrez son menu d'actions et choisissez Uninstall. Après la désinstallation, PrestaShop peut supprimer le dossier du module, ou vous pouvez supprimer le dossier depuis modules/modulename/ une fois la désinstallation terminée proprement.

Certains modules conservent volontairement les données historiques après désinstallation, notamment les modules de paiement, commande, livraison, support, marketplace et audit. Ce n'est pas toujours une mauvaise routine de désinstallation : les factures, références de commande, journaux de validation ou historiques de licence peuvent devoir rester lisibles même lorsque le module est désactivé.

1. Sauvegardez d’abord votre base de données et vos fichiers, afin qu’un mauvais nettoyage soit réversible.
2. Dans le back-office, cliquez sur Uninstall sur le module. Cela exécute la routine de désinstallation propre au module et retire les données qu’il a créées.
3. Supprimez ensuite le dossier du module (le back-office peut le faire pour vous après désinstallation).

Si vous sautez la désinstallation et supprimez le dossier directement, vous laissez des tables et enregistrements de hooks orphelins dans la base de données. Pour récupérer d’écrans blancs et erreurs 500, consultez notre guide de dépannage PrestaShop.

SELECT m.id_module, m.name, h.name AS hook_name
FROM ps_module m
LEFT JOIN ps_hook_module hm ON hm.id_module = m.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.name = 'modulename';

SELECT id_tab, class_name, module, active
FROM ps_tab
WHERE module = 'modulename' OR class_name LIKE '%ModuleName%';

Il y a deux cas où il faut faire une pause : si le module fournissait une intégration paiement, livraison, taxe, marketplace ou ERP, confirmez d’abord qu’aucune commande active, transporteur, webhook ou cron job n’en dépend encore ; et si le module est personnalisé, inspectez sa routine de désinstallation, car certains modules gardent volontairement des tables historiques pour audit. Un bon nettoyage consiste à désinstaller un module à la fois, recharger le back-office, ouvrir le front-office et vérifier le log d’erreurs PHP avant de continuer.

Le code source du module explique généralement pourquoi l’étape de désinstallation back-office compte. Les modules bien construits retirent les tabs, la configuration, les hooks et parfois des préférences admin personnalisées dans leur méthode uninstall(). Supprimer seulement le dossier saute ce nettoyage et peut laisser des entrées de menu cassées, hooks morts ou tables de base de données qui compliquent les upgrades ultérieurs.

Votre URL admin PrestaShop est basée sur le nom physique du dossier admin sur le serveur. Il n’existe normalement pas de valeur séparée en base de données ou en configuration qui indique à PrestaShop l’URL du back-office.

Pour la trouver par FTP, ouvrez le répertoire racine PrestaShop et cherchez un dossier comme admin123abc, admin-dev ou backoffice. L’URL admin est votre domaine de boutique plus ce nom de dossier, par exemple https://example.com/admin123abc/.

Avec SSH, vous pouvez lister les dossiers admin probables depuis la racine de la boutique :

cd /var/www/html/prestashop
ls -ld admin* backoffice* 2>/dev/null
for d in admin* backoffice*; do test -f $d/index.php && echo $d; done

Si vous ne savez pas si vous êtes dans la bonne racine PrestaShop, cherchez des fichiers comme config/settings.inc.php, app/config/parameters.php, classes, modules et themes. Ils confirment la racine de la boutique, mais ne stockent pas le nom du dossier admin.

Si aucun dossier ressemblant à un admin n’est visible, vérifiez si votre hébergeur masque des dossiers système, si vous êtes dans le mauvais document root, ou si la boutique a été déployée dans un sous-répertoire.

Deux contrôles supplémentaires aident sur les vrais serveurs. D’abord, le dossier admin ne commence pas forcément littéralement par admin ; certaines boutiques le renomment avec un mot privé, donc cherchez un répertoire contenant un index.php et des contrôleurs plutôt que de vous fier seulement au nom. Ensuite, si la boutique est installée dans un sous-répertoire, incluez ce chemin de base dans l’URL, par exemple https://example.com/shop/admin123abc/.

Si vous trouvez plusieurs candidats, vérifiez les dates de modification et ouvrez le dossier en HTTPS plutôt que de supprimer quoi que ce soit. Si le navigateur redirige vers l’installateur ou le front-office, vous êtes probablement dans le mauvais document root ou devant une ancienne copie. Une fois l’accès retrouvé, enregistrez l’URL exacte dans votre gestionnaire de mots de passe ; changer ensuite le nom du dossier admin est un renommage filesystem avec attention au cache, pas un réglage normal du back-office.

Oui, et vous avez deux façons de procéder. Vous pouvez utiliser la fonction Multistore intégrée à PrestaShop (une installation gère plusieurs boutiques) ou exécuter des installations totalement séparées dans des répertoires ou sous-domaines distincts.

Le Multistore est la voie pratique quand vos boutiques partagent un catalogue, des clients ou une équipe back-office, vous gérez tout depuis un seul admin et réutilisez les produits entre boutiques. La contrepartie : plus de configuration et des boutiques qui partagent un même code et une même base de données. Les installations séparées sont plus simples à appréhender et totalement isolées (une boutique ne peut pas en affecter une autre), mais chacune demande ses propres mises à jour, sauvegardes et maintenance.

Le choix se résume à une question : vos boutiques partagent-elles produits et clients ? Si oui, penchez pour le Multistore ; si ce sont des marques vraiment indépendantes, les installations séparées sont plus nettes. Voir notre guide d'hébergement PrestaShop pour la partie serveur.

Les overrides PrestaShop modifient le comportement du cœur sans toucher aux fichiers du cœur : vous placez une copie d'une classe ou d'un contrôleur dans le dossier /override et PrestaShop charge la vôtre. Le piège : un seul override par classe peut l'emporter, si deux modules surchargent la même classe, le second perd en silence. C'est la cause la plus fréquente de conflits entre modules dans PrestaShop.

C'est pourquoi les modules modernes s'appuient plutôt sur les hooks et les services Symfony, qui se cumulent sans risque. Au moment de choisir un module, préférez celui qui agit via des hooks plutôt que des overrides, il risque bien moins d'entrer en conflit avec l'existant.

Plus de détails : hooks contre overrides dans PrestaShop.

Dans Design → Paramètres des images, définissez des tailles raisonnables pour chaque type d'image afin de ne pas servir d'énormes fichiers là où une miniature suffit. Compressez les images avant de les téléverser avec un outil comme TinyPNG, ShortPixel ou Squoosh, et activez la compression au niveau du serveur ou via un CDN avec optimisation d'images. Utilisez le WebP lorsque votre configuration le permet, il produit des fichiers nettement plus petits que le JPEG à qualité similaire. Le chargement différé des images hors écran aide aussi. Détails dans notre guide de performance PrestaShop.

Oui, mais traitez cela comme une migration structurée, pas comme une copie en un clic. Exportez produits, catégories, clients, adresses, commandes, images, URL et métadonnées SEO depuis Shopify ou WooCommerce, mappez-les vers les champs PrestaShop, importez par lots, puis vérifiez prix, taxes, stock, transporteurs, modules de paiement et redirections. Les commandes et mots de passe nécessitent souvent un traitement spécial, car les plateformes les stockent différemment.

Utilisez une checklist par étapes : migrez d'abord les données catalogue et les images, puis les clients et adresses, ensuite les commandes historiques, puis les URL SEO et les redirections. Les mots de passe ne peuvent généralement pas être copiés comme mots de passe fonctionnels, car Shopify, WooCommerce et PrestaShop les hachent différemment ; prévoyez donc une campagne de réinitialisation de mot de passe, sauf si vous disposez d'un module de migration compatible vérifié.

Avant le lancement, exécutez un delta final pour les nouveaux clients, commandes, stocks et prix créés depuis la migration de staging. Ensuite, crawlez les anciens handles Shopify ou slugs WooCommerce, testez la carte de redirections 301 et comparez le nombre de commandes, le nombre de clients, les totaux de taxes et les totaux de stock avant de modifier le DNS. La checklist de lancement côté serveur plus complète se trouve dans le PrestaShop migration guide.

Planifiez le modèle de données avant l’import. Les variantes Shopify et variations WooCommerce doivent devenir des déclinaisons PrestaShop avec les bons attributs, références, prix, images, stocks et déclinaison par défaut. Catégories, fabricants ou marques, caractéristiques, prix spécifiques, règles fiscales, groupes clients, statuts de commande, noms de paiement, noms de transporteurs, pages CMS, contenu blog et meta titles/descriptions doivent être mappés explicitement plutôt que de se fier uniquement aux noms de colonnes.

La migration de mots de passe est généralement le problème client le plus difficile, car les hash sont propres à chaque plateforme ; beaucoup de migrations importent les comptes client puis imposent une réinitialisation de mot de passe. L’historique de commandes peut souvent être importé à titre de référence, mais remboursements, transactions de paiement, factures et événements d’expédition ne se mappent pas toujours parfaitement au cycle de vie natif de PrestaShop. Avant lancement, exécutez une migration staging, crawlez les anciennes URL, construisez une carte de redirection depuis les handles Shopify ou slugs WooCommerce vers les URL PrestaShop, gelez les changements pendant le delta final, et réconciliez totaux, taxes, stock et nombres de commandes.

Vous pouvez trouver la version PrestaShop dans le footer du Back Office, dans Advanced Parameters > Information, et dans le code via app/AppKernel.php ou config/settings.inc.php selon la version. Dans les modules, _PS_VERSION_ est la constante runtime utilisée pour les contrôles de compatibilité.

grep -R "_PS_VERSION_" config/settings.inc.php app/AppKernel.php 2>/dev/null
php -r 'require "config/config.inc.php"; echo _PS_VERSION_, PHP_EOL;'

Pour le travail admin quotidien, le footer du back-office et Advanced Parameters > Information sont les endroits les plus sûrs, car ils affichent la version de la boutique en cours d’exécution. Pour les contrôles de code, les versions récentes de PrestaShop exposent souvent la version via AppKernel, tandis que les anciennes installations peuvent la définir dans config/settings.inc.php. Le numéro de version d’un module n’est pas la version PrestaShop ; il identifie seulement cette release du module.

Pour PrestaShop 1.6, la vérification dans le système de fichiers se fait généralement dans config/settings.inc.php, où _PS_VERSION_ est défini. Pour PrestaShop 1.7 et 8, app/AppKernel.php expose souvent la version de l'application utilisée par la boutique en cours d'exécution. Quelle que soit la génération, le pied de page du back-office et Advanced Parameters > Information sont préférables à une déduction depuis un fichier copié, car ils reflètent la boutique installée qui a réellement démarré.

Si vous maintenez plusieurs boutiques, vérifiez aussi l'URL d'administration à laquelle vous êtes connecté avant de lire le pied de page : une boutique de staging, une boutique de production et une sauvegarde restaurée peuvent avoir des versions différentes même si elles partagent des fichiers ou noms de base de données similaires.

Si vous vérifiez la compatibilité avant d’installer ou mettre à niveau un module, utilisez la version de la boutique en cours d’exécution et comparez-la à la plage de compatibilité déclarée par le module. Dans du code de module personnalisé, utilisez des contrôles de type version_compare(_PS_VERSION_, 'x.y.z', '>=') au lieu de coder des hypothèses depuis un chemin de fichier. Après une mise à niveau majeure, videz le cache et confirmez que le back-office affiche la version attendue, car des fichiers obsolètes ou un déploiement incomplet peuvent rendre les contrôles filesystem trompeurs.

En bref : les hooks PrestaShop sont la façon supportée et partagée d'étendre la boutique, et les overrides sont un recours plus lourd quand aucun hook n'existe. Un hook est un point nommé dans le code (et dans les templates) où PrestaShop invite les modules à ajouter du contenu ou un comportement. Plusieurs modules peuvent s'accrocher au même hook en même temps, si bien que deux modules ajoutant quelque chose à la fiche produit n'entrent pas en collision. C'est pourquoi les hooks sont le premier choix.

Un override remplace une classe ou un contrôleur du cœur par votre propre copie. C'est plus intrusif : un seul override peut s'appliquer par classe surchargée, donc deux modules qui surchargent la même classe entrent en conflit, et votre override peut cesser de correspondre au cœur après une mise à jour. N'utilisez un override que lorsqu'il n'existe vraiment aucun hook adapté, et gardez le code modifié minimal pour le revérifier facilement plus tard.

Pour la liste complète des hooks, comment créer les vôtres et des modèles d'override qui survivent aux mises à jour, voyez notre guide des hooks et overrides PrestaShop.

Migrer PrestaShop vers un nouveau domaine consiste surtout à indiquer à la boutique sa nouvelle adresse, puis à rediriger l'ancienne. En résumé : (1) Copiez tous les fichiers vers le nouveau serveur ou emplacement. (2) Mettez à jour la table ps_shop_url dans la base avec le nouveau domaine. (3) Mettez à jour PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL dans ps_configuration. (4) Mettez à jour /config/parameters.php si les identifiants de base ont changé. (5) Videz tous les caches. (6) Configurez des redirections 301 de chaque ancienne URL vers son équivalent. (7) Mettez à jour Google Search Console, Google Analytics et vos comptes publicitaires avec le nouveau domaine.

Ne sautez pas les redirections 301, elles transfèrent l'autorité déjà acquise vers le nouveau domaine et évitent que les clients tombent sur des pages mortes. Ajoutez le nouveau domaine comme nouvelle propriété dans la Search Console et soumettez votre sitemap pour que Google recrawle vite.

Pour le guide complet et les pièges courants, consultez notre guide de dépannage PrestaShop.

Une migration PrestaShop, nouveau serveur, nouveau domaine ou structure d’URL modifiée, ne met votre visibilité de recherche en risque que si les anciennes URL cessent de répondre. La correction consiste à faire en sorte que chaque ancienne URL reste identique ou redirige en 301 vers sa nouvelle destination, afin que l’équité de liens acquise soit transférée au lieu d’être perdue.

La version courte :

• Mappez d’abord chaque URL. Crawlez votre site actuel et récupérez vos pages principales depuis Search Console, puis listez chaque ancienne URL et la nouvelle URL vers laquelle elle doit pointer.
• Utilisez des redirections 301 (permanentes), jamais 302. Une 301 transmet l’équité de liens à la nouvelle URL ; une 302 non.
• Gardez HTTPS et le choix www/non-www cohérents pour ne pas créer accidentellement des URL dupliquées ou 404.
• Régénérez votre sitemap XML avec les nouvelles URL et soumettez-le à nouveau dans Search Console ; utilisez l’outil Change of Address si le domaine change.
• Surveillez Search Console pour les erreurs de crawl et changements d’indexation dans les premières semaines, et corrigez immédiatement toute redirection cassée.

Les redirections et sitemaps préservent la valeur gagnée, ils ne fabriquent pas de nouveaux classements. Pour le processus complet étape par étape, suivez notre guide de migration PrestaShop.

Dans SEO Revolution, les grandes cartes de migration peuvent être gérées dans la zone Redirects au lieu de coder chaque règle en dur dans .htaccess. Les lignes de redirection stockent l’URL source, l’URL cible ou l’entité cible, le type de redirection, l’indicateur actif, le nombre de hits et la date de dernier hit. Le module prend en charge 301, 302 et 410, donc les pages déplacées, déplacements temporaires et pages définitivement supprimées peuvent être traités différemment.

Le redirect manager possède des garde-fous utiles pour les migrations : les correspondances exactes d’URL sont vérifiées d’abord, les correspondances path-only peuvent préserver la query string originale, et les redirections prefix préservent le chemin enfant non correspondant sauf si cela détournerait une vraie route de module. Lors de l’ajout de redirections, le code peut réduire les chaînes afin que old URL → intermediate URL → final URL devienne old URL → final URL lorsque c’est approprié.

Le côté sitemap doit être vérifié après mise en place des redirections. Le vérificateur de sitemap ignore les URL non-200, les URL redirigées, les en-têtes/balises meta noindex et les canonical mismatches, tandis que les URL de niveau 500 restent pending pour réessai. Cela empêche un sitemap XML fraîchement généré de publier des URL que Google ne doit pas indexer.

Lorsque vous migrez une boutique PrestaShop, les URL changent souvent. Sans redirections, chaque ancienne adresse retourne une 404 aux visiteurs et aux moteurs de recherche. Une redirection 301 indique que la page a été déplacée définitivement et c'est le bon choix pour une migration permanente. Une 302 est temporaire et ne doit pas être utilisée pour les mappings d'anciennes vers nouvelles URL.

Préparer une correspondance ancien-vers-nouveau

Exportez les anciennes URL et les nouvelles URL dans un fichier à deux colonnes avant le lancement. Gardez les chemins normalisés : un seul hôte, un seul protocole, un seul style de slash final et aucune chaîne de redirections. Par exemple :

old_path,new_url
/old-product.html,https://www.example.com/new-product
/old-category/,https://www.example.com/new-category/
/3-shoes,https://www.example.com/shoes

Apache (.htaccess)

Placez les règles avant les règles dispatcher propres à PrestaShop, au-dessus du bloc # Dispatcher et après RewriteEngine On. Si PrestaShop traite la requête en premier, votre redirection peut ne jamais s'exécuter.

RewriteEngine On

# Exact old-to-new page mapping
Redirect 301 /old-product.html https://www.example.com/new-product
Redirect 301 /old-category/ https://www.example.com/new-category/

# Pattern redirect
RewriteRule ^old-brand/(.*)$ /brand/$1 [R=301,L]

# Strip ID-prefixed category URLs, e.g. /3-shoes -> /shoes
RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Nginx

Pour quelques redirections, utilisez des locations exactes. Pour une grande table de migration, utilisez map dans le contexte http et une seule règle return dans le bloc server.

# http {} context
map $request_uri $redirect_target {
    default 0;
    /old-product.html /new-product;
    /old-category/ /new-category/;
    /3-shoes /shoes;
}

# server {} context
if ($redirect_target) {
    return 301 https://www.example.com$redirect_target;
}

Pour des milliers d'URL, générez les règles depuis le CSV ou utilisez un module de redirection permettant au personnel de gérer les mappings dans le back-office. Testez avant la mise en ligne avec curl -I https://www.example.com/old-product.html ; vous voulez 301 Moved Permanently et le Location final. Utilisez curl -IL pour repérer les chaînes.

Pièges courants

• Chaînes de redirections : pointez les anciennes URL directement vers la destination finale.
• Boucles infinies : vérifiez www/non-www, HTTP/HTTPS et les règles de module conflictuelles.
• Sensibilité à la casse : les chemins Linux sont sensibles à la casse ; utilisez [NC] dans les règles rewrite Apache uniquement si vous voulez volontairement une correspondance insensible à la casse.
• Query strings supprimées : conservez-les uniquement lorsqu'elles portent un état utile ; supprimez les paramètres de tracking.
• Conservation trop courte : gardez les redirections de migration importantes au moins un an, souvent plus longtemps pour les pages à forte valeur.

Pour le déplacement complet, fichiers, base de données, thème et redirections inclus, suivez notre guide de migration PrestaShop.

Pourquoi la qualité d'un thème compte plus que son apparence

Choisir un thème PrestaShop est l'une des décisions les plus lourdes de conséquences. Un thème détermine non seulement l'aspect de votre boutique, mais aussi ses performances, son accessibilité, sa crawlabilité et la facilité à l'étendre avec des modules. Un thème mal conçu crée des problèmes qui s'accumulent : ce qui semble un détail à l'installation devient un goulot d'étranglement sous charge, un casse-tête de maintenance lors des mises à jour et une moins bonne expérience pour vos clients.

Les marchés de thèmes regorgent de thèmes superbes en captures de démo mais peu soucieux des standards de code, des performances ou de la compatibilité. Ce guide vous aide à regarder au-delà de la surface et à repérer les signaux d'alerte.

Trop de requêtes HTTP

Un signe fiable est un nombre excessif de requêtes HTTP. Chaque fichier CSS, script, image, police et ressource externe est une requête distincte qui ajoute de la latence, surtout sur mobile. Un thème propre charge une fiche produit ou une page catégorie avec un nombre modéré de requêtes ; les thèmes mal conçus le doublent ou le triplent en chargeant de nombreux fichiers CSS séparés, des bibliothèques inutilisées, des polices de plusieurs fournisseurs et des pixels de suivi intégrés au thème plutôt que chargés via des modules.

Vérifiez avant d'acheter : ouvrez la démo dans Chrome, ouvrez les DevTools (F12), onglet Réseau, rechargez. Regardez le nombre de requêtes et ce qui se charge, des dizaines de fichiers CSS individuels, plusieurs copies de jQuery ou des requêtes vers des domaines tiers inconnus sont des signaux d'alerte. Soyez attentif aux ressources bloquant le rendu dans l'en-tête : un bon thème diffère le CSS et le JavaScript non critiques.

Styles en ligne et design en dur

Les thèmes professionnels utilisent des classes CSS et des feuilles de styles, maintenables, surchargeables et mises en cache. Les mauvais sèment des styles en ligne dans leurs templates Smarty, comme style="color:#333;font-size:14px" sur des éléments individuels. Les styles en ligne ne se mettent pas en cache séparément, sont pénibles à surcharger (du !important partout) et rendent la personnalisation quasi impossible sans éditer les templates, vos changements disparaissent à la mise à jour suivante. Pire encore, du design figé dans le PHP (couleurs, tailles) : chaque changement impose alors d'éditer du code.

Pour vérifier, faites un clic droit sur des éléments de la démo et Inspecter. Si l'essentiel du style apparaît sous element.style plutôt que via des classes CSS, le thème s'appuie sur les styles en ligne. Quelques styles en ligne sont normaux (images de fond dynamiques) ; une majorité en ligne est le signal d'alerte.

Responsive absent ou médiocre

L'essentiel du trafic e-commerce est mobile, et Google indexe en mobile-first, un thème médiocre sur téléphone nuit là où ça compte. Avoir « une vue mobile » ne suffit pas. Signaux d'alerte : texte qui déborde, cibles tactiles trop petites, défilement horizontal, images qui ne se redimensionnent pas, menus difficiles au toucher et formulaires de commande inutilisables sur téléphone.

Testez la démo sur un vrai téléphone, pas seulement une fenêtre réduite, le redimensionnement ne reproduit ni le tactile, ni les réseaux réels, ni le rendu mobile. Parcourez tout le tunnel d'achat : naviguer, ouvrir un produit, ajouter au panier, commander. Vérifiez aussi que le thème sert des images responsives via srcset ou <picture> au lieu d'envoyer une énorme image bureau à chaque appareil.

Texte en dur sans traductions

Le système de traduction de PrestaShop permet de traduire chaque chaîne visible. Un bon thème passe chaque libellé, message et titre par ce système. La forme Smarty est {l s='Add to cart' d='Shop.Theme.Actions'}, ce qui expose la chaîne dans le traducteur du back-office. Les mauvais thèmes figent du texte brut comme <button>Add to cart</button>, non traduisible, inutilisable pour les boutiques multilingues et limitant même en monolingue.

Pour vérifier, notez des chaînes de la démo et cherchez les catalogues de traduction du thème ou l'usage cohérent des domaines de traduction. Si la documentation ne mentionne jamais les traductions, c'est un point de vigilance.

Conflits jQuery et problèmes JavaScript

De nombreux thèmes PrestaShop classiques ou anciens chargent jQuery ; un bon thème travaille avec la version déjà chargée. Vérifiez si le thème visé charge des bibliothèques JavaScript en double ou incompatibles. Un mauvais embarque son propre jQuery (conflits), charge des bibliothèques qui dupliquent le cœur ou utilise des techniques incompatibles avec d'autres modules. Les conflits se manifestent par des modules qui échouent en silence (boutons inertes, formulaires qui ne s'envoient pas, AJAX en panne), des erreurs console et des fonctions qui marchent dans la démo mais cassent avec de vrais modules.

Ouvrez la console de la démo (F12, Console) et tapez jQuery.fn.jquery pour voir la version chargée, puis cherchez plusieurs fichiers jQuery dans l'onglet Réseau. Plusieurs copies de jQuery sont un signal fort. Surveillez aussi les erreurs console en naviguant, des erreurs dans une démo contrôlée annoncent bien pire en boutique réelle.

Support de hooks manquant

Le système de hooks est la façon dont les modules s'intègrent, des points prédéfinis dans les templates (displayHeader, displayTop, displayFooter, displayProductAdditionalInfo et bien d'autres) où les modules insèrent du contenu. Un bon thème supporte tous les hooks standard. Un mauvais en supprime pour simplifier sa mise en page, remplace des hooks standard par des hooks propriétaires ou les place de façon à casser la mise en page. Des hooks manquants, et les modules installés n'ont nulle part où s'afficher : une confirmation de paiement qui n'apparaît jamais, un module produit invisible. Vous éditez alors les templates à la main (cassé aux mises à jour) ou êtes enfermé dans des modules spécifiques au thème.

Vérifiez la documentation pour une liste de hooks supportés ; son absence est déjà un point de vigilance. Si vous voyez des templates, cherchez {hook h='displayHome'} et autres noms standard.

Pas de support des thèmes enfants

Les thèmes enfants permettent de personnaliser sans modifier les fichiers d'origine, l'enfant hérite de tout et ne contient que vos surcharges, donc votre travail survit aux mises à jour du parent. Un thème qui ne les supporte pas force tous les changements dans ses propres fichiers, vous laissant choisir entre sauter les mises à jour ou perdre vos personnalisations. Vérifiez la documentation et le fichier theme.yml : une référence parent doit être possible. Si le développeur ne mentionne jamais les thèmes enfants, demandez avant d'acheter.

Quand un thème les supporte, inutile de construire l'ossature à la main, notre générateur de thème enfant gratuit produit un ZIP prêt à installer (Classic, Hummingbird ou Warehouse) avec le theme.yml, les fichiers d'assets et des exemples de surcharges via {extends file='parent:...'}.

Accessibilité médiocre

L'accessibilité, c'est permettre aux personnes en situation de handicap d'utiliser votre boutique, lecteurs d'écran, navigation au clavier, basse vision, daltonisme. Dans de nombreuses régions, les sites e-commerce doivent légalement respecter WCAG 2.1 niveau AA. Défauts courants : images sans texte alt, champs sans libellés, contraste insuffisant, éléments inaccessibles au clavier, indicateurs de focus supprimés et attributs ARIA mal utilisés ou absents.

Test rapide : parcourez la démo au clavier seul (Tab, Entrée). Si vous ne pouvez pas tout atteindre ou s'il n'y a pas d'indicateur de focus visible, les bases sont en échec. Passez la page dans un outil gratuit comme WAVE ou l'audit Accessibilité de Lighthouse, un bon thème y obtient un bon score.

Fichiers surdimensionnés

Le poids d'un thème agit directement sur le temps de chargement. Les thèmes surchargés embarquent des assets inutiles, des images non optimisées, du CSS/JS non minifié et des bibliothèques entières pour une seule fonction, par exemple plusieurs mégaoctets de CSS dont une fraction sert, plusieurs polices d'icônes chargées en entier pour une poignée d'icônes, ou une bibliothèque entière pour une fonction.

Vérifiez la taille totale transférée dans l'onglet Réseau au chargement de la démo (hors images produit). Un bon thème garde une page légère ; une démo chargeant plusieurs mégaoctets de CSS, JS et polices est surchargée. Surveillez surtout le CSS, un thème basé sur un framework ne devrait livrer que les composants utilisés. Vérifiez aussi que le CSS/JS de production est minifié : si la source est lisible, formatée et commentée, il manque un vrai processus de build.

Évaluer un thème avant l'achat

Lire theme.yml

Le fichier theme.yml est le cœur de configuration. Il déclare la compatibilité, les hooks enregistrés et leurs modules, les définitions de layout par type de page (produit, catégorie, CMS, commande) et la gestion des assets. S'il est minimal ou si des sections clés manquent, le thème n'a pas suivi les directives de thème PrestaShop.

Tester en mode debug

Si vous pouvez installer le thème en test, activez le mode debug (_PS_MODE_DEV_ à true dans config/defines.inc.php). Il révèle les erreurs, avertissements et notices PHP masqués en production. Un bon thème génère zéro erreur et peu d'avertissements ; un flot signale des problèmes de qualité de code.

Vérifier le parcours du développeur

Renseignez-vous : combien de thèmes publiés, mis à jour récemment, et ce que disent les avis. Un changelog détaillé de corrections et de mises à jour de compatibilité indique une maintenance active ; son absence suggère un thème abandonné après la vente.

Vérifier la compatibilité

Assurez-vous que le thème indique explicitement avoir été testé avec votre version exacte de PrestaShop. « Compatible avec les versions récentes » est trop vague, et si la compatibilité annoncée précède la sortie de la version, traitez l'affirmation comme non vérifiée.

Le vrai coût d'un mauvais thème

Un thème mal conçu a des coûts concrets : il ralentit la boutique et dégrade l'expérience client, des hooks manquants imposent du travail de développeur payant pour chaque nouveau module, une accessibilité médiocre crée un risque juridique, l'absence de thème enfant transforme chaque mise à jour en fusion manuelle, et les conflits jQuery cassent en silence les boutons d'ajout au panier et les formulaires de paiement. Raisonnez en coût total de possession, un thème bon marché qui réclame sans cesse du temps de développeur revient bien plus cher qu'un thème plus onéreux qui fonctionne dès le premier jour.

Liste de contrôle

Avant d'acheter : ouvrez la démo et vérifiez les requêtes excessives dans l'onglet Réseau ; inspectez les styles en ligne qui devraient être en CSS ; testez tout le tunnel d'achat sur un vrai téléphone ; cherchez du texte figé non traduisible ; vérifiez la console (erreurs, versions multiples de jQuery) ; confirmez la présence des hooks standard ; assurez-vous que le support des thèmes enfants est documenté ; lancez un audit d'accessibilité Lighthouse et testez la navigation clavier ; examinez les tailles transférées CSS/JS/polices ; lisez theme.yml pour la structure ; et vérifiez l'historique des mises à jour et la réactivité du support. Tout réussir ne garantit pas la perfection, mais franchit la barre entre travail professionnel et amateur.

À lire aussi : guide des thèmes enfants PrestaShop et Comment choisir le bon thème PrestaShop.

Le coût caché de la surcharge de polices dans les thèmes PrestaShop

Ouvrez les DevTools de votre navigateur, passez à l'onglet Réseau, filtrez par « Font » et rechargez votre boutique PrestaShop. Si vous voyez plus de trois ou quatre fichiers de polices en cours de téléchargement, vous avez un problème qui vous coûte silencieusement des clients. La plupart des thèmes PrestaShop sont livrés avec un nombre impressionnant de ressources de polices que la boutique moyenne n'utilise jamais, et chacune d'entre elles retarde le moment où vos visiteurs peuvent réellement lire votre contenu.

La surcharge de polices est l'un des problèmes de performance les plus négligés dans PrestaShop. Les propriétaires de boutiques passent des heures à optimiser les images, à activer le CCC (Combiner, Compresser, Mettre en cache) et à peaufiner les configurations serveur, tout en ignorant le fait que leur thème charge 800 Ko ou plus de fichiers de polices à chaque chargement de page. Cet article explique exactement pourquoi cela se produit, comment auditer votre chargement de polices et que faire pour y remédier.

Comment les thèmes PrestaShop intègrent les polices

Les thèmes PrestaShop sont distribués sous forme de packages autonomes. Lorsqu'un développeur de thème construit un thème, il souhaite qu'il fonctionne clé en main pour le plus grand nombre de boutiques possible. Cela signifie qu'il inclut chaque variante de police et chaque bibliothèque d'icônes dont il pourrait concevoir le besoin. Le résultat est un thème livré avec bien plus de ressources de polices qu'une seule boutique n'en utilisera jamais.

Un thème PrestaShop typique inclut trois catégories de polices. Premièrement, il y a les polices d'affichage utilisées pour les titres, le corps du texte et les éléments d'interface. Ce sont généralement des Google Fonts comme Roboto, Open Sans, Lato ou Montserrat. Deuxièmement, il y a les polices d'icônes comme FontAwesome, Material Icons ou des jeux d'icônes spécifiques au thème. Troisièmement, il y a les polices de repli ou décoratives que le thème utilise pour des composants spécifiques comme les bannières, les badges ou les sections promotionnelles.

Le problème se multiplie car chaque famille de polices est généralement livrée avec plusieurs graisses et styles. Une seule police comme Roboto peut inclure Regular (400), Medium (500), Bold (700) et leurs variantes italiques, chacune sous forme d'un fichier WOFF2 séparé. Multipliez cela par deux ou trois familles de polices plus une bibliothèque d'icônes, et vous atteignez rapidement 12 à 15 fichiers de polices individuels chargés à chaque page.

Le problème FontAwesome

FontAwesome mérite sa propre section car c'est le plus grand coupable en matière de performance liée aux polices dans les thèmes PrestaShop. La bibliothèque complète de FontAwesome 5 pèse environ 150 Ko pour le fichier de police web seul, plus 60 à 80 Ko supplémentaires pour son CSS. FontAwesome 6 est encore plus volumineux. La bibliothèque contient plus de 1 600 icônes, mais la boutique PrestaShop moyenne en utilise peut-être 20 à 30.

Cela signifie que vous forcez chaque visiteur à télécharger plus de 200 Ko de données de police et de CSS juste pour afficher une icône de panier, une loupe de recherche et quelques logos de réseaux sociaux. C'est un compromis absurde, et cela se produit parce que les développeurs de thèmes trouvent plus facile d'inclure la bibliothèque entière que de la sous-ensemble pour les besoins spécifiques de chaque boutique.

Le thème Classic embarque FontAwesome qui est légèrement plus petit mais contient tout de même des centaines d'icônes que vous n'utiliserez jamais. Le thème Hummingbird, plus récent, s'est éloigné de FontAwesome en faveur des icônes SVG, ce qui est une amélioration significative, mais de nombreux thèmes et modules tiers s'appuient toujours sur FontAwesome et chargent leur propre copie en plus de ce que le thème fournit.

Google Fonts et la taxe sur les performances

Google Fonts est le service de polices web le plus populaire, et les thèmes PrestaShop en font un usage intensif. Cependant, charger Google Fonts de la manière par défaut crée une chaîne de requêtes qui nuisent aux performances.

Lorsque votre thème charge Google Fonts via la balise link standard, le navigateur doit d'abord se connecter à fonts.googleapis.com pour télécharger le fichier CSS. Ce fichier CSS indique ensuite au navigateur de télécharger les fichiers de polices réels depuis fonts.gstatic.com. Chacune de ces connexions nécessite une résolution DNS, un handshake TCP et une négociation TLS. Sur les connexions mobiles, cette chaîne peut ajouter 300 à 500 ms de délai avant qu'un seul caractère de texte ne s'affiche à l'écran.

Pire encore, le CSS de Google Fonts utilise le descripteur font-display défini sur « swap » par défaut depuis 2019, mais de nombreux thèmes plus anciens référencent encore des URL de CSS Google Fonts qui précèdent ce changement. Sans font-display: swap, le navigateur peut masquer tout le texte de la page jusqu'à ce que la police soit téléchargée, créant le redouté Flash of Invisible Text (FOIT) où les visiteurs voient une page vide pendant une à trois secondes.

Il y a également une préoccupation en matière de vie privée. Charger des polices depuis le CDN de Google signifie que Google reçoit des informations sur chaque visiteur de votre boutique, y compris son adresse IP et les pages visitées. En vertu du RGPD, cela nécessite un consentement explicite, et un tribunal allemand a jugé en janvier 2022 que l'utilisation de Google Fonts sans consentement viole le RGPD, avec des amendes à la clé.

Comment auditer votre chargement de polices

Avant de pouvoir résoudre le problème, vous devez comprendre exactement quelles polices votre thème charge et lesquelles vous utilisez réellement. Voici une approche systématique.

Ouvrez les DevTools de Chrome (F12), allez dans l'onglet Réseau et cochez la case « Désactiver le cache ». Rechargez votre page et filtrez par « Font » dans la barre de filtre. Vous verrez chaque fichier de police que le navigateur télécharge. Notez les noms de fichiers, les tailles et la colonne Initiateur qui vous indique quel fichier CSS a demandé chaque police.

Ensuite, utilisez l'onglet Couverture dans les DevTools (Ctrl+Shift+P, puis tapez « Coverage »). Démarrez un enregistrement de couverture et naviguez dans votre boutique. L'onglet Couverture vous montre exactement quelle proportion de chaque fichier CSS est réellement utilisée. Pour le CSS de FontAwesome, vous verrez généralement 90 % ou plus marqué comme non utilisé.

Vous pouvez également utiliser l'audit Lighthouse dans les DevTools. Lancez un audit de performance et recherchez les opportunités « Réduire le CSS inutilisé » et « Garantir que le texte reste visible pendant le chargement des polices web ». Lighthouse signalera spécifiquement les problèmes de performance liés aux polices.

Pour une analyse plus approfondie, utilisez WebPageTest (webpagetest.org) pour lancer un test depuis une connexion mobile. Examinez le graphique en cascade et trouvez les requêtes de polices. Notez quand elles commencent à se charger par rapport aux autres ressources et combien de temps elles prennent. Sur une connexion 3G, les délais de chargement des polices deviennent douloureusement évidents.

Supprimer les polices inutilisées étape par étape

Une fois que vous savez quelles polices votre thème charge et lesquelles vous utilisez réellement, il est temps de supprimer le surplus. L'approche diffère selon l'architecture de votre thème.

Pour les thèmes qui chargent Google Fonts via une balise link dans le template d'en-tête, trouvez le fichier de template qui contient la référence Google Fonts. Dans la plupart des thèmes, il se trouve dans templates/layout/head.tpl ou un fichier similaire. Si vous utilisez un thème enfant, copiez ce template dans le répertoire de votre thème enfant avant de le modifier. Supprimez ou modifiez le lien Google Fonts pour n'inclure que les graisses et familles que vous utilisez réellement.

Pour FontAwesome, vérifiez si votre thème le charge via un fichier CSS dans le répertoire assets/css ou via un lien CDN. S'il s'agit d'un fichier local, vous avez deux options. Vous pouvez remplacer le package complet de FontAwesome par un sous-ensemble contenant uniquement les icônes que vous utilisez, ou vous pouvez remplacer entièrement l'utilisation de la police d'icônes par des SVG en ligne.

Pour créer un sous-ensemble de FontAwesome, utilisez un outil comme IcoMoon (icomoon.io) ou Fontello (fontello.com). Ces outils vous permettent de sélectionner uniquement les icônes spécifiques dont vous avez besoin et de générer un fichier de police personnalisé qui pourrait peser 5 à 10 Ko au lieu de 150 Ko. Vous devrez mettre à jour les noms de classes CSS si l'outil en génère de différents, mais la plupart permettent de conserver les noms de classes FontAwesome originaux.

Pour Google Fonts, vérifiez chaque fichier CSS de votre thème pour les déclarations @font-face. Les développeurs de thèmes importent parfois des polices directement dans le CSS plutôt que via le template d'en-tête. Utilisez la recherche DevTools (Ctrl+Shift+F) pour chercher dans toutes les ressources chargées « @font-face » et « fonts.googleapis.com ».

Implémenter font-display: swap

Si vous conservez des polices web, assurez-vous absolument qu'elles utilisent le descripteur font-display: swap. Cela indique au navigateur d'afficher immédiatement le texte en utilisant une police système de repli pendant que la police web se télécharge en arrière-plan. Une fois la police web prête, le navigateur la substitue. Cela élimine le FOIT et garantit que votre contenu est lisible instantanément.

Pour les Google Fonts chargées via CDN, ajoutez le paramètre display=swap à l'URL. Par exemple, changez fonts.googleapis.com/css2?family=Roboto:wght@400;700 en fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap. Notez que Google a ajouté ce paramètre par défaut en 2019, mais de nombreux thèmes PrestaShop utilisent encore des formats d'URL plus anciens.

Pour les polices auto-hébergées avec des déclarations @font-face dans votre CSS, ajoutez font-display: swap à chaque bloc @font-face. Ouvrez le fichier CSS de votre thème contenant les règles @font-face et ajoutez la propriété. Elle se place à l'intérieur du bloc @font-face aux côtés de font-family, src et font-weight.

Sachez que font-display: swap peut provoquer un Flash of Unstyled Text (FOUT) où le texte apparaît brièvement dans la police de repli avant de basculer vers la police web. C'est une bien meilleure expérience que du texte invisible, mais vous pouvez minimiser le décalage visuel en choisissant des polices de repli qui correspondent étroitement aux métriques de votre police web. Les propriétés CSS size-adjust, ascent-override et descent-override aident dans ce sens.

Auto-hébergement des polices vs chargement via CDN

L'auto-hébergement de vos polices plutôt que leur chargement depuis le CDN de Google offre plusieurs avantages significatifs pour les boutiques PrestaShop.

Les performances s'améliorent car vous éliminez la requête DNS supplémentaire et la connexion aux serveurs de Google. Vos polices se chargent depuis le même domaine que vos autres ressources, ce qui signifie que le navigateur peut réutiliser les connexions existantes. Avec HTTP/2 ou HTTP/3, tous vos fichiers de polices peuvent se télécharger simultanément via une seule connexion.

La conformité en matière de vie privée devient plus simple car les données des visiteurs ne sont plus envoyées à Google. Cela élimine entièrement une préoccupation liée au RGPD, et vous n'avez pas besoin d'ajouter Google Fonts à votre bandeau de consentement aux cookies.

La fiabilité s'améliore car vous ne dépendez pas d'un service externe. Si le CDN de Google a un problème (rare mais cela arrive), vos polices se chargent tout de même.

Pour auto-héberger les Google Fonts, utilisez l'outil google-webfonts-helper (gwfh.mranftl.com/fonts) qui fournit une interface simple pour télécharger n'importe quelle Google Font au format WOFF2 avec le CSS @font-face correct. Téléchargez uniquement les graisses et styles dont vous avez besoin, placez les fichiers dans le répertoire assets/fonts de votre thème et ajoutez le CSS @font-face à la feuille de style de votre thème.

Le seul inconvénient potentiel de l'auto-hébergement est la perte de la possibilité d'un cache hit si le visiteur a déjà chargé la même police depuis le CDN de Google sur un autre site. Cependant, les navigateurs ont largement éliminé ce cache inter-sites pour des raisons de confidentialité depuis 2020, donc cet avantage n'existe plus en pratique.

Le sous-ensemble de polices : l'option radicale

Le sous-ensemble de polices signifie la suppression des caractères dont vous n'avez pas besoin dans un fichier de police. Une police web latine typique inclut des caractères pour des dizaines de langues, dont beaucoup ne sont pas utilisées par votre boutique. En faisant un sous-ensemble limité aux seuls caractères dont votre boutique a besoin, vous pouvez réduire la taille des fichiers de polices de 50 à 70 %.

L'outil pyftsubset de la bibliothèque Python fonttools est la méthode la plus fiable pour créer des sous-ensembles de polices. Vous pouvez spécifier exactement quelles plages Unicode inclure. Pour une boutique qui opère uniquement en français, vous pourriez faire un sous-ensemble limité au Latin de base (U+0020-007F) plus le Supplément Latin-1 (U+00A0-00FF) pour les symboles de devises et les caractères accentués.

Pour les boutiques opérant dans plusieurs langues, vous devez être plus prudent. Incluez les plages Unicode pour toutes les langues que votre boutique prend en charge. Le CSS de Google Fonts fait en réalité cela automatiquement avec les descripteurs unicode-range, chargeant les sous-ensembles de caractères à la demande, mais les polices auto-hébergées nécessitent un sous-ensemble manuel.

Une approche plus simple consiste à utiliser exclusivement le format WOFF2 et à abandonner la prise en charge des formats plus anciens. WOFF2 utilise la compression Brotli et produit des fichiers 30 % plus petits que WOFF. Chaque navigateur moderne prend en charge WOFF2, donc à moins de devoir prendre en charge Internet Explorer 11, il n'y a aucune raison d'inclure les formats WOFF, TTF ou EOT. De nombreux thèmes PrestaShop sont encore livrés avec les quatre formats pour une rétrocompatibilité qui n'est plus nécessaire.

Les piles de polices système : l'alternative à coût zéro

L'approche la plus radicale aux problèmes de performance des polices est de ne pas utiliser de polices web du tout. Les systèmes d'exploitation modernes sont livrés avec des polices de haute qualité qui s'affichent parfaitement à l'écran. Une pile de polices système utilise la police que le système d'exploitation fournit, ce qui signifie zéro fichier de police à télécharger et un rendu du texte instantané.

La pile de polices système moderne ressemble à ceci : font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif. Cela vous donne San Francisco sur les appareils Apple, Segoe UI sur Windows et Roboto sur Android. Ce sont toutes des polices sans-serif propres, modernes et très lisibles.

GitHub, Bootstrap 5 et de nombreux sites web haute performance utilisent des piles de polices système. La différence visuelle entre une police système et une Google Font comme Open Sans ou Roboto est minimale, surtout pour le corps du texte. La plupart de vos clients ne remarqueront pas ou ne se soucieront pas de savoir si votre boutique utilise Roboto chargée depuis un serveur ou Roboto déjà installée sur leur téléphone Android.

Pour implémenter une pile de polices système dans PrestaShop, vous devez modifier le CSS de votre thème pour remplacer les déclarations font-family existantes, supprimer les règles @font-face et les balises link Google Fonts, et supprimer les fichiers de polices du répertoire assets de votre thème. Si vous utilisez un thème enfant, vous pouvez surcharger les déclarations de polices du thème parent sans modifier les fichiers du thème parent.

Et les polices d'icônes ?

Si vous supprimez FontAwesome ou une autre police d'icônes, vous avez besoin d'une alternative pour afficher les icônes. La meilleure approche moderne est le SVG en ligne. Les icônes SVG s'affichent nettement à toute taille, peuvent être stylisées avec du CSS, et n'ajoutent du poids que pour les icônes spécifiques que vous utilisez plutôt que de charger une bibliothèque d'icônes entière.

Le thème Hummingbird de PrestaShop utilise nativement les icônes SVG, ce qui est l'une des raisons pour lesquelles il est plus performant que Classic. Si votre thème utilise FontAwesome, vous pouvez remplacer les icônes individuelles par des SVG provenant de sources comme Heroicons, Feather Icons, ou même les fichiers SVG propres à FontAwesome (qui sont disponibles séparément de la version police).

Pour une boutique PrestaShop, vous avez généralement besoin de moins de 30 icônes uniques : panier, recherche, compte utilisateur, cœur/liste de souhaits, flèches, logos de réseaux sociaux et quelques icônes spécifiques aux catégories. Sous forme de SVG en ligne, celles-ci pourraient totaliser 10 à 15 Ko, contre 150 à 200 Ko pour la police et le CSS complets de FontAwesome.

Mesurer l'impact

Après avoir supprimé les polices inutilisées, mesurez l'amélioration. Lancez Lighthouse avant et après, en comparant le score de Performance, le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP). L'optimisation des polices améliore généralement le FCP de 200 à 500 ms sur les connexions mobiles.

Vérifiez la taille totale de transfert dans l'onglet Réseau des DevTools. Une boutique PrestaShop bien optimisée devrait transférer moins de 50 Ko de données de polices au total. Si vous passez aux polices système, ce chiffre tombe à zéro.

Vérifiez également que votre boutique s'affiche toujours correctement. Vérifiez chaque type de page : page d'accueil, catégorie, produit, panier et commande. Certains thèmes utilisent des polices spécifiques pour des éléments spécifiques, et la suppression d'une police peut provoquer un rendu de repli inattendu. Testez toujours minutieusement avant de déployer les modifications de polices en production.

Résumé : une checklist de chargement des polices

Auditez votre chargement de polices actuel avec l'onglet Réseau des DevTools filtré sur les polices. Identifiez quelles polices sont réellement utilisées en vérifiant la couverture CSS. Supprimez toutes les familles ou graisses Google Fonts que vous n'utilisez pas. Remplacez les polices d'icônes complètes par des versions sous-ensemblées ou des SVG en ligne. Ajoutez font-display: swap à toutes les déclarations @font-face restantes. Auto-hébergez vos polices au lieu de les charger depuis le CDN de Google. Envisagez le WOFF2 uniquement pour éliminer les formats plus anciens et volumineux. Évaluez si les polices système pourraient remplacer vos polices web entièrement. Mesurez avant et après avec Lighthouse et WebPageTest. L'objectif est simple : ne charger que ce dont vous avez besoin, le charger efficacement, et ne jamais faire attendre vos visiteurs pour des polices qu'ils ne peuvent pas voir.

Pour une checklist de vitesse complète, consultez notre guide de performance PrestaShop.

Classic vs Hummingbird, côte à côte

PrestaShop fournit deux thèmes officiels : Classic et Hummingbird. Classic est le thème par défaut historique ; Hummingbird est la nouvelle alternative axée performance. Le choix n'est pas affaire de goût, les deux adoptent des architectures front-end fondamentalement différentes, et votre décision influe sur la performance, la compatibilité des modules, l'effort de personnalisation et la maintenabilité dans le temps.

Architecture : ce qui change et pourquoi

Classic s'appuie sur jQuery et les templates Smarty avec une approche serveur classique : le serveur génère des pages HTML complètes que le navigateur affiche. Le JavaScript gère les parties interactives comme le panier, la fiche produit et le tunnel de commande. Le CSS est compilé depuis Sass en une seule grande feuille de styles.

Hummingbird est une refonte complète. Il abandonne jQuery au profit du JavaScript natif et d'une structure par composants, propose une couche CSS plus modulaire et présente une empreinte d'assets nettement plus légère.

L'abandon de jQuery est le changement le plus lourd de conséquences. Hummingbird s'appuie à la place sur des API navigateur modernes (fetch, querySelector, classList, délégation d'événements). Le thème est plus léger, mais les modules conçus pour jQuery doivent être mis à jour. Le framework CSS plus récent de Hummingbird utilise aussi des propriétés personnalisées (variables) pour faciliter le theming, ce qui touche tout CSS personnalisé référençant les noms de classes de l'ancien framework.

Performance : à quoi s'attendre

La performance est la principale raison d'être de Hummingbird. À installation équivalente, sa charge CSS réduite et l'absence de jQuery bloquant le rendu produisent généralement un First Contentful Paint et un Largest Contentful Paint plus rapides, ainsi qu'une nette baisse du Total Blocking Time, car bien moins de JavaScript doit être traité sur le thread principal. Le Cumulative Layout Shift est à peu près équivalent quand les deux sont bien configurés, la stabilité dépendant davantage des dimensions d'images et du lazy loading que du framework.

Considérez l'écart comme une tendance, pas une garantie : les modules tiers ajoutent leur propre CSS et JavaScript, ce qui peut creuser ou réduire la différence. Mesurez vos propres pages plutôt que de vous fier à des chiffres génériques.

Compatibilité des modules : le vrai piège

C'est là que l'avantage de Hummingbird s'accompagne d'une réserve. Beaucoup de modules ont été conçus pour l'architecture de Classic : ils dépendent de jQuery, utilisent l'ancien markup Bootstrap et supposent la structure de templates de Classic. Sur Hummingbird, le JavaScript jQuery peut échouer en silence, d'anciens composants peuvent mal s'afficher, et les surcharges de templates écrites pour Classic ne correspondent pas aux templates réorganisés de Hummingbird.

La gravité dépend de votre stack. Les modules natifs de PrestaShop fonctionnent sur les deux. Les modules tiers bien maintenus par des développeurs actifs supportent généralement Hummingbird ; les modules anciens ou abandonnés peuvent ne marcher que sur Classic. Avant de vous engager sur Hummingbird, testez chaque module prévu sur une copie de préproduction, surtout les paniers AJAX, les champs de personnalisation produit, les aperçus rapides et les étapes de commande. Quand un module fournit des dossiers de templates séparés pour Classic et Hummingbird, c'est le signe le plus clair qu'il supporte les deux.

Smarty vs Twig : pérennité

PrestaShop a annoncé son intention de faire passer le front-office de Smarty à Twig avec le temps, et la structure de templates de Hummingbird est organisée dans cette optique, même si les deux thèmes utilisent encore Smarty en front-office aujourd'hui. En pratique : des personnalisations lourdes bâties sur la structure de Classic peuvent demander plus d'efforts de migration le jour où cette transition arrivera. Ne décidez pas sur ce seul critère, mais c'est un point en faveur de Hummingbird.

Personnalisation

Personnaliser Classic est un terrain connu : des années de tutoriels et de discussions, du Sass simple et des templates Smarty faciles à lire. Hummingbird demande des compétences plus actuelles, CSS moderne, JavaScript natif et approche utility-first, la courbe d'apprentissage est donc plus raide si votre équipe s'appuie sur jQuery.

En contrepartie, les propriétés personnalisées CSS de Hummingbird simplifient bien des changements. Changer la couleur principale sur tout le thème ? Une propriété personnalisée au lieu de traquer des variables Sass et de recompiler. Son HTML plus sémantique facilite aussi le ciblage des éléments et améliore l'accessibilité.

Support des thèmes enfants

Les deux thèmes supportent les thèmes enfants, la méthode recommandée pour personnaliser sans toucher aux fichiers du parent, afin que vos changements survivent aux mises à jour. Vous créez un dossier de thème enfant, pointez son theme.yml vers le parent et ne surchargez que les fichiers nécessaires. Le mécanisme est identique ; la différence : un thème enfant bâti sur Classic ne se réutilise pas sur Hummingbird, car les templates sont structurés différemment, vous reconstruisez les surcharges pour Hummingbird.

Si vous commandez un thème sur mesure, partir de Hummingbird comme parent est le meilleur pari à long terme : architecture plus propre, moins de dette technique, moins de surcharges pour les changements courants. Dans tous les cas, créez un thème enfant correct en quelques secondes avec notre générateur de thème enfant gratuit, choisissez Classic ou Hummingbird comme parent et il câble pour vous le theme.yml, les fichiers d'assets et des exemples de surcharges.

Migration : de Classic vers Hummingbird

Si vous êtes sur Classic et envisagez le changement : les surcharges de templates doivent être reconstruites, on ne copie pas des surcharges Classic dans un thème enfant Hummingbird, car structure des fichiers, noms de variables et de blocs diffèrent. Le CSS personnalisé doit être revu et sans doute révisé, les noms de classes du framework ayant changé et tout style dépendant de jQuery cassant. Le JavaScript personnalisé doit être réécrit de jQuery vers du JavaScript natif, souvent la partie la plus longue. Et chaque module installé doit être vérifié. Planifiez cela comme un vrai projet de développement, avec préproduction, tests approfondis et plan de retour arrière, pas un projet de week-end.

Quand choisir Classic

Choisissez Classic quand votre boutique dépend de modules tiers anciens non mis à jour pour Hummingbird ; quand votre équipe est plus à l'aise avec jQuery et sans budget de formation ; ou quand, sous contrainte de délai, vous voulez le plus large choix de thèmes et modules compatibles. Si vous êtes déjà sur Classic avec de nombreuses personnalisations et que la boutique tourne bien, il n'y a peut-être aucune raison impérieuse de migrer.

Quand choisir Hummingbird

Choisissez Hummingbird pour une boutique neuve. Les gains de performance sont gratuits sans héritage à migrer. Choisissez-le quand la performance prime, surtout pour une audience surtout mobile sur connexions lentes. Choisissez-le pour rester aligné sur la direction de PrestaShop, et quand votre équipe maîtrise le JavaScript et le CSS modernes. C'est aussi un meilleur point de départ pour l'accessibilité, grâce à un HTML plus sémantique, un meilleur support ARIA et la navigation au clavier.

Thèmes tiers

Beaucoup de boutiques délaissent les deux thèmes officiels pour un thème du marché. Ceux-ci reposent presque toujours sur l'architecture de Classic, sa base installée étant plus large. Sur un thème tiers, la question Classic-vs-Hummingbird est largement théorique pour la boutique actuelle, l'auteur a tranché. Pour de nouveaux thèmes, vérifiez sur quelle base ils sont bâtis, et méfiez-vous de ceux qui se disent « basés sur Hummingbird » mais n'en empruntent que le style en restant dépendants de jQuery à l'intérieur.

Verdict : pas de mauvais choix, mais un meilleur

Pour les nouvelles boutiques, Hummingbird s'impose : plus léger, plus moderne, mieux aligné sur la direction de PrestaShop, et l'écart de compatibilité se réduit à mesure que l'écosystème suit. Pour les boutiques Classic existantes très personnalisées, faites le calcul honnêtement : mesurez la performance actuelle, estimez l'effort réel de migration et décidez si le gain le justifie. Parfois oui ; parfois le bon moment, c'est votre prochaine refonte.

Quel que soit votre choix, les fondamentaux comptent autant : réduire la taille des assets, charger en lazy le contenu sous la ligne de flottaison, optimiser les images et auditer régulièrement la vitesse. Une boutique Classic bien optimisée battra toujours une boutique Hummingbird mal configurée.

À lire aussi : guide des thèmes enfants PrestaShop et Comment choisir le bon thème PrestaShop.

Votre thème est sans doute plus lent que vous ne le pensez

Chaque commerçant a un avis sur la vitesse de son thème, mais très peu ont des données. « Ça paraît rapide » ne veut rien dire quand les Core Web Vitals se mesurent à la milliseconde. Pour comprendre l'impact réel, il faut une approche systématique qui isole la part du thème de la performance serveur, de la charge des modules et du réseau.

Ce guide déroule une méthodologie complète. Vous apprendrez à utiliser Lighthouse, WebPageTest, Chrome DevTools et le monitoring utilisateur réel pour chiffrer exactement ce que coûte votre thème en temps de chargement, en interactivité et en stabilité visuelle, et surtout à séparer le thème du reste pour décider quoi optimiser.

Pourquoi la performance du thème compte

Votre thème contrôle toute l'expérience front-end : quel CSS se charge, combien de JavaScript s'exécute, comment images et polices sont gérées, comment la mise en page se construit. Un thème lourd peut ajouter des secondes au chargement quelle que soit la vitesse du serveur. Les Core Web Vitals mesurent précisément les parties que votre thème contrôle : Largest Contentful Paint (rapidité d'apparition du contenu principal), Interaction to Next Paint (rapidité de réponse de la page) et Cumulative Layout Shift (stabilité visuelle). Les trois dépendent fortement de l'architecture du thème. Ce qui en fait une analyse de l'expérience client, pas seulement technique.

Préparer l'environnement de test

Mesurer sur une boutique en ligne pendant que les clients naviguent et que la charge fluctue donne des résultats incohérents. Réduisez les variables. Idéalement une copie de préproduction : même profil serveur, mêmes modules, mêmes produits, même config de thème, sans trafic réel. À défaut, testez en heures creuses, lancez chaque test au moins trois fois et faites la moyenne.

Désactivez tout proxy de cache (CDN) pour les tests, ou utilisez une URL de préproduction qui le contourne, le cache CDN masque le vrai coût. Documentez la base : version PHP, modules actifs, réglages CCC (Combiner, Compresser, Cache) et caractéristiques serveur, pour reproduire et comparer dans le temps.

Lighthouse : le point de départ

Lighthouse est intégré aux Chrome DevTools et c'est l'audit le plus accessible. Il simule un mobile sur connexion bridée. Pour le lancer : DevTools (F12), onglet Lighthouse, choisir « Performance » et « Mobile », cliquer « Analyze page load ». Le score Performance est une moyenne pondérée de plusieurs métriques, mais Largest Contentful Paint et Total Blocking Time dominent. Ce sont les plus affectées par la qualité du thème.

Lancez l'audit sur au moins quatre types de pages : accueil, catégorie, produit et panier/commande. Chacun a une complexité DOM et des besoins en assets différents, et votre thème peut s'y comporter très différemment. Une réserve : Lighthouse simule, ses valeurs absolues ne reflètent pas le réel. Elles servent à comparer (avant/après, thème A/B). Pour des chiffres réels, il faut le monitoring utilisateur réel (plus bas). Notez chaque résultat dans un tableur (URL, date/heure, score, chaque métrique) pour bâtir une base.

WebPageTest : analyse approfondie

WebPageTest (webpagetest.org) est gratuit et bien plus détaillé, avec de vrais navigateurs sur du vrai matériel dans le monde entier. Saisissez l'URL, choisissez un lieu de test proche de votre audience principale et un profil de connexion (boutiques européennes : Francfort ou Londres en Câble ou 4G), et lancez au moins trois tests pour une médiane.

Le diagramme en cascade est la sortie la plus précieuse : chaque ressource, dans l'ordre, avec son temps de téléchargement. Les ressources bloquant le rendu et les chargements inutiles deviennent évidents. Surveillez le CSS/JS bloquant le rendu en longues barres avant tout contenu, les grosses polices avant le contenu critique, et les requêtes tierces (analytics, widgets sociaux, chat) qui retardent vos assets. La vue pellicule montre des captures à intervalles pour voir quand texte et images apparaissent et quand surviennent les décalages. La répartition du contenu montre le poids total par type (HTML, CSS, JS, images, polices).

Onglet Performance de DevTools : image par image

L'onglet Performance offre la vue la plus fine, enregistrant une chronologie de l'exécution JavaScript, du layout, du paint et du compositing. DevTools (F12), Performance, activez « Screenshots » et « Web Vitals », réglez le réseau « Slow 3G » et le CPU « 4x slowdown », puis enregistrez et rechargez.

Concentrez-vous sur la piste du thread principal. Les longs blocs jaunes sont de l'exécution JavaScript. Tout ce qui dépasse 50 ms est une « tâche longue » qui bloque l'interaction et augmente le Total Blocking Time. Cliquez dedans pour voir la pile d'appels ; si les tâches longues viennent des scripts du thème, c'est un problème de thème. Les blocs rouges signalent du layout thrashing, où le navigateur recalcule la mise en page à répétition, souvent à cause de JavaScript qui lit des propriétés de layout (offsetHeight, getBoundingClientRect) puis modifie le DOM en boucle, cause fréquente d'un mauvais INP. Les onglets « Bottom-Up » et « Call Tree » trient par temps total ou propre pour trouver les fonctions les plus lourdes.

Cascade réseau pour les assets du thème

L'onglet Réseau offre une autre vue. Filtrez par type (CSS, JS, Font, Img) pour isoler les assets du thème. Repérez tout ce qui se charge depuis les chemins du thème (ex. /themes/votre-theme/assets/), notez le nombre et la taille cumulée, puis faites de même pour /modules/ afin de séparer la part des modules.

Cochez « Désactiver le cache » et rechargez pour simuler un premier visiteur ; notez la taille transférée et les temps DOMContentLoaded et Load. Rechargez sans la case pour l'expérience visiteur récurrent (en cache), l'écart montre combien le thème profite du cache. La colonne « Initiator » trace la chaîne de dépendances (un CSS chargé dans l'en-tête bloque le rendu ; un script async/defer non), la colonne « Priority » montre le classement du navigateur. Des ressources non critiques chargées en haute priorité sont une piste d'optimisation.

La comparaison avec/sans thème

Pour vraiment isoler l'impact, comparez. En préproduction, lancez une série complète avec votre thème, notez tout, puis basculez sur un thème par défaut (Classic ou Hummingbird) et remesurez. L'écart est l'impact additionnel de votre thème par rapport au défaut. Imparfait, le défaut n'a aucune de vos personnalisations, mais il donne un plafond de ce que l'optimisation du thème peut apporter. Plus contrôlé : désactivez progressivement les fonctions du thème (polices personnalisées, puis effets JavaScript, puis la police d'icônes) en mesurant après chaque étape.

Core Web Vitals : labo vs terrain

Les Core Web Vitals se mesurent sur de vrais utilisateurs via le Chrome User Experience Report (CrUX), pas en labo. Les mesures labo (Lighthouse, WebPageTest) utilisent des conditions simulées ; les mesures terrain (CrUX, RUM) captent les expériences réelles selon appareils, réseaux et lieux. Votre score Lighthouse peut être 75, mais si beaucoup de clients ont des téléphones anciens et des connexions lentes, les données terrain racontent une autre histoire.

Consultez le terrain dans le rapport Core Web Vitals de la Search Console ou dans PageSpeed Insights (pagespeed.web.dev), qui montre labo et terrain côte à côte si le trafic le permet. Les seuils « bon » sont LCP sous 2,5 s, INP sous 200 ms et CLS sous 0,1, évalués au 75e percentile de vos utilisateurs, une barre haute, car vos visiteurs les plus lents pèsent lourd. Votre thème touche les trois : LCP via taille du CSS, polices et image héro ; INP via exécution JavaScript et gestionnaires d'événements ; CLS via placeholders d'images, contenu injecté et chargement des polices.

Monitoring utilisateur réel : la vérité terrain

Le monitoring utilisateur réel (RUM) capte la performance de vos vrais visiteurs, la mesure la plus exacte de l'impact réel, reflétant leurs appareils et réseaux réels. Google Analytics 4 capte les Core Web Vitals automatiquement avec le snippet gtag.js ; consultez sous Rapports, Expérience utilisateur, ou une exploration personnalisée. Pour plus de détail, des services comme SpeedCurve ou Datadog, ou la bibliothèque JavaScript gratuite web-vitals, fournissent des données fines. Web-vitals est pratique car vous l'ajoutez au thème et envoyez les données vers n'importe quel endpoint.

Avec le RUM, segmentez par appareil, navigateur, pays et type de page, ce qui révèle souvent un thème bon sur Chrome bureau mais médiocre sur Safari mobile. Suivez-le dans le temps pour corréler les changements aux mises à jour de thème ou installations de modules, si le LCP bondit de 500 ms, regardez ce qui a changé ce jour-là.

Profilage serveur : back-end vs front-end

Parfois la lenteur est imputée au thème alors que la vraie cause est le temps de traitement serveur. Avant d'optimiser le thème, vérifiez que le serveur génère le HTML rapidement. Le profileur intégré de PrestaShop (Paramètres avancés > Performances > Mode debug) ajoute une barre de debug montrant le nombre et le temps des requêtes SQL, le temps de génération de page et la mémoire. La plupart des pages doivent se générer côté serveur bien en deçà d'une seconde ; si cela prend des secondes, le problème est le serveur, les requêtes ou les hooks de modules, optimiser le thème n'y changera rien.

Vous pouvez aussi lire le temps de réponse serveur (Time to First Byte) dans l'onglet Réseau : cliquez la requête du document HTML, regardez Timing > « Waiting (TTFB) ». Si le TTFB est élevé mais les assets du thème rapides, occupez-vous du serveur (OPcache PHP, cache MySQL, Redis/Memcached, cache objet PrestaShop). Si le TTFB est rapide mais la page lente, le thème est le goulot probable.

Le cadre de benchmark avant/après

Quand vous changez quelque chose, prouvez que ça aide. Avant tout changement, lancez cinq audits Lighthouse par page cible et notez la médiane du score et des métriques, plus trois runs WebPageTest pour une médiane, sauvegardez les rapports complets, pas seulement les scores. Faites le changement, puis videz tous les caches (cache Smarty, OPcache, cache CDN) et attendez au moins 60 secondes le reset d'OPcache si vous avez touché du PHP. Relancez les mêmes cinq tests Lighthouse et trois WebPageTest sur les mêmes pages et comparez les médianes. Un changement n'est significatif que s'il améliore de façon constante sur tous les runs ; si certains s'améliorent et d'autres régressent, c'est du bruit de mesure.

Méfiez-vous des petits gains. Lighthouse peut varier de quelques points entre runs identiques à cause du bridage, donc 62 à 65 peut être du bruit alors que 62 à 75 ne l'est presque sûrement pas. Le plus rigoureux : la comparaison visuelle de WebPageTest pour une pellicule côte à côte.

Problèmes de performance courants et comment les repérer

La mesure fait remonter des problèmes précis, chacun avec sa signature. Le CSS bloquant le rendu se voit en FCP/LCP élevés avec un long écart entre TTFB et FCP dans la cascade, corrigez en inlinant le CSS critique et différant le reste. Un JavaScript excessif se voit en Total Blocking Time élevé et mauvais INP, confirmé par des tâches longues dans la chronologie. Un mauvais chargement de polices se voit en texte invisible sur la pellicule ou un écart entre FCP et l'apparition du texte. Le décalage de mise en page dû à des images sans dimensions ou du contenu injecté se voit en CLS élevé. Apprenez ces signatures et le travail de performance passe de la devinette à l'ingénierie : mesurer, diagnostiquer d'après les données, corriger le problème précis, remesurer.

Mettre en place une routine de suivi

La mesure n'est pas ponctuelle. Chaque semaine, lancez Lighthouse sur vos quatre types de pages clés et consignez les résultats. Chaque mois, une analyse WebPageTest complète comparée au mois précédent. Après chaque mise à jour de thème ou installation de module, un avant/après. Revoyez les Core Web Vitals dans la Search Console chaque mois. Envisagez d'automatiser avec Lighthouse CI (audits dans votre pipeline de déploiement) ou des services de suivi continu qui alertent en cas de dégradation, pour attraper les régressions avant qu'elles n'atteignent les clients. Le but n'est pas un score parfait, mais de savoir exactement où passent votre temps et vos octets à chaque chargement, et de décider de façon délibérée et fondée sur les données.

Quand vous appliquez des correctifs côté thème, gardez-les dans un thème enfant pour qu'une mise à jour ne les efface pas, notre générateur de thème enfant gratuit en crée un en quelques secondes. À lire aussi : guide des thèmes enfants PrestaShop et Optimiser les performances de votre boutique PrestaShop : des requêtes BDD au cache pleine page.

La réponse honnête à « gratuit ou premium ? » : le vrai coût d'un thème est rarement son prix d'achat. Un thème gratuit qui demande des centaines d'euros de personnalisation, plombe les performances ou manque de fonctions peut coûter plus cher qu'un thème premium qui fonctionne correctement dès le départ.

Ce que les thèmes gratuits offrent vraiment

PrestaShop est livré avec un thème par défaut officiel. Il est vraiment bien conçu, il respecte les normes de codage de la plateforme, prend en charge les hooks standards, fonctionne avec le système de traduction et est mis à jour avec le cœur. Avec des compétences en CSS, c'est un point de départ légitime. Au-delà, la qualité des thèmes gratuits tiers varie énormément : certains sont des versions « aperçu » limitées de thèmes premium, d'autres des projets amateurs, et quelques-uns sont gratuits parce qu'ils embarquent des logiciels publicitaires, des liens cachés ou un suivi non déclaré. Examinez avec prudence les thèmes gratuits de sources inconnues.

Ce qu'apportent les thèmes premium

Un thème premium offre généralement un design soigné avec plusieurs mises en page et jeux de couleurs, un configurateur dans le back office pour changer couleurs, polices et mise en page sans code, des modules compagnons (méga menu, mises en page produit, carrousels), une documentation, une période de support définie et des mises à jour de compatibilité. La valeur tient moins au design qu'au temps de développement économisé : recréer ces éléments coûterait bien plus.

Qualité du code, support et mises à jour

La plus grande différence est souvent invisible : la qualité du code. Ceux qui vendent des thèmes comme activité ont intérêt à écrire un code propre et maintenable, car les mauvais avis et les tickets de support coûtent de l'argent. Les thèmes gratuits tiers n'ont pas cet intérêt, d'où une qualité inégale. Les thèmes premium achetés via une marketplace incluent une fenêtre de support et une obligation contractuelle de correction ; les gratuits, aucune, si ça casse, vous réparez, payez quelqu'un ou changez. Idem pour les mises à jour : les thèmes premium sont maintenus, beaucoup de gratuits sont abandonnés après leur sortie.

Sécurité et thèmes nulled

Un thème contrôle le HTML, le CSS et le JavaScript envoyés à vos clients : un thème malveillant peut injecter du code de minage, voler des données de formulaire ou ouvrir des portes dérobées. Les marketplaces sérieuses examinent les soumissions, pas les sites de téléchargement au hasard. Les thèmes nulled, thèmes premium piratés, sont le pire cas : la vérification de licence est retirée et d'autres modifications, cachées et obfusquées, sont souvent ajoutées (portes dérobées, collecte de données, spam SEO, cryptominage, redirections). Aucune raison légitime de les utiliser ; si le budget est serré, prenez le thème par défaut officiel.

Performances, personnalisation et où acheter

Le thème par défaut officiel est optimisé et prend en charge la combinaison d'assets CCC de PrestaShop. Les meilleurs thèmes premium font jeu égal en ajoutant des fonctions via le chargement différé et conditionnel ; les pires chargent tout partout. Les thèmes gratuits tiers ont souvent de faibles performances. Testez la démo d'un thème avec un outil comme Google PageSpeed Insights avant de vous engager. Côté personnalisation, le thème officiel se limite au logo et au favicon, les thèmes premium incluent en général un configurateur graphique. L'endroit d'achat compte aussi : la marketplace officielle PrestaShop Addons offre la meilleure protection acheteur et une vérification spécifique à PrestaShop, les marketplaces généralistes plus de choix avec un contrôle plus léger, les vendeurs indépendants allant d'excellents spécialistes à des inconnus à risque.

En résumé

La qualité de la documentation est un bon indicateur de la qualité globale, qui documente soigneusement code souvent avec soin. En cas de doute, commencez par le thème par défaut officiel : gratuit, maintenu, sécurisé et largement compatible. Optez pour un thème premium quand vous voulez une boutique soignée rapidement, avec modules et support. Évitez les thèmes gratuits tiers sauf pour des boutiques de test jetables, et n'utilisez jamais un thème nulled. Quel que soit votre choix : travaillez dans un thème enfant, documentez vos changements, testez les mises à jour en staging et conservez des sauvegardes. Pour aller plus loin, lisez comment choisir le bon thème PrestaShop pour votre activité.

Pourquoi la surcharge de modules est le tueur silencieux des performances PrestaShop

Chaque boutique PrestaShop démarre rapidement. Puis vous installez cinq modules, dix modules, trente modules, et soudain votre page d'accueil met quatre secondes à se charger. Le coupable est rarement un seul module massif. Ce sont plutôt des dizaines de petits modules qui ajoutent chacun leur propre fichier CSS, leur propre fichier JavaScript et leurs propres requêtes de base de données à chaque chargement de page. Ce poids cumulé est ce que nous appelons la surcharge de modules, et c'est la raison numéro un pour laquelle les boutiques PrestaShop deviennent lentes avec le temps.

Le problème est que la plupart des propriétaires de boutiques n'auditent jamais ce que leurs modules chargent réellement. Ils installent un module pour les étiquettes de produits, un autre pour les boutons de partage social, un autre pour un popup de newsletter, un autre pour les statistiques, et chacun s'enregistre silencieusement sur des hooks comme displayHeader et actionFrontControllerSetMedia. Même si un module n'affiche du contenu que sur les pages produits, il peut quand même charger ses fichiers CSS et JavaScript sur la page d'accueil, les pages catégories, la page panier et le tunnel de commande. Cela signifie que vos clients téléchargent des ressources qu'ils n'utiliseront jamais sur cette page particulière.

Un audit de modules approprié révèle exactement ce que chaque module contribue au poids de votre page. Il vous indique quels modules sont les plus gros contrevenants, lesquels chargent des ressources inutilement et lesquels vous pouvez optimiser ou supprimer entièrement. Cet article vous guide à travers le processus complet d'audit de vos modules PrestaShop pour la performance, en utilisant les DevTools du navigateur, le mode debug de PrestaShop et une analyse systématique.

Étape 1 : Activer le mode debug et le profilage des performances de PrestaShop

Avant d'ouvrir les outils de votre navigateur, vous devez activer les capacités de profilage intégrées de PrestaShop. PrestaShop dispose d'un mode debug qui révèle des informations détaillées sur l'exécution des hooks, les temps de chargement des modules et les requêtes de base de données. Pour l'activer, vous devez modifier deux paramètres.

Tout d'abord, allez dans Paramètres avancés, puis Performance dans votre back office. Réglez le Mode debug sur Oui. Cela active le reporting d'erreurs et la journalisation supplémentaire qui aide à identifier les modules problématiques. Cependant, la véritable puissance vient de la fonctionnalité de profilage.

Pour activer le profilage complet, vous devez modifier le fichier defines.inc.php situé dans le répertoire config de votre PrestaShop. Trouvez la ligne qui définit _PS_DEBUG_PROFILING_ et réglez-la sur true. Sur les versions actuelles de PrestaShop, cette constante contrôle l'affichage de la barre de profilage en bas de chaque page du front office. Une fois activée, rechargez n'importe quelle page de votre boutique et vous verrez un panneau de profilage détaillé montrant les temps d'exécution de chaque hook, chaque module et chaque requête SQL.

Le panneau de profilage est divisé en plusieurs sections. La section des hooks vous montre chaque hook exécuté sur la page courante, quels modules sont attachés à chaque hook et combien de temps chaque module a mis à s'exécuter. La section SQL montre chaque requête de base de données, son temps d'exécution et quel module ou fonction du coeur l'a déclenchée. La section des modules vous donne un résumé du temps d'exécution total par module sur tous les hooks.

Portez une attention particulière à la colonne du temps d'exécution total. Un module bien optimisé devrait contribuer à moins de 10 millisecondes au chargement d'une page. Si vous voyez un module prendre 50, 100, voire 500 millisecondes, c'est un problème de performance sérieux qui nécessite une investigation.

Étape 2 : Utiliser les DevTools du navigateur pour cartographier les ressources des modules

Le profilage intégré de PrestaShop vous renseigne sur les performances côté serveur, mais il ne vous montre pas l'image complète de ce qui se passe dans le navigateur. Pour cela, vous avez besoin des outils de développement de votre navigateur. Ouvrez Chrome ou Firefox, appuyez sur F12 et accédez à l'onglet Réseau (Network).

Rechargez votre page d'accueil avec l'onglet Réseau ouvert. Vous verrez chaque requête effectuée par le navigateur : HTML, fichiers CSS, fichiers JavaScript, images, polices et appels AJAX. L'objectif est d'identifier lesquelles de ces requêtes proviennent de modules.

Dans PrestaShop, les ressources des modules suivent un schéma d'URL prévisible. Les fichiers CSS des modules sont généralement servis depuis des chemins comme /modules/nomdumodule/views/css/nomdefichier.css ou /modules/nomdumodule/css/nomdefichier.css. Les fichiers JavaScript suivent le même schéma avec js au lieu de css. Utilisez la barre de filtre dans l'onglet Réseau pour filtrer par « modules/ » et vous verrez instantanément chaque ressource chargée depuis vos modules installés.

Pour chaque ressource de module que vous trouvez, notez les informations suivantes : le nom du fichier, sa taille (à la fois transférée et non compressée), et s'il se charge sur le type de page actuel. Vous voulez construire un tableur ou une simple liste qui associe chaque module à ses ressources. Un audit typique pourrait révéler quelque chose comme ceci : le module A charge deux fichiers CSS totalisant 45 Ko et un fichier JavaScript de 120 Ko sur chaque page, mais il n'affiche du contenu que sur les pages produits. Cela signifie que les pages catégories, la page d'accueil et le panier chargent tous 165 Ko de ressources inutiles.

L'onglet Réseau vous montre également la vue en cascade (waterfall), qui révèle quand chaque ressource commence à se charger et combien de temps cela prend. Les ressources qui bloquent le rendu (CSS bloquant le rendu et JavaScript synchrone) sont particulièrement nuisibles car elles empêchent le navigateur d'afficher tout contenu jusqu'à ce qu'elles aient fini de se charger. Recherchez les fichiers JavaScript de modules qui se chargent dans le head sans attributs async ou defer, car ce sont les pires contrevenants en termes de temps de chargement perçu.

Étape 3 : Analyser la cascade réseau par module

La vue en cascade dans les DevTools mérite sa propre section car elle révèle des problèmes de performance que les tailles brutes de fichiers ne montrent pas. Lorsque vous examinez la cascade, vous voulez identifier trois types de problèmes.

Premièrement, recherchez les ressources bloquant le rendu provenant de modules. Elles apparaissent comme des barres qui démarrent tôt dans la cascade et retardent l'événement de premier affichage (la ligne verticale verte ou bleue). Dans PrestaShop, les fichiers CSS ajoutés via le hook displayHeader ou via addCSS dans setMedia bloquent généralement le rendu. Si un module ajoute un gros fichier CSS qui n'est nécessaire que sur des pages spécifiques, il bloque le rendu sur toutes les pages sans raison.

Deuxièmement, recherchez les chaînes de chargement séquentielles. Certains modules chargent un fichier JavaScript qui déclenche ensuite le chargement de ressources supplémentaires : d'autres fichiers JavaScript, des fichiers CSS, des polices web ou des appels à des API externes. Chaque maillon de cette chaîne ajoute de la latence. Un module qui charge jQuery UI, puis un thème CSS jQuery UI, puis un widget personnalisé, puis le CSS du widget crée une chaîne de quatre requêtes séquentielles qui peuvent prendre 200 à 400 millisecondes même sur une connexion rapide.

Troisièmement, recherchez les requêtes externes. Certains modules effectuent des appels vers des serveurs externes pour des statistiques, du suivi, le chargement de polices, des widgets de réseaux sociaux ou des données d'API. Ces requêtes sont particulièrement dangereuses car vous n'avez aucun contrôle sur le temps de réponse du serveur externe. Un module de partage social qui appelle les API de Facebook, Twitter et Pinterest à chaque chargement de page peut ajouter 500 millisecondes ou plus de latence, et si l'un de ces serveurs est lent ou inaccessible, il peut bloquer le chargement complet de votre page.

Pour quantifier l'impact par module, utilisez la fonctionnalité de blocage des DevTools de Chrome. Faites un clic droit sur une requête d'un module spécifique et choisissez « Bloquer le domaine de la requête » ou « Bloquer l'URL de la requête ». Puis rechargez la page et comparez le temps de chargement. Cela vous donne une mesure directe de la contribution des ressources de ce module au temps total de chargement de votre page. Répétez l'opération pour chaque module afin de construire un classement du plus lourd au plus léger.

Étape 4 : Analyse de l'exécution des hooks

Comprendre quels hooks chaque module utilise est essentiel pour identifier les chargements inutiles. Le système de hooks de PrestaShop est le mécanisme par lequel les modules injectent leur contenu, leurs ressources et leur logique dans les pages. Les hooks les plus pertinents en termes de performance pour les pages du front office sont displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo et displayProductListFunctionalButtons.

Le hook displayHeader est le hook le plus couramment abusé dans l'écosystème PrestaShop. Les modules s'enregistrent sur ce hook pour ajouter leur CSS et JavaScript dans le head de la page. Le problème est que displayHeader se déclenche sur absolument chaque page du front office. Si un module s'enregistre sur displayHeader sans vérifier quelle page le client est en train de consulter, il charge ses ressources partout.

Pour voir quels modules sont enregistrés sur chaque hook, allez dans Apparence, puis Positions dans votre back office. Cette page montre chaque hook et chaque module qui y est attaché. Regardez spécifiquement displayHeader et actionFrontControllerSetMedia. Comptez combien de modules y sont enregistrés. Dans une boutique typique avec 30 modules ou plus installés, vous pourriez trouver 15 à 20 modules rien que sur displayHeader. Chacun ajoute au moins un fichier CSS ou JavaScript à chaque page.

Maintenant, croisez ces informations avec vos résultats DevTools. Pour chaque module sur displayHeader, vérifiez si ce module a réellement besoin de se charger sur la page courante. Un module d'avis produits n'a besoin de ses ressources que sur les pages produits. Un module de liste de souhaits n'a besoin de ses ressources que sur les pages produits et les pages de compte. Un module de guide des tailles n'a besoin de ses ressources que sur les pages produits. Pourtant, tous se chargent sur votre page d'accueil, vos pages catégories, vos pages CMS et votre tunnel de commande.

Les données de profilage de l'Étape 1 ajoutent une autre dimension à cette analyse. Certains modules ne se contentent pas de charger des ressources inutiles mais exécutent également du code PHP coûteux à chaque appel de hook. Un module qui exécute des requêtes de base de données dans sa méthode hookDisplayHeader pour vérifier des valeurs de configuration ou récupérer des données gaspille des ressources serveur sur chaque page, même lorsque sa sortie n'est pas nécessaire.

Étape 5 : Identifier les modules les plus lourds

Avec les données du profilage, des DevTools et de l'analyse des hooks, vous pouvez maintenant classer vos modules par leur impact sur les performances. Créez une liste avec les colonnes suivantes : nom du module, nombre de fichiers CSS chargés, taille totale du CSS, nombre de fichiers JavaScript chargés, taille totale du JavaScript, temps d'exécution serveur d'après le profilage, nombre de requêtes de base de données, et pages où le module affiche réellement du contenu.

Les modules qui obtiennent les scores les plus élevés sur ces métriques sont vos plus gros contrevenants. D'après notre expérience d'audit de centaines de boutiques PrestaShop, les catégories de modules suivantes sont systématiquement les moins performantes.

Les modules de construction de pages (page builders) sont souvent les plus lourds. Ils chargent de grands frameworks CSS, de multiples bibliothèques JavaScript pour leur éditeur visuel, et parfois même chargent les ressources de l'éditeur sur le front office. Un page builder qui charge 300 Ko de CSS et 500 Ko de JavaScript sur chaque page n'est pas inhabituel.

Les modules de réseaux sociaux qui intègrent des widgets de Facebook, Instagram ou Twitter chargent des ressources externes qui sont à la fois volumineuses et imprévisibles dans leur temps de chargement. Un seul widget de flux Instagram peut ajouter 1 Mo ou plus de JavaScript à votre page.

Les modules de statistiques et de suivi qui utilisent plusieurs pixels de suivi chargent des ressources depuis des domaines externes. Chaque pixel de suivi ajoute généralement 20 à 50 Ko de JavaScript plus des requêtes réseau supplémentaires pour les images de pixel et les appels API.

Les modules de carrousel et de diaporama chargent de grandes bibliothèques JavaScript comme Slick, Owl Carousel ou Swiper ainsi que leur CSS. Même si le diaporama n'apparaît que sur la page d'accueil, les ressources se chargent souvent sur chaque page.

Les modules de chat en direct chargent des bundles JavaScript conséquents pour l'interface du widget de chat, généralement 100 à 300 Ko, et ils établissent en plus des connexions WebSocket qui consomment des ressources tout au long de la session de navigation.

Étape 6 : Mesurer les performances avant et après

Avant de commencer à désactiver des hooks ou à supprimer des modules, établissez une mesure de référence. Utilisez plusieurs outils pour obtenir une image complète.

Dans les DevTools de Chrome, allez dans l'onglet Lighthouse et lancez un audit de performance. Enregistrez le Score de Performance, le First Contentful Paint (FCP), le Largest Contentful Paint (LCP), le Total Blocking Time (TBT) et le Cumulative Layout Shift (CLS). Lancez l'audit trois fois et faites la moyenne des résultats pour tenir compte de la variabilité.

Utilisez l'onglet Performance dans les DevTools pour enregistrer une trace de chargement de page. Cela vous donne un diagramme en flammes (flame chart) montrant exactement ce que le navigateur fait à chaque milliseconde. Recherchez les tâches longues (blocs de plus de 50 millisecondes) et identifiez quels modules en sont responsables.

Mesurez également le poids de votre page. Dans l'onglet Réseau, regardez le nombre total de requêtes et la taille totale transférée en bas du panneau. Filtrez par CSS et JS séparément pour obtenir les totaux spécifiques aux modules.

Enregistrez tous ces chiffres avant d'apporter des modifications. Puis, au fur et à mesure que vous optimisez les modules en les décrochant des hooks inutiles ou en les désactivant entièrement, relancez les mêmes mesures. La différence vous indique exactement combien de performance vous avez gagnée avec chaque changement.

Un audit de modules bien exécuté réduit généralement le poids des pages de 30 à 50 pour cent et améliore les temps de chargement d'une à deux secondes. Sur les boutiques avec de nombreux modules mal optimisés, l'amélioration peut être encore plus spectaculaire.

Étape 7 : Désactiver les hooks inutiles

Une fois que vous avez identifié quels modules chargent des ressources sur des pages où elles ne sont pas nécessaires, vous avez plusieurs options d'optimisation. L'approche la plus simple est de décrocher les modules des hooks où ils n'ont pas besoin d'être.

Allez dans Apparence, puis Positions dans votre back office. Trouvez le module sur le hook dont vous voulez le retirer. Cliquez sur l'icône de la poubelle ou le bouton de décrochage pour retirer le module de ce hook spécifique. Cela empêche le module de s'exécuter sur ce hook entièrement.

Cependant, soyez prudent avec cette approche. Certains modules utilisent displayHeader non seulement pour charger du CSS et du JavaScript mais aussi pour effectuer des tâches d'initialisation essentielles. Décrocher un tel module de displayHeader pourrait casser sa fonctionnalité sur les pages où il est réellement nécessaire. Testez toujours dans un environnement de staging ou au minimum testez les pages spécifiques où le module devrait encore fonctionner après le décrochage.

Une meilleure approche à long terme consiste à contacter le développeur du module et à demander un chargement conditionnel des ressources. Un module bien codé devrait vérifier le contrôleur ou le type de page actuel avant de charger ses ressources. Par exemple, un module d'avis produits ne devrait charger son CSS et son JavaScript que lorsque le contrôleur actuel est ProductController. De cette façon, le module reste accroché à displayHeader pour la compatibilité mais ne charge les ressources que lorsqu'elles sont réellement nécessaires.

Si vous êtes à l'aise avec la modification du code des modules, vous pouvez ajouter des vérifications conditionnelles vous-même. Dans la méthode hookDisplayHeader ou hookActionFrontControllerSetMedia du module, ajoutez une vérification du nom du contrôleur actuel. Si le contrôleur n'est pas l'un de ceux où le module affiche du contenu, retournez directement sans ajouter de ressources. C'est l'optimisation la plus ciblée et la plus efficace que vous puissiez faire.

Checklist pratique pour votre audit de modules

Pour résumer l'ensemble du processus d'audit, voici une checklist pratique que vous pouvez suivre. Commencez par activer le profilage debug de PrestaShop. Ouvrez l'onglet Réseau des DevTools et rechargez votre page d'accueil. Filtrez les requêtes par le chemin des modules et listez chaque ressource de module. Notez la taille et le type de chaque ressource. Vérifiez dans Apparence, puis Positions les modules sur displayHeader. Croisez les enregistrements de hooks avec les endroits où les modules affichent réellement du contenu. Utilisez le blocage de requêtes des DevTools pour mesurer l'impact par module. Enregistrez les scores Lighthouse de référence. Décrochez les modules des hooks où ils ne sont pas nécessaires. Ajoutez un chargement conditionnel aux modules qui se chargent globalement. Re-mesurez les scores Lighthouse après chaque changement. Documentez vos résultats et vos changements pour référence future.

Cette approche systématique garantit que vous ne manquez aucune opportunité de performance et vous donne des données concrètes pour justifier chaque changement que vous effectuez. La surcharge de modules n'est pas un mystère. C'est un problème mesurable et résoluble, et chaque boutique PrestaShop bénéficie d'un audit de modules approfondi au moins une fois par an.

Pour d'autres guides de performance, consultez notre blog.

Si vous avez déjà inspecté le code source de votre boutique en vous demandant pourquoi un module qui n'affiche un widget que sur les pages produit charge aussi son CSS et son JavaScript sur la page d'accueil, les pages catégories et même le tunnel de commande, vous n'êtes pas seul. C'est l'un des problèmes de performance les plus courants sous PrestaShop, et il vient du fonctionnement du système de hooks combiné à des raccourcis pris pendant le développement.

Pourquoi cela arrive

PrestaShop permet aux modules d'ajouter des ressources via des hooks comme displayHeader et actionFrontControllerSetMedia. Les deux se déclenchent sur chaque page front-office, aucun mécanisme intégré ne limite un hook à certains types de pages. C'est au module de vérifier quelle page est affichée et de décider d'ajouter ou non ses ressources. Beaucoup de modules sautent cette vérification et enregistrent leur CSS et JavaScript à chaque appel : le module fonctionne toujours, mais ses fichiers se chargent partout, qu'ils soient utiles ou non.

Le hook plus récent actionFrontControllerSetMedia (avec registerStylesheet et registerJavascript) offre un meilleur contrôle de la priorité et du placement, mais il se déclenche lui aussi sur chaque page. Seule la méthode d'enregistrement change, pas la portée du chargement. Sans test conditionnel, les ressources se chargent toujours globalement.

Ce que font les bons modules

Un module bien conçu vérifie le contrôleur courant avant de charger quoi que ce soit. Chaque page front-office est servie par un contrôleur précis, accueil, catégorie, produit ou panier. Dans le hook, le module lit $this->context->controller et n'enregistre ses ressources que lorsque la page en a besoin. Un module d'avis produit, par exemple, ne devrait charger ses ressources que sur les pages produit. Cela représente quelques lignes de code, que de nombreux modules omettent pourtant.

Comment repérer les fautifs

• Ouvrez les DevTools de Chrome sur votre page d'accueil, onglet Réseau, rechargez et filtrez par /modules/. Comptez les requêtes et leur taille cumulée. Sur une page où la plupart des modules n'affichent rien, c'est du poids inutile.
• Comparez avec une page produit, où beaucoup de modules ont légitimement besoin de leurs ressources. Sur une boutique bien tenue, la page produit charge plus de ressources de modules que l'accueil ; si les chiffres sont quasi identiques, les modules chargent tout partout.
• Activez le profilage de débogage de PrestaShop pour voir quels modules s'exécutent sur chaque hook. Tout module qui s'exécute sur displayHeader ou actionFrontControllerSetMedia sans rien afficher sur la page courante est un candidat.
• Triez les ressources par taille et commencez par les plus gros fichiers, un gros fichier JavaScript global pèse bien plus qu'un petit fichier CSS.

Comment y remédier

Demandez d'abord au développeur. La plupart des développeurs professionnels ajoutent le chargement conditionnel quand vous fournissez des données précises : quelle méthode charge les ressources, quelles pages en ont réellement besoin, et la taille et l'impact mesurés. Si le module vous appartient, ajoutez vous-même la vérification du contrôleur. Si vous ne pouvez pas le modifier (code chiffré, ou vous ne voulez pas maintenir un fork), un petit module sur mesure peut désenregistrer les ressources globales et ne les réajouter que sur les pages utiles, ou la configuration de votre thème peut retirer certaines ressources de modules. Re-testez ensuite chaque page où le module doit encore fonctionner. Retirer son CSS peut casser l'affichage et retirer son JavaScript peut casser les interactions.

La meilleure prévention est d'évaluer un module avant de l'installer : inspectez sa démo avec les DevTools, lisez les méthodes de hook si le code est disponible et parcourez les avis à la recherche de plaintes sur les performances. Pour un guide détaillé, voir notre guide de performance PrestaShop.

Quelques bons réglages suffisent pour que Cloudflare donne à votre boutique PrestaShop un CDN plus rapide, un filtrage DDoS et un WAF devant votre origine. Mal configuré, il provoque des boucles de redirection, checkouts cassés et commandes fantômes, voici donc la checklist courte et sûre.

• SSL/TLS mode: Full (Strict). N’utilisez jamais Flexible, il envoie du HTTP à votre origine et cause des boucles infinies de redirection HTTPS dans PrestaShop. Installez un Cloudflare Origin Certificate si vous n’en avez pas.
• Désactivez Rocket Loader. Il diffère et réordonne le JavaScript inline de PrestaShop, ce qui casse ajout panier, formulaires de paiement et back-office.
• Ne mettez jamais en cache les pages dynamiques. Bypassez le cache pour panier, checkout, compte client et dossier admin ; ne mettez en cache que les assets statiques. "Cache Everything" sans règles de bypass peut servir le panier d’un client à un autre.
• Restaurez les vraies IP visiteurs avec mod_remoteip (Apache) ou ngx_http_realip_module (Nginx), en lisant CF-Connecting-IP, sinon chaque commande logue une IP Cloudflare.
• Gardez les DNS mail non proxifiés (grey cloud) et ne laissez pas Bot Fight Mode bloquer les webhooks de paiement.

Cloudflare gère l’edge ; votre origine doit encore être rapide. Pour le cache côté serveur et l’optimisation des assets dans PrestaShop, voir Performance Revolution.

Si vous utilisez le cache de pages CDN de Performance Revolution avec Cloudflare, traitez-le comme un cache HTML contrôlé, pas comme une règle globale "cache everything". Il est désactivé par défaut et marque seulement les pages HTML anonymes front-office GET/HEAD comme éligibles. Les clients connectés, paniers avec produits, cookies de session, AJAX, requêtes admin/API, query strings dynamiques et signaux explicites de bypass reçoivent des en-têtes bypass/no-store.

Le HTML anonyme éligible reçoit des en-têtes orientés CDN comme Cloudflare-CDN-Cache-Control avec max-age plus des valeurs stale-while-revalidate et stale-if-error. Les TTL CDN par défaut du module sont 2592000 secondes pour max age, 86400 secondes pour stale-while-revalidate et 604800 secondes pour stale-if-error, mais ils ne comptent qu’après activation de la fonctionnalité cache CDN et déploiement des règles courantes.

curl -I https://example.com/category-page
Check: X-MPR-Cache: eligible or bypass
Check: Cloudflare-CDN-Cache-Control
Check: no Set-Cookie on eligible anonymous HTML

Pour la purge, le module peut envoyer des requêtes de purge Cloudflare lorsque le zone ID et l’API token sont configurés. Cloudflare Business/Enterprise peut purger par tags ; sur les plans inférieurs, le module se rabat sur la résolution des URL affectées et leur purge par lots.

WebP est un format d'image moderne qui compresse les photos produit en fichiers nettement plus légers que le JPEG ou le PNG, à qualité visuelle proche, vos pages téléchargent moins et s'affichent plus vite, surtout sur les catalogues riches en images.

L'activer dans PrestaShop :

• Allez dans Design → Paramètres des images (Préférences → Images sur les versions plus anciennes) et trouvez les options de génération d'images.
• Choisissez JPEG/PNG + WebP pour la sécurité du repli, ou WebP seul si vous connaissez bien votre audience.
• Réglez la qualité WebP autour de 80–85, enregistrez, puis régénérez les miniatures.

Sur les gros catalogues, la régénération dans le navigateur peut expirer, lancez-la plutôt en CLI, sans le timeout du serveur web.

Pièges courants :

• Pas de WebP dans PHP : GD ou ImageMagick doivent être compilés avec WebP. Vérifiez avec gd_info() ; sinon, demandez à votre hébergeur.
• Le serveur ne sert pas le WebP : PrestaShop écrit le WebP à côté du JPEG/PNG, mais le serveur doit négocier via l'en-tête Accept. Assurez-vous que image/webp est un type MIME connu.
• Caches obsolètes : purgez navigateur, Smarty, OPcache, CDN et cache pleine page après le changement.
• Conflits de modules : les sliders ou modules de zoom qui codent en dur .jpg peuvent afficher des miniatures cassées ; testez-les.

Si vous préférez ne pas configurer la régénération et la négociation .htaccess à la main, Performance Revolution génère le WebP (et l'AVIF) et sert le bon format automatiquement selon l'en-tête Accept. Pour aller plus loin, voir notre guide d'optimisation des images PrestaShop.

Le CSS critique est la petite partie des styles dont le navigateur a besoin pour afficher ce que le visiteur voit en premier, la zone au-dessus de la ligne de flottaison. Par défaut, une boutique PrestaShop charge l'ensemble des feuilles de style du thème et des modules avant d'afficher quoi que ce soit, d'où la page blanche sur les connexions lentes. En intégrant le CSS critique et en différant le reste, la page apparaît immédiatement pendant que les autres styles se chargent en arrière-plan.

Pourquoi le CSS bloquant le rendu ralentit le premier affichage

Chaque <link rel="stylesheet"> dans le <head> bloque le rendu jusqu'à son téléchargement et son analyse. Une boutique typique combine une feuille de thème, plusieurs feuilles de modules et parfois un framework CSS, vite plusieurs centaines de kilo-octets. Le navigateur ne peut peindre aucun pixel avant que tout soit arrivé, ce qui dégrade directement le First Contentful Paint et le Largest Contentful Paint des Core Web Vitals.

Comment différer le CSS dans PrestaShop

• Extraire le CSS critique pour chaque grand type de page (accueil, catégorie, produit), les règles de la zone visible.
• L'intégrer dans le <head> pour que le premier affichage n'ait besoin d'aucune requête supplémentaire.
• Différer la feuille complète en la chargeant de façon asynchrone (par exemple preload + onload), afin qu'elle ne bloque plus le rendu.
• Auditer vos modules, un module qui charge son CSS sur toutes les pages au lieu des seules pages utiles est une source fréquente de poids bloquant inutile.

Le faire à la main est laborieux et se casse à chaque mise à jour du thème. Performance Revolution génère et sert le CSS critique par type de page et diffère les ressources non critiques à votre place. Pour le contexte global, voir notre guide de performance PrestaShop.

Changer l'URL d'administration de PrestaShop revient à renommer le dossier admin sur votre serveur et à mettre à jour une valeur de configuration pour qu'elle corresponde. Le dossier admin est un vrai répertoire à la racine de PrestaShop (nommé par exemple admin1234), et PrestaShop enregistre ce nom dans son fichier de configuration. Si les deux concordent, votre back-office répond à la nouvelle URL ; s'ils divergent, vous vous bloquez l'accès, faites donc les deux ensemble.

La méthode sûre

1. Connectez-vous en FTP ou SSH et ouvrez la racine PrestaShop (le dossier avec classes/, modules/ et themes/).
2. Renommez le dossier admin avec un nom difficile à deviner mais mémorisable pour vous, par ex. store-mgmt-7x9. Évitez les noms évidents comme admin, administrator ou backend : ce sont les premiers testés par les scanners.
3. Mettez à jour la configuration pour que le nom de répertoire admin enregistré corresponde exactement au nouveau dossier. C'est l'étape qu'on oublie. Un décalage donne une page blanche ou une erreur 500.
4. Videz le cache (videz les dossiers var/cache/) pour effacer les références à l'ancien nom.
5. Testez la nouvelle URL dans votre navigateur ; vous devez arriver sur la page de connexion.

Deux points de vigilance : faites un vrai renommage, pas un lien symbolique vers l'ancien dossier (l'ancien nom resterait actif et annulerait l'intérêt), et ne renommez pas pendant que des collègues sont connectés, leurs sessions tombent aussitôt. Ensuite, mettez à jour favoris et gestionnaires de mots de passe, et vérifiez vos règles .htaccess personnalisées ou les modules qui ont codé en dur l'ancien chemin.

Le renommage complique les tentatives de connexion automatisées, mais ce n'est qu'une couche. Associez-le à un mot de passe fort et aux étapes de notre guide de sécurité PrestaShop. Si vous voulez seulement retrouver l'URL (sans la changer), voyez comment trouver l'URL de votre panneau d'administration.

PrestaShop fait passer son moteur de templates de Smarty à Twig, le moteur utilisé dans l'écosystème Symfony. Le back office a largement opéré la bascule ; le front office (thèmes) reste sous Smarty. Voici ce que cela implique pour vous.

La syntaxe, côte à côte

• Fichiers : Smarty .tpl → Twig .html.twig
• Affichage : {$product.name} → {{ product.name }}
• Filtres : {$var|default:'N/A'} → {{ var|default('N/A') }}
• Conditions/boucles : {if}…{/if}, {foreach}…{/foreach} → {% if %}…{% endif %}, {% for %}…{% endfor %}
• Héritage : {extends file='parent.tpl'} → {% extends 'parent.html.twig' %}

Où en est la migration

La transition a commencé avec les pages d'administration basées sur Symfony et a progressé version après version jusqu'à un back office essentiellement en Twig. Smarty reste dans le code parce que les thèmes front office, de nombreux modules tiers et les pages admin de modules construites sur d'anciens AdminControllers en dépendent encore.

Ce que cela implique pour vous

• Propriétaires de boutique : rien ne casse immédiatement. Avant une mise à niveau majeure, vérifiez la compatibilité de vos modules et de votre thème et testez d'abord en préproduction.
• Développeurs de modules : les templates .tpl front office fonctionnent toujours ; pour de nouvelles pages admin sur les versions actuelles, rendez du Twig depuis un contrôleur Symfony et détectez la version à l'exécution si vous supportez les deux.
• Développeurs de thèmes : Twig échappe automatiquement les sorties (meilleure sécurité XSS) et s'intègre nativement aux formulaires, au routage et aux traductions Symfony. Gardez vos templates simples dès maintenant.

Vous préparez le passage à la dernière version majeure ? Voir notre guide de migration PrestaShop.

Pourquoi la migration de serveur nécessite une planification

Déplacer une boutique PrestaShop vers un nouveau serveur est l'une des opérations les plus critiques que vous puissiez effectuer. Avec une bonne planification, vous pouvez réduire le temps d'arrêt à quelques minutes, voire atteindre une transition transparente sans temps d'arrêt visible.

Checklist pré-migration

• Vérifier les exigences du nouveau serveur
• Documenter la configuration actuelle
• Lister tous les domaines et sous-domaines
• Identifier les fichiers personnalisés
• Prévoir le certificat SSL

Phase 1 - Préparer le nouveau serveur

sudo apt update
sudo apt install apache2 mysql-server php8.1 php8.1-mysql \
  php8.1-gd php8.1-curl php8.1-intl php8.1-mbstring \
  php8.1-zip php8.1-xml php8.1-bcmath
sudo a2enmod rewrite ssl headers expires

Configurer PHP

memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Créer la base de données

CREATE DATABASE prestashop CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'ps_user'@'localhost' IDENTIFIED BY 'mot_de_passe_fort';
GRANT ALL PRIVILEGES ON prestashop.* TO 'ps_user'@'localhost';

Phase 2 - Transférer les fichiers

rsync -avz --progress -e ssh \
  /var/www/html/prestashop/ \
  user@nouveau-serveur:/var/www/html/prestashop/

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

Phase 3 - Transférer la base de données

mysqldump -u root -p --single-transaction --routines --triggers \
  prestashop > /tmp/prestashop_db.sql

scp /tmp/prestashop_db.sql user@nouveau-serveur:/tmp/
mysql -u ps_user -p prestashop < /tmp/prestashop_db.sql

Phase 4 - Mettre à jour la configuration

Éditez app/config/parameters.php avec les nouvelles informations de base de données. Ne changez PAS les URLs de la boutique.

Phase 5 - Tester sur le nouveau serveur

Modifiez votre fichier hosts local pour pointer vers le nouveau serveur et testez tout le site en profondeur.

Phase 6 - Le basculement

1. Baisser le TTL DNS 48h à l'avance
2. Mettre l'ancienne boutique en mode maintenance
3. Synchronisation finale de la base de données
4. Synchronisation finale des fichiers
5. Changer les enregistrements DNS
6. Sortir la nouvelle boutique du mode maintenance

Phase 7 - Vérification post-migration

• Vider tous les caches
• Régénérer le .htaccess
• Vérifier le SSL
• Tester l'envoi d'emails
• Vérifier les tâches cron
• Garder les deux serveurs actifs pendant 48-72 heures

Pièges courants de migration

• Chemins codés en dur dans les fichiers de modules
• Configuration email
• URLs des images
• Contenu mixte après SSL

Avant de commencer, vérifiez que le nouveau serveur est à la hauteur, voir choisir un hébergement pour PrestaShop, et faites d'abord une sauvegarde complète des fichiers et de la base de données.

PrestaShop stocke tout, produits, commandes, clients, réglages, dans une base MySQL, dont les tables utilisent un préfixe (par défaut ps_, défini à l'installation). Connaître les tables clés permet de diagnostiquer plus vite, d'exécuter des opérations en masse impossibles depuis l'admin, et de réagir quand le back office tombe. Voici l'essentiel.

SELECT p.id_product, pl.name, ps.active, ps.price, sa.quantity
FROM ps_product p
JOIN ps_product_lang pl ON pl.id_product = p.id_product AND pl.id_lang = 1
JOIN ps_product_shop ps ON ps.id_product = p.id_product AND ps.id_shop = 1
LEFT JOIN ps_stock_available sa ON sa.id_product = p.id_product AND sa.id_product_attribute = 0
ORDER BY p.id_product DESC
LIMIT 20;

SELECT id_order, reference, id_customer, total_paid, current_state, date_add
FROM ps_orders
ORDER BY id_order DESC
LIMIT 20;

Produits

• ps_product, une ligne par produit : id_product, price (HT), reference, active, dates.
• ps_product_lang, nom, description, méta et link_rewrite (slug d'URL) par langue, une ligne par produit, langue et boutique.
• ps_product_shop, prix, statut et visibilité par boutique (reflète ps_product en mono-boutique).
• ps_stock_available, la vraie source de stock (pas ps_product.quantity, obsolète).
• ps_product_attribute, déclinaisons ; ps_specific_price, remises et prix spécifiques.

Catégories

ps_category (arbre en nested set : nleft, nright, level_depth), ps_category_lang (noms, méta) et ps_category_product (quels produits dans quelle catégorie, avec position).

Commandes & clients

• ps_orders, une ligne par commande : reference, id_customer, current_state, total_paid_tax_incl, date_add.
• ps_order_detail, lignes de commande ; ps_order_history, chaque changement de statut horodaté ; ps_order_state(_lang), définitions des statuts.
• ps_customer (e-mail, passwd haché, groupe), ps_address, ps_cart / ps_cart_product (paniers qui ne deviendront pas forcément des commandes).

Configuration & structure

ps_configuration est le stockage clé-valeur de chaque réglage du back office ; ps_hook_module indique quels modules s'exécutent sur quel hook et dans quel ordre ; ps_shop_url associe les domaines aux boutiques, à ne jamais modifier à la main.

Optimiser la base

Les opérations en masse sont plus rapides en SQL, mais sauvegardez toujours d'abord, testez avec SELECT avant tout UPDATE/DELETE, et ne supprimez pas les tables de modules (désinstallez le module). Avec le temps, paniers abandonnés, anciens invités, connexions et logs gonflent ces tables ; les élaguer garde les requêtes rapides. Pour le nettoyage automatique et le cache, voyez Performance Revolution et notre guide d'optimisation de la base.

Les hooks sont les points d'extension de PrestaShop, des emplacements nommés dans le code où les modules s'attachent pour ajouter du contenu ou exécuter de la logique sans toucher au cœur. Pour une liste des hooks PrestaShop, le back-office vous la donne en direct : Apparence → Positions affiche chaque hook avec un module attaché, les modules dessus et leur ordre.

Deux types de hooks

• Hooks d'affichage (préfixe display) injectent du HTML, ex. displayHeader, displayHome, displayFooter, displayProductAdditionalInfo.
• Hooks d'action (préfixe action) exécutent de la logique sans HTML, ex. actionCartSave, actionValidateOrder, actionOrderStatusUpdate, actionProductAdd.

Comment l'ordre est décidé

PrestaShop consulte la table ps_hook_module pour tous les modules enregistrés sur un hook et les exécute par position, la plus basse d'abord.

SELECT hm.position, m.name AS module_name, h.name AS hook_name
FROM ps_hook_module hm
JOIN ps_module m ON hm.id_module = m.id_module
JOIN ps_hook h ON hm.id_hook = h.id_hook
WHERE h.name = 'displayHeader'
ORDER BY hm.position ASC;

Pour les hooks d'affichage, la position contrôle l'ordre visuel ; pour les hooks d'action, l'ordre de traitement, crucial quand des modules touchent les mêmes données. Les nouveaux modules sont ajoutés à la fin ; réordonnez-les dans Apparence → Positions.

Enregistrer des hooks dans un module

public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('actionCartSave');
}

public function hookDisplayHeader($params)
{
    $this->context->controller->addCSS($this->_path . 'views/css/style.css');
}

Problèmes courants

• Deux modules sur un même hook d'affichage produisant un contenu dupliqué, réordonnez ou détachez le mauvais.
• Ordre de chargement CSS/JS. Un reset doit avoir une position inférieure aux styles qui en dépendent.
• Performances, chaque module sur displayHeader s'exécute à chaque page ; détachez l'inutile.

SELECT h.name, COUNT(*) AS module_count
FROM ps_hook_module hm
JOIN ps_hook h ON hm.id_hook = h.id_hook
GROUP BY h.name
ORDER BY module_count DESC
LIMIT 20;

En cas de souci, activez le mode debug, vérifiez les modules et leur ordre sur le hook, et testez si réordonner ou transplanter règle le problème avant de modifier du code.

Voir notre guide des hooks PrestaShop.

Selon le RGPD, un client de l'EEE peut demander une copie de ses données personnelles (droit d'accès) ou leur suppression (droit à l'oubli), et vous avez un mois civil pour répondre. Un module RGPD PrestaShop gère l'essentiel ; le reste relève du processus.

Où se trouvent les données

Les données personnelles sont réparties dans la base : ps_customer (nom, e-mail, date de naissance, IP à l'inscription), ps_address (adresses, téléphones), ps_orders et ps_order_detail (historique d'achats), ps_message, ps_connections et ps_guest. Les modules tiers en ajoutent, newsletters, avis, listes d'envies, fidélité. Tenez un court inventaire de chaque emplacement pour qu'un export soit réellement complet.

Le module RGPD officiel de PrestaShop

Le module RGPD officiel de PrestaShop (psgdpr), disponible dans les versions actuelles de PrestaShop, ajoute des cases de consentement horodatées, un export de données côté client et une fonction d'effacement. Les modules compatibles RGPD peuvent déclarer leurs données pour qu'elles soient incluses automatiquement ; ceux qui ne gèrent pas ce hook se traitent à la main.

Traiter accès et effacement

Vérifiez d'abord l'identité (un compte connecté suffit souvent ; sinon, faites confirmer des détails que seul le client connaît, sans exiger de documents excessifs). Pour l'accès, exportez depuis le module et ajoutez le contexte exigé par l'article 15 : finalités, tiers destinataires et durées de conservation, souvent un lien vers votre politique de confidentialité.

Pour l'effacement, anonymisez plutôt que supprimer entièrement. Le module remplace noms, e-mails et adresses par des marqueurs tout en conservant les montants de facturation (produits, prix, taxes) que la loi fiscale impose de garder, souvent 6 à 10 ans selon le pays. N'oubliez pas vos sous-traitants (paiement, livraison, e-mailing) : demandez-leur aussi la suppression et journalisez chaque étape. Traitez les demandes d'effacement en self-service comme des demandes à examiner, non comme des suppressions immédiates, en cas de commandes en cours.

Pour la vue d'ensemble, voir RGPD et conformité des cookies pour PrestaShop et notre politique de confidentialité.

Réponse courte : pour la plupart des boutiques, n'importe quel serveur web PrestaShop convient, mais Nginx consomme généralement moins de ressources sous charge, tandis qu'Apache est plus simple si vous dépendez du .htaccess.

La vraie différence est architecturale. Apache attribue un processus ou un thread à chaque requête ; Nginx utilise une boucle d'événements, si bien que quelques processus gèrent des milliers de connexions à coût mémoire quasi constant. Cet écart compte peu à faible trafic mais grandit avec la concurrence, d'où le choix de Nginx pour les boutiques chargées et les catalogues riches en images.

Trois points pratiques tranchent pour la plupart des marchands :

• .htaccess : PrestaShop écrit ses règles d'URL propres dans .htaccess, qu'Apache lit automatiquement. Nginx n'a pas de .htaccess, vous traduisez ces règles une fois, à la main, dans la config serveur.
• PHP-FPM : exécutez PHP via PHP-FPM sur les deux serveurs. Cela sort le moteur PHP des processus qui servent images et CSS, et économise de la mémoire.
• Fichiers statiques : Nginx sert les nombreuses requêtes statiques par page à très faible coût. C'est là qu'il prend l'avantage sur une vraie boutique.

Une voie médiane courante : Nginx devant Apache. Nginx gère les connexions et les fichiers statiques, Apache conserve le support .htaccess. Nginx consomme généralement moins de ressources sous forte concurrence et charge de fichiers statiques ; Apache est plus simple lorsque la compatibilité .htaccess compte. Pour aller plus loin, lisez notre guide d'optimisation des performances PrestaShop.

Comment la recherche PrestaShop fonctionne en interne

PrestaShop inclut un moteur de recherche de produits intégré qui fonctionne sur un index en texte intégral stocké directement dans la base de données MySQL. Contrairement aux services de recherche externes, cet index se trouve aux côtés de vos données produits dans la même base de données, ce qui signifie que les requêtes sont rapides mais nécessitent une maintenance explicite pour rester à jour. Comprendre le fonctionnement de ce système de recherche est la première étape pour diagnostiquer et corriger les problèmes de recherche.

Lorsqu'un client tape une requête dans la barre de recherche de votre boutique, PrestaShop ne parcourt pas chaque nom et description de produit en temps réel. Au lieu de cela, il recherche les termes de la requête dans un index préconstruit qui associe des mots individuels aux produits. Cet index est construit en décomposant les champs textuels des produits en mots individuels (tokenisation), en les normalisant (mise en minuscules, suppression des accents), et en stockant la relation entre chaque mot et les produits dans lesquels il apparaît, accompagnée d'un poids de pertinence.

Cette approche est fondamentalement la même que celle des moteurs de recherche comme Google, simplement à une échelle beaucoup plus petite. Le compromis est que l'index doit être reconstruit chaque fois que les données produits changent d'une manière que l'indexation automatique ne capture pas, ce qui est la cause principale de la plupart des problèmes de recherche dans PrestaShop.

Les tables de base de données de recherche

L'index de recherche de PrestaShop est réparti sur plusieurs tables de base de données, chacune remplissant un rôle spécifique dans le pipeline de recherche.

SET @id_product = 123;

SELECT COUNT(*) AS indexed_words
FROM ps_search_index
WHERE id_product = @id_product;

SELECT sw.id_word, sw.word, si.weight
FROM ps_search_index si
JOIN ps_search_word sw ON sw.id_word = si.id_word
WHERE si.id_product = @id_product
ORDER BY si.weight DESC
LIMIT 50;

Réindexation depuis le Back Office et l’URL cron

Les contrôles de reconstruction pris en charge se trouvent dans le Back Office, sous Paramètres de la boutique > Recherche, dans la section d’indexation.

Utilisez Ajouter les produits manquants à l’index pour un traitement incrémental, ou Reconstruire l’index complet lorsque les données déjà indexées peuvent être obsolètes après des imports, des modifications directes de la base de données, des changements de langue ou des modifications des pondérations de recherche.

Pour l’automatisation, utilisez l’URL cron de l’indexeur affichée sur cette même page du Back Office. Elle pointe vers le contrôleur cron de recherche de PrestaShop, par exemple index.php?controller=searchcron&...&token=...&full=1. Le jeton et l’URL complète sont générés par la boutique ; copiez-les donc depuis Paramètres de la boutique > Recherche au lieu de créer l’URL manuellement.

L’URL cron de l’indexeur convient aux très gros catalogues (dizaines de milliers de produits sur plusieurs langues), car elle peut être appelée en HTTP GET planifié et évite les timeouts du navigateur.

Si vous exécutez PrestaShop dans Docker, appelez l’URL cron de l’indexeur depuis un environnement qui peut joindre la boutique en HTTP. Utilisez l’URL complète générée par le Back Office, avec son jeton.

Automatisation de la réindexation

Si votre boutique repose sur des imports automatisés de produits ou une synchronisation de données externe, programmez des réindexations périodiques en tant que tâche cron. Une réindexation nocturne garantit que tous les produits ajoutés ou modifiés par des processus automatisés sont recherchables le lendemain. L'entrée cron doit appeler l’URL cron de l’indexeur en HTTP GET selon un planning.

Sachez que la réindexation verrouille brièvement les tables de recherche pendant la reconstruction. Sur une boutique active, programmez la réindexation pendant les heures de faible trafic pour éviter d'impacter la disponibilité de la recherche pour les clients actifs.

Configuration des poids : contrôler la pertinence de la recherche

PrestaShop vous permet de configurer l'importance que différents champs produits ont dans les résultats de recherche. C'est l'une des fonctionnalités les plus sous-utilisées du système de recherche intégré.

Champs de poids disponibles

La configuration des poids se trouve dans Paramètres de la boutique > Recherche. Vous pouvez attribuer un poids (généralement de 1 à 10, bien que des valeurs plus élevées fonctionnent) à chacun de ces champs produits :

Nom du produit : Celui-ci devrait typiquement avoir le poids le plus élevé. Lorsqu'un client recherche un produit par son nom, le produit portant exactement ce nom devrait apparaître en premier.

Référence : Les codes de référence produit sont souvent utilisés par les clients B2B qui connaissent le SKU exact dont ils ont besoin. Un poids modéré garantit que les recherches basées sur la référence fonctionnent bien sans surpasser les recherches basées sur le nom.

Description courte : La description courte contient souvent les principaux arguments de vente et les caractéristiques du produit. Un poids modéré est approprié.

Description : La description complète contient le plus de texte et donc le plus grand nombre de correspondances de mots-clés potentielles. Cependant, comme elle contient tant de texte, un poids élevé peut causer des correspondances non pertinentes où un terme de recherche apparaît incidemment dans une longue description. Un poids inférieur par rapport au nom du produit est recommandé.

Catégorie : L'inclusion des noms de catégories dans la recherche permet aux clients de trouver des produits par termes de catégorie même lorsque ces termes n'apparaissent pas dans le texte propre du produit.

Marque (fabricant) : Les clients recherchent souvent par nom de marque. Un poids modéré à élevé garantit que les recherches de marques retournent des résultats pertinents.

Tags : Les tags sont des termes de recherche explicitement attribués aux produits. Un poids élevé pour les tags vous donne un contrôle direct sur les produits qui apparaissent pour des requêtes de recherche spécifiques.

Attributs : Les valeurs d'attributs produits (taille, couleur, matériau) peuvent être incluses dans l'index de recherche. Cela permet des recherches comme "rouge XL" pour retourner des produits avec ces combinaisons d'attributs.

Caractéristiques : Les valeurs de caractéristiques produits (poids, dimensions, type de matériau) peuvent également être indexées.

Stratégie de pondération

Une configuration de départ raisonnable pourrait être : nom du produit à 6, référence à 4, description courte à 3, description à 1, catégorie à 2, fabricant à 3, tags à 4, attributs à 2, caractéristiques à 2. Mais les poids optimaux dépendent entièrement de votre catalogue et du comportement de recherche de vos clients.

Si vos clients recherchent fréquemment par SKU ou numéro de référence, augmentez le poids de la référence. Si les recherches par marque sont importantes, augmentez le poids du fabricant. Si vous constatez que de longues descriptions font remonter des résultats non pertinents, réduisez le poids de la description ou mettez-le à zéro pour exclure complètement les descriptions de l'index.

Après avoir modifié les poids, effectuez toujours une réindexation complète pour que les nouvelles valeurs prennent effet sur tous les produits.

Problèmes de recherche courants et correctifs

Les produits n'apparaissent pas dans les résultats de recherche

C'est la plainte la plus courante concernant la recherche. Un produit existe dans le catalogue mais le rechercher par son nom ne retourne aucun résultat. Les causes incluent : le produit a été ajouté via un import qui n'a pas déclenché l'indexation, le produit est désactivé ou en rupture de stock et la recherche est configurée pour exclure ces produits, ou l'index de recherche est corrompu.

Correctif : Vérifiez d'abord que le produit est actif et visible. Puis lancez une réindexation complète. Si le produit n'apparaît toujours pas, vérifiez si le nom du produit contient des caractères spéciaux qui pourraient être supprimés lors de la tokenisation, et vérifiez si le paramètre de longueur minimale de mot (dans la configuration de recherche) exclut les mots courts du nom du produit.

Mauvais produits en premier

Lorsqu'une recherche de "widget bleu" retourne un produit appelé "support de widget" avant le vrai produit "widget bleu", c'est généralement un problème de configuration des poids. Le produit mieux classé a accumulé plus de poids total sur tous les champs indexés. Peut-être que "widget" apparaît plusieurs fois dans la description du produit support, et avec un poids de description élevé, ces occurrences surpassent une seule correspondance dans le nom du produit.

Correctif : Ajustez les poids des champs pour prioriser le nom du produit. Définissez le poids du nom du produit significativement plus haut que le poids de la description. Réindexez après les modifications.

La recherche retourne trop de résultats non pertinents

Cela se produit lorsque le poids de la description est trop élevé ou lorsque des mots courants apparaissent dans de nombreuses descriptions de produits. Une recherche de "premium" retourne chaque produit dont la description contient le mot "premium" même quand ce n'est pas une caractéristique distinctive de ces produits.

Correctif : Réduisez le poids de la description ou utilisez la fonctionnalité de mots blacklistés pour exclure les mots courants non discriminants de l'index. La liste noire est configurée dans Paramètres de la boutique > Recherche et vous permet de spécifier les mots qui doivent être ignorés lors de l'indexation.

La recherche ne trouve pas les correspondances partielles

La recherche intégrée de PrestaShop ne prend pas en charge la véritable correspondance approximative. Si un client recherche "chaussur", il ne trouvera pas les produits contenant uniquement le mot "chaussures" sauf si les fonctionnalités de stemming ou d'alias gèrent la variation. C'est une limitation fondamentale de l'approche d'index basée sur les mots.

Correctif : Utilisez la fonctionnalité d'alias pour associer les variations courantes ("chaussur" à "chaussures", "TV" à "télévision"). Pour une correspondance partielle plus complète, envisagez un moteur de recherche externe comme Elasticsearch.

Les caractères accentués causent des échecs

PrestaShop normalise les caractères accentués lors de l'indexation (par exemple, en convertissant "cafe" et "café" à la même forme de base). Si cette normalisation ne fonctionne pas correctement, les recherches avec ou sans accents peuvent produire des résultats différents.

Correctif : Vérifiez que la suppression des accents est activée dans la configuration de recherche. Réindexez après vérification. Si le problème persiste, vérifiez le jeu de caractères et la collation de la base de données, car des encodages incompatibles peuvent interférer avec la normalisation du texte.

Optimisation des performances de recherche

Pour les boutiques avec de gros catalogues (10 000+ produits), les performances de recherche peuvent devenir un problème. La recherche intégrée effectue des requêtes de base de données contre les tables d'index à chaque recherche, et avec un gros index, ces requêtes peuvent devenir lentes.

Indexation de la base de données

Assurez-vous que les tables ps_search_word et ps_search_index ont des index de base de données appropriés. PrestaShop les crée par défaut, mais si les tables ont été modifiées ou reconstruites, des index peuvent manquer. Les index clés sont sur id_word et id_lang dans ps_search_word, et sur id_product et id_word dans ps_search_index.

Longueur minimale de mot

Le paramètre de longueur minimale de mot contrôle le mot le plus court qui sera indexé. La valeur par défaut est généralement de 3 caractères, ce qui signifie que les mots d'un et deux caractères sont exclus. L'augmenter à 4 réduit la taille de l'index et peut améliorer la vitesse de recherche, mais cela signifie que les recherches de termes courts comme "XL" ou "TV" ne fonctionneront pas. Trouvez un équilibre entre la taille de l'index et vos exigences de recherche.

Mots blacklistés

L'ajout de mots courants ("le", "et", "pour", "avec") à la liste noire réduit significativement la taille de l'index car ces mots apparaissent dans presque chaque description de produit. Des tables d'index plus petites signifient des requêtes plus rapides.

Optimisation des tables

Après une réindexation complète, exécutez OPTIMIZE TABLE ps_search_word, ps_search_index dans MySQL. Le processus de réindexation supprime et réinsère de grandes quantités de lignes, ce qui peut fragmenter les tables. L'optimisation récupère cet espace et améliore les performances des requêtes.

Elasticsearch comme alternative

Pour les boutiques qui ont dépassé la recherche intégrée de PrestaShop, Elasticsearch offre une amélioration significative tant en qualité de recherche qu'en performances. Elasticsearch est un moteur de recherche dédié qui fonctionne comme un service séparé et offre des fonctionnalités que la recherche intégrée basée sur MySQL ne peut pas égaler.

Ce qu'Elasticsearch apporte

La correspondance approximative permet à Elasticsearch de trouver des résultats même lorsque le terme de recherche est mal orthographié. Une recherche de "cuire" trouvera quand même les produits "cuir". Le stemming réduit les mots à leur forme racine, de sorte que "courant", "court" et "couru" trouvent tous les produits contenant l'une de ces variations. Le support des synonymes vous permet de définir des relations entre les mots ("canapé" et "sofa") au niveau du moteur de recherche plutôt que via des alias manuels.

La recherche à facettes (filtrage des résultats par attributs comme la fourchette de prix, la couleur, la marque) est drastiquement plus rapide avec Elasticsearch car il est conçu exactement pour ce type de requête d'agrégation. Les suggestions d'auto-complétion et les fonctionnalités "vouliez-vous dire" sont également des capacités natives d'Elasticsearch.

En termes de performances, Elasticsearch gère les gros catalogues (100 000+ produits) avec des temps de réponse inférieurs à la seconde car il utilise des index inversés optimisés pour la recherche en texte intégral, contrairement à MySQL qui est principalement conçu pour les données relationnelles.

Intégration avec PrestaShop

Plusieurs modules PrestaShop fournissent une intégration Elasticsearch. Ces modules remplacent typiquement le contrôleur de recherche par défaut par un qui interroge Elasticsearch au lieu des tables de recherche MySQL. Les données produits sont synchronisées de PrestaShop vers Elasticsearch soit en temps réel (lors de l'enregistrement du produit) soit via une synchronisation par lots périodique.

L'exécution d'Elasticsearch nécessite un serveur ou conteneur dédié avec suffisamment de RAM (minimum 2 Go pour les petits catalogues, plus pour les plus grands). Cela ajoute de la complexité opérationnelle puisque vous avez maintenant un service supplémentaire à surveiller et maintenir. Pour de nombreuses petites et moyennes boutiques, la recherche intégrée avec une configuration de poids appropriée et une réindexation régulière est suffisante.

Quand envisager Elasticsearch

Envisagez Elasticsearch lorsque votre catalogue dépasse 10 000 produits et que les performances de recherche se dégradent, lorsque les clients font fréquemment des fautes de frappe dans les termes de recherche et s'attendent à une correspondance approximative, lorsque vous avez besoin de fonctionnalités avancées comme l'auto-complétion ou le filtrage à facettes, ou lorsque la qualité de recherche est un avantage concurrentiel pour votre entreprise (boutiques B2B avec des catalogues de produits complexes, par exemple).

La checklist de réindexation

Lorsque la recherche ne fonctionne pas correctement dans votre boutique PrestaShop, suivez ce processus de diagnostic et de résolution. Premièrement, vérifiez que les produits concernés sont actifs, visibles et en stock (si votre recherche exclut les produits en rupture de stock). Deuxièmement, vérifiez la configuration des poids de recherche et assurez-vous qu'elle correspond à vos priorités. Troisièmement, lancez une reconstruction complète de l'index de recherche depuis Paramètres de la boutique > Recherche ou via l’URL cron de l’indexeur. Quatrièmement, videz le cache PrestaShop après la réindexation. Cinquièmement, testez la recherche avec des termes spécifiques pour vérifier la correction. Sixièmement, si les problèmes persistent, vérifiez les tables ps_search_word et ps_search_index directement pour vérifier que les produits problématiques ont des entrées. Septièmement, si l'index semble correct mais que la recherche échoue toujours, examinez la logique du contrôleur de recherche et les modules qui le remplacent.

Une réindexation régulière, combinée à une configuration de poids réfléchie et une liste d'alias bien maintenue, maintient la recherche intégrée de PrestaShop fonctionnelle de manière fiable pour la majorité des boutiques. Pour celles qui ont besoin de plus, Elasticsearch offre un chemin de mise à niveau sans nécessiter de changement de plateforme.

Pour d'autres diagnostics, voir notre guide de dépannage PrestaShop.

OPcache PrestaShop est le cache bytecode PHP : il garde votre PHP compilé en mémoire afin que le serveur évite de reparser les fichiers à chaque requête. C’est la couche qui compte le plus pour le temps de réponse brut, et elle résout un problème différent des deux autres caches PrestaShop.

• OPcache (PHP) : met en cache le bytecode PHP compilé. Activez-le en production et videz-le à chaque déploiement ou mise à jour de code ou modules, sinon l’ancien code continue de tourner.
• Cache Smarty (templates) : met en cache les templates .tpl compilés et, optionnellement, leur HTML rendu. Videz-le après modification de templates, changement de thème ou changement de hooks module.
• Cache navigateur (client) : piloté par les en-têtes Cache-Control / ETag afin que les visiteurs récurrents réutilisent CSS, JS et images sans aller-retour serveur.

L’erreur fréquente est de vider la mauvaise couche : un changement PHP qui n’apparaît pas relève d’OPcache, un changement de template qui n’apparaît pas relève de Smarty, et une feuille de style obsolète relève du navigateur. MPR Performance Revolution affiche l’état OPcache live (état activé, scripts mis en cache, hit ratio, mémoire), vide chaque couche séparément, et réchauffe OPcache, Smarty et CCC après un déploiement afin que le premier visiteur ne paie pas un cache froid. Pour le guide complet par réglage, consultez notre guide Performance Optimization.

Performance Revolution sépare plus de couches de cache que l’écran PrestaShop habituel : cache de requêtes PrestaShop, cache module, Smarty, cache Symfony et OPcache. Ses stats OPcache incluent scripts cached, used/free/total memory, memory percentage, hits, misses et hit ratio lorsque l’extension PHP est disponible et non restreinte par l’hébergement.

Le vidage est aussi spécifique par couche. Le vidage Smarty appelle les méthodes propres de Smarty pour cache et templates compilés, puis vide aussi les répertoires filesystem Smarty production/development. Le vidage OPcache appelle opcache_reset(). Le vidage Symfony cible le répertoire de cache de l’environnement en évitant les répertoires Smarty, et le vidage du cache module passe par le gestionnaire de cache du module.

Le warm-up est une préoccupation distincte du vidage. Le cache warmer du module est désactivé par défaut, a une concurrence par défaut de 2 et un temps d’exécution maximal par défaut de 120 secondes, et peut réchauffer des URL origin après déploiement. Le warming de l’edge CDN est également séparé et ne tourne que lorsque edge warming est activé.

PHP code changed: clear OPcache.
Theme .tpl changed: clear Smarty.
CSS/JS changed: clear browser/CDN asset cache or change asset version.
After deploy: warm origin/cache so first real visitor does not pay the cold-cache cost.

Une Content Security Policy (CSP) est un header HTTP qui indique au navigateur quelles sources peuvent charger scripts, styles, images, polices, frames et connexions sur vos pages PrestaShop. Si un attaquant injecte un script depuis une source non autorisée, le navigateur le bloque. CSP est une couche de protection supplémentaire ; elle ne remplace pas la correction du code vulnérable.

Les directives importantes

• default-src 'self' est le fallback.
• script-src est le contrôle XSS principal et doit inclure uniquement les sources de scripts dont votre thème, vos modules, vos analytics et vos flux de paiement ont réellement besoin.
• style-src, img-src et font-src nécessitent généralement des tolérances de compatibilité pour les thèmes PrestaShop, les polices et les CDN d'images.
• connect-src couvre AJAX, les beacons analytics et certains appels SDK de paiement.
• frame-src et frame-ancestors comptent pour les paiements embarqués, YouTube, reCAPTCHA et la protection contre le clickjacking.
• object-src 'none' et base-uri 'self' sont de bonnes directives de durcissement de départ.

Politique de départ pour les stacks PrestaShop courantes

Commencez en mode report-only et ajustez à partir des vraies violations. Cet exemple autorise les services Google courants d'analytics/tagging, Google Fonts, les images depuis des sources HTTPS/CDN, les frames Google/reCAPTCHA et les intégrations YouTube. Ajoutez les domaines de prestataires de paiement comme Stripe, PayPal ou votre PSP seulement après avoir testé leur checkout complet et le flux 3-D Secure.

# Apache .htaccess or vhost with mod_headers
<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com https://www.google.com https://www.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: blob:; font-src 'self' https://fonts.gstatic.com data:; connect-src 'self' https://www.google-analytics.com https://stats.g.doubleclick.net; frame-src 'self' https://www.google.com https://www.youtube.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
</IfModule>

# Nginx server block
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com https://www.google.com https://www.gstatic.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: blob:; font-src 'self' https://fonts.gstatic.com data:; connect-src 'self' https://www.google-analytics.com https://stats.g.doubleclick.net; frame-src 'self' https://www.google.com https://www.youtube.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'" always;

Déployer sans casser la boutique

Les thèmes et modules PrestaShop utilisent souvent des scripts et styles inline, donc une politique stricte peut casser de vrais comportements de boutique si vous l'appliquez immédiatement. Lancez d'abord Content-Security-Policy-Report-Only, testez les pages produits, panier, checkout, création de compte, formulaires de contact, redirections de paiement et 3-D Secure, puis passez au header d'application Content-Security-Policy une fois le log de violations propre.

Security Revolution peut gérer les headers de sécurité depuis le back-office. Son support CSP est désactivé par défaut pour la compatibilité, démarre en mode report-only lorsqu'il est activé, stocke les rapports de violation CSP et peut suggérer des ajouts à partir des sources bloquées répétées. Il couvre aussi X-Frame-Options, HSTS, Referrer-Policy et Permissions-Policy. Pour la checklist plus large, consultez notre guide de durcissement sécurité PrestaShop.

Un cache pleine page PHP (comme celui qu'offre un module PrestaShop de type "page cache pro") et Varnish servent tous deux des pages mises en cache, mais à des endroits différents de la pile, et c'est tout l'enjeu du choix.

Comment fonctionne un cache pleine page PHP : la requête atteint toujours Apache ou Nginx, PHP démarre, PrestaShop s'initialise, puis le module de cache renvoie une copie HTML stockée avant l'exécution complète du contrôleur. Bien plus rapide qu'un rendu complet, mais PHP démarre à chaque accès, d'où un surcoût par requête sous forte charge.

Comment fonctionne Varnish : Varnish est un reverse proxy HTTP placé devant votre serveur web. Sur un hit de cache, il répond directement depuis la mémoire, PHP ne s'exécute jamais, MySQL n'est jamais interrogé. Cela supprime presque tout le surcoût par requête, ce qui permet d'absorber de gros pics de trafic.

Quand un cache pleine page PHP suffit : pour la plupart des boutiques, oui. Si votre serveur répond déjà vite en charge normale et que PHP n'est pas saturé en permanence, l'élément supplémentaire qu'est Varnish ne se justifie pas. Un cache PHP gère aussi la logique propre à PrestaShop (clients connectés, panier) dans l'application, là où Varnish exige des règles de cookies et de variation de cache.

Optez pour Varnish quand : des pics de trafic réguliers (ventes flash, campagnes) saturent PHP, vous visez des temps de réponse très bas, ou votre trafic est très majoritairement anonyme.

Pour la couche de cache pleine page PHP, Performance Revolution sert des en-têtes de cache pleine page CDN pour les visiteurs anonymes et gère le cache par page et les purges, une étape sensée avant Varnish. Pour la configuration approfondie, voir notre guide du cache PrestaShop.

Si les miniatures de produits sont étirées, floues, mal recadrées ou n'apparaissent pas, le réflexe habituel est de régénérer les images. PrestaShop conserve une copie redimensionnée distincte pour chaque type d'image (petite, moyenne, grande, etc.) ; quand ces copies manquent ou sont obsolètes, la boutique affiche des miniatures cassées ou mal dimensionnées. La régénération reconstruit chaque copie à partir de l'original.

Quand reconstruire les miniatures

• Vous avez ajouté ou modifié un type d'image (Design → Réglages des images) et les produits affichent encore les anciennes tailles.
• Vous avez changé de thème et le nouveau attend d'autres dimensions.
• Les miniatures sont manquantes ou déformées après un import ou un changement de serveur.
• Vous avez activé le WebP et voulez servir les images existantes dans ce format.

Comment régénérer

Pour les petits catalogues, utilisez Design → Réglages des images → Régénérer les miniatures dans le back-office. Les grands catalogues y atteignent souvent la limite de temps ou de mémoire PHP, car chaque original est chargé en mémoire puis redimensionné un par un. Lancez alors la régénération en ligne de commande (console Symfony ou script CLI) : cela évite le timeout du navigateur et permet de traiter le catalogue par lots. Augmenter memory_limit et max_execution_time au préalable aide aussi.

Une erreur fréquente consiste à garder d'énormes originaux de plusieurs mégapixels : ils rendent chaque régénération lente et gourmande en mémoire, alors réduisez d'abord les images sources à un maximum raisonnable. Une fois les miniatures saines, gardez les nouvelles images légères et en lazy-load, voir notre guide de performance PrestaShop pour la vue d'ensemble.

Une mauvaise version de PHP provoque des écrans blancs, des tunnels de commande cassés et des erreurs de modules dans PrestaShop, accordez donc PHP à votre branche PrestaShop. Voici la correspondance pratique.

Branche PrestaShop → PHP

L'essentiel : aucune version de PrestaShop 1.7 ne prend en charge PHP 8, Smarty utilise des fonctions supprimées en PHP 8.0 et plante. Pour un PHP moderne, il faut la branche 8.x ou 9.x.

Fin de vie de PHP (calendrier php.net)

PHP 7.4 et 8.0 sont en fin de vie et ne reçoivent plus de correctifs de sécurité, les utiliser sur une boutique qui traite des paiements est un vrai risque. Vérifiez la liste prise en charge à jour sur php.net avant de choisir.

Vérifier votre version de PHP

Dans le back office, Paramètres avancés → Informations affiche votre version PHP active. En SSH, php -v donne la version CLI (qui peut différer de la valeur web). Ne comptez pas sur un fichier phpinfo() temporaire, si vous en créez un, supprimez-le aussitôt.

Mettre à jour PHP en sécurité

Testez d'abord sur une copie de préproduction, vérifiez chaque module et votre thème avec la nouvelle version, puis changez PHP dans votre panneau d'hébergement et videz tous les caches. Ce qui casse le plus souvent : un module non maintenu ou un thème ancien, pas le cœur. Vous planifiez aussi un changement de version ? Voyez notre guide de migration PrestaShop.

Lazy Loading en 2026 : ce que les navigateurs gèrent nativement vs ce qui nécessite un module

Le lazy loading est une technique d'optimisation des performances qui diffère le chargement des ressources hors écran jusqu'à ce que l'utilisateur défile vers elles. En 2026, le support natif du lazy loading par les navigateurs a considérablement mûri, mais il existe encore des scénarios où les propriétaires de boutiques PrestaShop ont besoin de modules supplémentaires ou d'implémentations personnalisées. Ce guide explique exactement ce que les navigateurs gèrent seuls, quelles lacunes subsistent et comment implémenter la meilleure stratégie de lazy loading pour votre boutique PrestaShop.

Ce que le lazy loading natif couvre en 2026

L'attribut HTML loading="lazy" est maintenant supporté par plus de 95% des navigateurs dans le monde. Cela inclut Chrome (depuis v77), Firefox (depuis v75), Safari (depuis v15.4), Edge (depuis v79) et tous les navigateurs basés sur Chromium.

Comment fonctionne le lazy loading natif

Ajouter loading="lazy" à une balise <img> ou <iframe> indique au navigateur de différer le chargement de cette ressource jusqu'à ce qu'elle soit à une certaine distance du viewport.

<img src="image-produit.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nom du produit">

Ce que les navigateurs gèrent nativement

Ce que les navigateurs NE gèrent PAS

Implémenter le lazy loading natif dans PrestaShop

Pour les thèmes PrestaShop modernes

Les thèmes PrestaShop modernes (comme Hummingbird) incluent souvent le lazy loading natif par défaut. Pour vérifier ou l'ajouter, éditez vos fichiers de template.

{* Avant - pas de lazy loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Après - avec lazy loading natif *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Règle critique : ne jamais lazy loader les images above-the-fold

L'erreur de lazy loading la plus courante est de l'appliquer aux images visibles sans défilement. Cela nuit en fait aux performances car le navigateur retarde le chargement du contenu que l'utilisateur voit immédiatement. Les Core Web Vitals de Google vous pénaliseront avec un score LCP plus élevé.

Images qui ne doivent PAS être lazy loadées :

• Le logo de votre boutique
• Les images hero/bannière en haut de page
• Les 1-2 premières images produits sur les pages catégorie

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Bannière promotion été">

Quand vous avez besoin d'un module : images d'arrière-plan CSS

Les thèmes PrestaShop utilisent fréquemment des images d'arrière-plan CSS pour les sliders, bannières et en-têtes de catégorie. L'attribut loading="lazy" ne fonctionne pas pour les fonds CSS. Vous avez besoin de JavaScript.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Quand vous avez besoin d'un module : effets de placeholder

• Effet blur-up (LQIP) - Chargez d'abord une version minuscule et floue
• Écrans squelettes - Blocs de placeholder gris correspondant aux dimensions
• Placeholders de couleur dominante - Utilisez la couleur dominante de l'image comme fond

Impact sur la performance et les Core Web Vitals

• LCP - Le lazy loading des images above-the-fold NUIT au LCP
• CLS - Les images sans attributs width/height causent des décalages de mise en page
• INP - Moins de ressources chargées simultanément améliorent l'interactivité

Indispensable : attributs width et height

<!-- MAUVAIS - cause un décalage de mise en page -->
<img src="produit.jpg" loading="lazy" alt="Produit">

<!-- BON - réserve l'espace -->
<img src="produit.jpg" loading="lazy" 
     width="400" height="400" alt="Produit">

Recommandations spécifiques PrestaShop

Pages de liste de produits

Lazy loader toutes les images produits sauf la première rangée. Appliquer fetchpriority="high" à la première rangée.

Pages de détail produit

L'image principale doit être chargée en eager avec fetchpriority="high". Les miniatures de la galerie peuvent être lazy loadées.

Page d'accueil

Les images du slider above the fold doivent être chargées en eager. Les blocs de modules below the fold doivent utiliser le lazy loading.

Résumé : Module vs. Natif

Pour aller plus loin, lisez Optimisation des images PrestaShop : balises alt, lazy loading et vitesse.

Le fichier .htaccess PrestaShop contrôle la réécriture d’URL et les redirections, et une règle mal placée peut mettre toute la boutique hors ligne, donc modifiez-le prudemment et à partir d’une sauvegarde.

Placez les règles personnalisées au bon endroit. PrestaShop régénère ses propres règles entre deux commentaires marqueurs (# ~~start~~ ... # ~~end~~) chaque fois que vous activez/désactivez Friendly URLs ou cliquez sur "Generate .htaccess file." Tout ce que vous ajoutez dans ce bloc est écrasé, placez toujours vos redirections personnalisées avant le bloc PrestaShop.

Utilisez le bon type de redirection. Utilisez 301 pour une page déplacée définitivement (elle transmet l’équité de liens), 302 pour un déplacement temporaire, et 410 pour un contenu définitivement supprimé sans remplacement.

Ne cassez pas la boutique. Les erreurs classiques : une règle catch-all qui boucle indéfiniment, ou une règle qui avale admin, API, modules et fichiers statiques. Protégez-vous des deux avec des conditions, par exemple :

# Add a default language prefix, but never loop or touch admin/api/modules/assets
RewriteCond %{REQUEST_URI} !^/(en|fr|de|es|it|pl)(/|$) [NC]
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules/ [NC]
RewriteCond %{REQUEST_URI} !\.(css|js|jpe?g|png|gif|svg|webp|ico|woff2?)$ [NC]
RewriteRule ^(.*)$ https://yourstore.com/en/$1 [R=301,L]

Testez d’abord avec une 302, vérifiez avec curl -I -L, puis passez en 301. Pour beaucoup de redirections ou du personnel non technique, un module de redirection piloté par base de données avec UI est plus sûr que la modification à la main. Voir notre guide de dépannage PrestaShop pour récupérer si une règle vous bloque l’accès.

Le redirect manager de SEO Revolution est l’option pilotée par base de données la plus sûre pour la plupart des changements d’URL au niveau boutique. Il prend en charge les redirections 301, 302 et 410, la sélection d’entités cibles pour produits/catégories/CMS et autres entités, les cibles URL personnalisées, indicateurs actifs, compteurs de hits et dates de dernier hit. Une ligne 410 n’a pas de cible de remplacement et envoie une vraie réponse Gone.

Le module gère aussi des cas pénibles en .htaccess : correspondances exactes, correspondances path-only qui préservent la query string originale, redirections prefix qui préservent les chemins enfants, et garde-fous empêchant un préfixe large de détourner de vraies routes de module. Il peut aussi réduire les chaînes 301 quand les redirections sont ajoutées ou mises à jour, ce qui garde les chemins de migration plus propres pour les crawlers.

Utilisez .htaccess pour les règles serveur globales qui doivent s’exécuter avant PrestaShop, comme hôte, protocole ou réécritures de sécurité très précoces. Utilisez l’UI de redirection pour migrations de contenu, produits retirés, anciennes URL CMS et gestion SEO quotidienne des redirections lorsque vous voulez du reporting et des modifications plus sûres.

Les bots représentent une grande partie du trafic web, et tous ne sont pas des crawlers amicaux. Les scrapers copient les données produits, les bots de credential stuffing attaquent les formulaires de connexion, les bots de faux comptes abusent de l'inscription, et les crawlers de filtres agressifs peuvent bloquer votre serveur en forçant des pages catégorie coûteuses. Un WAF reste la meilleure première ligne, mais vous pouvez déjà obtenir une protection utile avec des limites serveur, des limites applicatives et des allowlists prudentes. Testez chaque règle sur staging d'abord.

Bloquer les mauvais bots évidents dans Apache (.htaccess)

RewriteEngine On

# Block common scraper and attack bots
RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot|DotBot|BLEXBot) [NC]
RewriteRule .* - [F,L]

# Block empty user agents
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F,L]

Rate limiting Apache avec mod_evasive

.htaccess convient pour de simples blocages user-agent, mais le vrai rate limiting Apache se configure normalement au niveau vhost/serveur, par exemple avec mod_evasive :

DOSHashTableSize 3097
DOSPageCount 20
DOSPageInterval 1
DOSSiteCount 200
DOSSiteInterval 60
DOSBlockingPeriod 300
DOSLogDir /var/log/mod_evasive

Limites de requêtes Nginx

# http {} context
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=search:10m rate=30r/m;
limit_req_zone $binary_remote_addr zone=general:20m rate=10r/s;

# server {} context
location ~* /(login|authentication|password-recovery) {
    limit_req zone=login burst=3 nodelay;
    try_files $uri $uri/ /index.php$is_args$args;
}

location ~* /(search|module/ps_facetedsearch|module/mprfilterrevolution) {
    limit_req zone=search burst=20;
    try_files $uri $uri/ /index.php$is_args$args;
}

location / {
    limit_req zone=general burst=40;
    try_files $uri $uri/ /index.php$is_args$args;
}

fail2ban pour la protection brute-force

# Filter: /etc/fail2ban/filter.d/prestashop-login.conf
[Definition]
failregex = ^<HOST> .* "POST .*/login.*" (401|403)

# Jail: /etc/fail2ban/jail.d/prestashop.conf
[prestashop-login]
enabled  = true
filter   = prestashop-login
logpath  = /var/log/apache2/access.log
maxretry = 10
findtime = 300
bantime  = 3600

Utiliser les allowlists avec prudence

• Prestataires de paiement : ne limitez pas et ne bloquez pas les callbacks de paiement, webhooks, retours 3-D Secure ou endpoints de validation de commande avant d'avoir leurs plages IP actuelles et testé de vrais paiements.
• Moteurs de recherche : ne bloquez pas Googlebot/Bingbot uniquement par user agent. Les vrais crawlers de recherche doivent être vérifiés par reverse DNS ou par un mécanisme équivalent de crawler vérifié, car de faux bots réutilisent ces noms.
• CDN/proxies inverses : configurez d'abord les IPs proxy de confiance ; sinon chaque client peut apparaître comme l'IP du proxy et une minute chargée peut bloquer toute la boutique.
• Back-office et IPs support : autorisez de façon étroite et réexaminez régulièrement. Une allowlist trop large contourne la protection que vous venez d'ajouter.

Security Revolution ajoute une protection applicative pour cette couche : limites d'actions pour paniers, inscriptions, contact et commentaires ; limites globales par IP ; budgets de crawl par crawler ; limiteur pondéré pour les requêtes de listes à facettes coûteuses ; gestion des crawlers ; mode bot-fight ; et configuration d'IPs whitelistées. Les règles serveur restent importantes parce qu'elles stoppent le trafic avant PHP, mais le module donne au back-office de la visibilité sur ce qui a été bloqué.

Surveiller vos logs d'accès

# Top 20 IPs by request count
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

# IPs hitting login most
grep 'login' /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Superposer blocages user-agent, limites serveur, fail2ban, CAPTCHA, protections CDN et limites de module conscientes de PrestaShop donne l'essentiel de la protection anti-bots quotidienne sans WAF payant. Pour une checklist plus large, consultez notre guide de sécurité PrestaShop.

PrestaShop envoie des e-mails transactionnels, dont les modèles liés aux statuts de commande comme la confirmation, à partir de fichiers de modèles modifiables sur votre serveur, que vous pouvez entièrement personnaliser. Voici la manière sûre de personnaliser la confirmation de commande.

Chaque e-mail a deux fichiers : une version HTML (ce que voient la plupart des clients) et une version texte de secours. Ils se trouvent dans mails/<iso>/, un dossier par langue. La confirmation de commande, c'est order_conf.html et order_conf.txt.

Modifiez une copie, jamais le fichier d'origine :

• Copiez order_conf.html et order_conf.txt depuis mails/en/ vers themes/votre-theme/mails/en/ (répétez par langue). Les modèles du thème sont prioritaires et survivent aux mises à jour du cœur.
• Construisez la mise en page avec des tableaux HTML et du CSS en ligne, les clients de messagerie ignorent les feuilles de style externes et les mises en page modernes. Fixez une largeur (600px est le standard) et restez en une colonne pour le mobile.
• Insérez les données via des variables entre accolades comme {order_name}, {firstname}, {total_paid} et {items} pour la liste des produits. Pour connaître les variables disponibles, regardez le code PHP qui envoie l'e-mail (la confirmation est construite dans classes/PaymentModule.php).

Deux choses cassent le plus souvent les confirmations : les images en chemin relatif (utilisez des URL https:// complètes) et les balises de tableau non fermées. Et si les e-mails arrivent en retard ou en spam, le correctif concerne souvent la délivrabilité, pas le modèle, passez de PHP mail() à un SMTP authentifié dans Paramètres avancés > E-mail. Tout le détail dans notre guide e-mail & SMTP PrestaShop.

Un audit mensuel de 30 minutes repère les petits problèmes, logiciel obsolète, logs qui grossissent, erreurs silencieuses, avant qu’ils ne deviennent des pages lentes, une faille ou une indisponibilité. Voici la checklist ciblée.

• PHP & config (3 min) : utilisez une version PHP supportée ; vérifiez memory_limit (256M+), max_execution_time et qu’OPcache est actif.
• Logs d’erreurs (4 min) : dans Advanced Parameters > Logs, scannez la dernière semaine pour les entrées Error/Critical ; parcourez le log PHP pour les fatals et avis de dépréciation.
• Modules (5 min) : désinstallez (ne désactivez pas seulement) les modules que vous n’utilisez plus, et appliquez d’abord les mises à jour aux modules de paiement et sécurité.
• Base de données (4 min) : vérifiez la taille totale et les tables couramment gonflées, ps_connections, ps_guest, ps_cart, ps_log, ps_mail. Notre module Database Cleanup les purge en sécurité.
• Sécurité (5 min) : confirmez un dossier admin randomisé, SSL valide, permissions fichier raisonnables (pas de 777), mode debug désactivé en production.
• Performance (4 min) : lancez un audit Lighthouse ; vérifiez que Smarty cache et CCC sont actifs dans Advanced Parameters > Performance.
• SEO & sauvegardes (5 min) : vérifiez robots.txt et le sitemap XML ; confirmez une sauvegarde récente, complète et hors site.

L’audit identifie les problèmes, il ne les corrige pas. Corrigez d’abord sécurité et fonctionnalités cassées, puis performance et nettoyage.

Mappez l’audit à des données module mesurables quand c’est possible. Les stats de cache de Performance Revolution séparent cache de requêtes PrestaShop, cache module, Smarty, Symfony et OPcache, et OPcache rapporte scripts cached, memory usage, hits, misses et hit ratio. Son écran de requêtes lentes regroupe les SQL lents par hash de requête et contrôleur, donc un contrôle mensuel peut montrer si une page ou un module se dégrade.

Database Cleanup est volontairement count-first. Il rapporte les candidats au nettoyage avant suppression et utilise des lots limités pour les vieux paniers de plus de 30 jours sans commande, stats de recherche de plus de 90 jours, specific prices expirés, vieux logs, anciennes connexions, invités orphelins et logs mail de plus de 30 jours. Chaque tâche s’exécute par lots et s’arrête autour d’une limite de sécurité, donc les très grandes boutiques peuvent nécessiter plusieurs passages plutôt qu’un énorme delete.

Pour le SEO, utilisez le même audit pour vérifier la cohérence entre robots.txt et sitemaps. Le vérificateur de sitemap de SEO Revolution peut ignorer les URL non-200, redirigées, noindex ou avec canonical mismatch, donc une chute soudaine du nombre d’URL sitemap est un signal pour inspecter codes de réponse, canonicals et règles robots avant de supposer que Google est en cause.

Fast monthly evidence list: OPcache hit ratio; slow queries last 24h; cleanup candidate counts; sitemap verified/skipped counts; latest backup timestamp.