Instant Redis

OPcache est une extension PHP qui met en cache le code PHP compilé en mémoire, de sorte que PHP n'a pas à le recompiler à chaque requête. Vous devriez absolument l'activer — cela peut améliorer les performances de PrestaShop de 30 à 50 % sans aucun inconvénient en production. La plupart des hébergeurs l'ont activé par défaut. Le paramètre important est opcache.validate_timestamps : à 1 en développement, mais de nombreux serveurs de production le mettent à 0 pour des performances maximales (ce qui signifie que vous devez réinitialiser manuellement OPcache après le déploiement de modifications de code).

See our full guide on PHP optimization

En général oui — le CCC combine plusieurs fichiers CSS en un seul et plusieurs fichiers JS en un seul, réduisant les requêtes HTTP et améliorant les temps de chargement. Cependant, le CCC peut causer des problèmes si le CSS/JS d'un module a des exigences spécifiques d'ordre de chargement ou utilise des attributs defer/async. Si vous activez le CCC et que quelque chose casse (généralement un problème visuel ou une erreur JS), vérifiez quels assets de module causent le problème et configurez ce module pour garder ses assets séparés.

Learn more about CSS/JS optimization

Gains de performance gratuits : (1) Activez OPcache dans PHP (impact massif, coût zéro). (2) Activez le Cache Smarty de PrestaShop et le CCC (Combine, Compress, Cache). (3) Désactivez les modules inutilisés — chaque module actif ajoute de la charge même s'il n'affiche rien de visible. (4) Optimisez vos images avant de les téléverser (utilisez tinypng.com ou similaire). (5) Activez le Cache de requêtes MySQL. (6) Assurez-vous de ne pas être en mode debug. Cela seul peut doubler la vitesse de vos pages.

See our real-world PageSpeed 99 case study

Désactiver entièrement le Cache rendra votre boutique sensiblement plus lente. Au lieu de cela, videz le Cache correctement : Paramètres avancés → Performance → Vider le cache. Si les problèmes persistent après le vidage : supprimez le contenu de /var/cache/prod/ et /var/cache/dev/ manuellement. Pour le Cache Smarty : vérifiez si "Forcer la compilation" est sur "Oui" (il devrait être sur "Non" en production). Si un module spécifique dysfonctionne avec le Cache, signalez-le au développeur du module — c'est un bug qui doit être corrigé.

Understand PrestaShop caching in depth

Utilisez les outils de développement de votre navigateur (F12 → onglet Réseau) pour identifier ce qui est lent. Causes courantes : (1) Un module chargeant des scripts externes lourds (polices, analytics, widgets de chat). (2) Un module effectuant des requêtes de base de données lentes — vérifiez la barre du Symfony profiler en mode debug. (3) Trop de modules enregistrés sur le même Hook (ex. : displayHeader). (4) OPcache désactivé sur le serveur. (5) Ressources d'hébergement saturées. Désactivez les modules un par un pour identifier le coupable.

See how we achieved PageSpeed 99 with 80+ modules

Les deux fonctionnent bien. PrestaShop supporte officiellement MySQL 5.7+ et MariaDB 10.x+. MariaDB est souvent légèrement plus rapide pour les charges de lecture intensive (ce que tendent à être les boutiques e-commerce). La plupart des hébergeurs proposent l'un ou l'autre. Si vous avez le choix, MariaDB 10.11 LTS est une option solide. La différence de performance est minimale pour la plupart des boutiques — concentrez-vous sur une indexation et une optimisation des requêtes appropriées plutôt que sur le choix du moteur de base de données.

Read about database optimization for PrestaShop

PrestaShop fonctionne bien avec 256 Mo de limite mémoire PHP pour la plupart des boutiques. Cependant, si vous avez de nombreux modules installés, de grands catalogues de produits ou effectuez des opérations d'import/export, vous pourriez avoir besoin de 512 Mo ou plus. Le serveur lui-même devrait avoir au moins 2 Go de RAM pour une petite boutique, 4 Go+ pour les boutiques moyennes avec le Cache activé. Ce sont des minimums — plus c'est toujours mieux.

Read our performance tuning recommendations

Allez dans Paramètres avancés → Performance et cliquez sur "Vider le cache". Cela vide les templates Smarty compilés et le Cache Symfony. Pour un nettoyage plus complet : supprimez également le contenu de /var/cache/ manuellement (les dossiers prod et dev). Si vous utilisez OPcache, vous devrez peut-être aussi redémarrer PHP-FPM ou Apache pour vider le cache d'opcode. Vider simplement le Cache PrestaShop ne vide pas OPcache.

Learn about caching strategies for PrestaShop

Fonctionnement des modèles d'e-mails PrestaShop

PrestaShop envoie des e-mails transactionnels à chaque moment clé du parcours client : création de compte, confirmation de commande, notification d'expédition, réinitialisation de mot de passe, et bien plus encore. Ces e-mails sont générés à partir de fichiers de modèles stockés sur votre serveur, et ils sont entièrement personnalisables. Comprendre le fonctionnement du système de modèles est la première étape pour créer des e-mails de confirmation de commande professionnels et fidèles à votre marque, qui renforcent l'identité de votre boutique.

Chaque e-mail PrestaShop se compose de deux fichiers de modèles : une version HTML pour les clients de messagerie qui prennent en charge le formatage enrichi, et une version texte brut (TXT) pour les clients de messagerie qui ne le prennent pas en charge. Les deux fichiers doivent exister pour qu'un e-mail soit envoyé correctement. La version HTML est celle que la grande majorité de vos clients verront. La version TXT sert de solution de repli et est également utilisée par les outils d'accessibilité et certains filtres de messagerie d'entreprise.

Les modèles d'e-mails se trouvent dans la structure de répertoires mails/. L'emplacement exact dépend de l'utilisation d'e-mails du noyau, d'e-mails remplacés par le thème ou d'e-mails spécifiques à un module. Comprendre cette hiérarchie est essentiel, car PrestaShop vérifie plusieurs emplacements pour chaque modèle et utilise le premier qu'il trouve.

La structure des répertoires des modèles d'e-mails

PrestaShop organise les modèles d'e-mails dans une hiérarchie de répertoires spécifique. Lorsqu'il doit envoyer un e-mail, le système recherche dans ces emplacements par ordre de priorité :

Surcharges au niveau du thème (Priorité la plus élevée)

Les modèles dans /themes/votre-theme/mails/fr/ (où fr est le code ISO de la langue) ont priorité sur tous les autres emplacements. Si vous souhaitez personnaliser un modèle d'e-mail sans modifier les fichiers du noyau, c'est ici que vos modèles personnalisés doivent être placés. Cette approche survit aux mises à jour de PrestaShop car les fichiers du thème ne sont pas écrasés lors des mises à jour du noyau.

Modèles du noyau (Par défaut)

