La grille d'évaluation du risque des modules PrestaShop

Vous n'avez pas besoin de savoir lire le PHP pour déterminer si un module PrestaShop peut être installé sans risque sur votre boutique en production. La plupart des dégâts causés par un mauvais module sont visibles depuis un navigateur et votre back-office — à condition de savoir où regarder. Voici la liste de contrôle que nous utilisons, rédigée pour qu'un commerçant puisse l'exécuter sans développeur.

L'idée est simple. Un module est du code non cloisonné qui s'exécute avec l'ensemble des privilèges de votre boutique : il peut charger des ressources sur chaque page, écrire dans votre base de données, modifier le comportement du cœur et communiquer avec d'autres serveurs. Alors, plutôt que de vous fier à la page de vente, vous observez ce que le module fait réellement sur une copie sécurisée de votre boutique, et vous lui attribuez une note. Dix cases vertes sur douze, et c'est un module que vous pouvez installer en toute confiance. Mais la note ne dit pas tout : certaines lignes sont des blocages absolus. Un signal d'alerte sur le checkout ou les données clients, sur le test de réversibilité, sur un nouveau domaine externe ou sur des surcharges non déclarées signifie que le module reste hors de votre boutique en production tant que l'éditeur ne s'en explique pas — quoi que disent les autres lignes.

Faites-le d'abord sur une copie de préproduction — jamais en production. Dupliquez votre boutique (la plupart des hébergeurs proposent un clone de préproduction en un clic), ou utilisez une installation jetable avec votre thème et vos autres modules présents. Vous voulez que le module se confronte à la même réalité désordonnée que votre vraie boutique : votre thème, votre configuration de langue et de devise, vos modules existants, vos versions de PrestaShop et de PHP. Un module qui ne se comporte correctement que sur une installation vierge vous dit quelque chose.

Les douze vérifications

1. Domaines externes et CDN

Comment l'exécuter : ouvrez la page d'accueil de votre boutique — pas la page de réglages du module — dans votre navigateur, appuyez sur F12 pour ouvrir les outils de développement, cliquez sur l'onglet Réseau et rechargez la page. Triez par domaine. Notez chaque domaine qui n'est pas le vôtre. Installez maintenant le module et rechargez à nouveau. Un nouveau domaine tiers est-il apparu ?

Réussite : aucun nouveau domaine externe sur les pages qui n'utilisent pas la fonctionnalité. Cas d'échec : c'est exactement le piège décrit dans notre essai — un module qui charge une police, un script ou un traceur depuis le serveur de quelqu'un d'autre sur chaque page, ajoutant des résolutions DNS, du poids, une exposition en matière de vie privée et une dépendance à un serveur que vous ne contrôlez pas. Si ce serveur est lent ou hors service un jour, le rendu de votre boutique peut se bloquer ou se dégrader avec lui.

Si vous préférez les compter précisément plutôt que de lire la liste à l'œil, collez ceci dans le même onglet Console des outils de développement et appuyez sur Entrée — il liste chaque domaine qui n'est pas le vôtre et le nombre de requêtes que chacun a effectuées :

// On your homepage: reload the page first, then paste this into DevTools → Console.
const here = location.host;
const thirdParty = {};
for (const r of performance.getEntriesByType('resource')) {
    const host = new URL(r.name).host;
    if (host && host !== here) {
        thirdParty[host] = (thirdParty[host] || 0) + 1;
    }
}
console.table(thirdParty); // each row is an external host your page called

Il compte chaque hôte qui n'est pas votre domaine principal — y compris les éventuels sous-domaines de CDN que vous gérez vous-même, que vous pouvez ignorer sans risque. Exécutez-le avant d'installer le module, puis à nouveau après : tout hôte véritablement nouveau est un nouveau tiers dont votre boutique dépend désormais.

C'est la vérification la plus précieuse de la liste, car elle repère exactement la défaillance de notre essai : un module qui ajoute discrètement un domaine tiers à chaque page. Si un hôte apparaît ici sans que vous l'ayez ajouté intentionnellement, arrêtez-vous et demandez à l'éditeur pourquoi, avant que le module n'atteigne votre boutique en production.

2. Ressources globales du front-office

Comment l'exécuter : dans le même onglet Réseau, filtrez par CSS et JS, et comparez le nombre sur votre page d'accueil avant et après l'installation. Vérifiez ensuite une page que le module devrait affecter, et une page qu'il ne devrait pas.

