La recette fonctionnelle, expliquée à un dirigeant qui doit valider avant de payer

Pourquoi elle existe : le moment où vous vérifiez ce que vous avez payé

Un sprint de construction se facture, chez Techmind, entre 8 000 et 22 000 euros hors taxes selon le format retenu, sur deux semaines de travail. Ce montant n'a de sens que si quelqu'un vérifie, avant d'accepter la facture, que ce sprint a produit ce qui était attendu. La recette est ce moment de vérification, rien de plus, rien de moins.

Sans elle, la définition de « terminé » appartient à une seule personne : celle qui a codé. Un développeur honnête livre ce qu'il a compris de la demande, pas nécessairement ce que le métier voulait dire. L'écart entre les deux ne se voit jamais sur un compte rendu de réunion, il se voit uniquement à l'usage.

Ce n'est pas une question de confiance envers le prestataire. Un développeur compétent peut très bien avoir livré exactement ce qu'on lui a demandé, tout en ayant mal compris une règle métier qu'il n'a jamais vécue lui-même. La recette existe pour rattraper ce genre d'écart avant qu'il coûte cher, pas pour surveiller quelqu'un de malhonnête.

Certains dirigeants pensent qu'un acompte versé au démarrage du projet suffit à garantir la qualité du résultat final, puisque le prestataire est déjà engagé financièrement. Un acompte protège le démarrage du chantier, il ne dit rien sur ce que le sprint aura réellement produit deux semaines plus tard : seule la recette répond à cette question.

Beaucoup de dirigeants ressentent, sans le formuler, l'impression de payer pour un logiciel qui existe sur le papier plus que dans les mains de leurs équipes. Cette impression vient presque toujours du même endroit : personne n'a jamais rejoué, devant eux, les situations réelles que le logiciel doit gérer chaque jour.

Voir fonctionner l'outil sur un cas concret change la nature de la relation avec le prestataire. On ne discute plus d'une promesse, mais d'un résultat visible, ce qui déplace la conversation du terrain de la confiance vers celui des faits.

C'est pour cette raison que la recette mérite d'être organisée comme un moment à part, et non expédiée entre deux réunions, comme le montre la section suivante sur les personnes qui doivent la mener.