Les modèles par défaut se trouvent dans /mails/fr/ dans le répertoire racine de votre PrestaShop. Ce sont les modèles livrés avec PrestaShop et utilisés lorsqu'aucune surcharge de thème n'existe. Modifier ces fichiers directement fonctionne, mais ce n'est pas recommandé car vos modifications seront perdues lors de la mise à jour de PrestaShop.

Modèles spécifiques aux modules

Les modules qui envoient leurs propres e-mails stockent les modèles dans /modules/nom-du-module/mails/fr/. Par exemple, les e-mails de notification de commande envoyés par les modules de paiement du noyau sont stockés dans leurs répertoires de modules respectifs. Vous pouvez les surcharger en plaçant des copies modifiées dans le répertoire mails/ de votre thème avec le même nom de fichier.

Sous-répertoires de langues

Chaque répertoire mails/ contient des sous-répertoires pour chaque langue installée, utilisant le code ISO de la langue : en pour l'anglais, fr pour le français, de pour l'allemand, et ainsi de suite. Lorsque PrestaShop envoie un e-mail, il utilise le modèle du répertoire correspondant à la préférence linguistique du client. Si un modèle n'existe pas dans la langue du client, PrestaShop se rabat sur la langue par défaut.

Anatomie d'un modèle de confirmation de commande

L'e-mail de confirmation de commande est l'e-mail transactionnel le plus important que votre boutique envoie. Il s'agit du fichier nommé order_conf.html (et de son compagnon order_conf.txt) dans votre répertoire mails. Examinons sa structure en détail.

Structure du modèle HTML

Les modèles d'e-mails PrestaShop sont des documents HTML autonomes. Ils n'utilisent pas de fichiers CSS externes car la plupart des clients de messagerie suppriment les feuilles de style externes. Tout le style doit être en CSS en ligne. Un modèle typique de confirmation de commande comprend ces sections :

Le document commence par un doctype HTML standard et une section head. Le corps contient une mise en page basée sur des tableaux (car les clients de messagerie ont un support médiocre des méthodes de mise en page CSS modernes comme flexbox et grid). À l'intérieur de cette mise en page, vous trouvez une section d'en-tête avec le logo de votre boutique, la zone de contenu principal avec les détails de la commande, un tableau de produits listant chaque article commandé, un résumé des prix avec sous-totaux et totaux, les informations d'expédition, les détails du mode de paiement et un pied de page avec les coordonnées de la boutique et les mentions légales.

Le système de variables

PrestaShop utilise un système simple de remplacement de variables dans les modèles d'e-mails. Les variables sont encadrées par des accolades : {nom_variable}. Lorsque l'e-mail est généré, PrestaShop remplace chaque variable par sa valeur réelle. Le modèle de confirmation de commande utilise ces variables clés :

{firstname} et {lastname} contiennent le nom du client. {order_name} est le numéro de référence de la commande (comme ABCDEF123). {shop_name} est le nom de votre boutique tel que configuré dans le back-office. {shop_url} est l'URL de votre boutique. {shop_logo} est le chemin vers l'image du logo de votre boutique. {date} est la date de la commande. {payment} est le mode de paiement utilisé. {total_paid} est le montant total payé. {delivery_company} et {delivery_address} contiennent les informations sur le transporteur et l'adresse de livraison.

Pour la liste des produits, PrestaShop utilise une syntaxe de bloc spéciale. La section des articles de produits est encapsulée dans une boucle qui se répète pour chaque produit de la commande : {items} contient le HTML préformaté pour l'ensemble du tableau de la liste des produits, y compris les noms des produits, les quantités, les prix et tous les détails de personnalisation.

Référence des variables disponibles

Pour voir toutes les variables disponibles pour un modèle d'e-mail spécifique, consultez le code PHP qui envoie l'e-mail. Pour la confirmation de commande, vérifiez la classe PaymentModule (dans /classes/PaymentModule.php). La méthode validateOrder() construit le tableau des variables du modèle. Chaque clé du tableau correspond à un nom de variable que vous pouvez utiliser dans le modèle.

Les variables couramment disponibles dans les e-mails de confirmation de commande incluent : {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} et {total_products}.

Personnaliser le modèle de confirmation de commande

Étape 1 : Créer une surcharge de thème

Ne modifiez jamais directement les fichiers de modèles du noyau. Copiez plutôt le modèle dans le répertoire mails de votre thème :

Copiez /mails/fr/order_conf.html vers /themes/votre-theme/mails/fr/order_conf.html. Faites de même pour order_conf.txt. Si le répertoire mails/fr/ n'existe pas dans votre thème, créez-le.

Si votre boutique prend en charge plusieurs langues, copiez les modèles pour chaque répertoire de langue. Votre confirmation de commande en allemand va dans /themes/votre-theme/mails/de/order_conf.html et ainsi de suite.

Étape 2 : Modifier la mise en page HTML

Ouvrez le modèle HTML dans un éditeur de texte (pas un éditeur visuel qui pourrait ajouter du code indésirable). Le HTML d'e-mail diffère du HTML web de plusieurs manières importantes :

Utilisez des tableaux pour la mise en page, pas des divs. Les clients de messagerie, en particulier Outlook, ont un support CSS très limité. Une mise en page à trois colonnes doit utiliser un <table> avec trois éléments <td>, pas des colonnes CSS ou flexbox.

Utilisez des styles en ligne sur chaque élément. Au lieu de <p class="heading"> avec une feuille de style séparée, utilisez <p style="font-size:18px; font-weight:bold; color:#333333;">. Chaque élément stylé a besoin de son propre attribut de style en ligne.

Définissez des largeurs explicites sur les tableaux et les cellules. Les clients de messagerie ne respectent pas toujours les largeurs en pourcentage. Utilisez une largeur fixe pour votre tableau de contenu principal (600 pixels est le standard) avec des colonnes internes en pourcentage.

Utilisez des polices web-safe. Tous les clients de messagerie ne prennent pas en charge les polices personnalisées. Restez avec Arial, Helvetica, Georgia, Times New Roman, Verdana ou Trebuchet MS. Vous pouvez essayer de charger une police personnalisée en solution de repli, mais spécifiez toujours une police web-safe comme dernier recours.

Étape 3 : Ajouter votre branding

Remplacez l'en-tête PrestaShop par défaut par le branding de votre boutique. Cela implique généralement la mise à jour du logo (la variable {shop_logo} utilise automatiquement le logo de votre boutique, mais vous pourriez vouloir une version spécifique pour les e-mails), le changement de la couleur d'arrière-plan de l'en-tête pour correspondre à votre marque, l'ajout de la palette de couleurs de votre marque aux titres et aux liens, et l'inclusion du slogan de votre boutique ou d'un bref message marketing.

Gardez la structure d'ensemble simple. Les designs d'e-mails trop complexes se cassent dans différents clients de messagerie. Une mise en page propre à colonne unique avec les couleurs et le logo de votre marque est plus efficace et plus fiable qu'un design élaboré à plusieurs colonnes.

