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.
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.
Pages liées
-
Cadrer un besoin de module
Les informations à réunir pour qu’un chiffrage soit possible.
-
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é.
-
Tarifs et modalités
Comment je facture selon la nature de l’intervention.
-
Développement sur mesure
Ce que couvre la prestation, du cadrage à la mise en production.
Questions fréquentes
Pourquoi un module « simple » peut-il coûter cher ?
Le prix inclut-il les évolutions futures ?
Puis-je réduire le coût en acceptant moins de fonctions ?
Le code du module m’appartient-il ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.