Question sur le produit

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.

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+

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

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.

Ce qu'est Varnish et pourquoi c'est important pour PrestaShop

Varnish Cache est un reverse proxy HTTP qui se place entre votre serveur web et Internet, servant des copies en cache des pages sans jamais toucher PHP ou MySQL. Lorsqu'un visiteur demande une page que Varnish a mise en cache, la réponse provient directement de la mémoire en quelques microsecondes. PHP ne s'exécute pas. MySQL ne reçoit aucune requête. Le serveur web remarque à peine que la requête a eu lieu.

Cela est fondamentalement différent du fonctionnement des modules de cache Full Page (FPC) basés sur PHP dans PrestaShop. Un module FPC s'exécute toujours au sein de PHP. La requête atteint Apache ou Nginx, PHP démarre, PrestaShop s'initialise (chargement de la configuration, établissement des connexions à la base de données, analyse des routes), puis le module FPC intercepte la requête avant que la logique complète du contrôleur ne s'exécute, servant un fichier HTML mis en cache. Bien que cela soit nettement plus rapide que de rendre la page à partir de zéro, cela implique toujours le démarrage de PHP et le chargement du framework PrestaShop. Cette surcharge, typiquement de 50 à 200 millisecondes même pour un cache hit, s'accumule sous charge.

Varnish élimine entièrement cette surcharge. Un cache hit Varnish est servi en 1 à 5 millisecondes. Sous un trafic élevé, la différence est spectaculaire. Une boutique PrestaShop qui peine à gérer 100 utilisateurs simultanés avec un module FPC peut servir des milliers d'utilisateurs simultanés avec Varnish, car la grande majorité des requêtes n'atteint jamais le backend PHP.

Quand les modules Full Page Cache en PHP sont suffisants

Avant d'investir dans Varnish, il est utile de comprendre quand un module FPC basé sur PHP est suffisant. Pour de nombreuses boutiques PrestaShop, c'est le cas.

Si votre boutique enregistre moins de 50 000 pages vues par jour, un module FPC bien configuré gérera la charge sans problème. La complexité supplémentaire de Varnish n'est pas justifiée lorsque votre serveur dispose de capacité de réserve. Si vos temps de réponse serveur avec le FPC sont constamment inférieurs à 200 millisecondes, vos visiteurs bénéficient déjà de chargements rapides. Le goulot d'étranglement à ce stade est probablement le rendu frontend (CSS, JavaScript, images) plutôt que le temps de réponse du serveur.

Les modules FPC gèrent également certains scénarios spécifiques à PrestaShop de manière plus élégante que Varnish, car ils fonctionnent à l'intérieur de l'application. Ils peuvent vérifier si un utilisateur est connecté, si le panier contient des articles et si certains contenus dynamiques doivent être personnalisés, le tout au sein du même processus PHP. Avec Varnish, ces vérifications doivent être gérées via l'inspection des cookies et des règles de variation du cache, ce qui ajoute de la complexité à la configuration.

Envisagez Varnish lorsque votre boutique fait régulièrement face à des pics de trafic (ventes flash, campagnes marketing, pics saisonniers) qui saturent votre capacité PHP, lorsque vous avez besoin de temps de réponse inférieurs à 10 ms pour des raisons de SEO ou d'expérience utilisateur, lorsque votre budget d'hébergement est limité et que vous devez servir plus de trafic avec le même matériel, ou lorsque votre boutique génère un ratio élevé de navigation anonyme (pages de catégories, pages de produits) par rapport à l'activité du panier et du checkout.

Comment fonctionne Varnish : le flux des requêtes

Comprendre le flux des requêtes à travers Varnish est essentiel pour le configurer correctement avec PrestaShop.

Arrivée de la requête

Lorsqu'un visiteur demande une page, la requête atteint d'abord Varnish (Varnish écoute sur le port 80 ou 443 si la terminaison est assurée par un proxy frontal). Varnish examine la requête : l'URL, la méthode HTTP, les cookies et les en-têtes.

Recherche dans le cache

Varnish vérifie son cache à la recherche d'une réponse stockée correspondant à cette requête. La clé de cache est typiquement basée sur l'URL et des en-têtes sélectionnés. Si une réponse correspondante existe et n'a pas expiré, Varnish la sert directement. C'est un cache hit. La réponse est envoyée au visiteur et le serveur backend n'est jamais contacté.

Cache miss

Si aucune réponse en cache correspondante n'existe, Varnish transmet la requête au serveur backend (Apache ou Nginx exécutant PrestaShop). PrestaShop traite la requête normalement, génère la réponse HTML et la renvoie à Varnish. Varnish stocke la réponse dans son cache (si la réponse est cacheable) et la transmet au visiteur. Les requêtes suivantes pour la même page seront servies depuis le cache.