Étape 4 : Personnaliser le tableau des produits

Le tableau de produits par défaut dans la confirmation de commande PrestaShop est fonctionnel mais basique. Vous pouvez l'améliorer en ajoutant des images de produits (utilisez des URLs absolues vers des images hébergées sur votre serveur, pas des chemins relatifs), en ajoutant des liens vers les pages produits pour que les clients puissent facilement recommander ou laisser des avis, en ajoutant des champs personnalisés comme les dates de livraison estimées ou des messages personnalisés, et en ajustant le style du tableau pour correspondre à votre marque.

Lorsque vous ajoutez des images de produits, gardez-les petites (50 à 80 pixels de large) et incluez toujours un attribut alt. Certains clients de messagerie bloquent les images par défaut, et le texte alt permet aux clients d'identifier quand même leurs produits.

Ajouter des champs personnalisés aux e-mails de commande

Les variables par défaut de PrestaShop couvrent les informations standard de commande, mais vous pourriez vouloir inclure des données supplémentaires comme les points de fidélité gagnés, la date de livraison estimée, un message de remerciement personnalisé ou des recommandations de produits en vente croisée.

Ajouter des variables via un module

La manière la plus propre d'ajouter des variables personnalisées est via un module qui se connecte au processus d'envoi d'e-mails. Créez un module qui enregistre le hook actionEmailSendBefore (disponible à partir de PrestaShop 1.7.6) ou le hook actionGetExtraMailTemplateVars. Dans votre gestionnaire de hook, ajoutez vos variables personnalisées au tableau des variables du modèle :

Votre fonction de hook reçoit le tableau des variables du modèle par référence. Vous pouvez ajouter de nouvelles variables à ce tableau, et elles deviennent disponibles dans le modèle en utilisant la syntaxe standard {nom_variable}. Par exemple, après avoir ajouté loyalty_points au tableau dans votre hook, vous pouvez utiliser {loyalty_points} dans votre modèle HTML de confirmation de commande.

Utiliser les données existantes de la base de données

Vous pouvez intégrer n'importe quelles données de votre base de données PrestaShop dans les variables d'e-mail. Les exemples courants incluent le nombre total de commandes du client (pour afficher "Merci pour votre 5e commande !"), le solde de points de fidélité du client, les champs de produits personnalisés stockés dans les caractéristiques ou attributs de produits, et les informations sur l'entrepôt ou le fournisseur pour les produits commandés.

Configuration des e-mails multilingues

Si votre boutique sert des clients dans plusieurs langues, chaque modèle d'e-mail a besoin d'une version pour chaque langue. PrestaShop gère automatiquement la sélection de la langue en fonction de la préférence linguistique du client, mais vous devez fournir les modèles.

Créer des modèles spécifiques à chaque langue

Pour chaque langue prise en charge par votre boutique, créez un répertoire dans le dossier mails de votre thème : /themes/votre-theme/mails/en/, /themes/votre-theme/mails/fr/, /themes/votre-theme/mails/de/, et ainsi de suite. Copiez et traduisez chaque fichier de modèle dans le répertoire approprié.

N'utilisez pas la traduction automatique pour les e-mails transactionnels. Ces e-mails représentent la communication de votre boutique avec les clients, et des traductions médiocres nuisent à la confiance. Faites rédiger ou relire chaque version linguistique par un locuteur natif.

Support des langues de droite à gauche

Si vous prenez en charge des langues comme l'arabe ou l'hébreu, vos modèles d'e-mails ont besoin d'un support de mise en page RTL (droite à gauche). Ajoutez dir="rtl" à l'élément de tableau principal et ajustez l'alignement du texte et les marges intérieures dans vos styles en ligne. Créez des modèles séparés pour les langues RTL plutôt que d'essayer de faire fonctionner un seul modèle dans les deux directions.

Formatage des dates et des devises

PrestaShop formate automatiquement les valeurs de dates et de devises selon les paramètres de langue et de devise du client. Les valeurs {date}, {total_paid} et les autres valeurs formatées reflètent déjà les paramètres régionaux corrects. Cependant, si vous ajoutez des variables personnalisées avec des valeurs de date ou de devise, assurez-vous de les formater correctement pour la langue cible.

Configuration SMTP pour une livraison fiable

Le plus beau modèle d'e-mail du monde est inutile si vos e-mails n'atteignent pas la boîte de réception. La configuration d'e-mail par défaut de PrestaShop utilise la fonction mail() intégrée de PHP, qui est peu fiable pour les e-mails transactionnels. La plupart de ces e-mails finissent dans le dossier spam ou sont entièrement rejetés par les fournisseurs de messagerie modernes.

Pourquoi le SMTP est important

Le SMTP (Simple Mail Transfer Protocol) avec une authentification appropriée est essentiel pour la délivrabilité des e-mails. Lorsque vous envoyez des e-mails via la fonction mail() de PHP, l'e-mail provient de l'adresse IP de votre serveur web sans aucune authentification. Les fournisseurs de messagerie comme Gmail, Outlook et Yahoo considèrent cela comme un signal d'alerte et classent souvent ces e-mails comme spam.

Avec le SMTP, vos e-mails sont envoyés via un serveur de messagerie authentifié avec des enregistrements SPF, DKIM et DMARC appropriés. Cela prouve aux serveurs de messagerie récepteurs que l'e-mail est légitime et autorisé par votre domaine.

Configurer le SMTP dans PrestaShop

Allez dans Paramètres avancés > E-mail dans votre back-office PrestaShop. Changez la méthode de "Utiliser la fonction mail() de PHP" à "Définir mes propres paramètres SMTP". Entrez les détails de votre serveur SMTP : l'adresse du serveur, le port (typiquement 587 pour TLS ou 465 pour SSL), le type de chiffrement, le nom d'utilisateur et le mot de passe.

