Le document qui fait chiffrer un MVP : ce qu'un prestataire lit pour s'engager sur un prix

---

title: "Le document qui fait chiffrer un MVP : ce qu'un prestataire lit pour s'engager sur un prix" seoTitle: "Faire chiffrer un MVP : le document qui compte" description: "Un prestataire qui s'engage sur un prix ferme ne lit pas votre document pour comprendre votre idée : il le lit pour trouver ce qui va lui coûter cher. Voici les sept blocs qu'il cherche, les formulations qui font gonfler le devis, et le périmètre d'exclusion qui vaut plusieurs milliers d'euros." seoDescription: "Ce qu'un prestataire cherche dans votre document pour chiffrer un MVP au forfait : les sept blocs utiles, les formulations qui font dériver le budget." date: "2026-10-03" author: "Équipe Raicode" tags: ["mvp", "saas", "gestion de projet", "développement"] category: "SaaS & MVP" keywords: ["faire chiffrer un MVP", "cahier des charges MVP", "expression de besoin SaaS", "devis développement MVP", "périmètre V1", "forfait développement logiciel", "critères d'acceptation", "cadrage produit"]

Vous avez passé le week-end à écrire. Quatorze pages dans Notion, la vision, les personas, le marché, une liste de trente-sept fonctionnalités triées en « must have » et « nice to have », trois captures d'écran d'outils dont vous aimez l'interface. Vous l'envoyez à quatre prestataires un lundi matin.

Deux ne répondent pas. Le troisième propose un atelier de cadrage payant à 4 500 € avant tout chiffrage. Le quatrième envoie un forfait à 48 000 € avec une phrase que vous relisez trois fois : « sur la base des éléments communiqués, sous réserve de validation du périmètre détaillé en phase de conception ».

Aucun des quatre n'a mal lu votre document. Il répond simplement à une autre question que la leur. Vous avez écrit pour expliquer ce que vous voulez construire ; eux cherchent de quoi s'engager sur un prix — très concrètement, de quoi évaluer ce qui va leur coûter plus cher que prévu. Ce sont deux documents différents, et le second est plus court.

Cet article décrit le second. Il ne remplace pas un cahier des charges classique, qui reste l'outil adapté quand on commande un site vitrine ou une refonte à périmètre stable. Il s'adresse au founder qui veut un prix ferme sur une V1 de produit, et qui tient encore le périmètre — la seule étape où il le tient vraiment.

Chiffrer, c'est acheter un risque

Un prestataire qui annonce un forfait prend un pari : il affirme que le travail tiendra dans un nombre de jours, et il assume l'écart. Son prix n'est donc pas une estimation de la charge, c'est une estimation de la charge plus une prime de risque. Cette prime est invisible sur le devis et représente souvent 20 à 40 % du total.

La prime grossit à chaque endroit où le document laisse place à l'interprétation. Non par mauvaise foi, mais parce qu'il a déjà vécu la conversation : « quand on parlait d'export, on parlait évidemment d'un export paramétrable ». Il a perdu douze jours sur ce « évidemment », et il les provisionne maintenant.

C'est le seul mécanisme à retenir : chaque phrase que vous rendez non ambiguë fait baisser le prix, et chaque fonctionnalité que vous excluez explicitement le fait baisser deux fois — une fois pour le développement, une fois pour la prime. Huit pages précises obtiennent de meilleurs devis que quarante pages enthousiastes, et surtout des devis comparables entre eux. Vous n'écrivez pas pour convaincre, vous écrivez pour retirer de l'incertitude.

Les sept blocs qu'un prestataire lit en premier

Voici ce qu'un chiffreur cherche, dans l'ordre où il le cherche. S'il ne le trouve pas, il invente une hypothèse — et une hypothèse est toujours chiffrée au pire.

1. Les rôles, et combien il y en a

Pas les personas marketing. Les rôles au sens des droits : qui se connecte, et que voit-il que les autres ne voient pas ? Un produit à un seul rôle, un produit à trois rôles et un produit avec une hiérarchie d'organisations (un administrateur de compte client qui gère ses propres utilisateurs) sont trois produits de coûts différents, dans un rapport d'environ un à trois sur la partie accès.

