# Ce qui fait réellement le prix d’un module sur mesure

> Deux demandes qui tiennent dans la même phrase peuvent demander des charges de travail sans rapport. Ce ne sont ni le nombre d’écrans ni la longueur du texte qui décident, mais l’endroit où le module s’accroche et ce qu’il fait des données.

- Source canonique : [https://allaux.fr/modules/ce-qui-fait-le-prix-d-un-module](https://allaux.fr/modules/ce-qui-fait-le-prix-d-un-module)
- Langue : FR
- Dernière mise à jour : 2026-08-02

## Le premier facteur : où le module doit s’insérer

Ajouter un bloc d’information sur une fiche produit et modifier le calcul d’un total de commande ne sont pas du même ordre. Le premier s’accroche à un point d’affichage, se teste à l’œil et n’a aucune conséquence si le thème change. Le second entre dans le calcul du panier, se répercute sur la facture, sur la comptabilité, sur les remboursements et sur les avoirs. C’est pour cette raison que je demande toujours si la fonction touche l’argent : dès que la réponse est oui, le travail de vérification pèse plus lourd que le développement lui-même.

Même logique côté administration : afficher une liste existante avec une colonne de plus est rapide ; créer un écran qui écrit dans des tables du cœur suppose de gérer les droits, les journaux, la validation des saisies et les erreurs de concurrence.

## Les facteurs que je regarde en premier

- **Impact sur les montants** — Prix, taxes, frais de port, remises : toute fonction qui modifie un total doit être vérifiée sur la commande, la facture, l’avoir et les statistiques.
- **Nombre de points d’accroche** — Une fonction visible en fiche produit, en panier, au paiement et dans l’e-mail de confirmation, c’est quatre intégrations, pas une.
- **Échanges avec un système extérieur** — Une API tierce impose de gérer les pannes, les délais d’attente, les rejeux et les identifiants qui expirent. Une API mal documentée impose en plus une phase d’observation.
- **État de l’existant** — Un thème modifié directement, des surcharges accumulées ou une version de PHP en fin de vie ajoutent du travail avant même la première ligne du module.

## Le volume de données, souvent sous-estimé

Un traitement qui fonctionne sur trois cents produits peut s’effondrer sur cent mille. Passé un certain volume, la question n’est plus « est-ce que ça marche » mais « est-ce que ça tient dans le temps d’exécution et la mémoire alloués au serveur ». Cela impose de découper les traitements en lots, de suivre une progression et de pouvoir reprendre là où le traitement s’est arrêté. Ce découpage n’a rien d’optionnel sur un gros catalogue, et il double facilement la partie technique d’un module d’import ou de synchronisation.

Le multilingue et le multiboutique jouent le même rôle : ils ne changent pas la fonction, ils changent le nombre de cas à écrire et à tester.

## Ce que je ne chiffre pas au forfait

> Une intervention dans un code que je n’ai pas écrit, sans documentation et sans historique, ne peut pas être forfaitisée honnêtement avant d’avoir été lue. Dans ce cas je propose d’abord un temps borné de lecture et de diagnostic, au terme duquel le reste devient chiffrable.

## Pages liées

- **Cadrer un besoin de module** — Les informations à réunir pour qu’un chiffrage soit possible. ([/modules/cadrer-un-besoin-de-module](/modules/cadrer-un-besoin-de-module))
- **Acheter un module ou le faire développer** — Le chiffrage n’a de sens qu’une fois écartée l’hypothèse du module du marché. ([/modules/acheter-ou-faire-developper](/modules/acheter-ou-faire-developper))
- **Tarifs et modalités** — Comment je facture selon la nature de l’intervention. ([/tarifs](/tarifs))
- **Développement sur mesure** — Ce que couvre la prestation, du cadrage à la mise en production. ([/services/developpement-sur-mesure](/services/developpement-sur-mesure))

## FAQ

### Pourquoi un module « simple » peut-il coûter cher ?

Parce que la simplicité perçue porte sur l’écran final, pas sur ce qu’il y a derrière. Un bouton qui déclenche un échange avec un système extérieur est simple à l’écran et complexe en coulisses, à cause des cas d’échec à traiter.

### Le prix inclut-il les évolutions futures ?

Non. Un développement couvre le périmètre décrit. Les évolutions et l’adaptation aux futures versions de la plateforme relèvent de la maintenance, qui se traite séparément.

### Puis-je réduire le coût en acceptant moins de fonctions ?

Souvent oui, et c’est la meilleure façon de le faire. Retirer les cas rares, se limiter à l’administration dans un premier temps, ou traiter un seul canal de vente réduit réellement la charge.

### Le code du module m’appartient-il ?

Pour un développement spécifique, oui : vous recevez les sources et vous restez libre de les faire reprendre par quelqu’un d’autre. C’est une différence de fond avec un module acheté sous licence.