# Modules et extensions : acheter, faire développer, réparer

> Une boutique en ligne ne se distingue presque jamais par sa plateforme, mais par les modules qu’on lui ajoute. Cette rubrique réunit vingt-quatre pages sur ce terrain : décider entre l’achat et le développement, cadrer un besoin, et comprendre ce qui se passe quand un module cesse de fonctionner.

- Source canonique : [https://allaux.fr/modules](https://allaux.fr/modules)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## À qui s’adresse cette rubrique

On arrive ici dans deux états d’esprit très différents. Soit il manque une fonction : un configurateur de produit, un paiement en plusieurs fois, un écran de suivi pour l’équipe, une notification qui n’existe pas en standard. Soit un module déjà installé pose problème : il a cessé de s’afficher après une mise à jour, il entre en conflit avec un autre, il ralentit chaque page, ou son éditeur ne répond plus.

Dans les deux cas la question de fond est la même : jusqu’où faut-il s’appuyer sur l’existant, et à partir de quand vaut-il mieux écrire du code que l’on maîtrise. Ces pages répondent en donnant les critères, pas une recommandation unique — le bon arbitrage dépend du volume de commandes, de la durée de vie prévue de la boutique et de qui la maintiendra ensuite.

## Comment la rubrique est organisée

Les vingt-quatre pages suivent le cycle de vie d’un module. Les pages de décision d’abord : acheter ou faire développer, officiel, tiers ou sur mesure, ce qui fait réellement le prix, comment cadrer un besoin avant de demander un devis. Puis les besoins fonctionnels les plus fréquents : abonnement et espace membre, acompte et paiement fractionné, configurateur, documents PDF, notifications, champ supplémentaire sur un produit ou une commande, écran métier dans le back-office, service après-vente, traitement en tâche de fond.

Viennent ensuite les pannes : module cassé après une mise à jour, conflit entre deux modules, module actif dont rien ne s’affiche, modifications écrasées, module qui ralentit la boutique, éditeur disparu. Et enfin le cycle de vie : auditer un parc de modules, tester avant la production, désinstaller proprement, maintenir dans le temps, reprendre un développement inachevé.

## Ce qu’un module fait vraiment à votre boutique

Un module n’est pas une brique posée à côté du site : il s’insère dedans. Sur PrestaShop, il se greffe sur des hooks, ajoute ses tables, et peut déposer un fichier dans override/ pour modifier le comportement d’une classe du cœur. C’est là que naissent la plupart des conflits : deux modules qui veulent surcharger la même méthode ne peuvent pas coexister, et le second refuse simplement de poser son override, souvent sans message visible pour le commerçant.

Sur WooCommerce, le mécanisme équivalent passe par les actions et les filtres, et par les gabarits recopiés dans le thème enfant sous woocommerce/. Ces copies ne suivent pas les mises à jour de l’extension : quand WooCommerce fait évoluer un gabarit, la copie continue d’être utilisée telle quelle, et la page s’affiche avec une version périmée. C’est la cause la plus banale d’un tunnel de commande qui perd une mention légale ou un champ après une montée de version.

Retenir ces deux mécanismes suffit à comprendre pourquoi un parc de modules se dégrade avec le temps, et pourquoi la question à poser avant d’acheter n’est pas seulement « fait-il ce que je veux » mais « que touche-t-il ».

## Quatre pages qui répondent aux questions les plus fréquentes

- **Acheter un module ou le faire développer** — Les critères qui font pencher d’un côté ou de l’autre, et les situations où l’achat coûte plus cher à l’usage. ([/modules/acheter-ou-faire-developper](/modules/acheter-ou-faire-developper))
- **Conflit entre deux modules** — Comment reconnaître un conflit, l’isoler sans casser la boutique, et ce qu’il est possible de faire quand aucun des deux n’est modifiable. ([/modules/conflit-entre-deux-modules](/modules/conflit-entre-deux-modules))
- **Module cassé après une mise à jour** — Pourquoi une mise à jour de la plateforme suffit à désactiver un module, et ce qu’il faut vérifier avant de le réinstaller. ([/modules/module-casse-apres-une-mise-a-jour](/modules/module-casse-apres-une-mise-a-jour))
- **Ce qui fait le prix d’un module** — Ce qu’on paie réellement dans un développement sur mesure, et les postes qui font varier un devis du simple au triple. ([/modules/ce-qui-fait-le-prix-d-un-module](/modules/ce-qui-fait-le-prix-d-un-module))

## Suivi des conversions ChatGPT Ads

- **Module ChatGPT Ads pour PrestaShop** — Pixel OpenAI et Conversions API dédupliqués, oppref conservé jusqu’à la commande, consentement respecté : développé et installé par mes soins. ([/prestashop/module-chatgpt-ads](/prestashop/module-chatgpt-ads))
- **Extension ChatGPT Ads pour WooCommerce** — Pixel OpenAI et Conversions API, compatible HPOS, tunnel en blocs et extensions de consentement : d?velopp?e et install?e par mes soins. ([/wordpress-woocommerce/extension-chatgpt-ads](/wordpress-woocommerce/extension-chatgpt-ads))

## Un module ne se teste pas en production

> L’installation d’un module modifie la base de données, et la désinstallation ne défait pas toujours ce qu’elle a créé. Un environnement de préproduction, même sommaire, coûte moins cher qu’une seule mauvaise surprise sur la boutique en ligne.

## FAQ

### Combien de modules une boutique peut-elle supporter ?

Il n’y a pas de nombre limite : ce qui compte est ce que chacun exécute à chaque page. Dix modules bien écrits pèsent moins que trois modules qui interrogent la base à chaque affichage. La page consacrée aux modules qui ralentissent la boutique explique comment mesurer avant de désinstaller au hasard.

### Un module payant est-il plus fiable qu’un module gratuit ?

Le prix ne dit rien de la qualité du code. Ce qui la prédit le mieux, c’est la fréquence des mises à jour, la compatibilité annoncée avec votre version de la plateforme et la réactivité du support. Un module payant abandonné depuis deux ans est plus risqué qu’un module gratuit maintenu.

### Puis-je faire modifier un module acheté ?

Techniquement souvent oui, mais toute modification directe disparaît à la mise à jour suivante. La bonne approche est d’isoler le changement dans un module complémentaire ou dans un thème enfant, pour qu’il survive aux mises à jour de l’original. La page sur les modifications écrasées détaille les cas.

### L’éditeur de mon module a disparu, que faire ?

Le module continue de fonctionner tant que la plateforme ne change pas, mais il ne recevra plus de correctif de sécurité, ce qui devient le vrai risque. Selon la complexité, on peut le reprendre, le remplacer ou le réécrire en ne gardant que la fonction réellement utilisée.

### Je ne sais pas décrire mon besoin en termes techniques, est-ce bloquant ?

Non. Décrivez le geste métier : qui fait quoi, à quel moment, et ce qui doit en sortir. La traduction technique fait partie du travail. La page sur le cadrage d’un besoin liste les questions à se poser avant de demander un chiffrage.