Les fournisseurs SMTP courants pour PrestaShop incluent Gmail SMTP (smtp.gmail.com, port 587, TLS, nécessite un mot de passe d'application si la 2FA est activée), Amazon SES (abordable pour les grands volumes), SendGrid (niveau gratuit généreux), Mailgun (convivial pour les développeurs avec une bonne journalisation) et le serveur SMTP de votre hébergeur (vérifiez auprès de votre hébergeur pour les paramètres).

Tester la configuration SMTP

Après avoir configuré le SMTP, utilisez le bouton "Envoyer un e-mail de test" en bas de la page de configuration des e-mails. Entrez votre propre adresse e-mail et vérifiez que l'e-mail de test arrive dans votre boîte de réception (pas dans le spam). Si l'e-mail de test échoue, vérifiez vos identifiants SMTP, assurez-vous que votre serveur peut atteindre le serveur SMTP sur le port configuré (certains hébergeurs bloquent les ports sortants 25 et 587) et vérifiez si votre fournisseur SMTP nécessite des paramètres de sécurité spécifiques.

Enregistrements SPF, DKIM et DMARC

Pour une délivrabilité maximale, configurez ces enregistrements DNS pour votre domaine. SPF (Sender Policy Framework) spécifie quels serveurs sont autorisés à envoyer des e-mails au nom de votre domaine. DKIM (DomainKeys Identified Mail) ajoute une signature numérique à vos e-mails qui prouve qu'ils ont été envoyés par votre domaine. DMARC (Domain-based Message Authentication, Reporting, and Conformance) indique aux serveurs récepteurs quoi faire des e-mails qui échouent aux vérifications SPF ou DKIM.

Votre fournisseur SMTP vous donnera les enregistrements DNS spécifiques à ajouter. Par exemple, si vous utilisez SendGrid, ils fournissent les enregistrements SPF et DKIM pendant le processus d'authentification du domaine. Ajoutez-les comme enregistrements TXT dans les paramètres DNS de votre domaine.

Tester les modèles d'e-mails

Envoyer des e-mails de test

PrestaShop ne dispose pas d'un moyen intégré pour prévisualiser des modèles d'e-mails spécifiques. Pour tester votre modèle de confirmation de commande, vous devez passer une vraie commande de test. Créez un compte client de test, ajoutez des produits au panier et terminez le processus de commande avec une méthode de paiement de test. Si vous avez un module de paiement en mode sandbox configuré, utilisez-le. Sinon, les méthodes de paiement par virement bancaire ou par chèque vous permettent de finaliser une commande sans traitement de paiement réel.

Tests sur différents clients de messagerie

Le rendu des e-mails varie considérablement entre les clients de messagerie. Ce qui est parfait dans Gmail peut être cassé dans Outlook. Au minimum, testez vos modèles dans Gmail (web), Outlook (bureau et web), Apple Mail, Yahoo Mail et au moins une application de messagerie mobile. Des services comme Litmus ou Email on Acid automatisent ces tests en rendant votre e-mail dans des dizaines de clients de messagerie simultanément, mais ce sont des services payants.

Problèmes de rendu courants

Si votre e-mail est cassé dans Outlook, c'est presque certainement un problème de CSS. Outlook utilise le moteur de rendu de Microsoft Word pour les e-mails HTML, qui a un support CSS extrêmement limité. Il ne prend pas en charge les images d'arrière-plan sur les cellules de tableau (utilisez des couleurs d'arrière-plan à la place), le padding sur les éléments de bloc (utilisez le padding des cellules de tableau), max-width (utilisez des largeurs fixes), margin pour le centrage (utilisez align="center" sur les tableaux) et les floats CSS.

Pour la réactivité mobile, encapsulez votre tableau de contenu dans un conteneur avec max-width:600px et ajoutez une media query dans le bloc de style du head (que certains clients de messagerie prennent en charge) qui définit les largeurs de tableau à 100% sur les petits écrans. Ce n'est pas un design responsive parfait, mais cela empêche le défilement horizontal sur la plupart des appareils mobiles.

Problèmes courants et dépannage

Images manquantes dans les e-mails

C'est le problème de modèle d'e-mail le plus courant. Les images dans les e-mails doivent utiliser des URLs absolues (commençant par https://), pas des chemins relatifs. Si votre modèle fait référence à /img/logo.png, changez-le en https://www.votredomaine.com/img/logo.png. La variable {shop_logo} génère automatiquement une URL absolue, mais toutes les images que vous ajoutez manuellement doivent utiliser des URLs complètes.

Vérifiez également que vos images sont accessibles depuis l'extérieur de votre réseau. Si votre boutique est derrière un pare-feu ou une authentification HTTP, les clients de messagerie ne peuvent pas charger les images. Testez en ouvrant l'URL de l'image dans une fenêtre de navigateur privée/incognito.

Mise en page cassée après modification

Le HTML d'e-mail est fragile. Une seule balise non fermée ou une cellule de tableau manquante peut casser l'ensemble de la mise en page. Validez toujours votre HTML après modification. Comptez vos balises ouvrantes et fermantes table, tr et td. Chaque <table> a besoin d'un </table>, chaque <tr> a besoin d'un </tr> et chaque <td> a besoin d'un </td>. Vérifiez que chaque ligne d'un tableau a le même nombre de cellules (ou utilise colspan pour compenser la différence).

Variables non remplacées

Si vous voyez le texte littéral {nom_variable} dans vos e-mails envoyés au lieu des valeurs réelles, vérifiez le nom de la variable pour les fautes de frappe. Les noms de variables sont sensibles à la casse. Vérifiez également que la variable existe pour le type spécifique d'e-mail que vous personnalisez. Toutes les variables ne sont pas disponibles dans tous les modèles d'e-mails. Les variables spécifiques aux commandes comme {order_name} ne sont disponibles que dans les e-mails liés aux commandes.

Les e-mails ne sont pas envoyés du tout

Si les e-mails ne sont pas envoyés, vérifiez le back-office PrestaShop sous Paramètres avancés > E-mail. Vous pouvez y voir un journal des e-mails envoyés. Si le journal montre des échecs, vérifiez votre configuration SMTP. Si aucun e-mail n'apparaît dans le journal, l'e-mail n'est peut-être pas déclenché du tout. Vérifiez que vos transitions de statut de commande sont configurées pour envoyer des e-mails au client (Commandes > Statuts > modifier le statut > cocher "Envoyer un e-mail au client").

Vérifiez également le journal d'erreurs PHP de votre serveur pour les erreurs liées aux e-mails. Les problèmes courants incluent la fonction mail() de PHP désactivée par l'hébergeur, les échecs d'authentification SMTP dus à des mots de passe modifiés et les problèmes de connectivité réseau entre votre serveur et le serveur SMTP.

Les e-mails arrivent dans le spam

Même avec une configuration SMTP correcte, les e-mails peuvent toujours atterrir dans le spam. Les raisons les plus courantes sont des enregistrements SPF/DKIM/DMARC manquants ou incorrects, un contenu d'e-mail qui déclenche les filtres anti-spam (utilisation excessive de majuscules, mots déclencheurs de spam comme "gratuit" ou "agissez maintenant", trop d'images avec peu de texte), l'envoi depuis une adresse IP avec une mauvaise réputation (courant avec l'hébergement mutualisé) et l'adresse e-mail "de" dont le domaine ne correspond pas au domaine du serveur SMTP.

Corrigez d'abord les enregistrements DNS, puis examinez le contenu de vos e-mails. Utilisez un outil comme mail-tester.com pour analyser vos e-mails à la recherche de déclencheurs de spam. Envoyez un e-mail de test à l'adresse qu'ils fournissent, et ils renvoient un rapport détaillé montrant ce qui pourrait causer la classification en spam.

Surcharges d'e-mails spécifiques au thème

Certains thèmes PrestaShop incluent leurs propres modèles d'e-mails qui correspondent au design du thème. Si votre thème a des modèles dans /themes/votre-theme/mails/, ceux-ci remplacent automatiquement les modèles du noyau.

Vérifier les modèles d'e-mails du thème

Cherchez dans le répertoire de votre thème actif un dossier mails. S'il existe, le thème fournit des modèles d'e-mails personnalisés. Ces modèles correspondent généralement à la palette de couleurs et au design de l'en-tête/pied de page du thème, donnant à vos e-mails une cohérence visuelle avec votre vitrine.

Personnaliser les modèles d'e-mails du thème

Si votre thème fournit des modèles d'e-mails, modifiez ceux-ci plutôt que de copier depuis le répertoire mails/ du noyau. Les modèles du thème peuvent utiliser une structure HTML différente ou inclure du CSS supplémentaire spécifique au système de design du thème. Partir de la version du thème assure la cohérence visuelle.

Garder les modèles synchronisés avec les mises à jour du thème

Lorsque vous mettez à jour votre thème, vérifiez si la mise à jour inclut des modifications des modèles d'e-mails. Si c'est le cas, vos personnalisations pourraient être écrasées. Avant la mise à jour, sauvegardez vos modèles personnalisés. Après la mise à jour, comparez les nouveaux modèles avec vos sauvegardes et réappliquez vos personnalisations aux versions mises à jour. C'est fastidieux mais nécessaire pour maintenir à la fois vos personnalisations et les améliorations ou corrections que le développeur du thème a apportées.

Bonnes pratiques pour les e-mails de confirmation de commande

Un e-mail de confirmation de commande bien conçu fait plus que confirmer la transaction. Il instaure la confiance, réduit les demandes au support et crée des opportunités d'engagement.

Incluez un numéro de référence de commande clair et bien visible en haut. Les clients ont besoin de ce numéro lorsqu'ils contactent le support ou suivent leur commande. Listez chaque produit avec son nom, sa quantité, son prix et toutes les options ou personnalisations. Incluez le détail complet du sous-total, des frais de livraison, des taxes, des remises et du total. Affichez l'adresse de livraison pour que les clients puissent la vérifier et vous contacter immédiatement si elle est incorrecte. Indiquez le mode de paiement utilisé et tous les détails de transaction pertinents. Fournissez un lien vers la page de suivi de commande ou l'historique des commandes du client dans son compte. Ajoutez vos coordonnées de service client pour que les clients sachent comment vous joindre en cas de problème.

Gardez le design épuré et adapté aux mobiles. Plus de la moitié de tous les e-mails sont lus sur des appareils mobiles. Utilisez une mise en page à colonne unique, un texte lisible de grande taille (minimum 14px pour le corps du texte) et des boutons avec des zones tactiles suffisantes (minimum 44px de hauteur). Votre e-mail de confirmation de commande est le reflet du professionnalisme de votre boutique. Investissez le temps nécessaire pour le réussir.

Pourquoi les audits techniques reguliers sont importants

Les boutiques PrestaShop se degradent avec le temps. Des modules sont installes et oublies. Les versions de PHP prennent du retard. Les journaux d'erreurs se remplissent d'avertissements que personne ne lit. Les tables de la base de donnees se gonflent avec les donnees de paniers abandonnes et les sessions expirees. Les correctifs de securite ne sont pas appliques. Chacun de ces problemes est petit en soi, mais ensemble ils s'accumulent pour engendrer des chargements de page lents, des vulnerabilites de securite, et finalement des temps d'arret ou des pertes de donnees.

Le probleme est que la plupart des proprietaires de boutiques ne decouvrent ces problemes que lorsque quelque chose casse. Un client se plaint d'un checkout lent. Google fait chuter vos classements parce que votre site echoue aux Core Web Vitals. Ou pire, vous decouvrez que votre panneau d'administration a ete compromis parce que vous n'avez jamais change le chemin admin par defaut et que votre version PHP avait une vulnerabilite connue.

Un audit technique de 30 minutes, effectue mensuellement, previent tout cela. Ce n'est pas un examen approfondi de chaque parametre de configuration. C'est une checklist ciblee qui detecte les problemes les plus courants et les plus dangereux avant qu'ils ne deviennent des urgences. Ce guide vous accompagne a travers chaque verification avec des estimations de temps approximatives, vous donnant un processus repetable que vous pouvez suivre chaque mois.

Verification 1 : version et configuration PHP (3 minutes)

PHP est le moteur qui fait tourner PrestaShop, et utiliser une version obsolete est a la fois un risque de performance et de securite. Les versions PHP recoivent un support actif pendant deux ans et des correctifs de securite pendant une annee supplementaire. Apres cela, les vulnerabilites connues restent sans correctif.

Verifier votre version PHP

Allez dans votre back office PrestaShop et naviguez vers Parametres avances > Informations. La version PHP est listee dans la section Informations du serveur. Vous pouvez egalement la verifier dans votre panneau de controle d'hebergement (cPanel, Plesk ou similaire).

En 2026, les versions PHP activement supportees sont 8.2, 8.3 et 8.4. Si vous utilisez PHP 8.1 ou une version anterieure, la mise a niveau devrait etre une priorite. PrestaShop 8.x necessite PHP 7.2 ou superieur mais fonctionne nettement mieux avec PHP 8.1 et versions superieures. PrestaShop 1.7.x supporte PHP 7.1 a 8.1, selon la version specifique.

Parametres PHP cles a verifier

Sur la page d'informations, verifiez ces valeurs de configuration PHP :

memory_limit devrait etre d'au moins 256M pour PrestaShop. S'il est inferieur, vous pourriez rencontrer des pages blanches ou des operations incompletes lors de la gestion de grands catalogues ou de la generation de rapports.

max_execution_time devrait etre d'au moins 300 (5 minutes). Des valeurs inferieures peuvent causer des timeouts lors des operations d'import, des reconstructions de cache et des installations de modules.

upload_max_filesize et post_max_size devraient etre d'au moins 16M, ou plus si vous telechargez regulierement de grandes images de produits ou des fichiers d'import.

OPcache devrait etre active. OPcache stocke le code PHP compile en memoire, reduisant dramatiquement les temps de chargement des pages. S'il est desactive, votre boutique fonctionne nettement plus lentement qu'elle ne le pourrait.

Verification 2 : examen du journal d'erreurs (4 minutes)

Les journaux d'erreurs vous indiquent ce qui casse en coulisses, meme lorsque le frontend semble fonctionner normalement. Les avertissements et les notices qui ne font pas planter la page indiquent neanmoins des problemes qui gaspillent les ressources du serveur et peuvent s'aggraver en pannes reelles.

Journaux PrestaShop

Dans le back office, allez a Parametres avances > Journaux. Triez par date (les plus recents en premier) et parcourez les entrees de la derniere semaine. Concentrez-vous sur les messages de Severite 3 (Erreur) et Severite 4 (Critique). Les erreurs critiques courantes incluent les echecs de connexion a la base de donnees, les erreurs de permissions de fichiers, les exceptions de modules et les erreurs de traitement de paiement.

Si vous voyez des erreurs repetees provenant du meme module, ce module a un bug qui necessite attention. Si vous voyez des erreurs de base de donnees, votre serveur de base de donnees peut etre a court de connexions ou d'espace disque.

Journal d'erreurs PHP

L'emplacement du journal d'erreurs PHP depend de votre environnement d'hebergement. Les emplacements courants incluent /var/log/php/error.log, /var/log/apache2/error.log, ou un chemin specifie dans votre panneau de controle d'hebergement. Verifiez les 100 dernieres lignes pour les erreurs fatales, les avertissements et les avis de depreciation.

Les avis de depreciation sont particulierement importants a suivre. Ils vous avertissent qu'une fonction ou une fonctionnalite utilisee par votre code sera supprimee dans une future version de PHP. Les corriger maintenant empeche votre boutique de casser lors de la mise a niveau de PHP.

Que faire avec les erreurs

N'essayez pas de corriger chaque erreur pendant l'audit. L'audit sert a l'identification. Creez une liste des erreurs les plus critiques et les plus frequentes, priorisees par severite. Les erreurs fatales et critiques necessitent une attention immediate. Les avertissements devraient etre traites dans le mois. Les notices et les avertissements de depreciation peuvent etre programmes pour votre prochaine fenetre de maintenance.

Verification 3 : audit des modules (5 minutes)

Les modules sont la source la plus courante de vulnerabilites de securite, de problemes de performance et de problemes de compatibilite dans PrestaShop. Un audit rapide des modules identifie le poids mort et les risques potentiels.

Identifier les modules inutilises

Allez a Modules > Gestionnaire de modules. Cherchez les modules qui sont installes mais desactives. Ces modules ont toujours des fichiers sur votre serveur et potentiellement des tables de base de donnees, mais ils ne servent a rien. Ils augmentent votre surface d'attaque (une vulnerabilite dans les fichiers d'un module desactive peut toujours etre exploitee) et ralentissent les sauvegardes.