Écrivez-le comme un tableau : rôle, comment il obtient son compte, ce qu'il peut faire, ce qu'il ne doit surtout pas voir. Cette dernière colonne est celle qui engage le plus, parce qu'elle décide de l'isolation des données entre clients — un choix qu'on ne rattrape pas après le MVP.

2. Les objets métier et leur cycle de vie

Listez les cinq à dix objets que le produit manipule : un dossier, une mission, une facture, un candidat. Pour chacun, donnez les états par lesquels il passe et qui provoque chaque transition. « Un devis est en brouillon, puis envoyé, puis accepté ou refusé ; il expire automatiquement au bout de trente jours ; un devis accepté ne peut plus être modifié. »

Trois lignes de ce type remplacent deux pages de description de fonctionnalités, parce que c'est exactement là que vit la complexité. Un objet à trois états coûte un peu ; un objet à sept états dont deux réversibles sous conditions coûte beaucoup, et surtout coûte en tests.

3. Les parcours de bout en bout, numérotés

Pas une liste de fonctionnalités : des parcours. « P1 — un client crée un compte, importe un fichier, reçoit un rapport par email. » Numérotez-les, vous en avez entre six et douze pour une V1 honnête. Pour chacun, décrivez le cas nominal en cinq lignes, puis les cas tordus : le fichier est vide, l'email n'arrive pas, l'utilisateur ferme l'onglet au milieu, deux personnes modifient la même fiche.

Les cas tordus sont la moitié du travail réel et la quasi-totalité des mauvaises surprises. Un prestataire qui lit un document sans aucun cas d'erreur sait qu'il devra les inventer seul, puis les défendre en réunion. Il provisionne.

4. Les intégrations, avec les détails que personne n'écrit

« Intégration Stripe » ne se chiffre pas. Ce qui se chiffre : dans quel sens vont les données, qui détient le compte, existe-t-il un environnement de test, qui obtient les accès et quand, et que se passe-t-il quand le service distant est indisponible.

Répondez à ces cinq points pour chaque intégration. Une ligne « connexion au CRM du client » dans laquelle il s'avère, trois semaines plus tard, que le CRM est un Salesforce maison dont l'API est gérée par un intégrateur externe injoignable en août a fait dérailler plus de MVP que tous les choix de framework réunis.

5. L'état de l'existant

Que faut-il reprendre ? Des données dans un tableur, un outil no-code à migrer, une authentification d'entreprise à brancher, un back-office legacy à conserver ? Dites-le même si c'est embarrassant, surtout si c'est embarrassant.

La reprise de données est le poste le plus systématiquement sous-estimé d'un MVP : nettoyer, dédoublonner et importer trois ans de données hétérogènes prend souvent plus de temps que la fonctionnalité qui les consomme. Joignez un extrait anonymisé de vingt lignes — elles valent deux pages de description.

6. Les contraintes non fonctionnelles, avec des nombres

Volumétrie à douze mois, nombre d'utilisateurs simultanés attendu, taille et nature des fichiers, données personnelles ou de santé, exigence d'hébergement en France, délai de réponse acceptable sur l'opération la plus lourde, disponibilité attendue.

Une seule de ces lignes peut déplacer l'architecture entière. « Les documents déposés contiennent des données de santé » change l'hébergement, le contrat et le coût d'exploitation. Écrite au moment du chiffrage, c'est une contrainte. Découverte au troisième sprint, c'est un avenant.

7. Ce qui est explicitement hors périmètre

C'est le bloc le plus rentable du document, et celui que presque personne n'écrit. Une page qui commence par « ne sont pas inclus dans cette V1 : » et qui liste quinze choses — application mobile, multi-langue, mode hors ligne, exports personnalisables, facturation à l'usage, SSO, tableau de bord analytique, back-office d'administration autre que l'accès direct à la base, notifications autres que l'email transactionnel.

