Recevoir le MVP livré par un prestataire : le cahier de recette qui protège le founder, et ce qu'on ne signe pas

---

title: "Recevoir le MVP livré par un prestataire : le cahier de recette qui protège le founder, et ce qu'on ne signe pas" seoTitle: "Recette d'un MVP : le cahier qui vous protège" description: "Le prestataire annonce que c'est livré, vous cliquez dix minutes et vous signez. C'est le dernier moment où vous avez un levier, et la plupart des founders le dépensent mal. Voici comment conduire la recette d'un MVP, qualifier les anomalies et relire le procès-verbal avant de le signer." seoDescription: "Conduire la recette d'un MVP livré par un prestataire : cahier de recette, campagne de tests, qualification des anomalies et procès-verbal à relire." date: "2026-10-02" author: "Équipe Raicode" tags: ["mvp", "saas", "gestion de projet", "qualité"] category: "SaaS & MVP" keywords: ["cahier de recette", "recette informatique", "recette fonctionnelle MVP", "procès-verbal de recette", "recevoir un MVP", "tests d'acceptation", "garantie développement logiciel", "anomalie bloquante", "réception projet web"]

Le message arrive un jeudi soir : « C'est en ligne, vous pouvez tester. » Vous ouvrez l'URL, vous créez un compte, vous cliquez pendant vingt minutes, tout a l'air de marcher. Le prestataire vous envoie un procès-verbal de recette à signer et la facture de solde. Vous signez, parce que rien ne vous saute aux yeux et que vous avez hâte de montrer le produit.

Trois semaines plus tard, un utilisateur paie, Stripe encaisse, et le compte reste en plan gratuit. Vous écrivez au prestataire. La réponse est polie et imparable : la recette a été prononcée sans réserve le 12, le périmètre est réceptionné, l'anomalie sera traitée dans le cadre d'un devis de maintenance.

Ce moment est le dernier où vous avez un vrai levier contractuel. Après la signature, chaque correction se négocie ; avant, elle est due. La plupart des founders le dépensent en vingt minutes de clics parce que personne ne leur a dit à quoi ressemblait l'alternative. Cet article décrit l'alternative.

Ce que la recette d'un MVP a de particulier

La recette, dans un projet informatique classique, vérifie la conformité d'une livraison à une spécification écrite en amont. Sur un MVP, cette spécification n'existe pratiquement jamais sous une forme assez précise pour arbitrer un désaccord. Le périmètre a bougé trois fois, la moitié des décisions ont été prises en visio, et la seule trace écrite est un devis de deux pages et un backlog d'outils de suivi.

Conséquence directe : votre cahier de recette ne peut pas être une simple relecture du cahier des charges. Il faut l'écrire, et l'écrire vous-même, à partir de ce que le produit doit faire pour qu'un utilisateur paie. C'est désagréable — c'est du travail que vous pensiez avoir acheté — mais c'est aussi l'exercice qui révèle les désaccords de périmètre avant qu'ils ne deviennent des litiges.

Deuxième particularité : sur un MVP, l'enjeu de la recette n'est pas la perfection fonctionnelle. Un MVP livré avec des angles rugueux est normal, et refuser la livraison pour un alignement CSS vous coûtera plus cher que de le corriger vous-même plus tard. Ce que la recette doit attraper, c'est la catégorie d'anomalie qui vous empêche d'exploiter le produit : les parcours qui touchent à l'argent, aux données, aux comptes et à la sortie. Le reste se négocie ; ces quatre-là, non.

Troisième particularité, la plus mal anticipée : la recette suppose que vous ayez accès au produit ailleurs que dans la démo du prestataire. Si vous n'avez ni accès au dépôt, ni accès à l'hébergement, ni compte administrateur, vous ne réceptionnez pas un logiciel, vous assistez à une présentation. Ces accès se demandent avant la livraison, et leur refus est un signal en soi — c'est l'un des points que nous recommandons de tester dès l'entretien de sélection dans notre grille pour choisir une agence MVP.

Les trois niveaux de recette, et celui qui vous revient

Le mot « recette » recouvre trois choses distinctes, et la confusion entre les trois est la source d'une bonne partie des malentendus de fin de projet.

La recette technique est faite par le prestataire, chez lui, avant de vous livrer. Elle couvre les tests automatisés, le comportement sur les navigateurs cibles, les temps de réponse, le déploiement. Vous ne la conduisez pas, mais vous avez le droit d'en demander la trace : le résultat de la suite de tests, le rapport d'un audit de performance, la liste des navigateurs vérifiés. Un prestataire qui n'a rien à montrer à ce niveau vous dit quelque chose d'important sur la suite.

La recette fonctionnelle est la vôtre. C'est le cœur du sujet : vérifier que chaque parcours annoncé fonctionne, avec de vraies données, dans l'ordre où un utilisateur l'emprunte. Elle se conduit sur un environnement dédié, avec un cahier écrit, et elle produit une liste d'anomalies qualifiées.

