Modules PrestaShop : la règle avant la liste.

Il n’existe pas de liste de modules PrestaShop indispensables ; il existe une règle de décision, et elle tient en deux phrases. On n’installe pas un module pour une fonction qu’un développeur écrit en une journée. Et on n’installe jamais — jamais — un module qui touche au routage, au panier ou au paiement pour un simple gain de confort. Cet article ne vous donnera donc pas de noms : un nom de module est invérifiable sans accès à sa page du moment, et périmé en six mois. Il vous donnera mieux : la grille qui permet de juger n’importe quel module, aujourd’hui comme dans trois ans.

Le raisonnement s’appuie sur des mesures faites sur banc et déjà publiées dans cette série : le coût d’un script tiers sur l’affichage (de 268 ms à 760 ms pour l’élément principal), l’effet d’une politique de sécurité de contenu sur les requêtes sortantes (de 3 à 0), et une requête SQL que vous pouvez lancer telle quelle sur votre propre boutique pour mesurer votre dette de modules. Tout ce qui suit se vérifie ; rien ne se croit sur parole.

Les trois coûts d’un module — et pourquoi le troisième est le seul qui compte

Le prix affiché d’un module est le plus petit de ses trois coûts. Le premier est l’achat, connu et borné. Le deuxième est l’abonnement : mises à jour et support payants à l’année, souvent au tiers ou à la moitié du prix initial — vérifiez la grille de l’éditeur au moment de l’achat, elles bougent. Le troisième est le coût de compatibilité, et c’est lui qui décide de tout : chaque module installé devra suivre chaque montée de version du cœur, pendant toute la vie de la boutique, sous peine de la bloquer.

Ce troisième coût a deux propriétés désagréables. Il est différé : on le découvre au moment de la montée de version, c’est-à-dire au pire moment. Et il est composé : il croît avec le nombre de modules, pas avec leur prix. L’article de cette série consacré à la sécurité des boutiques en fait l’arithmétique complète — avec trente modules et une probabilité de blocage de 5 % chacun, la probabilité qu’au moins un module bloque une montée de version atteint 79 % — et notre retour d’expérience après quinze ans de PrestaShop raconte ce que cette formule donne en vrai sur des boutiques qui vivent longtemps.

D’où la conclusion qui structure tout l’article : évaluer un module, c’est évaluer un engagement de plusieurs années auprès d’un éditeur, pas une fonctionnalité. La fonctionnalité, elle, s’évalue en une démonstration ; l’éditeur s’évalue sur sa durée d’existence, son rythme de publication et sa réactivité au support — trois choses qui se vérifient sur sa page avant l’achat.

Pour comparer honnêtement un module à son alternative en sur-mesure, posez le coût à trois ans plutôt que le prix du jour. La formule tient sur une ligne :

cout_3_ans = achat + 3 x abonnement + 3 x heures_compatibilite x taux_horaire

Les deux premiers termes se lisent sur la page de l’éditeur au moment où vous la consultez. Le troisième s’estime avec votre prestataire : combien d’heures par an ce module coûtera-t-il en suivi de versions, en tests de fenêtre mensuelle, en incidents de compatibilité ? Même une estimation grossière — une heure par an pour un module simple, une journée pour un module qui surcharge des classes du cœur — suffit à renverser des comparaisons qui paraissaient évidentes sur le seul prix d’achat. Faites le produit vous-même : les nombres se calculent, ils ne se devinent pas.

La grille de décision en quatre questions

Avant tout achat, quatre questions, dans cet ordre. Chacune peut arrêter la discussion.

Grille de décision avant l’installation d’un module — quatre questions, dans l’ordre, et ce qui arrête la discussion

Question	Comment y répondre	Réponse qui arrête tout
1. Le cœur le fait-il déjà ?	Chercher dans le back-office et la documentation officielle avant la place de marché	Oui — une part des modules vendus recouvre des fonctions natives mal connues
2. Est-ce moins d’une journée de développement ?	Demander un chiffrage à votre prestataire, avec la consigne « sans module »	Oui — le sur-mesure d’une journée ne coûte ni abonnement ni compatibilité future
3. Touche-t-il au routage, au panier ou au paiement ?	Lire la description technique : surcharges, points d’accroche utilisés	Oui, pour un gain de confort — le risque porte sur la partie de la boutique qui encaisse
4. L’éditeur survivra-t-il au module ?	Ancienneté, journal des versions, délai de réponse au support (posez une question avant d’acheter)	Journal des versions muet depuis plus d’un an, ou support silencieux