Chaque ligne de cette page retire une hypothèse défensive du devis. C'est aussi le document qui vous protégera plus tard, quand la discussion portera sur ce qui était « évidemment compris ». Et c'est l'exercice qui vous apprend le plus sur votre propre produit : si vous n'arrivez pas à exclure quinze choses, votre périmètre n'est pas une V1. C'est l'engrenage qui conduit aux MVP qui durent huit mois.

Décrire le besoin sans imposer la solution — sauf quand il le faut

Le conseil habituel — décrire le quoi, laisser le comment au prestataire — est juste à 80 %. La nuance qui compte : une préférence technique non justifiée fait monter le prix sans rien acheter, mais une contrainte réelle non déclarée le fera exploser plus tard.

Imposez ce qui est une vraie contrainte : votre équipe interne reprendra la maintenance et ne connaît que Python ; votre client grand compte exige un hébergeur précis ; vous avez déjà un design system. Dites-le, et dites pourquoi — le pourquoi permet de proposer une alternative équivalente si la contrainte peut être satisfaite autrement.

N'imposez pas ce qui est une préférence de lecture : le choix de la base de données, le framework front, l'outil de déploiement. Vous ne gagnez rien à les figer, et vous écartez les prestataires les plus efficaces sur leur propre stack. Si vous voulez tout de même cadrer, posez une exigence de résultat plutôt qu'une exigence de moyen : « le code doit pouvoir être repris par un développeur Python senior sans formation spécifique » dit la même chose qu'imposer Django, sans fermer la porte.

Les formulations qui font dériver un budget

Certaines expressions reviennent dans presque tous les documents qu'on nous envoie. Elles sont chiffrées au pire, ou pas chiffrées du tout — et ce sont elles qui produisent l'écart entre le devis signé et la facture finale.

« etc. », « et autres », « notamment ». Un chiffreur ne peut pas estimer un ensemble ouvert : soit il le ferme arbitrairement et vous aurez une discussion, soit il provisionne. Fermez vos listes vous-même, quitte à ajouter « toute autre règle sera traitée en avenant ».

« simple », « basique », « un petit ». « Un simple back-office d'administration » est la ligne la plus coûteuse de la langue française. Un back-office qui permet de chercher, filtrer, créer, modifier, désactiver et exporter sur six types d'objets, avec gestion des droits, représente couramment dix à quinze jours — souvent plus que la fonctionnalité principale. Si vous pouvez vous en passer en V1, dites-le dans le hors-périmètre et acceptez qu'on administre à la main les trois premiers mois.

« comme sur Notion / Slack / Airtable ». La référence visuelle est utile, la référence fonctionnelle est un piège : vous désignez un produit qui représente des centaines d'années-homme. Précisez ce que vous empruntez : « la navigation latérale, pas l'édition collaborative en temps réel ».

« un tableau de bord ». Deux mots, trois jours ou trente selon ce qu'il y a derrière. Un tableau de bord qui affiche quatre compteurs calculés à la volée n'a rien à voir avec un tableau de bord filtrable sur douze mois d'historique, qui suppose des agrégats précalculés. Donnez la liste des indicateurs, la maille temporelle et les filtres. Si vous ne la connaissez pas encore, excluez le tableau de bord de la V1.

« il faudra que ce soit scalable ». Sans nombre, cette phrase ne demande rien et autorise tout. Remplacez-la par la volumétrie du bloc 6. Même logique pour « reprise de l'existant » : jamais sans extrait de données réel.

Écrire la recette avant d'écrire le devis

Un bon document de chiffrage contient, pour chaque parcours numéroté, une ou deux phrases qui disent comment on saura qu'il est terminé. « P3 est accepté quand un utilisateur sans compte reçoit son rapport par email en moins de deux minutes après dépôt d'un fichier de 10 Mo, et qu'un fichier corrompu produit un message d'erreur explicite sans email. »

Ces phrases font trois choses à la fois : elles lèvent l'ambiguïté résiduelle, elles donnent au prestataire la matière pour écrire ses tests, et elles deviennent votre cahier de recette au moment de la livraison. Les écrire avant le devis transforme un débat futur en critère contractuel, et évite la conversation où « livré » et « fini » ne veulent pas dire la même chose des deux côtés.

