Cadrer un besoin de module avant de le chiffrer
« Il me faudrait un module pour gérer les acomptes », « un module de filtre », « un module de synchronisation » : formulées ainsi, ces demandes ne peuvent pas être chiffrées sérieusement, parce qu’elles décrivent une solution imaginée plutôt qu’un besoin.
Décrire le problème, pas la solution
La première question que je pose n’est jamais « que doit faire le module », mais « que faites-vous aujourd’hui à la main, et à quel moment ça coince ». La réponse déplace souvent le périmètre : ce qui était demandé comme un module d’import se révèle être un problème de format de fichier fournisseur, et ce qui était demandé comme un module de tarification est déjà couvert par les règles de prix natives, mal paramétrées.
Quand le besoin est réel, cette description donne aussi les cas limites, qui sont l’essentiel de la charge : que se passe-t-il si le client annule, si le stock manque, si la commande est passée hors ligne, si le produit existe en plusieurs déclinaisons, si la boutique est multilingue.
Ce que je dois savoir avant de chiffrer
- La plateforme et sa version exacte, ainsi que la version de PHP du serveur
- Le thème utilisé, et s’il a été modifié directement ou via un thème enfant
- Qui saisit l’information, où elle doit apparaître, et qui doit la voir
- Ce qui doit se passer en cas d’erreur : bloquer, alerter, ou continuer sans rien dire
- S’il faut que la fonction survive à une mise à jour majeure de la plateforme
- Si des données existantes doivent être reprises, et sous quel format
Le point qui change tout : front, back, ou les deux
Un traitement purement interne, visible seulement dans l’administration, ne dépend ni du thème ni du parcours d’achat : il est cadré, testable et stable dans le temps. Dès que la fonction doit apparaître côté client, elle entre en contact avec le thème, avec le cache, avec le tunnel de commande et avec l’affichage mobile. Sur PrestaShop, cela veut dire choisir des points d’accroche que le thème appelle réellement ; sur WooCommerce, cela veut dire dépendre des actions et filtres que le thème n’a pas court-circuités par une surcharge de gabarit.
C’est pour cette raison que je demande une capture d’écran ou une maquette, même grossière, de l’endroit où la fonction doit apparaître. Une phrase ne suffit pas à savoir si le développement dure deux jours ou deux semaines.
Pages liées
-
Ce qui fait le prix d’un module sur mesure
Les facteurs techniques qui font varier la charge une fois le besoin cadré.
-
Acheter un module ou le faire développer
Le cadrage sert d’abord à savoir si un module du marché suffit.
-
Comprendre les hooks PrestaShop
Le vocabulaire des points d’accroche, utile pour décrire où une fonction doit apparaître.
-
Développement sur mesure
Le cadre de la prestation une fois le besoin décrit et chiffré.
Questions fréquentes
Faut-il un cahier des charges formel ?
Pourquoi refusez-vous de chiffrer sur une phrase ?
Le cadrage est-il facturé ?
Et si je ne connais pas la version exacte de ma boutique ?
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.