Dans cet article
L’essentiel
Une estimation SaaS crédible relie un premier parcours utilisable à l’effort de réalisation, aux incertitudes et à l’exploitation. Décomposez le travail, chiffrez les mêmes hypothèses et rendez visibles migration et support.
Estimer un parcours, pas une liste d’écrans
Prenons un service fictif de réservation B2B. Un premier parcours utilisable permet à une organisation d’inviter un collègue, créer une réservation, éviter un conflit et recevoir une confirmation. « Cinq écrans » ne décrit pas ce travail : les invitations expirent, les droits diffèrent, deux personnes réservent simultanément et le fournisseur d’e-mails peut échouer.
Définissez des exemples d’acceptation pour chaque étape. Un administrateur peut-il retirer un accès ? Que se passe-t-il après une confirmation échouée ? Quels dossiers le support doit-il consulter ? Ces questions révèlent la logique derrière l’interface. Elles rendent aussi les devis comparables : l’un peut inclure reprise et administration, tandis qu’un autre suppose uniquement le parcours sans incident.
Le budget suit le périmètre
Des postes à estimer, et non un devis forfaitaire.
Périmètre produit
Parcours utilisateurs, règles métier et critères de validation.
Intégrations et données
API, migration, droits et dépendances externes.
Exploitation dans la durée
Hébergement, support, sécurité et évolutions futures.
Construire un modèle de charge explicite
Voici un scénario pédagogique, pas un devis ni un tarif de marché : 8 jours-personnes pour cadrage et conception, 18 pour la réservation, 10 pour identité et intégrations, 12 pour vérification et mise en service, 7 pour administration et transmission. Le total atteint 55 jours-personnes. Avec une réserve illustrative de 11 jours pour les incertitudes, l’enveloppe devient 66 jours-personnes.
Multipliez l’effort par le tarif journalier moyen convenu pour estimer la réalisation ; chiffrez licences et infrastructure séparément. Des jours-personnes ne sont pas des jours calendaires. Parallélisation, disponibilité, délais de retour et dépendances modifient la durée. L’intérêt du modèle réside dans ses hypothèses visibles, qu’une phase de cadrage peut remplacer par des éléments vérifiés.
Répartition des 55 jours-personnes illustratifs
Hypothèses pédagogiques, pas un devis. Charge : 55 jours ; réserve : 11 jours ; enveloppe : 66 jours-personnes. Durée calendaire et coûts externes sont distincts.
jours-personnes
Réduire la première version sans la rendre inutilisable
Dans cet exemple, reportez les multiples calendriers, la tarification complexe et le constructeur de statistiques. Conservez prévention des conflits, droits élémentaires, visibilité pour le support et reprise après incident. Retirer une fonction secondaire réduit le périmètre ; retirer la correction d’une réservation échouée transfère du travail aux utilisateurs et au support.
Une première version doit répondre à une question produit : les équipes vont-elles réellement y coordonner leurs réservations ? Mesurez finalisation et abandon, puis échangez avec celles qui retournent aux tableurs. Évitez de financer un catalogue de fonctions avant l’usage du parcours central. Inversement, un prototype incapable de traiter des données réelles ne doit pas être chiffré ou présenté comme une version exploitable.
Identifier ce qui peut faire varier l’estimation
Une API mal documentée, des données historiques incohérentes ou une isolation client floue peuvent changer l’architecture, pas seulement ajouter quelques écrans. Étudiez tôt ces points par une expérimentation limitée. Pour un calendrier, testez authentification, limites d’usage et conflits avec un compte représentatif avant de vous engager sur une charge précise.
Conservez un registre des hypothèses : responsable, preuve, date de décision et impact budgétaire. Lorsqu’une hypothèse tombe, discutez du périmètre au lieu de masquer l’effort supplémentaire. Une fourchette est utile seulement si chacun comprend la différence entre ses bornes. Distinguez les besoins encore inconnus de la réserve prévue pour les variations ordinaires de réalisation.
Budgéter les mois qui suivent le lancement
Les coûts récurrents couvrent hébergement, stockage, e-mails, supervision, sauvegardes et services externes. Le travail humain couvre mises à jour, support, incidents et évolutions produit. Séparez-les du développement initial et précisez trafic, conservation et horaires de service envisagés. Une facture d’hébergement modeste peut coexister avec beaucoup d’exploitation manuelle.
Demandez une transmission comprenant déploiement, propriété des accès, preuve de restauration et liste des travaux reportés. Après lancement, remplacez les hypothèses par l’usage observé. Le budget peut ainsi évoluer avec le produit, au lieu de rester un chiffre ponctuel qui perd son utilité dès l’arrivée du premier client.
FAQ / DÉCISIONS
Questions fréquentes
Puis-je démarrer avec un petit budget ?+
Commencez par réduire la frontière de décision, pas par masquer les travaux nécessaires de sécurité, reprise ou responsabilité. Si la plus petite tranche sûre ne rentre pas, arrêtez ou choisissez une autre approche.