Cahier de recette : définition, contenu et méthode de rédaction
Un cahier de recette est le document qui liste tous les cas de test à exécuter avant d'accepter un logiciel : pour chaque cas, les étapes à suivre, les données à utiliser et le résultat attendu. Il permet de vérifier que la livraison respecte la spécification, et ses résultats alimentent le PV de recette qui acte l'acceptation.
À quoi sert un cahier de recette ?
Le cahier de recette transforme une spécification, forcément rédigée en langage courant, en vérifications concrètes que n'importe quel testeur peut rejouer. Il sert à quatre choses :
- Vérifier la conformité : chaque exigence de la spécification est couverte par au moins un cas de test.
- Partager un référentiel : le prestataire et le client s'accordent, avant les tests, sur ce qui sera contrôlé et sur ce qu'on attend de chaque fonction.
- Tracer les résultats : chaque exécution est enregistrée (OK, KO, bloqué ou non applicable), avec ses commentaires et ses anomalies.
- Décider de la livraison : la synthèse des résultats fonde le verdict du PV de recette (acceptée, acceptée avec réserves ou refusée).
Qui rédige et qui exécute le cahier de recette ?
La répartition dépend du contrat. Le plus souvent, le prestataire (la maîtrise d'œuvre, MOE) rédige le cahier à partir de la spécification et le soumet au client (la maîtrise d'ouvrage, MOA) pour relecture. Le client peut aussi l'écrire lui-même. L'exécution revient aux utilisateurs métier du client, parfois accompagnés d'un testeur du prestataire, sous le pilotage d'un chef de projet.
Dans les ESN et les agences, le cahier est le plus souvent écrit par le prestataire, puis exécuté par des testeurs côté client : il faut donc que ceux-ci puissent le consulter et saisir leurs résultats sans outil lourd. Voir Spec2Sign pour les ESN et agences.
Que contient un cahier de recette ?
Un cahier de recette est en général un tableau dont chaque ligne est un cas de test. Les colonnes les plus courantes sont les suivantes :
| Colonne | Rôle |
|---|---|
| Identifiant | Référence unique du cas (par exemple CT-012), reprise dans les anomalies et dans le PV. |
| Exigence source | Section ou exigence de la spécification que le cas vérifie : c'est ce qui permet de prouver la couverture. |
| Lot ou module | Regroupement fonctionnel, utile pour répartir l'exécution entre plusieurs testeurs. |
| Titre | Ce que le cas vérifie, en une phrase. |
| Préconditions et jeu de données | État de départ, comptes à utiliser, valeurs de test. |
| Étapes | Actions à réaliser, une par ligne, dans l'ordre. |
| Résultat attendu | Comportement observable qui valide le cas. |
| Priorité | Importance du cas dans la décision de recette. |
| Statut | OK, KO, bloqué ou non applicable, renseigné à l'exécution. |
| Commentaire et anomalie | Observation du testeur et lien vers l'anomalie ouverte en cas d'écart. |
Comment rédiger un cahier de recette en 6 étapes
- Extraire les exigences testables de la spécification. Une exigence floue (« le site doit être rapide ») est à clarifier avec le client avant d'écrire le moindre cas.
- Organiser en lots et en modules qui reflètent l'application (authentification, commande, facturation…), pour pouvoir répartir et suivre l'exécution.
- Écrire les cas : une intention de test par cas, des étapes courtes à l'impératif, un résultat attendu que l'on peut constater sans interprétation.
- Prévoir les jeux de données et les prérequis : comptes, droits, états initiaux. Un cas qu'on ne peut pas rejouer faute de données se retrouve « bloqué ».
- Prioriser : si le temps manque, les cas critiques doivent être exécutés en premier. Indiquez aussi ce qui bloque la livraison et ce qui peut devenir une réserve.
- Faire relire par le client, puis versionner le cahier avec la spécification qu'il vérifie. Un cahier qui ne suit pas la version de la spec ne prouve plus rien.
Exemple de cas de test
| Champ | Contenu |
|---|---|
| Identifiant | CT-012 |
| Exigence source | Authentification, § 2.3 : un mot de passe erroné est refusé. |
| Titre | Connexion avec un mot de passe incorrect |
| Préconditions | Un compte actif existe avec l'adresse [email protected]. |
| Étapes | 1. Ouvrir la page de connexion. 2. Saisir [email protected] et un mot de passe incorrect. 3. Cliquer sur « Se connecter ». |
| Résultat attendu | Un message d'erreur explicite s'affiche, l'utilisateur reste sur la page de connexion et n'accède à aucune donnée. |
| Priorité | Haute |
Les statuts d'exécution d'un cas de test
| Statut | Signification |
|---|---|
| OK | Le résultat observé correspond au résultat attendu. |
| KO | Un écart est constaté : une anomalie est ouverte et rattachée au cas. |
| Bloqué | Le cas ne peut pas être exécuté (prérequis manquant, anomalie bloquante en amont). |
| N/A | Le cas ne s'applique pas à cette version ou à ce périmètre. |
À la fin de la campagne, le nombre de cas par statut et la gravité des anomalies restantes servent de base au verdict du PV de recette.
Recette, VABF, VSR : quelles différences ?
La recette désigne l'ensemble de la phase de vérification qui aboutit à l'acceptation du logiciel. Dans certains contrats, notamment les marchés publics informatiques, elle se décompose en deux étapes : la VABF (vérification d'aptitude au bon fonctionnement), qui contrôle que le système livré fonctionne conformément à ce qui était attendu, puis la VSR (vérification de service régulier), qui observe son fonctionnement dans la durée, en conditions réelles d'exploitation. Leur durée et leurs critères sont fixés par le contrat.
Le cahier de recette décrit ce que l'on vérifie ; ces sigles décrivent le moment et le cadre contractuel de la vérification. Retrouvez ces définitions dans le glossaire de la recette logicielle.
Les erreurs fréquentes
- Écrire le cahier en fin de projet, quand il n'y a plus le temps de corriger la spécification ambiguë qu'il révèle.
- Des cas sans résultat attendu mesurable (« la page s'affiche correctement ») : deux testeurs concluront différemment.
- Aucun lien avec les exigences : impossible de dire ce qui n'est pas couvert.
- Une spécification qui évolue et un cahier qui ne suit pas : les cas testent une version qui n'existe plus.
- Plusieurs versions d'un même fichier Excel qui circulent par email, avec des résultats saisis à plusieurs endroits.
Excel ou outil dédié ?
Pour un petit projet et un seul testeur, un tableur suffit. Dès que la recette implique plusieurs testeurs, des versions successives de la spécification et un suivi des anomalies, un outil dédié évite les doublons et garde la traçabilité. Le comparatif entre Excel, les outils de gestion de tests et Spec2Sign détaille les critères de choix.
Générer son cahier de recette avec Spec2Sign
Spec2Sign produit le cahier de recette à partir de vos spécifications :
- vous déposez la spécification (PDF, Word, Excel ou Markdown) ;
- l'IA en extrait les exigences, citées mot pour mot avec leur source, et propose un plan en lots et modules ;
- pour chaque exigence, elle rédige des cas de test avec étapes, résultat attendu, priorité et jeux de données, et signale les points à clarifier que la spécification laisse ouverts ;
- une matrice de couverture montre les exigences sans cas de test ;
- quand la spécification change, une analyse d'impact propose les cas à ajouter, à modifier ou à rendre obsolètes, que vous acceptez ligne par ligne.
Le cahier généré est une proposition : relisez-le et validez-le avant tout usage contractuel.
Questions fréquentes
Quelle est la différence entre un cahier de recette et un plan de test ?
Le plan de test décrit la stratégie : périmètre, types de tests, environnements, ressources et planning. Le cahier de recette en est la partie opérationnelle : la liste des cas de test précis à exécuter, avec leur résultat attendu. Sur de nombreux projets d'ESN et d'agences, on produit directement le cahier de recette, précédé de quelques lignes de cadrage.
Quand faut-il rédiger le cahier de recette ?
Dès que la spécification est stable, et pas à la fin du développement. Écrire les cas en parallèle fait apparaître tôt les ambiguïtés de la spécification, quand elles sont encore peu coûteuses à lever.
Combien de cas de test faut-il prévoir ?
Il n'existe pas de nombre universel. L'objectif minimal est que chaque exigence soit couverte par au moins un cas ; on ajoute ensuite des cas aux limites et aux erreurs sur les fonctions critiques. Prioriser les cas permet d'exécuter l'essentiel si le temps manque.
Peut-on générer un cahier de recette avec l'IA ?
Oui. Spec2Sign extrait les exigences d'une spécification et rédige les cas de test correspondants, chacun rattaché à sa section source. Le résultat reste une proposition qu'un humain doit relire et valider avant de l'utiliser pour une recette.