Définir une version que l’on peut décrire
Commencez par une phrase : quel utilisateur doit accomplir quelle tâche dans cette première version ? Décrivez ensuite le point de départ, les étapes et le résultat attendu. Un parcours concret rend visibles les écrans, les données et les règles nécessaires.
Par exemple, permettre à un responsable d’inviter son équipe et de faire valider une demande implique plusieurs rôles, des invitations et un historique. C’est un exemple de cadrage, pas un devis : le budget dépend encore des règles et du contexte.
Séparer les postes de réalisation
Demandez une estimation qui distingue les grandes phases. Vous pourrez discuter d’un poste précis sans remettre en question l’ensemble du projet.
- Cadrage : hypothèses, périmètre et critères de validation.
- Design : parcours, interfaces et prototype.
- Développement : fonctions, administration et intégrations.
- Recette : scénarios, corrections et vérifications.
- Lancement : configuration, documentation et transmission.
Identifier les inconnues qui font varier le devis
Une connexion à un outil externe peut être simple si son API est documentée et les accès disponibles. Elle demande une investigation si les données sont incohérentes ou si son fonctionnement est mal connu. La même ligne de devis peut donc couvrir des travaux très différents.
La reprise de données, les droits d’accès, la facturation et les exigences de disponibilité sont d’autres sujets à préciser. Pour chaque inconnue, demandez si elle sera étudiée avant le chiffrage ou traitée comme une hypothèse dans la proposition.
Prévoir les dépenses après lancement
Distinguez le prix de construction du coût mensuel de fonctionnement. Hébergement, services externes, support et maintenance doivent rester visibles même si les volumes sont faibles au départ.
Construisez plusieurs scénarios d’usage : nombre d’utilisateurs actifs, stockage, emails ou appels à des services payants. Demandez ce qui déclenche une hausse des coûts. Une estimation doit pouvoir être révisée lorsque les hypothèses changent.
Comparer deux propositions sur la même base
Comparez les inclusions, les exclusions, les critères de recette et les responsabilités. Un devis moins élevé peut reporter une intégration ou laisser la mise en production à votre charge. Cela peut convenir, à condition de l’avoir compris.
La question utile n’est pas seulement « combien ? », mais « qu’est-ce qui sera utilisable et comment le vérifierons-nous ? ». Avant de vous engager, faites préciser le traitement des changements de périmètre et les conditions de transmission du code et des accès.
Le document à préparer
Rassemblez une description des utilisateurs, un parcours prioritaire, la liste des outils à connecter et les contraintes de lancement. Classez les autres idées dans une liste distincte. Cette séparation permet de discuter d’une première version sans perdre de vue la suite.
Nous ne proposons pas ici de tarif universel : ce guide sert à préparer une estimation de projet, pas à annoncer une moyenne de marché. Un cadrage permet ensuite de chiffrer des livrables définis.