La recette utilisateur vient après, et elle ne répond pas à la même question. La recette fonctionnelle demande « est-ce que ça marche comme convenu » ; la recette utilisateur demande « est-ce que ça sert ». Les deux sont utiles, mais seule la première a une valeur contractuelle. Ne mélangez pas les deux dans le même document : une remarque d'ergonomie glissée au milieu d'anomalies bloquantes donne au prestataire un argument facile pour requalifier l'ensemble en « demandes d'évolution ».

Écrire le cahier de recette

Un cahier de recette utile tient en un tableau. Une ligne par cas de test, et cinq colonnes : l'identifiant, le parcours testé, les données de départ, les actions, le résultat attendu. Une sixième colonne reste vide jusqu'à la campagne : le résultat observé.

La discipline qui fait la différence tient dans la colonne « résultat attendu ». Écrire « le paiement fonctionne » ne sert à rien : vous ne pourrez pas trancher un désaccord avec. Écrivez plutôt : « après paiement réussi, l'utilisateur est redirigé vers le tableau de bord, son plan affiche Pro, la facture est disponible en PDF dans son espace, et un e-mail de confirmation arrive en moins de deux minutes. » Quatre vérifications au lieu d'une, et aucune place pour l'interprétation.

Sur un MVP, trente à cinquante cas suffisent, à condition de les choisir dans cet ordre :

1. Les parcours qui encaissent de l'argent. Inscription, choix du plan, paiement, échec de paiement, changement de plan, résiliation, remboursement. L'échec de paiement est celui qu'on oublie le plus souvent et celui qui coûte le plus cher : testez une carte refusée, pas seulement la carte de test qui passe.
2. Les parcours qui touchent aux comptes. Création, connexion, mot de passe oublié, changement d'e-mail, suppression de compte. Et surtout, le cas qui révèle les vrais défauts : un utilisateur peut-il voir les données d'un autre en changeant un identifiant dans l'URL ? Si votre produit est multi-locataire, ce test seul justifie la campagne — nous détaillons pourquoi dans notre article sur les fondations d'un SaaS multi-tenant.
3. Les parcours qui écrivent des données. Import, export, suppression, modification concurrente. Testez avec un fichier mal formé, pas seulement avec l'exemple fourni.
4. Les parcours d'administration. Si vous ne pouvez pas rembourser un client, corriger une adresse ou désactiver un compte sans appeler le prestataire, le produit n'est pas exploitable, même s'il est conforme.

Les cas qu'on oublie systématiquement et qui reviennent toujours : le comportement sur mobile réel (pas la vue réduite du navigateur), le deuxième utilisateur de la même organisation, les caractères accentués dans les noms et les exports, les e-mails qui partent en spam, et la page qui s'affiche quand on arrive sur une URL d'un objet supprimé.

Un détail de forme, mais il a coûté cher à plus d'un projet : si vos cas de test décrivent des modèles d'e-mail avec des variables, écrivez-les en code inline, par exemple « Bonjour {{prenom}} ». Dans la plupart des environnements de documentation modernes, une accolade en pleine prose est interprétée comme du code et casse la page.

Conduire la campagne

Fixez la date de début de recette dans le contrat, pas après la livraison. La formulation qui fonctionne : la campagne démarre à la mise à disposition de l'environnement de recette et dure dix jours ouvrés. Sans durée écrite, vous héritez du délai que le prestataire voudra bien vous laisser, et il sera court parce que sa facture de solde en dépend.

Trois conditions matérielles décident de la qualité de la campagne. Un environnement dédié, séparé de la production, avec des données qui ressemblent aux vraies — un jeu de dix comptes fictifs et deux cents enregistrements vaut mieux qu'une base vide. Un mode de paiement en bac à sable, pour pouvoir dérouler les scénarios d'échec sans dépenser. Et un canal unique pour remonter les anomalies : un outil de suivi, pas une conversation de messagerie où les remontées se perdent entre deux blagues.

Côté charge, comptez deux à quatre jours de votre temps, étalés sur les dix jours ouvrés. C'est la ligne que les devis de MVP omettent presque toujours, aux côtés du cadrage et de l'infrastructure — un angle mort que nous avons documenté en détail dans notre grille de lecture d'un devis de MVP. Si vous n'avez pas ces jours, décalez la livraison plutôt que de bâcler la recette : une réception signée à la va-vite transfère chez vous un risque que vous aviez payé pour ne pas porter.

Faites tester par deux personnes, dont une qui n'a pas participé au projet. Le commanditaire connaît trop bien le chemin heureux ; il clique là où il faut sans s'en rendre compte. Un testeur neuf trouve en une heure des blocages que vous ne verrez jamais.

Qualifier les anomalies

C'est ici que les recettes dégénèrent. Vous remontez quarante points, le prestataire en requalifie trente en évolutions, et la discussion s'enlise. La parade est de fixer la grille de qualification avant la campagne, dans le contrat, et de s'y tenir.

Trois niveaux suffisent :