Pour chaque module desactive, decidez si vous l'utiliserez a nouveau. Si non, desinstallez-le completement (pas seulement desactiver). La desinstallation supprime les tables de base de donnees et la configuration du module. Apres la desinstallation, supprimez egalement le repertoire du module de /modules/ pour retirer completement ses fichiers du serveur.

Verifier les mises a jour

Dans le Gestionnaire de modules, cherchez les modules avec des mises a jour disponibles. Les modules obsoletes sont un vecteur principal pour les exploits de securite. Les notifications de mise a jour apparaissent sous forme de badges dans la liste des modules. Priorisez les mises a jour pour les modules qui traitent des donnees sensibles : les modules de paiement, les modules de compte client et tout module qui traite des formulaires.

Avant de mettre a jour un module, consultez le changelog pour comprendre ce qui a change. Si la mise a jour inclut des correctifs de securite, appliquez-la immediatement. S'il s'agit d'une mise a jour de fonctionnalites, testez-la d'abord dans un environnement de staging si possible.

Compter le nombre total de modules

Verifiez combien de modules sont installes au total. PrestaShop est livre par defaut avec de nombreux modules, et les boutiques en accumulent d'autres au fil du temps. Chaque module actif ajoute des hooks qui s'executent a chaque chargement de page, augmentant le temps de reponse. Si vous avez plus de 80 a 100 modules actifs, passez la liste en revue de maniere critique. De nombreux modules PrestaShop par defaut (comme les boutons de partage social, la notice de confidentialite et les modules de statistiques) peuvent etre desactives si vous ne les utilisez pas, resultant en une amelioration mesurable des performances.

