La décision
Un budget logiciel part des tâches à accomplir, y compris les exceptions. Compter les écrans masque les droits d’accès, les imports, les connexions externes et la reprise après erreur. Deux applications de cinq écrans peuvent donc demander des efforts très différents.
Un cas concret
Prenons un portail fournisseurs fictif : 8 jours de travail pour le cadrage et la conception, 15 pour le parcours principal, 6 pour l’intégration, 5 pour les vérifications et 3 pour la mise en service, soit 37 jours-personnes. Ces hypothèses illustrent un calcul, sans constituer un devis ni un prix de marché. L’hébergement et le suivi restent séparés.
Transformer le chiffrage en registre de périmètre
Décomposez chaque travail en résultat promis, hypothèse, responsable et preuve d’acceptation. « Intégration » est trop vague : une commande approuvée arrive une fois, reçoit une référence et reste visible en cas d’échec. Notez qui fournit le compte d’essai. Une offre basse ne doit pas dépendre d’un travail caché. Comparez les mêmes responsabilités.
Chiffrer aussi les exceptions
Examinez une commande difficile : article retiré, adresse modifiée après validation, réponse tardive. Qu’est-ce qui est inclus, quelle hypothèse change ? Révisez une ligne précise. Une preuve manquante peut justifier une petite investigation liée à une décision. La provision couvre l’incertitude dans la promesse ; une nouvelle promesse demande un changement de périmètre.
Séparer lancement et responsabilité durable
Après livraison, quelqu’un vérifie les sauvegardes, met à jour et traite les transferts en échec. Attribuez les responsabilités à l’entreprise, au studio ou au fournisseur et décrivez les relais. Précisez quand le support devient développement autorisé. Vérifiez critères, exclusions, frais externes, comptes et provision inutilisée. Le but est de rendre les décisions futures explicables, pas de prédire chaque facture.
Les options à comparer
Une fourchette convient lorsque l’incertitude est réelle. Une API documentée se chiffre mieux qu’un export inconnu. Une étude initiale rémunérée peut lever le doute ; un forfait convient si le périmètre et les exemples d’acceptation sont établis.
Les points de rupture
Ne dissimulez pas le nettoyage des données dans le développement. Réservez du temps aux tests. Écrivez les exclusions et les décisions encore attendues. Associez la provision à des risques précis, comme des accès manquants.
Avant de lancer le projet
Qui fournit les données d’essai ? Qui valide les autorisations ? Comment reconnaître une opération terminée ? Apportez ces réponses à votre échange sur le développement sur mesure et demandez quelles découvertes pourraient modifier l’estimation.