Invalidation du cache

Lorsque les données produit changent, que les prix sont mis à jour ou que le contenu est modifié, la version en cache devient obsolète. Varnish doit être informé de supprimer l'ancienne version en cache afin d'en récupérer une nouvelle depuis le backend. C'est l'invalidation du cache, et c'est la partie la plus difficile de tout système de mise en cache à maîtriser correctement.

Configuration VCL pour PrestaShop

Le Varnish Configuration Language (VCL) est un langage dédié qui contrôle la façon dont Varnish gère les requêtes. Une configuration VCL appropriée pour PrestaShop doit prendre en compte plusieurs comportements spécifiques à PrestaShop.

Définition du backend

La définition du backend indique à Varnish où transmettre les cache misses. Pour une installation PrestaShop typique où Apache ou Nginx tourne sur le même serveur sur le port 8080 :

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Les timeouts sont importants. Les pages PrestaShop peuvent prendre plusieurs secondes à se générer sur un cache froid, particulièrement les pages de catégories avec de nombreux produits. Un first_byte_timeout trop bas amène Varnish à retourner une erreur 503 avant que PrestaShop n'ait fini de générer la page.

Gestion des cookies et des sessions

Les cookies représentent le plus grand défi lors de la mise en cache de PrestaShop avec Varnish. PrestaShop définit plusieurs cookies par défaut, et Varnish traite toute requête avec des cookies comme non cacheable, sauf instruction contraire. Si vous ne gérez pas les cookies dans votre VCL, Varnish ne mettra quasiment rien en cache.

PrestaShop définit ces cookies sur la plupart des requêtes : le cookie de session (typiquement nommé PrestaShop-xxxx), les cookies liés au panier, les cookies Google Analytics (_ga, _gid, _gat) et divers cookies de tracking provenant d'outils marketing. Parmi ceux-ci, seul le cookie de session PrestaShop est pertinent pour le comportement du cache. Les cookies d'analytics et de tracking doivent être supprimés de la requête avant la recherche dans le cache afin qu'ils n'empêchent pas la mise en cache.

Dans votre sous-routine VCL vcl_recv, supprimez les cookies non essentiels :

sub vcl_recv {
  # Supprimer les cookies Google Analytics et autres cookies de tracking
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Supprimer l'en-tête cookie vide
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Décider quoi mettre en cache

Toutes les pages PrestaShop ne doivent pas être mises en cache. Le VCL doit distinguer les requêtes cacheables des requêtes non cacheables.

Toujours mettre en cache : les pages produit pour les visiteurs anonymes, les pages de listing par catégorie, les pages CMS (à propos, conditions générales, contact), la page d'accueil, les pages fabricants et fournisseurs, les pages du sitemap.

Ne jamais mettre en cache : la page du panier, les pages de commande (toutes les étapes), l'espace compte client (commandes, adresses, informations personnelles), les pages de connexion et d'inscription, toute page pour un client connecté, les requêtes POST, les requêtes AJAX qui modifient l'état (ajout au panier, mise à jour de la quantité).

La logique VCL pour cela vérifie typiquement le chemin de l'URL et la présence de cookies de session :

sub vcl_recv {
  # Ne pas mettre en cache les requêtes POST
  if (req.method == "POST") {
    return (pass);
  }
  # Ne pas mettre en cache la zone admin
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Ne pas mettre en cache le checkout et le panier
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Ne pas mettre en cache si le client a des articles dans le panier
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Définir la durée du cache

Dans la sous-routine vcl_backend_response, vous contrôlez combien de temps Varnish met chaque réponse en cache. PrestaShop envoie des en-têtes Cache-Control qui disent typiquement no-cache ou private car il suppose que chaque réponse peut contenir du contenu personnalisé. Vous devez les remplacer pour les pages que vous savez être sûres à mettre en cache :

sub vcl_backend_response {
  # Mettre en cache les pages produit et catégorie pendant 1 heure
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Mettre en cache les assets statiques pendant 1 jour
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

La suppression du Set-Cookie des réponses mises en cache est critique. Si une réponse en cache inclut un en-tête Set-Cookie, Varnish ne la mettra pas en cache par défaut, et même s'il est forcé de la mettre en cache, il définirait le même cookie de session pour chaque visiteur, provoquant un détournement de session.

Invalidation du cache avec des requêtes PURGE

Lorsqu'un prix de produit change, qu'un nouveau produit est ajouté ou que du contenu est mis à jour, la version en cache doit être invalidée. Varnish supporte les requêtes PURGE : une méthode HTTP spéciale qui indique à Varnish de supprimer une URL spécifique de son cache.

Configurer le support PURGE

Ajoutez la gestion PURGE à votre VCL :

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Non autorisé."));
    }
    return (purge);
  }
}

