Date de livraison estimée

Checkout Revolution affiche les options d'expédition fournies par vos modules transporteur, y compris les informations de délai de livraison qu'ils fournissent. Si votre module transporteur inclut des dates de livraison estimées, elles apparaîtront. Le module de checkout lui-même ne calcule pas les dates de livraison — cette logique appartient aux modules de livraison/transporteur.

Learn more in our one-page checkout guide.

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

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.

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.

Redirections .htaccess PrestaShop : ecrire des regles sans casser votre boutique

Le fichier .htaccess est l'un des fichiers les plus puissants et les plus dangereux de votre installation PrestaShop. Un seul caractere mal place peut mettre toute votre boutique hors ligne. Mais maitriser les redirections .htaccess est essentiel pour le SEO - vous en avez besoin lors du changement d'URLs, de la migration depuis une autre plateforme, de la suppression d'anciens produits ou de la restructuration de votre arbre de categories.

Comment PrestaShop utilise .htaccess

PrestaShop genere et gere automatiquement le fichier .htaccess. Lorsque vous activez les URLs simplifiees dans les parametres SEO et URLs, PrestaShop ecrit des regles de reecriture entre deux commentaires marqueurs.

Regle critique - N'ajoutez jamais vos redirections personnalisees a l'interieur de ce bloc. PrestaShop les ecrasera lors de la prochaine regeneration. Placez vos regles AVANT le bloc PrestaShop.

Types de redirections

301 - Redirection permanente

Utilisez quand une page a definitivement demenage. Les moteurs de recherche transferent la valeur SEO vers la nouvelle URL.

302 - Redirection temporaire

Utilisez quand une page est temporairement indisponible.

410 - Gone

Utilisez quand une page a ete definitivement supprimee sans remplacement.

Syntaxe de base des redirections

# Rediriger une URL unique
Redirect 301 /ancienne-page.html https://votreboutique.com/nouvelle-page.html

# Rediriger une ancienne URL produit
Redirect 301 /ancien-produit.html https://votreboutique.com/fr/nouveau-produit.html

Redirections basees sur des patterns avec RewriteRule

RewriteEngine On
RewriteRule ^ancien-dossier/(.*)$ https://votreboutique.com/nouveau-dossier/$1 [R=301,L]

Scenarios courants de redirection PrestaShop

Scenario 1 - Migration depuis une autre plateforme

# WooCommerce vers PrestaShop
RewriteRule ^product/ancien-slug/?$ https://votreboutique.com/fr/nouvelle-url.html [R=301,L]

Scenario 2 - Forcer HTTPS et WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Regles qui peuvent casser PrestaShop

Boucles de redirection infinies

L'erreur la plus dangereuse. Toujours utiliser des conditions pour prevenir les boucles.

# DANGEREUX
RewriteRule ^(.*)$ https://votreboutique.com/$1 [R=301,L]

# SUR
RewriteCond %{HTTP_HOST} !^www\.votreboutique\.com$ [NC]
RewriteRule ^(.*)$ https://www.votreboutique.com/$1 [R=301,L]

Casser l'acces au back office

# SUR - exclure admin et API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://votreboutique.com/fr/$1 [R=301,L]

Tester vos redirections en securite

# Toujours sauvegarder d'abord
cp .htaccess .htaccess.backup

# Tester avec curl
curl -I -L https://votreboutique.com/ancienne-page.html

Ou placer les regles personnalisees

# VOS REDIRECTIONS ICI (avant le bloc PrestaShop)
Redirect 301 /ancienne-page.html https://votreboutique.com/nouvelle-page.html

# ~~start~~ Bloc PrestaShop
# ... regles auto-generees ...
# ~~end~~ Bloc PrestaShop

Quand utiliser un module

Considerez un module de redirection quand du personnel non technique doit gerer les redirections, quand vous avez des centaines de redirections, ou quand vous voulez la detection automatique des 404.

Limitation de debit et protection contre les bots pour PrestaShop sans WAF

Les bots representent plus de 40% du trafic web en 2026. Ce guide montre comment implementer une protection efficace avec la configuration serveur, les regles .htaccess et des modules legers.

Methode 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Methode 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Methode 3 - fail2ban contre le brute force

fail2ban surveille les logs et bloque automatiquement les IPs malveillantes.

Methode 4 - Rate Limiting niveau PHP

Pour l'hebergement mutualisee implementer un limiteur base sur fichiers en PHP.

Methode 5 - robots.txt et controle du crawl

User-agent: SemrushBot
Crawl-delay: 10

Methode 6 - CAPTCHA sur les formulaires critiques

Ajouter reCAPTCHA sur login, inscription, contact et newsletter.