Un prestataire qui refuse de s'engager sur des critères d'acceptation écrits vous dit quelque chose d'important sur la suite. C'est d'ailleurs une des questions à poser en entretien, au même titre que celles qui permettent de distinguer un prestataire qui livre d'un prestataire qui facture.

Dites votre budget et votre date

Beaucoup de founders cachent leur budget, par crainte qu'on le consomme intégralement. C'est une erreur de calcul dans le cas d'un MVP, pour une raison simple : sans enveloppe, le prestataire chiffre votre liste, et votre liste est presque toujours trop grosse. Avec une enveloppe, il peut vous proposer l'arbitrage — ce qui tient dedans, ce qui n'y tient pas, et ce qu'il recommande de couper.

C'est précisément le travail que vous voulez acheter. Chez Raicode, un cadrage de développement de MVP SaaS commence par cette conversation : étant donné cette enveloppe et cette date, voilà les parcours qu'on tient, voilà ceux qu'on reporte, et voilà pourquoi ce découpage-là plutôt qu'un autre. Un prestataire qui se contente d'acquiescer à une liste de trente-sept fonctionnalités dans une enveloppe trop courte ne vous rend pas service : il reporte simplement le moment où quelqu'un dira non.

Donnez aussi votre date et surtout ce qui la motive : une levée, un salon, un client pilote qui a signé, une saisonnalité. Une date motivée se négocie sur le périmètre ; une date arbitraire se négocie sur la qualité, et c'est toujours vous qui payez l'addition ensuite, sous forme de dette technique que personne n'a choisie.

Le format : court, versionné, tabulaire

Huit à douze pages, pas quarante. Un tableau par bloc plutôt que de la prose. Des maquettes volontairement moches — un croquis basse fidélité annoté se lit mieux qu'une maquette Figma léchée, qui déclenche un débat esthétique au lieu d'un débat de périmètre. Numérotez tout, parce que les échanges de chiffrage se font par référence : « sur P7, que se passe-t-il si… ».

Datez et versionnez le document, et regroupez les questions non tranchées dans une section « points ouverts », avec la date à laquelle vous les trancherez. Un point ouvert déclaré se chiffre en fourchette ou se sort du forfait ; dissimulé, il se chiffre au pire. C'est la différence entre un devis à 34 k€ avec deux lignes en option et un devis à 48 k€ « sous réserve ».

L'autre bénéfice est souvent oublié : quand quatre prestataires répondent au même périmètre numéroté, l'écart entre leurs prix devient lisible, et vous pouvez lire un devis pour ce qu'il dit vraiment plutôt que choisir le moins cher.

Ce que ça change sur le contrat

Le document décide aussi du mode d'engagement qu'on peut vous proposer. Avec un périmètre numéroté, des critères d'acceptation et un hors-périmètre explicite, un forfait est tenable et vous êtes protégé. Sans cela, un prestataire honnête vous proposera de la régie encadrée ou un forfait par lot — un lot de cadrage chiffré fermement, puis un forfait sur le reste une fois le périmètre stabilisé.

Ce n'est pas une dérobade : c'est la seule manière de ne pas payer une prime de risque sur un périmètre que personne ne connaît encore. Ce qu'il faut refuser, c'est le forfait apparemment ferme assorti d'une réserve générale sur le périmètre : vous payez la prime et vous subissez les avenants.

La prochaine action

Ouvrez un document vierge et commencez par la fin : la page « hors périmètre », quinze lignes de choses que votre V1 ne fera pas. Puis numérotez vos parcours ; si vous dépassez douze, vous n'avez pas une V1 mais une V2 déguisée. Ajoutez pour chacun deux cas d'erreur et un critère d'acceptation, puis remplissez les blocs rôles, objets, intégrations et contraintes chiffrées. Huit pages, deux demi-journées, et vous pouvez les envoyer.

Les devis que vous recevrez seront comparables, plus bas, et accompagnés de questions précises plutôt que de réserves générales. Le temps investi là est le moins cher du projet : les mêmes arbitrages, menés trois mois plus tard, se paient en avenants.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.