Verification 4 : sante de la base de donnees (4 minutes)

Votre base de donnees PrestaShop croit continuellement. Chaque visite client cree des donnees de session. Chaque panier abandonne reste dans la base de donnees. Chaque entree de journal s'accumule. Sur des mois et des annees, ce gonflement ralentit les requetes et augmente les temps de sauvegarde.

Verifier la taille de la base de donnees

Dans votre panneau de controle d'hebergement (cPanel > phpMyAdmin, par exemple), verifiez la taille totale de la base de donnees. Une base de donnees PrestaShop saine pour une petite ou moyenne boutique (moins de 10 000 produits) devrait etre inferieure a 500 Mo. Si la votre est significativement plus grande, le gonflement des donnees en est probablement la cause.

Identifier les grandes tables

Dans phpMyAdmin, cliquez sur votre base de donnees et triez les tables par taille. Les suspects habituels de gonflement sont : ps_connections et ps_connections_page (donnees de suivi des visiteurs qui peuvent atteindre des gigaoctets), ps_log (table de journal interne de PrestaShop), ps_mail (historique des e-mails), ps_cart et ps_cart_product (donnees de paniers abandonnes), ps_guest (enregistrements de visiteurs anonymes) et ps_pagenotfound (suivi des erreurs 404).

Ces tables peuvent etre nettoyees des anciennes donnees en toute securite. Par exemple, vous n'avez pas besoin de donnees de connexion datant de deux ans. PrestaShop dispose d'une fonctionnalite integree pour nettoyer certaines de ces tables : allez dans Parametres avances > Administration et cherchez les options de nettoyage des donnees. Pour un nettoyage plus approfondi, le module gratuit PrestaShop Cleaner peut purger les anciennes donnees statistiques, les paniers abandonnes et les sessions expirees.

Verifier les index manquants

Pendant que vous etes dans phpMyAdmin, verifiez la structure de vos tables les plus importantes (ps_product, ps_category_product, ps_stock_available) et confirmez que des index existent sur les colonnes utilisees dans la recherche et le filtrage. Les index manquants causent des requetes lentes qui affectent les temps de chargement des pages. Cependant, n'ajoutez pas d'index sans comprendre les compromis, car chaque index ralentit legerement les operations d'ecriture.

Verification 5 : fondamentaux de securite (5 minutes)

Les vulnerabilites de securite dans les boutiques PrestaShop sont activement exploitees. Des scanners automatises sondent continuellement Internet a la recherche d'installations vulnerables. Cinq minutes de verifications de securite peuvent prevenir une breche catastrophique.

URL du panneau d'administration

Votre panneau d'administration ne devrait pas etre accessible a une URL previsible comme /admin/ ou /backoffice/. PrestaShop genere un nom de repertoire admin aleatoire lors de l'installation (comme /admin738xyz/). Verifiez que votre URL admin est toujours aleatoire en verifiant le nom du repertoire admin sur votre serveur. Si quelqu'un l'a renomme en quelque chose de devinable, renommez-le en une chaine aleatoire.

Certificat SSL