La question 2 mérite une précision, parce qu’elle surprend : oui, une journée de développement sur mesure coûte souvent plus cher que le module au moment de l’achat. Mais la comparaison honnête se fait sur la durée : le sur-mesure d’une journée n’a ni abonnement annuel, ni éditeur qui disparaît, ni incompatibilité surprise — son code vous appartient et suit le cœur avec le reste de la boutique. À trois ans, l’ordre des coûts s’inverse fréquemment. C’est le même raisonnement que pour le prix d’une boutique dans son ensemble : le montant du devis initial est le mauvais chiffre à comparer, le coût de possession est le bon.

Les fonctions où un module est presque toujours le bon choix

La règle n’est pas « le moins de modules possible », elle est « un module là où il est plus sûr que du code maison ». Trois familles remplissent ce critère, pour la même raison de fond : elles encapsulent une complexité externe qui change souvent, et c’est l’éditeur qui absorbe ces changements à votre place.

Les connecteurs de paiement d’abord : un module de paiement édité par le prestataire de paiement lui-même suit les évolutions de son interface de programmation, ses obligations d’authentification et ses certifications — autant de choses qu’un développement maison devrait suivre seul, en portant la responsabilité d’une rupture. Les connecteurs logistiques et comptables ensuite (transporteurs, facturation, flux vers la gestion commerciale), pour la même raison : la complexité est chez le tiers, le module est la couche d’adaptation, et l’éditeur la maintient. Les exports réglementaires et fiscaux enfin, où l’enjeu n’est pas la difficulté technique mais la veille : les règles changent, et l’abonnement paie précisément cette veille.

Le point commun se retient facilement : dans ces trois familles, l’abonnement rémunère un travail réel et récurrent de l’éditeur. Quand l’abonnement ne rémunère aucune évolution externe — le module fait la même chose depuis trois ans et le paierait aussi bien sans vous —, c’est le premier signe que la fonction relevait du sur-mesure.

Les fonctions où un module est presque toujours une erreur

À l’inverse, quatre familles concentrent les mauvais achats. Les modules d’apparence — constructeurs de page, carrousels, effets — parce qu’ils chargent leurs propres bibliothèques sur toutes les pages pour un usage local, et que leur désinstallation laisse le thème truffé de références mortes. Les modules de « performance » qui promettent d’accélérer une boutique de l’extérieur : la lenteur d’une boutique a une cause mesurable — requêtes, images, scripts tiers — et un module qui ne corrige pas la cause l’enrobe. Les modules qui réécrivent le tunnel de commande pour un gain cosmétique : ils touchent exactement à la zone que la question 3 protège, et chaque montée de version du cœur les remet en cause. Et les modules à tout faire, qui cumulent vingt fonctions dont vous en utilisez deux : vous payez la surface d’attaque et la charge des dix-huit autres.

Une mesure fixe les idées sur le coût réel de ces familles. Sur un même banc, l’ajout d’un seul script tiers en tête de page fait passer l’affichage de l’élément principal de 268 ms à 760 ms — un facteur proche de trois, pour un script. Or les modules d’apparence et de mesure d’audience sont précisément ceux qui injectent des scripts tiers en tête de page. La même série de mesures montre le remède : une politique de sécurité de contenu correctement écrite fait tomber de 3 à 0 le nombre de requêtes partant vers des tiers — autrement dit, ce que vous n’autorisez pas explicitement ne part pas, quel que soit le module qui essaie.

Retenez l’asymétrie : les modules de la section précédente travaillent côté serveur et ne coûtent rien au visiteur ; ceux de cette section travaillent dans le navigateur du visiteur et lui coûtent, à chaque page, un temps qui se mesure en centaines de millisecondes.

Un mot de méthode sur la politique de sécurité de contenu, puisqu’elle est le garde-fou de toute cette famille : elle se déploie sans risque en deux temps. D’abord en mode observation, avec l’en-tête Content-Security-Policy-Report-Only, qui journalise ce qui serait bloqué sans rien bloquer — quelques jours de production suffisent pour dresser la liste réelle des domaines contactés par vos pages, modules compris. Ensuite seulement en mode strict, avec Content-Security-Policy, en n’autorisant que ce que la liste justifie. Le sous-produit est précieux : la phase d’observation est, en soi, un audit des modules bavards — tout domaine inconnu qui apparaît dans les rapports a un module derrière lui, et ce module a une explication à fournir. C’est ainsi que le passage de 3 à 0 requêtes tierces cité plus haut a été obtenu : pas en désinstallant à l’aveugle, en refusant d’autoriser ce qui ne se justifiait pas.

