Quelle version de PrestaShop utilisez-vous ? Audit technique du parc

Beaucoup de dirigeants de boutiques PrestaShop ne savent plus exactement quelle version fait tourner leur site. Entre les mises à jour partielles, les modules installés par un ancien prestataire et les évolutions du cœur logiciel jamais appliquées, le parc technique devient flou. Pourtant, cette information conditionne tout : sécurité, compatibilité des modules, performance, et faisabilité d'une évolution future. Cet article détaille comment identifier sa version, comprendre ce qu'elle implique, et structurer un audit technique fiable avant toute décision.

Pourquoi connaître sa version PrestaShop est la première étape de tout projet

Une boutique en ligne n'est jamais un objet figé. Elle évolue au fil des mises à jour de sécurité, des changements de thème, de l'ajout de modules et des évolutions réglementaires (facturation électronique, RGPD, DSP2 pour les paiements). Or chaque action corrective ou évolutive dépend directement de la version du cœur PrestaShop installée. Un prestataire ne peut pas proposer de devis sérieux, ni une agence estimer une migration, sans connaître précisément cette version de départ.

Cette méconnaissance n'est pas rare : de nombreux commerçants ont hérité d'une boutique construite par un prestataire disparu, ou ont accumulé des interventions ponctuelles sans suivi documenté. Le résultat est souvent un décalage entre la version affichée dans l'administration et la réalité du code, notamment lorsque des correctifs ont été appliqués manuellement sans mise à jour complète.

Comment trouver sa version PrestaShop en quelques clics

Plusieurs méthodes permettent de vérifier la version active :

• Dans le back-office, menu Paramètres avancés > Informations, la version du cœur est affichée directement.
• Dans le pied de page de certains thèmes non personnalisés, la mention « Powered by PrestaShop X.X » peut apparaître.
• En consultant le fichier config/settings.inc.php ou la constante _PS_VERSION_ dans le code source, pour les profils techniques.
• Via la documentation officielle PrestaShop (docs.prestashop-project.org), qui liste les versions prises en charge et leurs dates de fin de vie.

Si vous n'avez pas accès au back-office ou si l'accès a été perdu avec le départ d'un prestataire, un audit technique externe permet de récupérer cette information sans accès complet, à partir du code source ou de l'empreinte technique du site.

Ce que la version révèle sur l'état réel de la boutique

PrestaShop distingue plusieurs branches majeures : la série 1.6 (dont le support officiel est terminé), la série 1.7, et la branche 8 qui constitue aujourd'hui la version recommandée selon la documentation officielle. Chaque branche a des implications concrètes.

Une boutique encore en 1.6 : quels risques concrets ?

Les boutiques restées en version 1.6 cumulent plusieurs difficultés. D'abord, l'absence de correctifs de sécurité officiels expose à des vulnérabilités connues et documentées publiquement, donc exploitables par des outils automatisés. Ensuite, la compatibilité avec PHP récent pose problème : les hébergeurs mutualisés retirent progressivement le support des anciennes versions de PHP, ce qui peut rendre la boutique inaccessible du jour au lendemain. Enfin, le marché des modules et des prestataires se réduit année après année pour cette branche, rendant toute évolution plus coûteuse et plus lente à trouver.

Une boutique en 1.7 : une situation intermédiaire à surveiller

La branche 1.7 reste largement répandue mais certaines de ses versions mineures ne reçoivent plus de mises à jour de sécurité. Il est nécessaire de vérifier la version mineure exacte (1.7.6, 1.7.8, etc.) et de la comparer au calendrier de support publié par PrestaShop pour savoir si des correctifs sont encore disponibles.

Une boutique en version 8 : le socle recommandé

La branche 8 bénéficie d'un support actif et d'une compatibilité étendue avec les versions récentes de PHP. Elle reste néanmoins soumise à des mises à jour mineures régulières qu'il convient d'appliquer pour conserver le niveau de sécurité attendu.

Construire un audit technique du parc, étape par étape

Recenser les éléments techniques essentiels

Un audit sérieux ne se limite pas à la version du cœur. Il doit couvrir :

• La version de PHP utilisée et sa date de fin de support (consultable sur php.net).
• La liste des modules installés, actifs ou non, et leur date de dernière mise à jour.
• Le thème utilisé : natif, acheté sur une marketplace, ou développé sur mesure.
• Les surcharges de code (« overrides ») qui modifient le comportement standard et compliquent les futures mises à jour.
• La configuration serveur : base de données, cache, certificat SSL.

Identifier les écarts entre back-office et réalité du code

Il arrive que la version affichée dans le back-office ne corresponde pas exactement à l'état réel des fichiers, notamment après des interventions manuelles. Un audit technique rigoureux compare la version annoncée avec l'empreinte des fichiers cœurs pour détecter d'éventuelles modifications non documentées.

Évaluer la compatibilité avec les évolutions réglementaires

La facturation électronique obligatoire entre entreprises, dont le calendrier est précisé sur impots.gouv.fr, ainsi que les exigences de sécurité des paiements liées à la DSP2, nécessitent des connecteurs et des modules à jour. Une version ancienne de PrestaShop peut rendre ces mises en conformité plus complexes, voire impossibles sans migration préalable.

Que faire une fois le diagnostic posé ?

Cas 1 : la version est ancienne et non maintenue

Dans ce cas, une migration vers une version supportée devient prioritaire, idéalement planifiée en dehors des périodes de forte activité commerciale. Cette migration doit être précédée d'un audit des modules et du thème pour anticiper les incompatibilités.

Cas 2 : la version est récente mais mal entretenue

Une version à jour ne suffit pas si les mises à jour mineures de sécurité ne sont pas appliquées régulièrement, ou si des modules obsolètes restent actifs. Un contrat de maintenance structuré, avec des points de contrôle réguliers, permet d'éviter ce décalage silencieux.

Cas 3 : la version est correcte, mais la boutique ne performe plus

Dans ce cas, l'enjeu n'est plus la version elle-même mais l'optimisation : temps de chargement, taux de conversion, expérience mobile. Ces sujets relèvent d'un diagnostic de performance distinct, complémentaire à l'audit de version.

Quel que soit le résultat du diagnostic, la décision suivante (correctif, migration, refonte) doit s'appuyer sur un document d'audit écrit, daté, et partageable avec plusieurs prestataires pour comparer des devis sur une base identique. C'est cette rigueur qui évite les mauvaises surprises en cours de projet.