Methode 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode et Rate Limiting sont disponibles gratuitement.

Resume des couches de protection

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 8.x et 9.x

Les thèmes PrestaShop modernes (comme Hummingbird pour PS 9) 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

Performance admin PrestaShop : pourquoi le back office est lent

Un back office PrestaShop lent est l'un des problemes les plus frustrants. Ce guide identifie les causes les plus courantes et fournit des solutions concretes.

Les causes les plus courantes

1. Connexion API PrestaShop Addons

Cause numero un. Le back office fait des requetes HTTP vers addons.prestashop.com. Quand cette API est lente, tout votre back office attend.

Solution - Deconnectez-vous de votre compte Addons ou desactivez les appels API.

2. Mode debug active

Desactive tous les caches et recompile les templates a chaque requete.

define('_PS_MODE_DEV_', false);

3. Trop de modules installes

Chaque module ajoute du surcharge. Desinstallez les modules inutilises, surtout les modules de statistiques et de gamification.

4. Base de donnees non optimisee

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Limitations de l'hebergement mutualise

Recommandation : VPS avec 2+ CPU, 4 GB RAM, SSD et PHP 8.1+.

6. OPcache non active

opcache.enable = 1
opcache.memory_consumption = 256

7. Widgets du tableau de bord lents

Simplifier le tableau de bord. Supprimer les widgets inutiles.

8. Grand catalogue produits

Reduire les produits par page a 20-50. Utiliser la recherche plutot que la navigation.

Checklist d'optimisation

1. Desactiver le mode debug
2. Compilation des templates : "Ne jamais recompiler"
3. Activer le cache (Redis prefere)
4. Activer OPcache
5. Se deconnecter de l'API Addons
6. Desinstaller les modules inutilises
7. Nettoyer la base de donnees
8. Simplifier le tableau de bord
9. Passer au VPS/dedie
10. Utiliser PHP 8.1+

Quand les combinaisons PrestaShop tuent la performance : limites et solutions

Le systeme de combinaisons de PrestaShop permet de creer des variantes de produits. Il fonctionne parfaitement pour les produits avec quelques variantes. Mais quand les produits ont des centaines ou milliers de combinaisons, la performance se degrade dramatiquement.

Pourquoi les combinaisons causent des problemes de performance

Architecture de la base de donnees

PrestaShop stocke les donnees de combinaisons dans plusieurs tables : ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Un produit avec 5 tailles et 10 couleurs cree 50 combinaisons avec plus de 350 lignes en base.

Le probleme de croissance exponentielle

Limites pratiques

Solution 1 - Restructurer le catalogue

Au lieu d'un produit avec 50 combinaisons (10 couleurs x 5 tailles), creez des produits separes par couleur avec 5 combinaisons chacun. Plus rapide et meilleur pour le SEO.

Solution 2 - Optimisation base de donnees et serveur

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Solution 3 - Chargement progressif des combinaisons

Au lieu de charger toutes les combinaisons au chargement de la page, charger les donnees par AJAX quand le client selectionne un attribut.

Solution 4 - Strategies de cache

Cache de page complet (Varnish, LiteSpeed) pour les pages produits. Redis ou Memcached pour le cache objet.

Quand eviter completement les combinaisons

• Produits configurables avec 4+ attributs - Module configurateur de produit
• Produits dimensionnels - Module de dimensions personnalisees
• Produits print-on-demand - Module de design produit

Recommandations par nombre de combinaisons

Matrice de compatibilité des versions PHP pour PrestaShop

Choisir la bonne version de PHP pour votre boutique PrestaShop est l'une des décisions d'infrastructure les plus critiques que vous prendrez. L'utilisation d'une version PHP incompatible peut provoquer des écrans blancs, des processus de paiement défaillants, des erreurs de modules et des vulnérabilités de sécurité. Ce guide complet couvre chaque version de PrestaShop de 1.6 à 9.x et associe chacune à ses versions PHP prises en charge, configurations recommandées et considérations de mise à jour.

Pourquoi la version PHP est importante pour PrestaShop

PHP est le langage côté serveur qui fait fonctionner PrestaShop. Chaque version majeure de PHP apporte des améliorations de performance, de nouvelles fonctionnalités du langage et déprécie les fonctions plus anciennes. Le code source de PrestaShop évolue en parallèle avec PHP, ce qui signifie que les versions plus récentes de PrestaShop tirent parti des fonctionnalités modernes de PHP tout en abandonnant le support des versions obsolètes.

L'utilisation de la mauvaise version PHP provoque trois catégories de problèmes :

