Comment auditer la sante technique de votre boutique PrestaShop en 30 minutes

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.