Réussite : les feuilles de style et scripts du module ne se chargent que sur les pages qui les utilisent. Cas d'échec : un « petit » module qui enregistre ses ressources sur un hook d'en-tête global alourdit chaque page de la boutique, y compris le checkout, pour une fonctionnalité qui se trouve sur une seule. Multipliez cela par une douzaine de modules négligents et vous obtenez une boutique lente sans coupable unique.

3. Surcharges

Comment l'exécuter : avant l'installation, examinez le dossier /override de votre boutique via FTP ou le gestionnaire de fichiers de votre hébergeur (vous vérifiez seulement si des fichiers apparaissent — vous n'avez pas besoin de les lire). Installez le module, puis regardez à nouveau.

Réussite : aucun nouveau fichier n'est apparu dans /override (un dossier standard contient déjà des fichiers index.php de remplissage — vous cherchez les nouveaux). Cas d'échec : les surcharges vivent dans /override et modifient le comportement des classes et contrôleurs du cœur de PrestaShop. Deux modules qui surchargent la même classe entrent en conflit et — c'est crucial — une surcharge laissée en place après une désinstallation est l'une des principales causes du « ma boutique est cassée et désactiver les modules n'a rien réglé ». Les bons modules utilisent des hooks et des services plutôt que de surcharger le cœur.

4. Hooks utilisés

Comment l'exécuter : dans le back-office, allez dans Apparence › Positions (l'écran des hooks) et regardez où le module s'est enregistré. Vous pouvez aussi généralement voir les hooks d'un module sur sa page de configuration.

Réussite : les hooks correspondent à la fonctionnalité. Un module de livraison se branche sur la livraison et le checkout ; un module d'onglet produit se branche sur la page produit. Cas d'échec : un module branché sur chaque page — displayHeader, displayFooter sur tout — « au cas où », alors que sa fonctionnalité n'apparaît qu'à un seul endroit. Chacun de ces hooks est du code qui s'exécute à chaque chargement de page.

5. Modifications du schéma de base de données

Comment l'exécuter : dans l'outil de base de données de votre hébergeur (phpMyAdmin ou similaire), notez le nombre de tables avant l'installation. Installez, et regardez ce qui a été ajouté — vous vérifiez les noms, pas le contenu.

Réussite : les nouvelles tables portent clairement l'espace de noms du module (un préfixe reconnaissable) et, idéalement, sont documentées. Une poignée de tables bien nommées est tout à fait normale et sans problème. Cas d'échec : un module qui disperse des tables non étiquetées, ou qui écrit dans les tables du cœur de PrestaShop d'une manière qu'il ne déclare pas, est un module que vous ne pourrez pas analyser proprement plus tard.

Si vous avez accès à la base de données (phpMyAdmin ou la ligne de commande), vous pouvez lister exactement ce qu'un module a ajouté. Notez la liste avant l'installation, puis exécutez-la à nouveau après et comparez :

-- Note the list before installing, then run it again afterwards and compare.
SHOW TABLES;

-- Most well-built modules prefix their own tables — list them (base table + children):
SHOW TABLES LIKE 'ps\_mymodule%';