• Erreurs fatales - Les fonctions supprimées dans les nouvelles versions PHP (par exemple, les fonctions mysql_* supprimées en PHP 7.0, each() supprimée en PHP 8.0) provoquent des plantages immédiats.
• Avertissements de dépréciation - Les fonctions dépréciées génèrent des avertissements qui peuvent casser les réponses AJAX, la sortie JSON et la génération de PDF lorsque display_errors est activé.
• Exposition aux risques de sécurité - Les versions PHP qui ont atteint leur fin de vie ne reçoivent plus de correctifs de sécurité, laissant votre boutique vulnérable.

Matrice de compatibilité complète

PrestaShop 1.6.x

PHP recommandé pour 1.6.x - PHP 7.1. Il offre le meilleur équilibre entre performance et compatibilité. L'exécution de 1.6.x sur PHP 7.2+ nécessite des modifications de fichiers core qui brisent le chemin de mise à jour et n'est pas recommandée.

PrestaShop 1.7.x

Avertissement critique - Aucune version de PrestaShop 1.7 ne supporte PHP 8.0 ou ultérieur. Si vous exécutez PS 1.7.6 sur PHP 8, Smarty plantera immédiatement car le moteur de templates utilise des fonctions supprimées en PHP 8.0. La suppression de la fonction each() et les changements dans le fonctionnement de array_key_exists() avec les objets provoquent des erreurs fatales.

PrestaShop 8.x

PHP recommandé pour 8.x - PHP 8.1. C'est le point idéal offrant une compatibilité complète, un support de sécurité actif et d'excellentes performances avec la compilation JIT. PHP 8.1 apporte les fibres, les enums, les propriétés en lecture seule et les types d'intersection que PrestaShop 8 peut exploiter.

PrestaShop 9.x

PHP recommandé pour 9.x - PHP 8.3 ou 8.4. PrestaShop 9 fonctionne sur Symfony 6.4 LTS et requiert PHP 8.1 comme minimum. PHP 8.4 apporte les Property Hooks et la visibilité asymétrique que les futures mises à jour de PrestaShop exploiteront.

Dates de fin de vie PHP à connaître

Si vous utilisez PHP 7.4 ou 8.0 en 2026, vous fonctionnez sur une version non supportée qui ne reçoit plus de correctifs de sécurité. C'est un risque critique pour toute boutique e-commerce traitant des données de paiement.

Comment vérifier votre version PHP actuelle

Méthode 1 - Back Office PrestaShop

Naviguez vers Paramètres avancés > Informations. La section Informations du serveur affiche votre version PHP, ainsi que la limite de mémoire, le temps d'exécution maximum et d'autres paramètres pertinents.

Méthode 2 - Fichier PHP Info

Créez un fichier nommé phpinfo.php dans le répertoire racine de votre boutique avec ce contenu :

<?php phpinfo();

Accédez-y via votre navigateur à https://votreboutique.com/phpinfo.php. Supprimez ce fichier immédiatement après vérification - il expose des détails sensibles de configuration du serveur.

Méthode 3 - Ligne de commande

php -v
php -r "echo PHP_VERSION;"

Notez que la version PHP CLI peut différer de la version PHP du serveur web. Vérifiez toujours via l'interface web ou phpinfo().

Problèmes courants avec la mauvaise version PHP

Écran blanc de la mort (WSOD)