Qui doit la faire (et pourquoi ce n'est presque jamais le développeur)

La question se pose rarement en ces termes, et pourtant elle change tout : qui, dans votre entreprise, doit s'asseoir devant l'écran et dire si ça marche. La réponse tient en une phrase, celles et ceux qui utilisent la fonction concernée au quotidien, jamais une personne qui la découvre pour la première fois ce jour-là.

Un module de facturation se fait valider par la comptable qui émet vingt factures par semaine, pas par le chef de projet informatique qui suit le dossier depuis son bureau. Un module de gestion de stock se fait valider par le magasinier qui compte les palettes, pas par celui qui a rédigé le cahier des charges six mois plus tôt.

Cette règle n'a rien d'arbitraire. Un module de devis validé par le développeur qui l'a codé passe presque toujours l'épreuve, puisqu'il connaît déjà le chemin à suivre pour que tout fonctionne. Le même module, validé par la personne qui rédige vingt devis chaque semaine, trouve les trous que le développeur ne pouvait pas voir.

Le prestataire, quel que soit son sérieux, ne devrait jamais être seul juge de son propre travail. Ce n'est pas une accusation de mauvaise foi : personne ne teste bien ce qu'il a construit lui-même, parce qu'il sait déjà, sans même y penser, comment éviter les erreurs qu'un utilisateur novice commettrait spontanément.

Le chef de projet côté client joue un rôle utile, celui d'organiser les sessions et de collecter les retours, mais il ne remplace jamais les utilisateurs métier. Sa connaissance du projet est large, rarement assez fine sur chaque geste quotidien pour repérer un écart précis.

Une objection revient souvent : « notre chef de projet a déjà testé, ça devrait suffire ». Un chef de projet compétent repère les problèmes évidents, rarement les détails métier fins, parce que son rôle porte sur l'avancement du projet dans son ensemble, pas sur les vingt gestes précis qu'accomplit chaque jour la personne qui utilisera vraiment l'outil.

Réunir les bonnes personnes demande parfois de bousculer un agenda chargé. C'est pourtant l'investissement le moins cher de tout le projet, comparé au coût d'un écart découvert deux mois après la mise en service, une fois le logiciel payé et les habitudes prises.

Sur quoi porte la recette : des scénarios, pas des lignes de code

Un scénario de recette raconte une histoire complète, du début à la fin : créer un devis, le transformer en facture, l'envoyer au client, plutôt que de vérifier isolément si un bouton répond au clic. Cette différence sépare un test technique d'une vérification métier.

Une fonction testée seule peut très bien fonctionner et pourtant produire un résultat faux une fois enchaînée avec les autres. Un calcul de TVA correct isolément peut s'appliquer au mauvais pays si le champ précédent n'a pas transmis la bonne information. Seul un scénario bout en bout révèle ce genre de rupture.

Une poignée de scénarios bien choisis couvre l'essentiel d'un premier produit. Il ne s'agit pas de rejouer des centaines de cas possibles, mais de repérer les cinq ou six situations que vos équipes rencontrent le plus souvent, et de vérifier qu'elles fonctionnent de bout en bout, dans les conditions réelles de travail.

Les scénarios de recette découlent directement des besoins décrits au début du projet. Un cahier des charges précis facilite grandement cette étape, puisque chaque besoin qu'on y a couché sur le papier devient un scénario à rejouer avant d'accepter la livraison.

Un scénario mal choisi teste un cas rare et laisse passer un cas fréquent. Mieux vaut rejouer trois fois la situation qui se produit chaque jour dans votre entreprise qu'une fois une exception qui ne se produira peut-être jamais.

Il faut aussi tester les cas limites qui comptent réellement pour votre métier : une commande sans quantité, un client sans adresse, une facture à montant nul. Ce sont ces situations en marge qui, en général, révèlent les défauts que personne n'avait anticipés.

Le nombre de scénarios utile varie selon la taille du projet. Un premier outil ou un MVP, facturé entre 15 000 et 50 000 euros, se recette souvent avec cinq à huit scénarios centraux. Une plateforme plus large, entre 80 000 et 150 000 euros, en demande davantage, répartis sur plusieurs sessions au fil des sprints plutôt que sur une seule.

Pourquoi elle est presque toujours bâclée

Dans la pratique, la recette se réduit souvent à un clic rapide en fin de sprint, alors qu'elle devrait être le moment le plus sérieux du projet après sa livraison. Trois raisons concrètes expliquent ce décalage, et aucune ne relève de la mauvaise volonté.

Personne n'a bloqué de temps dans l'agenda. Un dirigeant occupé reçoit un message annonçant l'entrée en recette et répond entre deux réunions, sans avoir prévu une heure dédiée pour ouvrir réellement le logiciel et y entrer une vraie commande dans les conditions du quotidien.

Le prestataire a intérêt, sans forcément le vouloir consciemment, à ce que la recette passe vite : elle conditionne souvent son paiement et il n'a aucune envie de retarder une facture pour un détail qu'il juge mineur. Cet intérêt n'a rien de malhonnête, il reste un biais qu'il faut connaître.

Le client, de son côté, ne sait souvent pas quoi chercher. Sans méthode ni scénarios préparés à l'avance, il ouvre l'écran, clique sur quelques boutons, et conclut que ça a l'air de marcher, sans avoir reproduit une seule situation réelle de travail.

Le résultat prend une forme reconnaissable : trois écrans ouverts, quelques clics sur « suivant », et un message final du type « ok c'est bon », sans qu'aucune vraie commande n'ait été entrée dans les conditions réelles d'usage. Le logiciel montre ses trous deux mois plus tard, une fois payé.

Cette recette bâclée coûte cher, mais pas tout de suite : c'est ce qui la rend si facile à accepter sur le moment. Le prix se paie plus tard, quand un écart trouvé en production interrompt le travail d'une équipe entière un jour ordinaire.

La période de fin d'année aggrave souvent le problème. Les équipes sont sous pression, les congés approchent, et la tentation de clore vite le projet avant la coupure devient plus forte que d'habitude. C'est dans ces périodes chargées que la recette bâclée laisse passer le plus d'écarts, faute d'attention disponible.

Éviter ce scénario ne demande ni compétence technique ni temps illimité. Cela demande une méthode simple, posée avant la première session, ce que la section suivante détaille.

Recette fonctionnelle et tests automatisés : deux choses différentes

Un test automatisé est écrit par le développeur pour vérifier que le code fait ce que le code est censé faire. Il tourne en quelques secondes, se répète à chaque modification, et rassure sur la solidité technique de l'ensemble. Il ne dit rien, en revanche, sur ce que le métier attend réellement.

Un test automatisé peut rester vert alors que le taux de TVA appliqué correspond à celui de la Suisse sur un client français. Le code fait exactement ce qu'on lui a demandé de faire, à la lettre, sans jamais se demander si la demande initiale correspondait à la réalité du terrain.

La recette fonctionnelle vérifie l'inverse : elle prend le point de vue de la personne qui utilise l'outil, pas celui du code qui l'exécute. Elle ne remplace jamais les tests automatisés, elle couvre l'angle mort qu'ils laissent forcément ouvert.

Un logiciel bien construit gagne à avoir les deux : des tests automatisés qui protègent contre les régressions techniques à chaque nouvelle version, et une recette fonctionnelle qui protège contre les malentendus sur ce qui était réellement demandé. L'un sans l'autre laisse une moitié du risque sans surveillance.

Ce sujet touche de près à la question plus large de la dette technique : un logiciel sans tests automatisés accumule un risque qui se paie plus tard, sous une autre forme, lors de chaque évolution future. La recette, elle, protège le moment présent de la livraison.

Le coût de mettre en place des tests automatisés varie selon le projet, et reste distinct du coût de la recette elle-même. Sur un assistant interne facturé entre 40 000 et 80 000 euros, les tests automatisés protègent la robustesse du moteur ; la recette, elle, continue de porter sur l'usage réel qu'en font vos équipes au quotidien.

Reformulons la formule habituelle des cabinets de conseil, qui dit que la recette valide la conformité aux spécifications : elle n'est pas fausse, mais elle n'aide personne à la mener. Ce qu'elle vérifie, en réalité, c'est que le logiciel fait ce que les gens qui vont s'en servir attendent de lui.

Comment organiser une recette sans y passer trois semaines

Une recette bien menée ne demande ni des semaines ni une équipe dédiée. Trois habitudes suffisent à la rendre sérieuse sans qu'elle devienne un chantier en soi, et elles se posent avant la première session, pas pendant.

Écrire les scénarios avant la session, pas pendant. Une liste de cinq ou six situations réelles, rédigée à l'avance avec les personnes qui connaissent le métier, évite d'improviser devant l'écran et d'oublier le cas qui compte vraiment.

Tester dans un environnement séparé de la production, jamais directement sur les données réelles de l'entreprise. Un écart trouvé pendant la recette ne doit jamais avoir de conséquence sur une vraie commande, une vraie facture ou un vrai client.

Préférer deux ou trois créneaux courts, d'une heure chacun, à une seule journée marathon. L'attention baisse vite après le premier scénario rejoué, et une session trop longue finit en clics distraits plutôt qu'en vérification réelle.

Si votre projet avance par sprints de deux semaines, appuyez-vous sur ce rythme déjà connu : une session de recette à la fin de chaque sprint, sur ce que ce sprint a produit, plutôt qu'une seule grande recette en fin de projet sur des mois de travail accumulé.

Cette cadence a un autre avantage, moins visible au départ : un écart trouvé à la fin d'un sprint de deux semaines coûte à corriger une fraction de ce que coûte le même écart découvert six mois plus tard, une fois le logiciel devenu la référence quotidienne de vos équipes.

Une objection fréquente : « nous n'avons pas le temps de faire tout ça ». Deux ou trois heures réparties sur un sprint de deux semaines représentent un temps modeste, comparé à celui qu'un écart non détecté finira par coûter en corrections, en explications et en confiance perdue envers l'outil.

La grille de recette : un exemple concret

Une grille de recette tient sur une page, avec trois colonnes : le scénario testé, le résultat attendu, le résultat obtenu. Rien de plus compliqué qu'un tableau simple, rempli au fur et à mesure de la session, devant les personnes qui font le test.

Premier exemple de ligne : scénario « créer un devis de 3 200 euros pour un client existant », résultat attendu « le devis apparaît dans la liste, au bon montant, avec la bonne TVA », résultat obtenu « conforme » ou, le cas échéant, la description précise de l'écart constaté.

Deuxième exemple : scénario « transformer ce devis en facture et l'envoyer par courriel », résultat attendu « le client reçoit un message avec la facture en pièce jointe, au format attendu », résultat obtenu noté de la même façon, avec le nom de la personne qui a fait le test et la date.

Troisième exemple, souvent négligé : scénario « annuler ce devis avant l'envoi », résultat attendu « le devis disparaît de la liste active sans laisser de trace incohérente ailleurs dans le logiciel », résultat obtenu vérifié avec la même rigueur que les cas positifs.

Quatrième exemple, utile sur un projet plus long : scénario « générer l'export comptable du mois », résultat attendu « le fichier reprend l'ensemble des factures émises, sans doublon ni facture manquante », résultat obtenu vérifié en comparant le fichier généré à la liste réelle du mois tenue par la comptabilité.

Cette grille n'a rien d'un document administratif à produire pour la forme. Elle sert d'abord de repère pendant la session, pour ne pas oublier un scénario en cours de route, et elle garde une trace utile si un désaccord survient plus tard sur ce qui a réellement été vérifié.

Trois ou quatre lignes remplies avec sérieux valent mieux que vingt cases cochées sans avoir vraiment testé quoi que ce soit. La qualité de chaque ligne compte davantage que leur nombre.

Ce qui se passe quand la recette trouve un écart

Trouver un écart pendant la recette prouve que la recette sert à quelque chose. Le vrai problème survient quand aucun écart n'est jamais trouvé, ce qui signale presque toujours une recette trop superficielle.

Tous les écarts ne se valent pas, et les trier vite évite deux excès opposés : tout bloquer pour un détail, ou tout accepter malgré un problème sérieux. Un écart mineur, comme une couleur de bouton ou un libellé mal formulé, se corrige au sprint suivant sans retarder l'acceptation.

Un écart bloquant, lui, empêche le métier de fonctionner correctement : un montant de facture faux, une commande qui disparaît, une donnée client écrasée par erreur. Ce type d'écart suspend l'acceptation du sprint tant qu'il n'est pas corrigé et revérifié.

La distinction entre les deux se joue sur une question simple : si cet écart restait tel quel demain matin, une personne de votre entreprise en subirait-elle une conséquence concrète sur son travail ou sur l'argent de l'entreprise ? Si oui, l'écart est bloquant.

Un écart trouvé un jeudi se corrige souvent en quelques jours et se revérifie avant la démonstration suivante, sans arrêter le reste du projet. Le rythme d'un sprint de deux semaines laisse largement le temps de reprendre un point précis sans tout retarder.

Cette étape reste une méthode de travail, pas un règlement de comptes envers le prestataire. Un écart révèle presque toujours un malentendu partagé, une règle mal expliquée d'un côté, mal comprise de l'autre, plus rarement une erreur isolée d'une seule personne.

Un même type d'écart qui revient sur plusieurs scénarios mérite une attention particulière : il signale souvent un problème de fond, comme une règle métier mal comprise dès le cahier des charges, plutôt qu'une série d'erreurs isolées. Corriger la racine évite de revoir le même écart réapparaître au sprint suivant sous une autre forme.

Ce que la recette a à voir avec le prix du sprint

Chez Techmind, un sprint de deux semaines se facture entre 8 000 euros hors taxes pour un format simple et 22 000 euros pour un format complet, avec un palier intermédiaire autour de 13 000 euros pour un format régulier. Ces chiffres n'ont de sens que rapportés à ce que le sprint a réellement produit.

Un sprint accepté sans vraie recette se paie exactement le même prix, mais avec les trous dedans. L'entreprise règle la facture, et découvre les écarts plus tard, au pire moment, souvent quand le logiciel est déjà devenu la référence quotidienne de ses équipes.

À l'inverse, un sprint validé par une vraie recette coûte le même montant, mais achète en plus une garantie concrète : ce qui a été payé fonctionne réellement, dans les conditions de travail réelles de l'entreprise, pas seulement sur l'écran du développeur qui l'a construit.

Cette logique change la nature de la négociation avec un prestataire. Un client qui sait exactement ce qu'il doit vérifier avant d'accepter un sprint négocie d'égal à égal, plutôt que de faire confiance par défaut, faute de savoir quoi contrôler.

Le détail complet des formats de sprint et de leur chiffrage se trouve sur la page de l'offre Construction, avec la manière dont chaque sprint se termine par une démonstration et une session de recette avant d'être accepté.

Investir une heure de recette sérieuse sur un sprint à 13 000 euros représente un coût proportionnellement minime, comparé au risque de payer plusieurs sprints sur des fondations jamais vérifiées.

Cette logique de prix rapporté à la vérification vaut pour tous les formats. Un audit initial, entre 5 000 et 15 000 euros, se juge sur la clarté du diagnostic livré ; un site avec des fonctions métier, entre 15 000 et 50 000 euros, se juge sur les mêmes scénarios rejoués en conditions réelles avant acceptation.

Comment nous organisons la recette chez Techmind

Chaque sprint de deux semaines se termine, chez nous, par une démonstration d'une heure sur le produit réel, jamais sur des maquettes ni des captures d'écran préparées à l'avance. Ce qui se montre à ce moment-là est exactement ce qui tourne, avec les vraies données de test.

Cette démonstration se déroule devant les utilisateurs métier concernés par le sprint, pas seulement devant le chef de projet côté client. Une comptable, un magasinier ou un commercial voit fonctionner la partie du logiciel qui le concerne, et pose ses questions en direct.

Les scénarios rejoués pendant cette heure sont ceux prévus au départ du sprint, écrits avec le client avant que le développement ne commence. Rien d'improvisé, rien de découvert sur place : la recette vérifie ce qui avait été annoncé, ni plus ni moins.

Quand un écart apparaît, il est noté sur place, trié entre mineur et bloquant selon la méthode décrite plus haut, et corrigé avant la démonstration suivante. Le sprint n'est considéré comme accepté qu'une fois cette vérification faite, jamais avant.

Nous ne facturons pas la recette comme une prestation séparée : elle fait partie du sprint lui-même, comprise dans le prix annoncé au départ. Aucune ligne supplémentaire n'apparaît sur la facture pour ce moment de vérification, parce qu'il fait partie, à nos yeux, du travail normal de livraison.

Cette pratique demande un effort réel de notre côté : préparer des données de démonstration propres, tenir le rythme des sessions, accepter qu'un écart retarde parfois une facture. Nous la maintenons parce qu'elle protège autant votre entreprise que notre propre réputation sur la durée.

Si votre entreprise prépare un projet de logiciel sur mesure et souhaite comprendre comment ce déroulé s'articule avec le cahier des charges puis la construction, la page qui présente l'ensemble du chantier reste le meilleur point de départ.

Une question précise sur votre projet trouve souvent une réponse plus rapide dans une conversation directe que dans une page générale, et nous restons disponibles pour en discuter avec vous.