L'ACL restreint les requêtes PURGE à localhost, empêchant les utilisateurs externes de vider votre cache.

Déclencher les purges depuis PrestaShop

PrestaShop n'envoie pas de requêtes PURGE nativement. Vous avez besoin d'un module ou d'un hook personnalisé qui détecte quand un contenu cacheable change et envoie une requête PURGE à Varnish. Le module s'accroche aux événements PrestaShop comme actionProductUpdate, actionCategoryUpdate et actionCMSPageUpdate. Lorsque ces événements se déclenchent, le module envoie une requête HTTP PURGE à l'URL correspondante sur le serveur Varnish.

Pour une mise à jour de produit, le module purgerait l'URL du produit, les URLs des catégories auxquelles le produit appartient (car les pages de listing de catégories affichent les prix et la disponibilité des produits), et potentiellement la page d'accueil si elle affiche des produits mis en avant. Cette cascade de purges est nécessaire pour empêcher l'apparition de données obsolètes n'importe où sur le site.

Invalidation basée sur les bans

Pour les scénarios où de nombreuses URLs doivent être purgées en même temps (une mise à jour de prix sur tout le site, un changement de design, une nouvelle bannière promotionnelle), les requêtes PURGE individuelles sont impraticables. Varnish supporte les bans, qui sont des règles d'invalidation basées sur des motifs. Un ban indique à Varnish de supprimer tout objet en cache correspondant à un motif :

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Non autorisé."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banni."));
  }
}

L'envoi d'une requête BAN avec l'en-tête X-Ban-Pattern: /category/ invaliderait toutes les pages de catégories en cache en une seule opération.

Edge Side Includes (ESI) pour les blocs dynamiques

De nombreuses pages PrestaShop contiennent un mélange de contenu statique et dynamique. Le listing de produits sur une page de catégorie est le même pour chaque visiteur, mais l'en-tête affichant le nombre d'articles dans le panier est personnalisé. Sans ESI, vous ne pouvez pas mettre la page en cache du tout car l'en-tête dynamique rend toute la réponse spécifique au visiteur.

Les Edge Side Includes résolvent ce problème en vous permettant de marquer des sections de la page comme des fragments récupérés séparément. Varnish assemble la page finale à partir de fragments en cache et non mis en cache.

Comment fonctionne ESI

Dans votre template Smarty, au lieu de rendre le widget du panier directement, vous incluez une balise ESI :

<esi:include src="/module/cartwidget/ajax" />

Lorsque Varnish traite la page en cache, il rencontre la balise ESI et effectue une requête backend séparée pour ce fragment. Le corps principal de la page est servi depuis le cache, tandis que le widget du panier est récupéré frais depuis PrestaShop. La réponse assemblée inclut à la fois le corps en cache et le widget du panier frais.

Activez le traitement ESI dans votre VCL :

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Considérations ESI pour PrestaShop

