Cahier de recette : modèle gratuit à remplir, exemple et méthode

Un cahier de recette est le document qui liste les cas de test permettant au client de vérifier qu'un logiciel livré fait bien ce qui était demandé. Chaque ligne décrit une vérification : l'exigence couverte, les étapes à suivre, les données à saisir, le résultat attendu, puis le résultat obtenu et un statut (OK, KO, bloqué). Ce guide vous montre comment le structurer, avec un exemple rempli, et vous donne un modèle Excel gratuit, prêt à remplir.

Qu'est-ce qu'un cahier de recette ?

En informatique, la recette est la phase pendant laquelle le client vérifie qu'un logiciel livré est conforme à sa commande avant de l'accepter. Le terme vient du vocabulaire industriel : « recetter » un ouvrage, c'est le contrôler avant de le réceptionner. Le cahier de recette rassemble les vérifications à mener pendant cette phase, puis en garde la trace : qui a testé quoi, quand, avec quel résultat.

Dans le vocabulaire international du test (celui de l'ISTQB), la recette correspond aux tests d'acceptation, et plus précisément aux tests d'acceptation utilisateur. Le cahier de recette en est la version opérationnelle : une suite de cas de test exécutables, et non un texte de principe.

Recette usine, VABF et VSR

Dans les projets français, surtout publics ou réalisés au forfait, la recette est souvent découpée en étapes successives :

• La recette usine : le fournisseur teste lui-même son logiciel, sur son environnement, avant de le livrer.
• La VABF (vérification d'aptitude au bon fonctionnement) : le client vérifie, sur un environnement proche de la production, que le logiciel répond aux exigences fonctionnelles. C'est là que le cahier de recette est le plus utilisé.
• La VSR (vérification de service régulier) : le logiciel tourne en production, en conditions réelles, pendant une période définie au contrat. On observe sa stabilité avant de prononcer la réception définitive.

Toutes les organisations n'emploient pas ces sigles. Dans une équipe agile, la recette se fait souvent sprint par sprint, sur les user stories terminées. Le besoin reste le même : une liste claire de ce qu'il faut vérifier et un suivi honnête de ce qui a été vérifié.

Recette et tests : quelle différence ?

Les tests unitaires, d'intégration et système sont menés par l'équipe qui construit le logiciel, pour trouver des défauts le plus tôt possible. La recette est menée du point de vue du client, pour décider si le logiciel peut être accepté. Les deux se recoupent : une bonne partie des cas de recette ressemble à des tests système. La différence tient à la question posée. Les tests de l'équipe demandent « est-ce que ça marche ? », la recette demande « est-ce que c'est ce qu'on a commandé ? ».

Qui rédige le cahier de recette ?

Le cahier de recette appartient au client, puisque c'est lui qui prononce l'acceptation. Concrètement, il est rédigé par le chef de projet côté métier (souvent appelé MOA), le Product Owner ou des utilisateurs clés, fréquemment avec l'aide d'un testeur logiciel ou d'un consultant QA qui maîtrise les techniques de conception de tests. Le fournisseur peut proposer une première version, mais le client la relit et la valide : sinon, c'est le fournisseur qui décide de ce sur quoi il sera jugé.

Idéalement, la rédaction commence dès que les exigences sont stables, bien avant la livraison. Écrire les cas de test tôt fait apparaître les exigences floues ou contradictoires au moment où elles coûtent le moins cher à corriger.

La structure d'un cahier de recette

Un cahier de recette tient en un tableau. Voici les colonnes que nous recommandons, et celles du modèle à télécharger :

Selon le projet, on ajoute une colonne priorité (pour savoir quoi jouer en premier si le temps manque), une colonne environnement ou navigateur, ou une colonne campagne lorsque le même cahier sert à plusieurs livraisons.

Exemple de cahier de recette rempli

Prenons une fonctionnalité simple : la connexion à un espace client par e-mail et mot de passe, plus le lien « mot de passe oublié ». Voici quatre cas, tels qu'ils apparaîtraient après une première campagne :

Trois enseignements dans ce petit extrait. Le cas CR-002 montre pourquoi on teste les erreurs : le parcours nominal fonctionne, mais un simple mot de passe erroné fait planter l'application. Le cas CR-004 n'est pas un échec du logiciel : il est bloqué par l'environnement, et le compter comme KO fausserait le bilan. Enfin, chaque résultat attendu est vérifiable sans interprétation : un message précis, un délai chiffré.

Méthode : rédiger et mener une recette pas à pas

1. Rassemblez les exigences. Cahier des charges, spécifications, user stories et leurs critères d'acceptation. Numérotez-les si ce n'est pas déjà fait.
2. Découpez par parcours métier. Regroupez les cas par fonctionnalité ou par parcours utilisateur (commander, payer, se faire rembourser) plutôt que par écran.
3. Écrivez d'abord les cas nominaux, ceux où tout se passe bien, puis les cas d'erreur et les cas limites. Les techniques classiques aident à ne rien oublier : partitions d'équivalence, valeurs limites, tables de décision.
4. Fixez les données de test et vérifiez qu'elles existent dans l'environnement de recette avant la campagne.
5. Faites relire le cahier par le métier : un cas que personne ne comprend sera mal exécuté.
6. Exécutez et notez au fil de l'eau : résultat obtenu, statut, date. Ne reconstituez jamais un cahier de mémoire en fin de journée.
7. Ouvrez une anomalie pour chaque KO, avec les étapes de reproduction, une capture et la gravité, puis reportez son numéro dans le cahier.
8. Rejouez après correction le cas concerné (retest) et ses voisins (non-régression), puis faites le bilan avec la synthèse : avancement, taux de réussite, anomalies ouvertes.

Le bilan sert à décider. On fixe à l'avance les critères d'acceptation de la recette, par exemple « aucune anomalie bloquante ou majeure ouverte, tous les cas prioritaires exécutés », et on compare la synthèse à ces critères. C'est plus solide qu'une impression générale.

Les erreurs fréquentes

• Des étapes trop vagues (« tester la connexion ») : impossible de savoir ce qui a été réellement vérifié.
• Un résultat attendu absent ou rédigé après coup : on finit par valider ce que fait l'application, pas ce qui était demandé.
• Uniquement des cas nominaux : la majorité des anomalies se cachent dans les erreurs de saisie, les droits et les cas limites.
• Des statuts libres (« presque OK », « à revoir ») : aucune synthèse fiable n'est possible.
• Des cas sans lien avec une exigence : on ne sait plus si tout a été couvert, ni ce que l'on peut retirer.
• Un cahier jamais mis à jour quand les exigences changent : il finit par tester une application qui n'existe plus.

Du cahier de recette à l'automatisation

Un cahier de recette bien écrit est aussi le meilleur point de départ pour automatiser des tests. Des étapes précises, des données fixées et un résultat attendu vérifiable : c'est exactement ce dont un script de test a besoin.

Tout n'est pas à automatiser. Les bons candidats sont les cas stables (la fonctionnalité ne change plus tous les quinze jours), rejoués souvent (à chaque livraison, en non-régression) et à fort enjeu (connexion, paiement, calculs). Les cas qui demandent un jugement humain, comme l'ergonomie ou la lisibilité d'un document, restent manuels.

Dans l'exemple ci-dessus, les cas CR-001 à CR-003 se transforment directement en tests Playwright qui tournent à chaque livraison, et les vérifications côté serveur relèvent des tests d'API. Pour savoir si l'effort vaut la peine sur votre projet, le calculateur de ROI de l'automatisation compare le temps passé en recette manuelle au coût d'écriture et de maintenance des scripts.

Questions fréquentes