L'ensemble de votre boutique doit fonctionner en HTTPS. Verifiez en visitant l'URL de votre boutique avec http:// et en confirmant qu'elle redirige vers https://. Dans le back office, allez dans Parametres de la boutique > General et verifiez que "Activer le SSL" et "Activer le SSL sur toutes les pages" sont tous deux sur Oui.

Verifiez egalement la date d'expiration de votre certificat SSL. Les certificats Let's Encrypt expirent tous les 90 jours et devraient se renouveler automatiquement, mais le renouvellement automatique echoue silencieusement plus souvent qu'on ne le penserait. Cliquez sur l'icone de cadenas dans la barre d'adresse de votre navigateur pour voir les details du certificat et la date d'expiration. S'il expire dans les 30 prochains jours, verifiez que le renouvellement automatique est configure et fonctionne.

Permissions de fichiers

Des permissions de fichiers incorrectes sont un risque de securite. Sur les serveurs Linux, vos fichiers PrestaShop devraient generalement appartenir a l'utilisateur du serveur web (typiquement www-data ou apache) et avoir ces permissions : les repertoires a 755 (le proprietaire peut lire/ecrire/executer, les autres peuvent lire/executer), les fichiers a 644 (le proprietaire peut lire/ecrire, les autres peuvent lire), et les fichiers de configuration comme config/settings.inc.php ou app/config/parameters.php a 640 ou 440 (acces en lecture restreint).

Verifiez quelques fichiers critiques pour vous assurer que les permissions ne sont pas trop ouvertes. Aucun fichier ne devrait etre en 777 (accessible en ecriture par tous). Si vous trouvez des permissions 777, corrigez-les immediatement. Elles permettent a tout utilisateur du serveur de modifier ces fichiers.

Mode debug

Verifiez que le mode debug est desactive sur votre boutique de production. Le mode debug expose aux visiteurs des messages d'erreur detailles, des chemins de fichiers et des requetes de base de donnees, ce qui constitue des informations precieuses pour les attaquants. Verifiez le fichier /config/defines.inc.php et assurez-vous que _PS_MODE_DEV_ est defini a false. Dans PrestaShop 8.x, verifiez egalement le fichier .env pour le parametre APP_DEBUG.

Vulnerabilites connues

Verifiez si votre version PrestaShop a des vulnerabilites de securite connues. Visitez la page des avis de securite PrestaShop et comparez les versions listees avec la votre. Si votre version est affectee par un avis que vous n'avez pas corrige, priorisez l'application du correctif.

Verification 6 : test de performance rapide (4 minutes)

La performance affecte directement les taux de conversion. Chaque seconde supplementaire de temps de chargement de page reduit les conversions de maniere mesurable. Un test de performance rapide identifie les goulots d'etranglement majeurs.

Executer un audit Lighthouse

Ouvrez Google Chrome, naviguez vers la page d'accueil de votre boutique, ouvrez les Chrome DevTools (F12) et cliquez sur l'onglet Lighthouse. Executez un audit pour Performance, Bonnes Pratiques et SEO sur un appareil Mobile. Le test prend environ 30 secondes.

Concentrez-vous sur le score de Performance. Un score inferieur a 50 indique de serieux problemes de performance. Entre 50 et 89 signifie qu'il y a de la marge pour l'amelioration. Au-dessus de 90 est bon. Le rapport d'audit montre les problemes specifiques et des estimations de combien de temps chaque correction permettrait d'economiser.

Metriques cles a verifier

Dans le rapport Lighthouse, pretez attention au Largest Contentful Paint (LCP), qui mesure le temps necessaire pour que le contenu principal apparaisse. Il devrait etre inferieur a 2,5 secondes. First Input Delay (FID) ou Interaction to Next Paint (INP) mesure la reactivite. Il devrait etre inferieur a 200 millisecondes. Cumulative Layout Shift (CLS) mesure la stabilite visuelle. Il devrait etre inferieur a 0,1.