Une liste courte et clairement préfixée est saine. Une dispersion de tables non étiquetées — ou des écritures non déclarées dans les tables du cœur comme ps_orders ou ps_customer — est ce que vous surveillez. (ps_ est le préfixe de table par défaut ; remplacez-le par le vôtre si vous l'avez changé, et utilisez le nom technique du module à la place de mymodule.)

6. Nettoyage à la désinstallation

Comment l'exécuter : après votre vérification du schéma, désinstallez le module et regardez à nouveau la base de données. Qu'a-t-il supprimé, et qu'a-t-il laissé ?

Réussite : le module supprime ce qu'il a créé — ou indique clairement dans sa documentation ce qu'il conserve délibérément et pourquoi (conserver vos réglages pour une future réinstallation est un choix légitime, s'il est déclaré). Cas d'échec : des résidus silencieux. Des tables orphelines, des lignes de configuration et des fichiers obsolètes qui s'accumulent à chaque fois que vous essayez un module. C'est la ligne où le « je n'aurai qu'à le désinstaller » échoue en silence.

7. Tâches planifiées et webhooks

Comment l'exécuter : vérifiez la documentation et la page de configuration du module pour tout ce qui s'exécute selon un calendrier ou appelle un service externe en arrière-plan — synchronisations, flux, tâches de nettoyage, intégrations de type « connectez votre compte ».

Réussite : les tâches en arrière-plan sont déclarées, et vous pouvez les désactiver. Cas d'échec : une activité en arrière-plan non déclarée — une tâche qui sollicite votre base de données selon un calendrier, ou un webhook qui expédie vos données quelque part sans que vous le sachiez. Vous ne pouvez pas gérer ce que vous ne savez pas être en cours d'exécution.

8. Points de contact avec le checkout, les commandes et les données clients

Comment l'exécuter : le module installé sur la préproduction, passez une commande de test complète de bout en bout. Recherchez un produit. Ouvrez une page produit. Ouvrez les principaux écrans du back-office. Tout fonctionne-t-il encore exactement comme avant ?

Réussite : le checkout, la recherche, les pages produit et l'administration ne sont pas affectés, sauf si c'est littéralement le rôle du module. Cas d'échec : un module qui touche au parcours de commande ou aux fiches clients touche à votre chiffre d'affaires et à vos obligations de conformité. Un checkout qui se casse — ou qui calcule mal en silence — vous coûte de l'argent réel le jour de sa mise en production, pas dans un laboratoire.

9. Multiboutique, langue et devise

Comment l'exécuter : si vous gérez plus d'une boutique, plus d'une langue ou plus d'une devise, testez le module dans chacune. Changez de boutique, changez de langue, changez de devise, et utilisez la fonctionnalité.

Réussite : le module respecte votre configuration — correct par boutique, traduit par langue, montants corrects par devise. Cas d'échec : un module construit et testé sur « boutique 1, anglais, euros » qui code en dur ces hypothèses. Il a l'air correct dans la démo et s'effondre sur votre deuxième boutique ou sur les prix de vos clients polonais.

10. Compatibilité PrestaShop et PHP

Comment l'exécuter : lisez la déclaration de compatibilité sur la page produit, et confrontez-la à votre version de PrestaShop (1.7, 8.x ou 9.x) et à votre version de PHP.

Réussite : l'éditeur nomme les versions exactes prises en charge par le module et les maintient à jour au fur et à mesure des nouvelles versions de PrestaShop. Cas d'échec : « compatible avec toutes les versions ». Aucun module sérieux n'est testé sur chaque version de PrestaShop et de PHP jamais publiée ; cette affirmation relève du marketing, et c'est la ligne la plus susceptible de casser le jour où vous mettrez votre boutique à niveau.

11. Journal des modifications et suivi du support

Comment l'exécuter : cherchez un journal des modifications daté et un véritable canal de support avant d'acheter.

Réussite : le module dispose d'un historique visible de mises à jour et d'un moyen de joindre une personne réelle qui le maintient. Cas d'échec : pas de journal des modifications et pas de support signifie pas de responsable. Un module sans maintenance est un module qui finira par cesser de fonctionner lors d'une mise à niveau de PrestaShop ou de PHP, sans personne pour le réparer — et vous le découvrirez au pire moment possible.

12. Le test de réversibilité

Comment l'exécuter : c'est toute la liste de contrôle en un seul geste, sur la préproduction. Prenez un instantané de votre boutique. Installez le module. Désactivez-le. Désinstallez-le. Comparez la boutique à votre instantané.

Réussite : installer → désactiver → désinstaller laisse la boutique essentiellement dans l'état où elle était — pas de fichiers résiduels, pas de tables orphelines, pas de pages cassées. Cas d'échec : tout ce qui ne revient pas. Si un module ne peut pas être retiré proprement sur une copie de test, il ne pourra certainement pas l'être proprement sur votre boutique en production, sous pression.

Signaux d'alerte, et ce que chacun signifie vraiment

Vous n'aurez pas toujours le temps de faire les douze vérifications. Voici les raccourcis — des signaux qui, à eux seuls, justifient un examen bien plus approfondi. Chacun correspond à une manière concrète dont les choses tournent mal :

Aucun de ces éléments ne prouve qu'un module est mauvais. Du code bon marché et simple peut être parfaitement bon ; un petit éditeur peut être excellent. Le problème n'est jamais le prix ni l'auteur — c'est le risque non maîtrisé. Un signal d'alerte signifie simplement que le risque n'a pas été maîtrisé pour vous, et que vous devez donc le maîtriser vous-même avant qu'il n'atteigne votre boutique en production.

Où se situent les standards officiels

PrestaShop publie lui-même les règles techniques qu'un module bien construit est censé respecter. Vous n'avez pas besoin de les mettre en œuvre, mais elles sont utiles pour orienter un éditeur, et elles recoupent une grande partie de ce qui précède. PrestaShop publie les Standards de développement technique qu'un module bien construit est censé suivre — discipline dans les surcharges, hygiène concernant les tables du cœur et la performance des ressources, sécurité et compatibilité des versions — aux côtés des Standards de qualité derrière le badge Verified+ sur la marketplace Addons. Ni l'un ni l'autre n'est une garantie en soi — de nombreux bons modules existent en dehors de la marketplace, et un badge ne remplace pas les observations ci-dessus — mais ils font raisonnablement partie du tableau. Si vous achetez via la marketplace, notre guide d'achat de la marketplace PrestaShop Addons explique comment lire une fiche.

Un ordre d'installation sûr, du début à la fin

Mis bout à bout, tout cela forme une seule séquence tranquille :

• Sauvegardez votre boutique en production — fichiers et base de données.
• Installez sur une copie de préproduction qui reflète votre vrai thème, vos modules et vos réglages.
• Prenez un instantané de la boutique de préproduction, puis effectuez les douze vérifications ci-dessus.
• Surveillez l'onglet Réseau sur votre page d'accueil pour repérer les nouveaux domaines et les ressources chargées sur tout le site.
• Passez une commande de test et sollicitez la recherche, les pages produit et l'administration.
• Désinstallez et comparez à votre instantané — confirmez que tout revient proprement.
• Seulement alors, installez en production, pendant une période calme, et vérifiez vos pages clés une fois de plus.

Questions fréquentes

Ai-je besoin d'un développeur pour évaluer un module ?

Pour la plupart de ces vérifications, non. Compter les requêtes tierces, tester le checkout et exécuter le test installer → désactiver → désinstaller sont autant de choses que vous pouvez faire depuis un navigateur et votre back-office sur une copie de préproduction. Deux vérifications — examiner /override, lister les tables de la base de données — nécessitent un accès aux fichiers ou à la base de données, que votre hébergeur ou votre développeur peut vous fournir, mais vous n'avez jamais à lire le moindre code.

Si un module est sur la marketplace officielle PrestaShop, est-il automatiquement sûr ?

La validation de la marketplace et le badge Verified+ sont un signal réel et utile — ils vérifient beaucoup de ces éléments pour vous. Mais ils ne remplacent pas le fait d'observer le module se comporter sur votre propre boutique, avec votre thème et vos autres modules. De nombreux bons modules existent aussi en dehors de la marketplace. Effectuez les vérifications dans tous les cas.

Le module est gratuit — est-ce un signal d'alerte en soi ?

Non. Les modules gratuits et bon marché peuvent être excellents, et les modules coûteux peuvent être négligés. Le prix ne vous dit rien sur la manière dont le code se comporte. La grille d'évaluation porte sur le risque maîtrisé, pas sur le coût : un module gratuit qui passe ces vérifications est plus sûr qu'un module payant qui les échoue.

Si je n'ai le temps que pour une seule vérification, laquelle ?

Ouvrez l'onglet Réseau de votre page d'accueil et comptez les nouveaux domaines tiers après l'installation. Cela prend une minute, ne nécessite aucun code, et repère le type de module négligent le plus courant et le plus dommageable — celui qui taxe chaque page pour une fonctionnalité que vous ne verrez que rarement.

Écrit noir sur blanc, cela paraît beaucoup ; en pratique, c'est l'affaire d'un après-midi, et c'est bien moins cher que l'après-midi que vous passeriez sinon à découvrir pourquoi votre boutique est devenue lente, ou pourquoi une page ne revient pas après avoir retiré le module qui l'avait cassée. Pour l'histoire qui explique pourquoi cela compte — et un récit honnête d'une erreur que nous avons nous-mêmes commise — lisez ce qu'un module PrestaShop peut faire que la désinstallation n'annulera pas. Et oui : appliquez aussi cette liste de contrôle à nos modules. C'est fait pour ça. Si vous souhaitez qu'on le fasse pour vous, notre scan de sécurité gratuit et notre audit de performance reposent exactement sur ces vérifications — et si vous préférez que votre boutique surveille ces éléments en continu plutôt qu'au moment de l'installation, c'est le rôle de Performance Revolution et de Security Revolution.