Le cahier de recette est le document qui prouve, test par test, que ce qui a été livré correspond à ce qui a été commandé. Voici comment le construire, avec un exemple rédigé et une trame à copier.
Qu’est-ce qu’un cahier de recette ?
La recette (ou recettage) est la phase d’un projet où le client vérifie que le livrable fonctionne comme prévu avant de l’accepter : un logiciel, un site web, un outil de gestion paramétré, une intégration entre deux systèmes. Le cahier de recette est le support de cette vérification : la liste organisée des tests à dérouler, avec pour chacun le scénario à exécuter, le résultat attendu, le résultat obtenu et le verdict. Une fois tous les tests passés, il fonde le procès-verbal de recette, c’est-à-dire l’acceptation formelle du livrable.
Le terme vient du monde informatique, mais l’objet sert bien au-delà des équipes techniques : c’est le document du client, pas celui du développeur. Il se rédige du point de vue de l’utilisateur métier (« quand je crée un devis et que je le convertis en facture, la numérotation suit »), et il peut être déroulé par des personnes qui n’ont jamais écrit une ligne de code. Pour une TPE ou une PME qui fait développer son site, déploie un nouvel outil de gestion ou fait paramétrer un module par un prestataire, c’est même l’un des documents les plus rentables du projet : quelques heures de rédaction contre des semaines de litiges évités.
Le cahier de recette remplit trois fonctions :
- Vérifier avant d’accepter. Il organise la chasse aux écarts entre le commandé et le livré, pendant qu’il est encore temps de les faire corriger au titre du projet, pas de la maintenance.
- Objectiver le désaccord. « Ça ne marche pas » contre « si, ça marche » est un dialogue sans issue. « Le test 12 donne X au lieu de Y » est un constat que les deux parties peuvent regarder ensemble.
- Dater l’acceptation. La signature du procès-verbal de recette déclenche en général le paiement du solde, le démarrage de la garantie et le transfert de responsabilité. Sans recette formelle, ces trois curseurs restent flous, et le flou profite rarement au client.
Un peu de vocabulaire : recette, VABF, VSR, PV
Les projets informatiques structurés distinguent deux temps. La vérification d’aptitude au bon fonctionnement (VABF) est la recette à proprement parler : le client teste le livrable hors production et prononce l’acceptation, le cas échéant avec des réserves. La vérification de service régulier (VSR) observe ensuite le comportement en conditions réelles pendant une période convenue avant l’acceptation définitive. Chaque étape se conclut par un procès-verbal signé. Dans les projets plus modestes, on parle simplement de recette et de PV de recette ; l’important n’est pas le vocabulaire, c’est qu’un document liste les vérifications et qu’une signature date l’acceptation.
Cahier de recette, cahier des charges, plan de test : qui fait quoi
| Document | Qui l’écrit | Ce qu’il dit | Quand |
|---|---|---|---|
| Cahier des charges fonctionnel | Le client | Ce que le livrable doit permettre de faire (le besoin) | Avant de contractualiser |
| Plan de test | Le prestataire ou l’équipe qualité | La stratégie de test complète : tests unitaires, d’intégration, de performance, de sécurité | Pendant la réalisation |
| Cahier de recette | Le client (aidé du prestataire) | Les vérifications métier qui conditionnent l’acceptation | Préparé pendant la réalisation, déroulé à la livraison |
| PV de recette | Les deux parties | Le constat signé : accepté, accepté avec réserves, ou refusé | À l’issue de la campagne |
La filiation est directe : chaque exigence du cahier des charges doit se retrouver dans au moins un cas de recette, sinon elle ne sera jamais vérifiée. C’est d’ailleurs le premier réflexe de construction : dérouler le cahier des charges ligne à ligne et se demander « comment saurai-je que c’est fait ? ». Inversement, le cahier de recette ne teste pas tout : les tests techniques internes (unitaires, charge, sécurité) relèvent du plan de test du prestataire. La recette se concentre sur ce que le client peut constater : les parcours métier, les données, les documents produits.
Ce que contient un cahier de recette
Le cœur du document est un tableau de cas de test. Chaque ligne suit la même anatomie, six colonnes qui suffisent à presque tous les projets :
- Un identifiant (T-01, T-02…) pour désigner le cas sans ambiguïté dans les échanges et les tickets d’anomalie.
- Le scénario : les actions à exécuter, pas à pas, du point de vue de l’utilisateur, avec le point de départ précisé (« connecté en tant que commercial, depuis la fiche client… »).
- Les données de test : avec quel client fictif, quel produit, quel montant. Sans données définies, deux testeurs obtiennent des résultats différents et le débat repart.
- Le résultat attendu : observable et binaire, comme un jalon. « La facture PDF affiche la mention X et le total Y » se constate ; « la facturation fonctionne correctement » s’interprète.
- Le résultat obtenu, rempli pendant la campagne, avec une capture d’écran quand il diffère de l’attendu.
- Le verdict : OK, KO, ou non testable (quand un KO en amont bloque le cas), avec la référence de l’anomalie ouverte le cas échéant.
Autour du tableau, quelques rubriques de cadrage évitent les malentendus : le périmètre exact de la recette (quelle version, quel environnement, quelles fonctionnalités), les prérequis (comptes de test, jeu de données chargé, accès), le calendrier de la campagne et les personnes qui testent, la grille de classement des anomalies et la règle d’acceptation (on y revient plus bas), et l’historique des versions du document. L’ensemble tient dans un tableur partagé pour la plupart des projets ; les grandes campagnes utilisent des outils dédiés, mais l’outil ne change rien à la méthode.
Construire son cahier de recette en cinq étapes
1. Partir du cahier des charges, pas de l’écran
La tentation naturelle est d’ouvrir l’application livrée et de lister ce qu’on voit. C’est le piège : on teste alors ce qui existe, pas ce qui était demandé, et les manques passent au travers. La bonne matrice de départ est le cahier des charges (ou le devis détaillé, ou la note de cadrage quand c’est le seul écrit) : chaque exigence devient un ou plusieurs cas de test. Ce travail révèle au passage les exigences invérifiables (« l’interface devra être intuitive ») : mieux vaut les découvrir en préparant la recette qu’au moment du désaccord.
2. Écrire des scénarios métier, de bout en bout
Les cas les plus révélateurs ne testent pas un écran mais un processus complet, tel qu’il se déroulera en vrai : créer un client, lui faire un devis, le faire accepter, le facturer, encaisser, relancer. Les défauts se logent dans les enchaînements (les reports de données, les statuts, les numérotations) bien plus que dans les écrans pris un à un. Écrivez ces parcours avec les utilisateurs qui feront le travail au quotidien : ils connaissent les cas tordus qui font la vraie vie, le client avec deux adresses, l’avoir partiel, le devis modifié après envoi.
3. Couvrir les cas aux limites, pas seulement le chemin heureux
Un cahier de recette qui ne teste que les cas nominaux valide un livrable de démonstration. Ajoutez systématiquement trois familles : les cas d’erreur (que se passe-t-il si le champ est vide, si le montant est négatif, si le fichier est trop lourd), les cas limites (le dernier jour du mois, la TVA à taux multiples, le nom avec apostrophe), et les interdits (ce que l’utilisateur ne doit PAS pouvoir faire : modifier une facture validée, voir les données d’un autre compte). Quelques cas bien choisis suffisent ; l’exhaustivité est l’affaire du plan de test du prestataire.
4. Fixer la règle du jeu avant de commencer
Deux conventions se négocient avant la campagne, jamais pendant. D’abord la classification des anomalies : bloquante (un processus essentiel est impossible), majeure (un processus est dégradé mais contournable), mineure (défaut sans impact sur l’usage : libellé, mise en forme). Ensuite la règle d’acceptation qui en découle, par exemple : zéro bloquante, zéro majeure non corrigée, les mineures listées en réserves avec un délai de correction. Sans cette règle écrite, la fin de recette se joue au rapport de force ; avec elle, le verdict se constate.
5. Organiser la campagne comme un mini-projet
Une recette se planifie : qui teste quoi, sur quel environnement, sur quelle période, et comment les anomalies sont remontées (un canal unique, un format unique : identifiant du cas, constat, capture). Prévoyez d’emblée deux passes : la première campagne détecte, le prestataire corrige, la seconde campagne vérifie les corrections et rejoue les cas voisins. Croire qu’une seule passe suffira est l’erreur de planning la plus courante de la phase, et c’est elle qui met la date de mise en service sous pression au pire moment.
Exemple rédigé : la recette d’un outil de gestion déployé
Reprenons une situation concrète : une PME de services, huit salariés, a fait paramétrer son nouvel outil de gestion (clients, devis, factures) par un intégrateur, avec reprise de ses données. Extrait du cahier de recette déroulé avant la bascule, sur l’environnement de test, semaine du 6 octobre. Testeuses : Sofia (comptabilité) et Inès (commerce).
| ID | Scénario | Données | Résultat attendu | Obtenu | Verdict |
|---|---|---|---|---|---|
| T-01 | Connectée en profil commercial, créer un devis depuis la fiche client, ajouter 2 lignes du catalogue, envoyer par email | Client test « Dupré SARL », articles A12 et A15 | Devis numéroté à la suite, PDF conforme au modèle, email reçu sur la boîte test | Conforme | OK |
| T-02 | Accepter le devis T-01 puis le convertir en facture | Devis issu de T-01 | Facture reprenant lignes et remise, numérotation factures distincte de celle des devis | La remise de pied de devis n’est pas reprise | KO, anomalie A-07 (majeure) |
| T-03 | Vérifier la reprise des données clients | Échantillon de 30 fiches tirées du fichier d’origine | Coordonnées, conditions de paiement et encours identiques à l’ancien système | 28 conformes, 2 écarts d’adresse | KO, anomalie A-08 (mineure) |
| T-04 | En profil commercial, tenter de modifier une facture validée | Facture validée du jeu de test | Modification impossible, proposition de créer un avoir | Conforme | OK |
| T-05 | Créer une facture avec deux taux de TVA et un acompte déjà facturé | Client test, lignes à 20 % et 10 %, acompte de 30 % | Totaux par taux exacts, acompte déduit, solde correct | Conforme | OK |
La campagne complète comptait 42 cas : 36 OK, 4 KO corrigés puis revalidés en seconde passe, 2 réserves mineures au PV avec correction sous quinzaine. Le PV signé a déclenché la bascule le 20 octobre. À noter : le cas T-02, celui qui aurait coûté le plus cher en production (des factures fausses), a été trouvé par Sofia en vingt minutes de test, précisément parce que le scénario suivait un enchaînement réel et non un écran isolé.
Trame de cahier de recette à copier
Le canevas suivant s’adapte à la plupart des projets de TPE et PME. Copiez-le dans un tableur partagé : un onglet de cadrage, un onglet de cas, un onglet d’anomalies.
Cahier de recette : [projet]. Version [n°] du [date]. Rédacteurs : [noms].
1. Périmètre. Livrable testé : [application, site, module] en version [n°], sur l’environnement [test/préproduction, URL]. Hors périmètre : [ce qui n’est pas testé ici et pourquoi].
2. Prérequis. Comptes de test : [profils et droits]. Jeu de données : [contenu, qui le charge]. Accès : [qui, comment].
3. Organisation. Campagne du [date] au [date]. Testeurs : [nom : périmètre]. Anomalies remontées via [canal], au format [ID du cas, constat, capture]. Seconde passe prévue du [date] au [date].
4. Règle d’acceptation. Anomalie bloquante : [définition]. Majeure : [définition]. Mineure : [définition]. Le livrable est accepté si : [zéro bloquante, zéro majeure ouverte, mineures en réserves avec délai].
5. Cas de test. Tableau : ID, scénario pas à pas, données, résultat attendu, résultat obtenu, verdict (OK / KO / non testable), anomalie liée.
6. Registre des anomalies. ID, cas d’origine, description, gravité, statut (ouverte / corrigée / revalidée), version de correction.
7. Synthèse et PV. Cas passés : [x/y]. Anomalies restantes : [liste]. Décision : accepté / accepté avec réserves [listées, avec délais] / refusé. Signatures et date.
Le PV de recette : ce que l’acceptation engage
La recette n’est pas qu’une affaire de qualité, c’est un acte contractuel. Le procès-verbal signé matérialise l’acceptation du livrable, et cette acceptation emporte des conséquences qu’il faut connaître avant de signer : elle déclenche généralement l’exigibilité du solde, elle fait démarrer les périodes de garantie prévues au contrat, et elle rend plus difficile de se plaindre ensuite des défauts qui étaient décelables pendant la campagne. D’où trois pratiques de prudence :
- Les réserves s’écrivent. Une acceptation avec réserves ne vaut que si les réserves sont listées précisément dans le PV, avec un délai de correction et ce qui se passe s’il n’est pas tenu. « Quelques points restent à corriger » ne protège personne.
- On ne signe pas sous la pression du calendrier. Si la date de mise en service arrive et que des anomalies majeures subsistent, l’alternative honnête est le report ou l’acceptation partielle sur un périmètre réduit, pas la signature « pour avancer » d’un PV qui dit que tout va bien.
- Le refus est un droit qui se motive. Un refus de recette s’appuie sur le cahier : la liste des cas KO au regard de la règle d’acceptation convenue. C’est exactement pour ce moment-là que la règle a été écrite avant la campagne.
Ces principes valent dans les deux sens : un prestataire sérieux a autant intérêt au cahier de recette que son client, car le même document qui permet de refuser un livrable défaillant permet aussi de constater qu’un livrable conforme doit être payé, et de distinguer l’anomalie (à corriger sous garantie) de la demande nouvelle (à chiffrer en avenant).
Les erreurs qui vident la recette de son sens
- Écrire le cahier après la livraison. Rédigé devant le produit fini, il décrit ce qui existe au lieu de vérifier ce qui était dû. Il se prépare pendant la réalisation, à partir du cahier des charges.
- Laisser le prestataire recetter seul. Le prestataire teste ce qu’il a compris du besoin ; or c’est justement l’écart de compréhension qu’on cherche. Les scénarios s’écrivent et se déroulent côté métier.
- Des résultats attendus flous. « Vérifier que la facturation fonctionne » n’est pas un cas de test. Chaque attendu doit être constatable par un tiers qui n’a pas assisté aux discussions.
- Tester sans jeu de données défini. Chacun teste avec « son » client et « son » exemple, les constats divergent, et la moitié des anomalies ne sont pas reproductibles.
- Ne dérouler que les cas nominaux. Les défauts coûteux vivent dans les limites : fins de mois, taux multiples, statuts verrouillés, droits d’accès.
- Négocier la gravité pendant la campagne. Si « bloquant » se rediscute à chaque anomalie, la classification devient un bras de fer. La grille se fige avant le premier test.
- Oublier la seconde passe. Valider une correction sans rejouer le cas (et ses voisins) revient à croire sur parole ; les régressions naissent là.
- Confondre recette et formation. Découvrir l’outil en le testant fausse les deux exercices. Une prise en main rapide précède la campagne ; la recette vérifie, elle n’enseigne pas.
Après la recette : la bascule ne s’improvise pas
Un PV signé n’est pas une mise en service. Entre les deux restent la reprise finale des données (celle de la recette portait sur un échantillon ou une copie datée), la formation des utilisateurs, la période de fonctionnement en conditions réelles avec un suivi rapproché des premiers jours, et la décision explicite d’éteindre l’ancien système. Ces étapes appartiennent à la feuille de route du projet, avec leurs propres jalons ; la revue de projet qui suit la mise en service, un mois plus tard, referme proprement le cycle en comparant ce qui avait été promis, recetté et réellement obtenu.
Un mot sur l’outillage, enfin. Le cahier de recette lui-même vit très bien dans un tableur partagé. Ce qui mérite un vrai outil, c’est le pilotage autour : les cas à dérouler assignés comme tâches datées, les anomalies suivies jusqu’à revalidation, les jalons de la campagne visibles dans le planning du projet. Les entreprises qui gèrent leurs projets dans un outil comme Djaboo y logent naturellement la campagne de recette : les cas répartis en tâches par testeur, les anomalies en tickets avec leur statut, et le jalon « PV signé » qui conditionne la suite de la feuille de route. La méthode reste la même ; elle est simplement au même endroit que le reste du projet.
Questions fréquentes sur le cahier de recette
Qui doit rédiger le cahier de recette : le client ou le prestataire ?
Le client tient la plume sur les scénarios métier, car c’est sa compréhension du besoin qui sert d’étalon ; le prestataire aide à la mise en forme, signale les cas techniques utiles et fournit l’environnement et les données. Un cahier écrit à quatre mains est l’idéal ; un cahier écrit par le seul prestataire perd sa fonction de contrôle.
Quelle est la différence entre recette et test ?
Le test est le terme générique ; la recette est la campagne de tests d’acceptation menée par le client pour décider s’il accepte le livrable. Les tests unitaires, d’intégration ou de performance relèvent du prestataire pendant la réalisation ; la recette arrive en bout de chaîne et se place du point de vue de l’usage.
Combien de cas de test faut-il prévoir ?
Autant que d’exigences à vérifier, pas plus : de vingt à cinquante cas pour un déploiement d’outil de gestion en PME, plusieurs centaines pour un développement sur mesure conséquent. Le bon indicateur n’est pas le nombre mais la couverture : chaque exigence du cahier des charges doit être tracée vers au moins un cas.
Que faire si le projet n’a pas de cahier des charges ?
Reconstituer la référence avant de tester : le devis détaillé, les comptes rendus, les échanges écrits définissent ce qui était convenu. La recette révélera alors surtout des zones jamais spécifiées ; traitez-les comme des décisions à prendre (et éventuellement des avenants), pas comme des anomalies, et retenez la leçon pour le projet suivant.
Une anomalie découverte après la recette est-elle couverte ?
Cela dépend du contrat : c’est le rôle de la garantie (souvent appelée garantie de parfait achèvement ou période de maintenance corrective) qui suit l’acceptation. D’où l’importance de faire figurer sa durée et son périmètre au contrat, et de lister en réserves au PV tout ce qui est déjà connu : une réserve écrite ne se discute pas, un souvenir oral si.
Combien de temps prévoir pour une recette ?
Comptez la campagne elle-même, mais aussi les corrections et la seconde passe : pour un déploiement d’outil en PME, une à deux semaines de tests répartis sur les testeurs, une à deux semaines de corrections, puis quelques jours de revalidation forment un ordre de grandeur réaliste. Le point dur n’est pas la durée totale, c’est la disponibilité des testeurs : des cas déroulés « quand on a le temps » étirent la phase sans fin. Bloquez des créneaux nommés dans les agendas, comme pour n’importe quel jalon du projet.
Le cahier de recette sert-il encore en méthode agile ?
Oui, sous une autre forme : les critères d’acceptation de chaque user story jouent le rôle des résultats attendus, et la démonstration de fin de sprint celui de mini-recettes continues. Un jalon de recette globale reste utile avant une mise en production majeure, précisément parce qu’il rejoue les parcours de bout en bout que les validations au fil de l’eau ne couvrent pas.
L’essentiel à retenir
Un bon cahier de recette en 2026 se prépare pendant la réalisation à partir du cahier des charges, décrit des scénarios métier de bout en bout avec des données définies et des attendus constatables, fixe la grille de gravité et la règle d’acceptation avant le premier test, et prévoit deux passes. Il se conclut par un PV daté où les réserves sont écrites. Quelques heures de préparation, déroulées par les utilisateurs eux-mêmes : c’est le prix d’une mise en service sereine et d’une relation prestataire qui repose sur des constats plutôt que sur des impressions.