Le symptôme le plus courant d'incompatibilité PHP. Vérifiez votre journal d'erreurs PHP (généralement à /var/log/php-errors.log ou accessible via votre panneau d'hébergement). Erreurs typiques :

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Les avertissements de dépréciation cassent AJAX

Lorsque display_errors = On et que vous mettez à jour PHP, les notices de dépréciation sont ajoutées aux réponses AJAX. Cela casse le parsing JSON dans le back office, provoquant l'échec silencieux de fonctionnalités comme la recherche de produits, la recherche de clients et la création de commandes. La solution :

; php.ini
display_errors = Off
log_errors = On
error_log = /chemin/vers/php-error.log

Incompatibilité des modules

Les modules tiers peuvent ne pas supporter votre version PHP. Avant de mettre à jour PHP, vérifiez la compatibilité de chaque module installé. Zones problématiques courantes :

• Modules utilisant create_function() - supprimée en PHP 8.0
• Modules utilisant les fonctions mysql_* - supprimées en PHP 7.0
• Modules utilisant l'accès positionnel aux chaînes avec accolades $str{0} - supprimé en PHP 8.0
• Modules ne gérant pas les types de retour nullable - plus strict à partir de PHP 8.1+

Comment mettre à jour PHP pour PrestaShop en toute sécurité

Étape 1 - Auditer votre configuration actuelle

Avant de modifier quoi que ce soit, documentez votre environnement actuel :

php -v                    # Version PHP actuelle
php -m                    # Extensions chargées
php -i | grep memory      # Limite de mémoire
php -i | grep max_exec    # Limite du temps d'exécution

Étape 2 - Vérifier la compatibilité des modules

Examinez chaque module installé. Consultez la documentation du développeur du module pour le support des versions PHP. Si un module n'a pas été mis à jour depuis plus de deux ans, il est probablement incompatible avec PHP 8.x.

Étape 3 - Tester d'abord en staging

Ne mettez jamais à jour PHP sur votre serveur de production sans test préalable. Créez une copie de staging de votre boutique et testez avec la nouvelle version PHP. Vérifiez :

• Les pages du front office se chargent correctement
• Pages produits, pages catégories, pages CMS
• Le processus de panier et de commande se termine complètement
• Les modules de paiement traitent les transactions de test
• Les fonctionnalités du back office fonctionnent (édition de produits, gestion des commandes)
• Tous les modules tiers fonctionnent correctement
• Les tâches cron s'exécutent sans erreur

Étape 4 - Mise à jour avec plan de retour en arrière

La plupart des hébergeurs vous permettent de changer de version PHP depuis le panneau de contrôle (cPanel, Plesk, DirectAdmin). Gardez la version PHP précédente disponible pour un retour rapide si des problèmes surviennent.

Étape 5 - Vider tous les caches après la mise à jour

Après le changement de version PHP, videz chaque couche de cache :

# Vider le cache PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Vider les templates Smarty compilés
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Si vous utilisez OPcache, redémarrer PHP-FPM
systemctl restart php8.3-fpm

# Vider le cache CDN (Cloudflare, etc.)

Meilleures pratiques de configuration PHP pour PrestaShop

Quelle que soit la version PHP choisie, ces paramètres sont essentiels pour des performances optimales de PrestaShop :

; paramètres php.ini recommandés
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Paramètres OPcache (critiques pour les performances)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Extensions requises
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Considérations pour les développeurs de modules

Si vous développez des modules PrestaShop, vous devez considérer attentivement la compatibilité PHP :

• Version PHP minimum - Ciblez PHP 7.2 comme minimum pour les modules devant fonctionner sur PrestaShop 8.0+, ou PHP 8.1 pour les modules exclusifs à PrestaShop 9.
• Utilisez PHPStan ou Psalm - Les outils d'analyse statique détectent les incompatibilités de version PHP avant vos utilisateurs.
• Évitez la syntaxe spécifique à une version - Les fonctionnalités comme les expressions match (PHP 8.0), les enums (PHP 8.1) et les propriétés readonly (PHP 8.1) limitent votre module à ces versions PHP et supérieures.
• Testez sur plusieurs versions - Utilisez des conteneurs Docker avec différentes versions PHP pour tester votre module sur toute la plage de compatibilité.

Questions fréquemment posées

Puis-je exécuter PrestaShop 1.7 sur PHP 8 ?

Non. Aucune version de PrestaShop 1.7 ne supporte officiellement PHP 8.0 ou ultérieur. Bien que certains utilisateurs aient appliqué des correctifs pour le faire fonctionner partiellement, cela n'est pas supporté et causera des problèmes lors des mises à jour. Le bon chemin est de migrer vers PrestaShop 8.x.

Dois-je utiliser PHP 8.4 avec PrestaShop 8.1 ?

Déconseillé. PrestaShop 8.1 a été développé et testé principalement avec PHP 8.1. Bien que PHP 8.2 soit partiellement supporté dans les versions 8.1.x ultérieures, PHP 8.4 introduit des changements qui peuvent causer des problèmes avec les composants Symfony plus anciens. Restez avec PHP 8.1 pour PrestaShop 8.x.

PHP 8.x est-il beaucoup plus rapide que 7.x ?

Les benchmarks montrent que PHP 8.1 est environ 20-30% plus rapide que PHP 7.4 pour les charges de travail PrestaShop typiques. Le compilateur JIT offre le plus d'avantages pour les tâches de calcul. Pour les opérations liées aux E/S (requêtes de base de données, lectures de fichiers), l'amélioration est plus faible mais néanmoins mesurable.

La mise à jour de PHP nécessite-t-elle une mise à jour de PrestaShop ?

Pas nécessairement, mais les deux vont de pair. Vous pouvez mettre à jour PHP dans la plage supportée pour votre version PrestaShop sans mettre à jour PrestaShop lui-même. Cependant, si vous souhaitez utiliser une version PHP moderne (8.3+), vous aurez besoin de PrestaShop 8.1 ou 9.x.