À jour pour PrestaShop 1.6, 1.7, 8.x et la branche 9.0–9.1. Les chemins du back-office ci-dessous sont rédigés pour 8.x/9.x ; en 1.7, certains libellés de menu diffèrent légèrement.
Une installation PrestaShop toute fraîche démarre sans problème : elle dispose d’un catalogue, d’un panier, d’un tunnel de commande, d’un panneau d’administration, et elle peut accepter une vraie commande d’un vrai client dès le premier jour. Alors pourquoi toute boutique qui dépasse le stade du projet amateur finit-elle par installer la même douzaine de modules, à peu de choses près ? Parce que le cœur de PrestaShop est conçu pour être correct et généraliste, pas pour être optimisé pour votre boutique précise. Les manques qu’il laisse, un seul sitemap plat, aucune alerte en cas de modification de fichier, un tunnel de commande qui oblige les clients à franchir des étapes, pas d’éditeur de prix en masse, sont exactement ceux qui vous coûtent du budget d’exploration, du sommeil et des commandes dès que vous avez du vrai trafic.
Voici donc la liste des indispensables : les fonctions que presque toute boutique PrestaShop sérieuse finit par couvrir, regroupées selon leur utilité pour l’activité, avec les vrais chemins du back-office et le comportement de PrestaShop pour que vous compreniez pourquoi le cœur ne suffit pas et ce qu’un module change. L’approche est volontairement centrée sur les fonctions, pas sur les marques : la plupart de ces besoins peuvent être couverts par un module communautaire gratuit, un module payant ou le cœur lui-même, et nous indiquons clairement ce qu’il en est. Transparence dès le départ : nous développons et vendons des modules PrestaShop, et nous exploitons de vraies boutiques avec eux. Plusieurs de nos propres modules apparaissent donc ci-dessous comme exemples. Nous les citons parce que nous les avons conçus pour combler des lacunes rencontrées à répétition en production, pas parce que chaque boutique a besoin de tous les installer.
- Vous venez tout juste d’installer PrestaShop et vous cherchez l’ordre d’installation. Ce qu’il faut activer dans la première heure et ce qui peut attendre, c’est une autre question, avec sa propre réponse : les modules que toute nouvelle boutique PrestaShop devrait installer en premier.
- Cette liste traite de la couverture fonctionnelle, pas du nombre de modules. Le débat « douze modules, est-ce trop ? quarante ? » a sa propre place dans pourquoi la qualité des modules compte davantage que leur quantité.
Comment lire cette liste
Pour chaque fonction, nous vous donnons trois éléments : ce que fait réellement le cœur de PrestaShop (pour décider si vous avez vraiment besoin d’un module), les conséquences pour votre activité si vous laissez le manque en l’état, et une recommandation sur l’intérêt d’acheter un module. Nous n’avons aucun accord d’affiliation avec les acteurs mentionnés ; lorsque nous citons l’un de nos propres modules, c’est parce que nous l’avons créé pour combler une lacune que nous rencontrions régulièrement en production, et nous le disons clairement.
Visibilité : la base SEO
C’est la catégorie dans laquelle les marchands investissent le moins, parce que rien ne casse visiblement quand elle manque : vous n’apparaissez simplement pas, en silence.
Un sitemap XML qui tient la charge
Ce que fait le cœur : le module officiel Google Sitemap, généralement appelé gsitemap, génère un sitemap lorsqu’il est installé/activé (Modules → Gestionnaire de modules). Il fonctionne. Ses limites apparaissent avec la taille : il tend à produire un gros fichier unique, prend mal en charge les sitemaps d’images et ne sépare pas les produits, catégories et pages CMS en index distincts que Google peut explorer efficacement.
Conséquence : sur un catalogue de quelques milliers de produits, un sitemap unique et gonflé signifie que Google dépense son budget d’exploration de manière inefficace et découvre vos nouveaux produits avec retard, ce qui, sur un catalogue qui bouge vite, se traduit par du chiffre d’affaires perdu. Orientation : nécessaire au-delà d’environ 1 000 produits. Recherchez des sitemaps fractionnés (fichiers produits/catégories/CMS séparés sous un même index), des entrées pour les images, la prise en charge du multiboutique et du multilingue, ainsi qu’un ping automatique des moteurs de recherche lors des mises à jour. Notre mprsitemapbuilder fait exactement cela ; plusieurs modules de la place de marché Addons couvrent le même besoin. En dessous d’environ 500 produits, le sitemap du cœur est réellement suffisant.
Un gestionnaire de redirections (la fuite de revenus silencieuse)
Ce que fait le cœur : PrestaShop propose des réglages SEO & URL et quelques options de redirection au niveau des objets, mais pas de véritable gestionnaire de redirections qui rattrape chaque URL modifiée ou supprimée. Lorsque vous supprimez un produit, renommez une catégorie ou changez le modèle d’URL simplifiée, l’ancienne URL commence à renvoyer une 404.
Conséquence : chaque 404 sur une URL qui était positionnée gaspille l’autorité de liens que cette page avait accumulée, parfois pendant des années. Le client qui clique sur votre résultat Google arrive sur une erreur et repart. C’est la perte SEO évitable la plus fréquente que nous voyons sur les boutiques PrestaShop. Orientation : essentiel dès que votre catalogue évolue régulièrement. Il vous faut des 301 automatiques lors de la suppression d’un produit ou d’une catégorie et lors d’un changement d’URL, une table de redirections manuelles et un contrôle des canoniques. Notre mprseorevolution gère les redirections avec les modèles de balises meta, la gestion canonique et le hreflang ; pour des besoins uniquement centrés sur les redirections, la communauté propose des options plus légères.
Données structurées (extraits enrichis)
Ce que fait le cœur : PrestaShop émet certaines données structurées via le thème, mais la couverture varie selon les versions et les thèmes, et elle couvre rarement tout l’ensemble que Google peut exploiter.
Conséquence : les schémas Product, Offer, BreadcrumbList et Organization permettent à Google d’afficher directement dans le résultat le prix, la disponibilité, les notes et le fil d’Ariane. Une fiche avec un prix et des étoiles obtient plus de clics qu’un simple lien bleu ; le gain est réel, mais varie beaucoup selon les requêtes, donc ne misez pas sur un pourcentage précis. Orientation : pertinent pour toute boutique qui concurrence sur des requêtes d’achat. Un module de schéma comme notre mprschema (ou un équivalent de la place de marché) doit couvrir au minimum Product, Offer, BreadcrumbList et Organization ; évitez ceux qui balisent uniquement les produits en ignorant le fil d’Ariane et les avis. Pour voir comment les fiches de la place de marché se comparent vraiment en matière de qualité, consultez le guide d’achat de la place de marché Addons.
Dormir tranquille : la sécurité
Les modules de sécurité semblent facultatifs jusqu’au matin où ils ne le sont plus. PrestaShop est une cible populaire et open source ; la question n’est pas de savoir si des bots sondent votre boutique, mais si vous vous en apercevrez quand l’un d’eux entrera.
Surveillance de l’intégrité des fichiers
Ce que fait le cœur : rien ici. PrestaShop n’a pas d’alerte intégrée lorsqu’un fichier PHP change.
Conséquence : les compromissions dangereuses sont les plus discrètes : un skimmer de carte bancaire injecté dans un modèle de paiement, ou des liens de spam semés dans un contrôleur, qui tournent sans être détectés pendant des semaines. La surveillance de l’intégrité des fichiers compare vos fichiers à une base de référence saine et vous indique l’heure à laquelle quelque chose change. Orientation : essentiel pour toute boutique qui accepte des paiements. Notre mprsecurityrevolution surveille les fichiers du cœur, des modules et du thème pour détecter les modifications non autorisées et vous alerter ; l’enjeu est la vitesse de détection, car le coût d’un skimmer augmente avec sa durée d’activité.
Renforcement de l’administration et 2FA
Ce que fait le cœur : PrestaShop gère les comptes du back-office et les profils d’autorisation (Paramètres avancés → Équipe → Employés), mais ne fournit aucune authentification à deux facteurs native : la 2FA pour le back-office passe par un module tiers, pas par un interrupteur du cœur. Le cœur ne propose pas non plus de limitation des tentatives par force brute, de journal d’activité administrateur ni d’alertes d’anomalie.
Conséquence : votre panneau d’administration donne accès à tout le royaume ; un mot de passe employé faible ou réutilisé est le point d’entrée le plus courant. L’authentification à deux facteurs, combinée à la limitation des tentatives de connexion et à un journal d’activité administrateur, transforme un simple mot de passe volé d’une catastrophe en incident visible et maîtrisable. Orientation : ajoutez un module de sécurité back-office dès que vous avez des comptes employés ou un trafic d’attaque réel, il n’existe pas de 2FA native sur laquelle vous reposer. Notre mprtotaldefender ajoute l’authentification à deux facteurs, la protection contre la force brute, la journalisation de l’activité administrateur et la détection des comportements suspects.
CAPTCHA sur les formulaires publics
Ce que fait le cœur : aucun des formulaires publics de PrestaShop (inscription, contact, avis produit) n’inclut de CAPTCHA par défaut.
Conséquence : les formulaires ouverts attirent les inscriptions spam, les messages de contact indésirables et les faux avis, qui vous font perdre du temps et polluent vos données. Un CAPTCHA invisible moderne évalue les visiteurs silencieusement : les vrais clients ne voient jamais d’énigme. Orientation : une assurance peu coûteuse, ajoutez-la. Notre mprrecaptcha ajoute reCAPTCHA aux formulaires d’inscription, de contact et d’avis. Un problème voisin, les bots qui remplissent les paniers et faussent vos statistiques, a sa propre solution ; nous avons traité le diagnostic dans notre travail sur mprspamcartblocker, qui filtre le trafic automatisé d’ajout au panier.
Vitesse : modules de performance
PrestaShop rend les pages dynamiquement, en exécutant des dizaines de requêtes à chaque chargement. La plateforme vous donne ici de vrais outils gratuits : utilisez-les avant d’acheter quoi que ce soit.
Mise en cache des pages
Ce que fait le cœur : beaucoup de choses, en réalité. Paramètres avancés → Performance donne accès au cache Smarty, à CCC (Combiner/Compresser/Mettre en cache pour CSS & JS) et à des options de backend de cache selon la version, comme Memcached/APCu ; Redis peut nécessiter la bonne version de PrestaShop ou un module/une intégration supplémentaire. Activez-les d’abord : ils sont gratuits et utiles.
Conséquence : la mise en cache native réduit le travail par requête, mais PrestaShop assemble encore la plupart des pages pour chaque visiteur. Un cache pleine page stocke le HTML rendu et le sert en une fraction du temps ; la vraie difficulté est l’invalidation. Vider uniquement les pages qui ont changé lorsque vous modifiez un produit, au lieu de supprimer tout le cache. Orientation : exploitez d’abord les réglages Performance du cœur ; ajoutez un module de cache pleine page lorsque votre trafic le justifie. Notre mprperformancerevolution gère le cache pleine page avec invalidation ciblée. (Un point pratique à retenir pour tout cache : un déploiement qui lance cache:clear peut brièvement relancer votre boutique à froid, programmez-le sur une plage calme.)
Optimisation des images et chargement différé
Ce que fait le cœur : PrestaShop régénère les miniatures d’images (Apparence → Réglages des images), mais ne convertit pas en WebP et ne diffère pas les images hors écran par défaut sur les anciennes versions.
Conséquence : les images représentent généralement la plus grande part du poids d’une page ; des photos produit non optimisées sont donc la cause la plus fréquente d’une page mobile qui paraît lente. WebP réduit nettement la taille des fichiers par rapport au JPEG à qualité équivalente ; le chargement différé signifie qu’une page de catégorie avec 30 produits ne télécharge pas les 30 images alors que seules 6 sont visibles à l’écran. Orientation : fort impact, faible risque, faites-le. Recherchez une conversion WebP plus loading="lazy" avec solution de repli JS. Notre mprseoimageslazytags gère la partie chargement différé ; associez-le à une conversion WebP (communautaire ou payante) pour obtenir le bénéfice complet.
Transformer les visites en commandes : tunnel de commande & conversion
Un vrai tunnel de commande en une page
Ce que fait le cœur : depuis PrestaShop 1.7, le tunnel de commande se trouve sur une seule URL, mais se dévoile étape par étape : informations personnelles, puis adresses, puis livraison, puis paiement. Il n’est « en une page » qu’au sens d’une seule URL ; le client progresse toujours par étapes. L’ancien interrupteur de commande en une page de 1.6 a été supprimé et ne reviendra pas sous cette forme.
Conséquence : chaque étape est un moment où le client peut bloquer, et ceux qui veulent modifier une option de livraison ou une adresse après avoir vu le total ressentent le plus la friction. Un vrai tunnel de commande en une page affiche tout à l’écran, avec un total mis à jour en direct. Orientation : l’une des modifications au meilleur rendement sur la plupart des boutiques. Notre mprcheckoutrevolution transforme le flux natif par étapes en véritable commande sur une seule page, de 1.6 à 9, sans chirurgie du thème ni modification du cœur, et pour l’anatomie complète de ce qui fait convertir cette page (commande invitée, mobile, emplacement du coupon, portefeuilles express via mprexpresscheckout), consultez notre guide d’optimisation du tunnel de commande.
Avis et preuve sociale
Ce que fait le cœur : PrestaShop fournit un module basique de commentaires produit que vous pouvez activer, mais il ne propose pas les avis avec photo, les rappels d’avis ni l’import depuis des plateformes externes.
Conséquence : les avis jouent deux rôles à la fois : ils rassurent un acheteur hésitant et alimentent le schéma AggregateRating qui affiche les étoiles dans vos résultats de recherche. Orientation : activez les commentaires natifs tôt ; montez en gamme lorsque les avis deviennent un levier de vente. Notre mprcomments étend les avis natifs ; pour une confiance issue de Google, mprgooglereviews importe des notes vérifiées. Dans tous les cas, connectez-les à votre module de données structurées pour que les notes apparaissent réellement dans les SERP.
Savoir ce qui fonctionne : marketing & analytique
GA4, correctement configuré
Ce que fait le cœur : le module officiel Google Analytics de PrestaShop a historiquement pris du retard sur l’ensemble complet des événements e-commerce de GA4.
Conséquence : sans déclenchement correct de view_item, add_to_cart, begin_checkout et purchase, vos rapports de tunnel sont des estimations : vous ne pouvez pas savoir si vous perdez les visiteurs sur la page produit ou à l’étape de paiement. Orientation : essentiel, et il vaut mieux configurer correctement les événements que simplement coller une balise. Notre mprgoogleanalytics implémente le tunnel e-commerce complet de GA4 ; quel que soit votre choix, vérifiez que les événements se déclenchent bien dans DebugView de GA4 avant de faire confiance aux chiffres.
Un consentement cookies qui bloque vraiment les scripts
Ce que fait le cœur : le cœur de PrestaShop ne fournit pas par défaut de consentement cookies complet avec blocage des scripts ; il vous faut un module de consentement ou une intégration qui bloque les scripts non essentiels jusqu’au consentement. Une bannière seule ne satisfait pas le RGPD/ePrivacy : l’exigence est de bloquer les scripts de suivi jusqu’au consentement, pas seulement d’afficher une information.
Conséquence : pour toute boutique ayant des clients dans l’UE, c’est une obligation de conformité, pas un plus, et les modules qui se contentent d’afficher une bannière alors que GA4 s’est déjà déclenché vous exposent. Orientation : requis pour le trafic européen. Il vous faut des catégories granulaires (nécessaires / analytique / marketing), un vrai blocage des scripts avant consentement et un journal de consentement pour audit. Notre mprcookiesrevolution couvre correctement le consentement avec blocage des scripts.
Gérer la boutique : administration au quotidien
Édition du catalogue en masse
Ce que fait le cœur : l’import CSV de PrestaShop (Paramètres avancés → Import) existe, mais il gère difficilement les déclinaisons, traite les champs multilingues de façon peu commode et a longtemps eu tendance à expirer sur les gros fichiers.
Conséquence : modifier quelques milliers de prix ou de niveaux de stock produit par produit dans la grille d’administration, ce sont des heures que vous ne récupérerez jamais. Un bon éditeur en masse se rentabilise dès le premier mois d’un vrai catalogue. Orientation : essentiel au-delà de quelques centaines de références. Pour les changements de prix en masse spécifiquement, notre mprmasspriceupdate applique des règles à une sélection depuis le back-office ; pour un import/export plus large, cherchez un module qui gère les déclinaisons, le multilingue, les prix spécifiques et les données fournisseurs.
Améliorations du flux de traitement des commandes
Ce que fait le cœur : la page Commandes par défaut gère le cycle de vie de base, mais ne propose pas les changements de statut en masse, les notes réservées au personnel ni les modifications rapides après commande sans annuler et recréer.
Conséquence : à volume élevé, les petites limites dans le traitement des commandes deviennent une friction quotidienne pour la personne qui expédie vos colis. Orientation : ajoutez la fonction précise qui vous manque plutôt qu’un « gestionnaire de commandes » monolithique. Notre mprorderedit permet à l’équipe d’ajuster une commande existante, et mprorderworkflow automatise les transitions de statut ; installez celui qui correspond à votre vrai goulot d’étranglement.
Sauvegardes à la demande
Ce que fait le cœur : Paramètres avancés → Base de données → Gestionnaire SQL permet d’exporter la base, et il existe un outil de sauvegarde de base de données, mais c’est manuel et limité à la base.
Conséquence : la sauvegarde de votre hébergeur inclut ou non votre base PrestaShop, et restaurer depuis un instantané d’hébergement peut prendre des heures que vous n’avez pas en plein incident. Orientation : vérifiez ce que votre hébergeur sauvegarde ; ajoutez un module s’il y a un manque. Il vous faut les fichiers et la base de données, la planification, la possibilité d’exclure des répertoires qui changent rarement comme /img/, et du stockage hors site. Plusieurs modules de sauvegarde PrestaShop couvrent ce besoin.
Faites l’inventaire avant d’acheter : auditez ce qui est déjà installé
Avant d’acheter quoi que ce soit pour combler un manque, il vaut la peine de voir ce que vous avez déjà : modules à moitié installés, éléments laissés par un ancien développeur et éventuels fichiers de surcharge qui s’exécutent discrètement sur chaque page. Vous pouvez lire tout cela directement depuis la base de données avec quelques requêtes sûres et en lecture seule (exécutez-les dans Paramètres avancés → Gestionnaire SQL, ou dans n’importe quel client de base de données). Rien ici n’écrit la moindre ligne.
Listez chaque module installé et vérifiez s’il est réellement activé :
SELECT m.name, m.version, m.active
FROM ps_module m
ORDER BY m.active DESC, m.name;Et, parce que les conflits de surcharge sont la cause la plus courante d’une boutique qui casse « mystérieusement » après l’empilement de modules, listez les fichiers de surcharge effectivement présents sur le disque. Il n’existe pas de table de base de données pour cela, donc vérifiez le système de fichiers (en SSH ou via votre gestionnaire de fichiers) sous la racine de votre boutique :
# Every core class/controller a module has overridden
find override/ -name '*.php' -not -name 'index.php'Un résultat vide est le bon signe. Si deux modules surchargent la même classe, la collision classique sur Product, Cart ou Order, c’est par là qu’il faut commencer à chercher lorsque quelque chose cesse de fonctionner sans raison visible. Nous expliquons pourquoi les surcharges causent ce problème dans le vrai coût des modules gratuits.
« Combien de modules, c’est trop ? », la réponse courte
Chaque module ajoute des hooks, des requêtes et du CSS/JS ; l’instinct de garder une liste courte est donc juste. Mais le vrai mode de défaillance n’est pas le nombre, c’est la qualité : dix modules abandonnés et sujets aux conflits feront plus de dégâts que vingt modules bien construits et activement maintenus. La règle honnête consiste à installer pour une fonction que vous pouvez nommer et un besoin que vous pouvez mesurer, puis à tester l’impact sur le chargement des pages après chaque ajout. Nous avons développé l’argument complet, pourquoi un audit axé d’abord sur la qualité vaut mieux qu’un audit axé d’abord sur le nombre, dans pourquoi la qualité des modules compte davantage que leur quantité.
Gratuit ou payant : choisissez selon la conséquence d’une panne
Beaucoup de modules gratuits sont excellents et ont leur place dans cette liste. La bonne question n’est pas le prix, mais ce qui se passe si le module échoue ou n’est plus maintenu. Pour un bouton de retour en haut de page, un module gratuit qui casse se règle sans drame. Pour la surveillance de sécurité, votre plan de redirections ou votre tunnel de commande, un module abandonné est un risque réel : ce sont les fonctions pour lesquelles un module activement maintenu et accompagné justifie son coût. Nous avons détaillé toute l’économie du « gratuit », ce que vous échangez réellement, dans le vrai coût des modules gratuits, ainsi que les signaux de qualité à vérifier sur la place de marché avant d’acheter dans le guide d’achat de la place de marché Addons.
Tout ce qui figure sur cette page correspond à des modules que nous vendons, maintenons et gardons à jour, mais c’est parce que nous les avons construits pour combler des lacunes rencontrées sur de vraies boutiques, pas parce que chaque boutique a besoin de tous les installer. Partez des fonctions, pas de la marque. Couvrez d’abord la visibilité et la sécurité, parce que leurs échecs sont silencieux et coûteux ; ajoutez les performances et le tunnel de commande lorsque vous avez du trafic à convertir ; superposez les outils de gestion à mesure que votre catalogue et votre volume de commandes rendent la méthode manuelle pénible. Faites cela, et une installation PrestaShop nue devient une boutique rapide, sûre, visible et nettement moins susceptible de vous réveiller à 3 h du matin.
FAQ
Combien de ces modules une petite boutique doit-elle vraiment installer dès le premier jour ?
Moins que la liste ne le suggère. Une boutique de moins d’environ 500 produits avec un trafic léger peut se lancer avec le sitemap natif, la mise en cache du cœur (Paramètres avancés → Performance) et le module de commentaires produit inclus, puis ajouter le reste à mesure que le volume réel révèle les manques. Les deux que nous ne reporterions pas, quelle que soit la taille, sont un gestionnaire de redirections dès que votre catalogue commence à changer, et la sécurité du back-office dès que vous avez des comptes employés. Dans les deux cas parce que leurs échecs sont silencieux et coûteux à corriger.
Dois-je installer tout cela en une seule fois ?
Non. Chaque module est du code qui s’exécute au chargement des pages, et installer un paquet de modules d’un coup rend impossible l’identification de celui qui a ralenti votre boutique ou cassé un hook. Installez une fonction à la fois, comparez le chargement des pages avant et après (le profiler de débogage dans Paramètres avancés → Performance affiche le nombre de requêtes et le temps de rendu), et gardez ceux qui méritent leur place.
Ai-je encore besoin d’un module de sitemap séparé si j’utilise le gsitemap officiel ?
En dessous d’environ 1 000 produits, non : gsitemap est réellement suffisant et vous devriez éviter la mise à niveau. L’intérêt d’un module de sitemap dédié apparaît avec la taille : index produits/catégories/CMS séparés, entrées de sitemap d’images et prise en charge multilingue/multiboutique comptent davantage à mesure que le catalogue grandit, parce que c’est là que l’efficacité d’exploration commence à influencer la vitesse d’indexation des nouveaux produits.
Empiler une douzaine de modules va-t-il ralentir ma boutique ?
C’est possible, mais le nombre de modules n’est pas le bon indicateur : c’est leur qualité. Une douzaine de modules bien conçus et basés sur les hooks peut être plus légère que trois modules qui abusent des surcharges ou lancent des requêtes dans des boucles. Après chaque installation, jetez un œil au profiler de débogage pour repérer une hausse du nombre de requêtes ou du temps jusqu’au premier octet, et vérifiez override/ pour détecter les collisions. C’est la différence entre une boutique active et une boutique lente.
Vous vendez la plupart de ces modules : pourquoi faire confiance à ces recommandations ?
Question légitime, et la réponse honnête est de traiter chaque orientation « acheter » ci-dessus comme une recommandation centrée sur la fonction : nous décrivons ce que fait le cœur, où il atteint ses limites et ce qu’il faut chercher dans n’importe quel module qui comble le manque, le nôtre ou celui d’un concurrent de la place de marché. Lorsque le cœur fait déjà le travail (son cache, son import CSV pour les petites opérations, gsitemap sous 1 000 produits), nous le disons et nous vous conseillons de ne pas acheter. Le fait que nous vendions des modules et exploitions des boutiques avec eux explique pourquoi les manques de cette liste sont ceux qui nous ont réellement touchés en production.