L'implémentation d'ESI nécessite la modification de vos templates PrestaShop pour séparer le contenu dynamique en fragments compatibles ESI. Chaque fragment a besoin de son propre point de terminaison URL qui retourne uniquement le HTML pour ce bloc. Les fragments qui sont typiquement dynamiques et nécessitent un traitement ESI incluent le widget récapitulatif du panier (nombre d'articles, total), le message de bienvenue du client ("Bonjour, Pierre"), les recommandations de produits personnalisées, le lien connexion/déconnexion et les produits récemment consultés.

L'effort requis pour implémenter correctement ESI est considérable. Chaque fragment dynamique nécessite un contrôleur dédié, les templates doivent être restructurés, et les règles de mise en cache pour chaque fragment doivent être ajustées individuellement. C'est l'une des raisons pour lesquelles Varnish est considéré comme une optimisation avancée : il fonctionne le mieux lorsque l'application a été conçue en le prenant en compte.

Vérifications de santé du backend

Varnish peut surveiller la santé de votre serveur backend et prendre des mesures lorsqu'il devient indisponible. Ceci est configuré dans la définition du backend :

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish envoie une requête à /ping.php toutes les 5 secondes. Si 3 des 5 dernières vérifications échouent, Varnish marque le backend comme malade. Tant que le backend est malade, Varnish peut servir du contenu en cache périmé (mode grace) au lieu de retourner des erreurs aux visiteurs. Cela signifie que votre boutique reste partiellement disponible même lorsque le backend PHP tombe en panne ou redémarre.

La configuration du mode grace détermine combien de temps Varnish servira du contenu périmé :

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Avec un grace de 6 heures, si votre backend tombe en panne, les visiteurs verront des pages en cache (même si elles datent de 6 heures) plutôt que des pages d'erreur. Les prix des produits pourraient être légèrement obsolètes, mais la boutique reste fonctionnelle pendant que vous résolvez le problème du backend.

Benchmarks de performance

La différence de performance entre l'absence de cache, le FPC PHP et Varnish est substantielle et mesurable.

Sans cache (PrestaShop nu) : Une page produit PrestaShop typique prend 200 à 800 millisecondes à se générer, selon le matériel du serveur, le nombre de modules chargés et le nombre de requêtes à la base de données. Sous charge, les temps de réponse augmentent car les workers PHP sont saturés. Un seul serveur peut gérer 20 à 50 utilisateurs simultanés avant que les temps de réponse ne deviennent inacceptables.

Module FPC PHP : Les cache hits sont servis en 30 à 100 millisecondes car PHP démarre toujours et le framework s'initialise partiellement. Sous charge, la performance est bien meilleure car les réponses en cache nécessitent un temps de traitement PHP minimal. Un seul serveur peut gérer 200 à 500 utilisateurs simultanés selon la configuration. Les cache misses prennent toujours le temps complet de rendu.

Varnish : Les cache hits sont servis en 1 à 5 millisecondes. Sous charge, Varnish lui-même peut gérer des milliers de connexions simultanées car il est écrit en C et conçu spécifiquement pour cette charge de travail. Le serveur backend ne gère que les cache misses, qui représentent une petite fraction du trafic total sur un système correctement configuré. Le même matériel qui peine avec 50 utilisateurs simultanés sans cache peut en gérer 5 000 ou plus avec Varnish.

Ces chiffres illustrent pourquoi Varnish vaut la complexité de configuration pour les boutiques à fort trafic. L'amélioration des performances n'est pas incrémentale : c'est un ordre de grandeur.

Exigences d'hébergement

Varnish a des exigences d'hébergement spécifiques que tous les environnements d'hébergement PrestaShop ne peuvent pas satisfaire.

Accès au serveur

Vous avez besoin d'un accès root pour installer et configurer Varnish. Les plans d'hébergement mutualisé ne supportent pas Varnish car il nécessite son propre processus écoutant sur un port et interceptant tout le trafic HTTP. Vous avez besoin d'un VPS, d'un serveur dédié ou d'une instance cloud où vous contrôlez l'ensemble de la pile serveur.

Mémoire

Varnish stocke son cache en RAM. La quantité de RAM nécessaire dépend du nombre de pages uniques dans votre catalogue et de la taille de chaque réponse en cache. Une formule approximative : le nombre de pages cacheables multiplié par la taille moyenne des pages donne la taille minimale du cache. Une boutique avec 5 000 produits, 200 catégories et une taille moyenne de page de 50 Ko nécessite environ 260 Mo de RAM pour le cache. Ajoutez la surcharge pour Varnish lui-même et vous devriez allouer au moins 512 Mo. Pour les catalogues plus importants, 1 à 2 Go est courant.

Configuration des ports

Dans une configuration standard, Varnish écoute sur le port 80 (le port HTTP par défaut) et transmet les cache misses au serveur web sur un port différent (généralement 8080). Cela signifie que vous devez reconfigurer Apache ou Nginx pour écouter sur le port 8080 au lieu du 80. Si vous utilisez HTTPS (et vous devriez), vous placez typiquement Nginx devant Varnish pour gérer la terminaison SSL : Nginx sur le port 443 termine le SSL et transmet à Varnish sur le port 80, qui transmet les cache misses à Apache ou PHP-FPM sur le port 8080.

Exemple de configuration Docker

Faire tourner Varnish dans Docker aux côtés d'un conteneur PrestaShop est une manière propre d'ajouter Varnish à une installation existante sans modifier le système hôte.

Configuration Docker Compose

Une configuration Docker Compose basique avec Varnish, Nginx pour le SSL et PrestaShop :

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

Dans cette configuration, Varnish est le point d'entrée sur le port 80. Le conteneur PrestaShop n'expose pas son port à l'hôte, seulement au réseau Docker. L'hôte backend VCL serait prestashop (le nom du service Docker) sur le port 80.

VCL pour Docker

La définition du backend VCL pour Docker utilise le nom du service au lieu de localhost :

backend default {
  .host = "prestashop";
  .port = "80";
}

Le DNS interne de Docker résout le nom du service en IP du conteneur. Le reste de la configuration VCL reste identique à une configuration non-Docker.

Stockage du cache dans Docker

Par défaut, l'image Docker de Varnish utilise un stockage en mémoire (malloc), idéal pour les performances. La variable d'environnement VARNISH_SIZE contrôle la quantité de mémoire que Varnish alloue à son cache. Définissez cette valeur de manière à ce qu'elle tienne dans les limites de mémoire de votre conteneur tout en laissant de la place pour le processus Varnish lui-même.

Pour un cache persistant qui survit aux redémarrages du conteneur, vous pouvez utiliser un stockage basé sur des fichiers en montant un volume, mais c'est rarement nécessaire. Le cache se réchauffe rapidement (en quelques minutes après réception du trafic), et le stockage basé sur des fichiers est plus lent que le stockage en mémoire.

Surveillance des performances de Varnish

Varnish fournit des outils intégrés pour surveiller les performances du cache.

La commande varnishstat affiche des statistiques en temps réel incluant le taux de hits du cache, les connexions backend et l'utilisation de la mémoire. La métrique la plus importante est le taux de hits, qui devrait être de 85 % ou plus pour une configuration bien optimisée. Si votre taux de hits est inférieur à 70 %, révisez vos règles VCL car trop de requêtes passent au backend.

La commande varnishlog affiche des logs détaillés par requête, inestimables pour débuguer pourquoi certaines requêtes ne sont pas mises en cache. Vous pouvez filtrer par motif d'URL, code de réponse ou statut cache hit/miss.

La commande varnishtop affiche une liste classée des entrées de log les plus fréquentes, vous aidant à identifier des patterns dans les cache misses ou les erreurs.

Pièges courants

Oublier de supprimer les cookies

La mauvaise configuration Varnish la plus courante avec PrestaShop est de ne pas supprimer les cookies d'analytics et de tracking. Ces cookies sont présents sur pratiquement chaque requête et rendent chaque requête unique du point de vue de Varnish, résultant en un taux de hits de 0 %. Supprimez toujours les cookies dont vous n'avez pas besoin pour la variation du cache.

Mettre en cache du contenu personnalisé

Si votre VCL est trop agressive, elle mettra en cache des pages contenant du contenu personnalisé (message de bienvenue de l'utilisateur connecté, contenu du panier) et les servira à d'autres visiteurs. Cela cause de sérieux problèmes d'utilisabilité et des problèmes potentiels de confidentialité. Transmettez toujours les requêtes contenant des cookies de session au backend.

Pas d'invalidation lors des changements de contenu

Sans un mécanisme de purge approprié, les changements de contenu dans le back office ne seront pas visibles tant que les pages en cache n'expirent pas naturellement. Pour une boutique avec des changements d'inventaire actifs, cela signifie que les visiteurs pourraient voir des produits en rupture de stock, des prix incorrects ou des descriptions obsolètes. Implémentez le support PURGE ou BAN et intégrez-le avec les hooks de mise à jour de PrestaShop.

Ignorer HTTPS

Varnish ne gère pas nativement le SSL. Vous devez placer un proxy de terminaison SSL (Nginx, HAProxy ou un load balancer cloud) devant Varnish. Ne pas planifier cela dans votre architecture mène à des problèmes de contenu mixte, des boucles de redirection ou une incapacité à servir du trafic HTTPS.

Varnish est-il adapté à votre boutique

Varnish est un outil puissant, mais ce n'est pas le bon choix pour chaque boutique PrestaShop. Il ajoute de la complexité opérationnelle : un service supplémentaire à surveiller, un nouveau langage de configuration à apprendre, une couche supplémentaire dans votre processus de débogage. Les avantages sont clairs et mesurables pour les boutiques qui en ont besoin, mais ils ont un coût en temps de mise en place, en maintenance et en difficulté de dépannage.

Si votre boutique fait moins de 50 000 pages vues par jour et que votre serveur gère la charge confortablement avec un module FPC, Varnish est une complexité inutile. Si votre boutique fait régulièrement face à des pics de trafic qui submergent votre serveur, sert un volume élevé de trafic de navigation anonyme, ou a besoin des temps de réponse les plus rapides possibles pour le SEO ou l'expérience utilisateur, Varnish offre un niveau de performance qu'aucune solution de cache basée sur PHP ne peut égaler.

Commencez par une optimisation PrestaShop appropriée (optimisation des requêtes, audit des modules, PHP OPcache, optimisation des images) et un module FPC. Si ces optimisations ne suffisent pas, Varnish est l'étape suivante sur l'échelle de mise à l'échelle des performances.