• Bloquante : le parcours ne peut pas être terminé, ou le résultat est faux sans contournement acceptable. Un paiement encaissé qui n'active pas l'abonnement est bloquant. Une fuite de données entre comptes est bloquante. Une anomalie bloquante empêche la réception, point.
• Majeure : le parcours aboutit, mais avec un contournement manuel ou une dégradation sérieuse. Un export qui casse les accents est majeur. On réceptionne avec réserves, et les réserves sont levées dans un délai écrit.
• Mineure : tout le reste. Libellés, alignements, formulations. On réceptionne, on liste, on traite au fil de l'eau.

La ligne de partage entre anomalie et évolution est celle qui mérite le plus d'attention. Le critère défendable est simple : si le comportement observé contredit un document écrit avant la livraison — devis, maquette, compte rendu de réunion validé, cas de test transmis avant le début de la campagne — c'est une anomalie, et sa correction est due. Si vous découvrez pendant la recette que vous vouliez autre chose, c'est une évolution, et elle se paie. Transmettre le cahier de recette avant le début de la campagne n'est donc pas une politesse : c'est ce qui bascule vos cas de test du côté des documents opposables.

Acceptez ce partage honnêtement. Un founder qui requalifie toutes ses envies en anomalies obtient un prestataire qui se braque et un projet qui finit mal — et il est beaucoup plus difficile de faire reprendre un produit par une autre équipe que de terminer avec celle qui l'a écrit. Si la relation est déjà abîmée au moment de la recette, c'est un autre sujet, et il vaut mieux l'aborder de front : reprendre un MVP livré à moitié se fait, mais c'est un chantier qui se cadre, pas une formalité.

Le procès-verbal : ce qu'il engage

Le procès-verbal de recette est le document qui transfère la responsabilité. Il existe en trois formes, et la nuance entre les deux premières vaut souvent plusieurs milliers d'euros.

La réception sans réserve prononce la conformité. Tout ce qui apparaît ensuite relève de la garantie si elle existe, et du devis sinon.

La réception avec réserves prononce la conformité tout en listant les anomalies restantes, avec un délai de correction pour chacune. C'est la forme normale d'une fin de MVP honnête. Exigez que les réserves soient annexées au PV, nommément, avec leur niveau de gravité et leur date de levée — un PV qui mentionne « quelques points mineurs restants » sans annexe ne vous protège de rien.

Le refus de réception se prononce quand une anomalie bloquante subsiste. Il n'est pas un acte de guerre : il déclenche une nouvelle livraison et une nouvelle campagne, généralement plus courte, limitée aux cas concernés.

Avant de signer, relisez quatre points. Le solde : prévoyez qu'une part — dix à vingt pour cent — reste due à la levée des réserves, pas à la signature du PV. La durée de garantie : trois mois est un standard raisonnable sur un MVP ; vérifiez surtout ce qu'elle couvre, car une garantie qui exclut « les anomalies liées à l'usage » ne couvre rien. La réception tacite : beaucoup de contrats prévoient que la recette est réputée acquise si vous ne vous manifestez pas sous cinq ou dix jours — c'est légitime, à condition que le délai commence à la mise à disposition effective de l'environnement et que vous l'ayez noté dans votre agenda. Les livrables joints : accès au dépôt, documentation de déploiement, inventaire des comptes et des clés d'API, et transfert effectif de la propriété des services tiers. Un produit dont les clés appartiennent au prestataire n'est pas réceptionné, quelle que soit la signature au bas du PV.

Une réserve que nous recommandons d'ajouter systématiquement sur un MVP : la liste des raccourcis techniques assumés, avec leur coût estimé de remboursement. Ce n'est pas une anomalie, c'est une information, et elle a plus de valeur six mois plus tard que n'importe quelle clause — nous avons détaillé ce tri dans ce qu'on accepte et ce qu'on refuse comme dette technique sur un MVP.

Ce que la recette vous apprend sur la suite

Une campagne de recette est aussi le dernier test de votre prestataire, et le plus révélateur. Observez trois choses : le délai de première réponse sur une anomalie bloquante, la qualité du diagnostic — « corrigé » sans explication est un mauvais signe — et le taux de régression, c'est-à-dire le nombre de cas qui repassent au rouge après une correction. Un taux de régression élevé pendant la recette annonce exactement la même chose pendant la maintenance.

C'est aussi le moment où vous apprenez à exploiter le produit : chaque cas de test que vous écrivez est un morceau de votre future documentation d'exploitation, et chaque anomalie que vous qualifiez vous apprend où le produit est fragile. Les founders qui conduisent la recette sérieusement ne gagnent pas seulement une négociation ; ils arrivent en production en sachant ce qu'ils ont.

Votre prochaine action, si une livraison approche : ouvrez un tableau, écrivez les dix cas de test des parcours qui touchent à l'argent et aux comptes, et envoyez-les au prestataire avant qu'il ne livre. Ces dix lignes transforment la fin de projet. Elles disent ce que vous vérifierez, elles donnent au prestataire l'occasion de corriger avant de vous livrer, et elles deviennent le document qui tranchera si un désaccord surgit.

---

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