Le code a un poids variable dans une fonctionnalité. Une estimation échoue surtout quand elle oublie tout ce qui rend cette fonctionnalité utilisable par vos clients, intégrée à votre produit et tenable après sa mise en ligne. Le bon budget ne finance donc pas une demande formulée trop vite. Il finance un résultat précis, avec ses limites.
En 2020, j'ai signé un forfait pour une plateforme immobilière. À la livraison, les porteurs du projet ont relevé des fonctions qui leur semblaient évidentes, mais qui n'apparaissaient ni dans le contrat ni dans le cahier des charges. J'avais raison sur le papier. De leur côté, ces fonctions faisaient partie du produit attendu.
J'ai ajouté ces éléments sans les facturer, pour une à deux semaines de travail. J'en ai retenu ceci : décrire ce qui est prévu ne suffit pas, il faut aussi rendre les exclusions explicites.
Une fonctionnalité commence avant le code
Une fonctionnalité dépasse une phrase dans une roadmap. « Permettre l'export » ou « ajouter des notifications » pose une intention. L'utilisateur, lui, attend une action précise dans un contexte précis. Avant d'estimer, il faut pouvoir dire qui déclenche l'action et ce qu'il obtient. Sans cette réponse, votre équipe comble les trous à mesure qu'elle avance.
Le résultat attendu doit aussi couvrir les états moins agréables. Que voit un utilisateur qui n'a pas le droit d'agir ? Que se passe-t-il si une donnée manque, si l'opération échoue ou si le service connecté ne répond plus ? Ces cas font partie du produit. Ils déterminent le support que vous aurez à assurer, la confiance de vos clients et ce que la recette devra valider.
Une demande peut sembler isolée alors qu'elle touche déjà plusieurs parties du produit. L'export d'un rapport dépend peut-être des droits d'accès, de la qualité des données, du format attendu par le client et de l'endroit où le fichier sera disponible. Une notification peut impliquer des préférences utilisateur, un fournisseur d'envoi, des règles de consentement et des messages à écrire. Le code est souvent la partie visible de dépendances déjà présentes dans votre SaaS.
La recette doit être pensée au même moment. Elle répond à une question simple : dans quelles conditions saurez-vous que le résultat est acceptable ? L'équipe doit pouvoir reconnaître ce résultat avant de commencer. Sinon, elle estime une discussion qui n'a pas encore eu lieu.
Son coût continue après la mise en ligne
Une fonctionnalité mise en ligne entre dans la vie du produit. Il faut décider comment elle est activée, qui peut l'utiliser et comment revenir en arrière si elle gêne un parcours déjà existant. Au déploiement, la modification rencontre de vraies données, de vrais comptes et des usages que les maquettes ne montrent pas toujours.
Le support commence souvent par des questions très concrètes. Où un client trouve-t-il cette option ? Pourquoi ne voit-il pas le même résultat que son collègue ? Que lui répondre si une action reste bloquée ?
Ces questions révèlent parfois une règle métier oubliée. Elles peuvent aussi signaler que l'interface promet quelque chose que le système ne peut pas fournir.
La maintenance couvre les changements de règle, les évolutions d'intégration et les corrections de comportement. Une fonctionnalité qui dépend d'un service externe réclame notamment une réponse quand ce service change ou tombe en panne. Votre équipe doit savoir si elle corrige, contourne ou désactive temporairement l'option.
Cette réalité impose de choisir consciemment le niveau d'exploitation que vous financez. Une fonction interne peut tolérer une procédure manuelle. Une option vendue à des clients B2B appelle un service plus fiable et plus explicite. Confondre ces deux niveaux de service fausse les estimations, puis crée des déceptions prévisibles.
Cadrer le résultat avant d'estimer le travail
Un bon cadrage part d'une version observable du résultat. Décrivez le parcours concerné, les rôles autorisés, les données créées ou modifiées, les erreurs attendues et la manière de vérifier la livraison. Votre équipe dispose ainsi d'une frontière à challenger, au lieu d'un titre de ticket à interpréter.
Écrivez aussi ce qui reste en dehors du périmètre. Cette conversation est parfois inconfortable, car elle oblige à renoncer ou à différer. Elle évite pourtant le moment où une fonction « évidente » apparaît au dernier rendez-vous de recette. L'anecdote de la plateforme immobilière m'a appris qu'un non-dit laisse chacun imaginer un produit différent.
L'estimation devient plus utile quand l'équipe peut signaler les inconnues au lieu de les cacher dans un chiffre. Traitez une dépendance non confirmée, une donnée absente ou une règle de gestion encore discutée comme des décisions à prendre. Vous pouvez les résoudre avant le développement, réduire le périmètre ou accepter explicitement qu'il bougera.
Ce travail de cadrage fait partie d'un développement SaaS sérieux. Il rend visibles les attentes, les contraintes et les intégrations qui doivent influencer la décision initiale. Votre équipe les découvre plus tôt, au moment où elle peut encore arbitrer.
Décider quoi construire et quoi laisser de côté
Une fois le résultat compris, vous pouvez construire, acheter, réduire ou abandonner. Construire convient quand la fonctionnalité porte une différence utile pour vos clients et qu'aucune solution existante ne répond correctement à votre besoin. Acheter convient quand la fonction est standard et que son exploitation peut relever d'un fournisseur. Dans les deux cas, évaluez séparément le coût d'intégration puis d'exploitation. Lors d'un achat, vérifiez aussi comment récupérer vos données et changer de fournisseur.
Réduire est souvent la décision la plus saine. Vous pouvez livrer le parcours qui répond au besoin immédiat et reporter les cas rares, les automatisations complexes ou les options avancées. Vous choisissez alors une frontière compréhensible, que vous saurez exploiter sans faire peser sur le produit des promesses encore floues.
Abandonner reste une option légitime. Une fonctionnalité demandée par un prospect, un client très insistant ou une idée interne doit résoudre un problème que vous pouvez nommer. Vous devez aussi identifier les personnes concernées et ce que vous êtes prêt à maintenir. Sans cela, la reporter peut être une meilleure décision que la transformer en dette de produit.
Ce raisonnement complète la question plus large de ce que coûte un SaaS. Il aide aussi à choisir un cadre de collaboration dans forfait ou TJM pour votre projet SaaS.
Pour une fonctionnalité précise, demandez moins « combien de temps pour la coder ? » et davantage « quel résultat voulons-nous assumer après la livraison ? ». La réponse rend l'estimation plus honnête et la décision plus facile à défendre.
Ce qu'il faut retenir
Le coût d'une fonctionnalité comprend ce qu'il faut comprendre avant de la construire, ce qu'elle touche dans le produit et ce qu'il faudra assumer après sa mise en ligne. Le poids du code change selon le contexte. Une estimation fiable suppose un résultat, des états, des dépendances, une recette et des exclusions explicites.
Avant de donner le feu vert, décidez ce que vous cherchez à obtenir et ce que vous acceptez de laisser de côté. Vous pourrez alors comparer une construction sur mesure, un outil existant, une version réduite ou l'abandon de la demande. Ce choix est plus utile qu'un chiffre arraché trop tôt.
Questions fréquentes
Pourquoi une fonctionnalité simple devient-elle difficile à estimer ?
Elle paraît simple tant que l'on regarde seulement l'action principale. L'estimation change dès qu'il faut préciser les rôles, les erreurs, les données concernées, les intégrations et la recette. Une demande reste estimable si son résultat et ses limites sont connus.
Que doit contenir un cadrage de fonctionnalité SaaS ?
Il décrit le résultat attendu pour l'utilisateur, les règles métier, les cas d'erreur, les dépendances et les conditions de recette. Il précise aussi les exclusions. Cette partie évite que chacun imagine un produit différent derrière le même intitulé.
Quand vaut-il mieux acheter plutôt que développer ?
Achetez lorsque la fonction est standard et qu'elle ne porte pas votre différence produit. Vérifiez tout de même l'intégration, les données échangées, le support et les limites de l'outil. Un achat n'efface pas ces questions, il les déplace.
Conclusion
Réservez un échange pour cadrer une fonctionnalité avant de financer son développement.