Si le LCP est eleve, les causes les plus courantes dans PrestaShop sont des images non optimisees (grandes images de produits servies sans compression ni dimensionnement adequat), un temps de reponse serveur lent (verifiez votre plan d'hebergement et les performances de la base de donnees), du CSS et JavaScript bloquant le rendu (desactivez les modules inutiles qui ajoutent leurs assets sur chaque page), et un cache desactive (le cache Smarty et le CCC devraient etre actives en production).

Verifier la configuration du cache

Dans le back office, allez dans Parametres avances > Performances. Verifiez ces parametres : le cache Smarty devrait etre sur Oui avec le type de cache sur "Fichier". Le CCC (Combiner, Compresser, Cache) devrait avoir la minification et la combinaison CSS et JavaScript activees. La compilation des templates devrait etre sur "Recompiler les templates si les fichiers ont ete mis a jour" (pas "Forcer la compilation" qui est reserve au developpement).

Si l'un de ces parametres est mal configure, le corriger procure une amelioration de performance immediate et perceptible.

Verification 7 : fondamentaux SEO (3 minutes)

Les problemes techniques de SEO empechent les moteurs de recherche de crawler et d'indexer correctement votre boutique. Quelques verifications rapides detectent les problemes les plus impactants.

Robots.txt

Visitez votredomaine.fr/robots.txt dans votre navigateur. Verifiez qu'il existe et contient des regles sensees. PrestaShop genere automatiquement un fichier robots.txt. Verifiez qu'il ne bloque pas les pages importantes. Vos pages produit, pages de categories et pages CMS ne devraient pas etre interdites. Les erreurs courantes incluent le blocage de toutes les URLs avec parametres (ce qui bloque les pages de categories filtrees et les resultats de recherche) et le blocage du repertoire /modules/ (ce qui peut empecher le chargement du CSS et du JavaScript par les moteurs de rendu des moteurs de recherche).

Verifiez egalement que le robots.txt inclut une directive sitemap pointant vers votre sitemap XML : Sitemap: https://www.votredomaine.fr/1_index_sitemap.xml.

Sitemap XML

Visitez l'URL du sitemap listee dans votre robots.txt. Verifiez qu'elle se charge, qu'elle est recente (verifiez les dates de derniere modification) et qu'elle contient vos pages importantes. Si le sitemap est obsolete ou vide, regenerez-le. Si vous utilisez le generateur de sitemap integre de PrestaShop, allez dans Modules > Gestionnaire de modules, trouvez le module Google Sitemap et cliquez sur Configurer pour le regenerer.

Verifiez le nombre d'URLs dans le sitemap par rapport a votre compte attendu. Si vous avez 1 000 produits mais que le sitemap ne liste que 200 URLs, quelque chose ne va pas avec le processus de generation. Les causes courantes incluent des produits desactives ou en rupture de stock exclus du sitemap, des parametres de visibilite de categorie filtrant les produits, et le processus de generation du sitemap qui expire avant de se terminer.

URLs canoniques

Visitez quelques pages produit et consultez le code source de la page (Ctrl+U). Cherchez la balise <link rel="canonical"> dans la section head. Elle devrait contenir l'URL propre de la page courante sans parametres de requete. Si les balises canoniques sont manquantes ou incorrectes, les problemes de contenu duplique nuiront a votre SEO. Dans le back office, allez dans Parametres de la boutique > Trafic & SEO et verifiez que "Desactiver l'option MultiViews d'Apache" et "Desactiver le module mod_security d'Apache" sont configures correctement pour votre serveur.

Verification 8 : verification des sauvegardes (3 minutes)

Les sauvegardes qui n'ont jamais ete testees ne sont pas des sauvegardes. Ce sont des voeux pieux. Cette verification confirme que votre systeme de sauvegarde fonctionne reellement.

Verifier la fraicheur de la sauvegarde

Determinez ou vos sauvegardes sont stockees. Cela varie selon l'hebergeur. Verifiez votre panneau de controle d'hebergement pour les outils de sauvegarde (cPanel a une section Sauvegarde, Plesk a un Gestionnaire de sauvegardes). Si vous utilisez un module de sauvegarde dans PrestaShop, verifiez sa configuration et le journal de sauvegarde recent.

Votre sauvegarde la plus recente ne devrait pas dater de plus de 24 heures pour les boutiques actives. Si votre derniere sauvegarde date de plus d'une semaine, votre systeme de sauvegarde n'est soit pas configure, ne fonctionne pas, ou echoue silencieusement. Corrigez cela immediatement. La perte de donnees suite a une panne serveur ou un piratage sans sauvegarde recente peut mettre fin a votre activite.

Verifier la completude de la sauvegarde

Une sauvegarde PrestaShop complete inclut l'integralite de la base de donnees (toutes les tables, pas seulement les donnees produit) et le systeme de fichiers (tous les fichiers PrestaShop, y compris les images telechargees, les fichiers de modules et les personnalisations de theme). De nombreuses solutions de sauvegarde ne capturent que la base de donnees ou seulement les fichiers. Verifiez que la votre capture les deux.

Verifiez les tailles des fichiers de sauvegarde. Une sauvegarde de base de donnees pour une petite boutique devrait faire au moins plusieurs megaoctets. Si elle est suspicieusement petite (moins de 1 Mo pour une boutique active), elle pourrait etre vide ou corrompue. Une sauvegarde de fichiers devrait inclure votre repertoire /img/, qui est typiquement le plus grand repertoire et peut faire plusieurs gigaoctets pour les boutiques avec de nombreuses images de produits.

Stockage de sauvegarde hors site

Les sauvegardes stockees sur le meme serveur que votre boutique sont vulnerables aux memes pannes. Si le disque dur du serveur tombe en panne, vous perdez a la fois la boutique et la sauvegarde. Verifiez que vos sauvegardes sont copiees vers un emplacement separe : un serveur different, du stockage cloud (comme Amazon S3, Google Cloud Storage ou Dropbox), ou telechargees sur un ordinateur local.

Verification 9 : etat des mises a jour (2 minutes)

Utiliser un logiciel obsolete est la raison la plus courante pour laquelle les boutiques PrestaShop se font pirater. Cette derniere verification confirme que votre installation de base et vos modules critiques sont a jour.

Version du noyau PrestaShop

Verifiez votre version PrestaShop actuelle dans le pied de page du back office ou sur la page Parametres avances > Informations. Comparez-la avec la derniere version stable sur le site web de PrestaShop ou la page des releases GitHub. Si vous etes en retard de plus d'une version mineure (par exemple, vous utilisez 8.1.2 alors que 8.1.5 est disponible), planifiez une mise a jour. Si vous utilisez une version avec des vulnerabilites de securite connues, mettez a jour de toute urgence.

Les mises a niveau de version majeure PrestaShop (comme 1.7 vers 8.x) sont des projets de migration complexes, pas de simples mises a jour. Ne les tentez pas sans une planification et des tests approfondis. Mais les mises a jour de version mineure (comme 8.1.2 vers 8.1.5) sont generalement sures et contiennent principalement des correctifs de securite et de bugs.

Mises a jour des modules critiques

Certains modules gerent des operations sensibles et doivent etre maintenus a jour : les modules de paiement (tout module qui traite les cartes de credit, PayPal ou d'autres methodes de paiement), le module PrestaShop Autoupgrade (utilise pour les mises a jour du noyau) et tout module lie a la securite. Verifiez le Gestionnaire de modules pour les mises a jour disponibles sur ces modules specifiques.

Resume de votre checklist d'audit en 30 minutes

Voici la checklist complete avec les allocations de temps que vous pouvez suivre chaque mois :

Minutes 1-3 : version et configuration PHP. Verifier que la version PHP est supportee. Confirmer memory_limit, max_execution_time et le statut OPcache.

Minutes 4-7 : examen du journal d'erreurs. Scanner les journaux PrestaShop pour les entrees de Severite 3 et 4. Verifier le journal d'erreurs PHP pour les erreurs fatales et les avis de depreciation. Noter les erreurs recurrentes pour suivi.

Minutes 8-12 : audit des modules. Examiner les modules desactives et desinstaller les inutilises. Verifier les mises a jour disponibles, en particulier sur les modules de paiement et de securite. Compter le total des modules actifs et identifier les candidats a la suppression.

Minutes 13-16 : sante de la base de donnees. Verifier la taille totale de la base de donnees. Identifier les tables gonflees. Planifier le nettoyage des anciennes donnees de connexion, de journal et de panier.

Minutes 17-21 : fondamentaux de securite. Verifier que l'URL admin est aleatoire. Verifier le certificat SSL et sa date d'expiration. Confirmer les permissions de fichiers. Confirmer que le mode debug est desactive. Verifier les vulnerabilites connues de votre version.

Minutes 22-25 : test de performance rapide. Executer un audit Lighthouse sur la page d'accueil. Verifier les metriques LCP, INP et CLS. Confirmer les parametres de cache et CCC dans le back office.

Minutes 26-28 : fondamentaux SEO. Verifier le robots.txt pour les erreurs. Confirmer que le sitemap est a jour et complet. Verifier ponctuellement les URLs canoniques sur les pages produit.

Minutes 29-30 : sauvegarde et mises a jour. Confirmer la fraicheur et la completude de la sauvegarde. Comparer les versions du noyau PrestaShop et des modules critiques avec les dernieres versions publiees.

Cet audit ne corrige pas les problemes. Il les identifie. Apres avoir complete la checklist, vous devriez avoir une liste priorisee de problemes a traiter. Les problemes de securite critiques et les fonctionnalites cassees passent en premier. Les optimisations de performance et les taches de nettoyage viennent en second. Les ameliorations mineures et la planification future en troisieme. En effectuant cet audit mensuellement, vous detectez les problemes tot, maintenez une vision claire de la sante technique de votre boutique, et evitez les mauvaises surprises qui viennent de mois de maintenance negligee.