Le test d’un module avant installation

Quand un module a passé la grille, il reste à le tester — sur la préproduction, jamais en production, et selon un protocole en trois temps qui tient en une demi-journée.

Mesurer avant. Trois pages de référence — accueil, une fiche produit, le panier — passées dans l’outil d’audit du navigateur, résultats notés : temps d’affichage de l’élément principal, poids transféré, nombre de requêtes, domaines tiers contactés. Sans point de départ, aucun « après » ne prouve rien.

Lire ce que le module fait. Pas ligne à ligne : structurellement. Le dossier override/ du module dit s’il remplace des classes du cœur — chaque surcharge est un conflit potentiel avec le prochain module et la prochaine version. La liste de ses points d’accroche dit où il s’exécute : un module de pied de page qui s’accroche au panier doit expliquer pourquoi. Et ses appels sortants se voient dans l’onglet réseau : un module qui téléphone à un domaine inconnu à chaque page a perdu d’office.

Mesurer après, et rejouer. Les mêmes trois pages, les mêmes relevés, plus une commande de bout en bout avec paiement en mode test. Toute dégradation se paie en connaissance de cause ou fait rejeter le module — mais elle ne se découvre pas en production trois semaines plus tard.

Sur la lecture du code, deux vérifications rapides valent mieux qu’une revue complète que personne ne fera. Un balayage du code du module à la recherche d’exécution dynamique et d’appels sortants — grep -rn "eval(" modules/nom_du_module/ puis la même recherche sur curl_exec et file_get_contents("http — dit en une minute si le module exécute du code construit à la volée ou téléphone à l’extérieur depuis le serveur. Aucun des deux n’est disqualifiant en soi — un connecteur appelle légitimement son prestataire —, mais chaque occurrence doit correspondre à une fonction annoncée. Un module de carrousel qui contacte un serveur distant n’a pas d’explication acceptable.

Ce protocole a un sous-produit précieux : il vous laisse une trace écrite, datée, des mesures avant/après pour chaque module installé. Le jour où la boutique ralentit, cette trace transforme deux jours d’enquête en dix minutes de lecture.

Mesurer la dette de modules d’une boutique existante

Pour une boutique déjà en production, la première étape n’est pas d’acheter, c’est d’inventorier. Deux commandes suffisent, et vous pouvez les lancer aujourd’hui. La première compte et décrit ce qui est enregistré côté base :

SELECT m.id_module, m.name, m.active, m.version,
       COUNT(hm.id_hook) AS points_daccroche
FROM ps_module m
LEFT JOIN ps_hook_module hm ON hm.id_module = m.id_module
GROUP BY m.id_module, m.name, m.active, m.version
ORDER BY points_daccroche DESC;

La seconde compare la base au disque : listez le contenu du dossier modules/ et rapprochez-le du résultat précédent. Trois populations apparaissent, et chacune appelle un traitement différent : les modules actifs (à justifier un par un avec la grille en quatre questions), les modules désactivés mais présents (leur code reste sur le serveur, donc leur surface d’attaque aussi : à désinstaller puis supprimer du disque), et les modules sur le disque sans enregistrement en base — restes d’essais ou d’anciens prestataires, à supprimer sans état d’âme après sauvegarde.

Les quatre populations révélées par l’inventaire, le risque que chacune porte et son traitement

Population	Risque porté	Traitement
Actifs et justifiés par la grille	Coût de compatibilité assumé	Conserver, suivre les avis de l’éditeur, mesurer à chaque fenêtre
Actifs sans réponse à « et si on le retirait demain ? »	Compatibilité et surface d’attaque payées pour rien	Remplacer par du natif ou une journée de sur-mesure, puis retirer
Désactivés mais présents sur le disque	Le code reste exécutable : surface d’attaque intacte	Désinstaller proprement par le back-office, puis supprimer le dossier
Sur le disque sans enregistrement en base	Code orphelin que plus personne ne surveille	Supprimer après sauvegarde, sans état d’âme

Complétez par le relevé des surcharges globales : le contenu de override/ à la racine dit quelles classes du cœur ont été remplacées, et par qui — chaque fichier de ce dossier est une dette qui se rappellera à vous à la prochaine montée de version. Un dossier override/ vide est un signe de boutique saine ; un dossier fourni sans documentation est le premier chantier à ouvrir.

Le résultat de l’inventaire se lit avec une règle simple : chaque ligne active doit pouvoir répondre à la question « que se passerait-il si on le retirait demain ? ». Les lignes sans réponse sont votre dette, et son remboursement — désinstallation, remplacement par du natif ou par une journée de sur-mesure — est presque toujours le chantier au meilleur rapport effort/effet d’une boutique chargée.

Comment sortir d’une dette de modules

La sortie se fait par lots, en préproduction, avec la même discipline de mesure que l’installation — dans l’autre sens. D’abord les modules sur disque sans enregistrement : suppression simple, risque nul, gain immédiat de surface d’attaque. Ensuite les désactivés : désinstallation propre par le back-office (qui nettoie tables et réglages), puis suppression du dossier. Enfin les actifs non justifiés, un par un, du moins accroché au plus accroché — la colonne points_daccroche de la requête donne l’ordre de marche —, avec à chaque retrait le rejeu d’une commande complète.

Deux pièges connus. Certains modules laissent des références dans le thème (appels de fonctions, blocs) : le retrait doit inclure un passage sur les gabarits, sinon la boutique journalise des erreurs à chaque page. Et certains modules stockent des données métier dans leurs propres tables — des avis clients, des champs personnalisés : exportez avant de désinstaller, car la désinstallation propre supprime aussi les tables. C’est le genre de chantier qu’il vaut mieux confier à une équipe de développement PrestaShop qui l’a déjà fait, non parce qu’il est difficile, mais parce que les pièges s’y apprennent une fois.

Sur le rythme, la bonne unité est la fenêtre mensuelle décrite dans notre article sur la sécurité des boutiques : deux ou trois retraits par fenêtre, chacun suivi de son rejeu, plutôt qu’un grand nettoyage d’un week-end qui mélange dix causes possibles au premier incident. Et mesurez le gain comme vous avez mesuré la dette : reprenez les trois pages de référence à la fin de chaque lot — poids transféré, nombre de requêtes, domaines tiers. C’est ce relevé, pas une impression, qui dira si le chantier a produit son effet ; et c’est lui qui convaincra la direction de financer le lot suivant. Une dette de modules s’est constituée achat par achat ; elle se rembourse retrait par retrait, avec un relevé à chaque étape.

Le tableau récapitulatif

Synthèse par famille de fonctions : module, sur-mesure ou natif, et le critère qui tranche

Famille de fonctions	Choix par défaut	Le critère qui tranche
Paiement	Module de l’éditeur du prestataire de paiement	L’éditeur absorbe les évolutions du prestataire et leurs certifications
Logistique, comptabilité, flux	Module connecteur maintenu	La complexité vit chez le tiers ; l’abonnement paie son suivi
Obligations fiscales et réglementaires	Module avec veille active	On paie la veille, pas le code
Apparence, carrousels, constructeurs	Thème et gabarits propres	Coût mesuré côté visiteur, désinstallation salissante
« Performance »	Corriger la cause mesurée	Un module qui n’enlève ni requêtes ni poids n’accélère rien
Tunnel de commande	Natif, ajustements en sur-mesure	Zone qui encaisse : aucun confort ne vaut le risque
Petites fonctions métier	Sur-mesure d’une journée	Pas d’abonnement, pas d’éditeur, code qui vous appartient

Ce qu’il faut retenir

Un module a trois coûts — l’achat, l’abonnement, la compatibilité — et seul le troisième décide, parce qu’il est différé et composé : c’est lui qui, module après module, transforme une montée de version en projet à risque. La grille tient en quatre questions posées dans l’ordre : le cœur le fait-il déjà, est-ce moins d’une journée de développement, est-ce que ça touche au routage, au panier ou au paiement, et l’éditeur survivra-t-il au module. Une seule mauvaise réponse suffit à s’abstenir.

Les mesures donnent l’ordre de grandeur de ce qui se joue côté visiteur : un seul script tiers en tête de page fait passer l’affichage de l’élément principal de 268 ms à 760 ms sur le même banc, et une politique de sécurité de contenu bien écrite ramène de 3 à 0 les requêtes qui partent vers des tiers. Les modules qui travaillent côté serveur — paiement, connecteurs, exports — ne coûtent rien au visiteur ; ceux qui travaillent dans son navigateur lui coûtent des centaines de millisecondes par page.

Enfin, sur une boutique existante, tout commence par l’inventaire : une requête sur ps_module et ps_hook_module, un rapprochement avec le dossier modules/, un relevé des surcharges dans override/. Chaque module actif doit répondre à « que se passerait-il si on le retirait demain ? » ; les lignes sans réponse sont la dette, et leur remboursement est le chantier au meilleur rapport effort/effet d’une boutique chargée.