Cahier de recette informatique : la méthode complète pour le rédiger + modèle

Dans un projet informatique, 70 à 80 % des anomalies détectées en production auraient pu l’être en phase de recette, à condition d’avoir un cahier de recette bien construit. Ce document n’a rien de cosmétique : c’est lui qui acte la conformité du livrable, qui déclenche le paiement final côté prestataire, et qui couvre vos arrières en cas de litige.

Pourtant, beaucoup de chefs de projet le bâclent ou le confondent avec un simple plan de tests. Dans cet article, nous allons voir ce qu’est précisément un cahier de recette, à quel moment le rédiger, quelles rubriques il doit contenir, et comment écrire des cas de test exploitables sans y passer trois semaines.

Qu’est-ce qu’un cahier de recette en informatique ?

Le cahier de recette est le document qui regroupe l’ensemble des tests à dérouler pour vérifier qu’un livrable informatique (site web, application, logiciel, module ERP) est conforme aux spécifications définies en amont. Il sert de référence partagée entre la maîtrise d’ouvrage (MOA, côté métier) et la maîtrise d’œuvre (MOE, côté technique).

Concrètement, il répond à une question simple : est-ce que ce qui a été livré fonctionne et correspond bien à ce qui avait été demandé ?

À ne pas confondre avec :

• Le cahier des charges : il décrit ce qu’il faut construire, en amont du projet.
• Le plan de tests : il décrit la stratégie globale de tests (périmètre, méthode, planning), pas les tests eux-mêmes.
• Le procès-verbal de recette : c’est le document final qui acte la validation (ou non) du livrable à l’issue des tests.

Le cahier de recette se situe donc entre les deux : c’est la matérialisation opérationnelle de la phase de recette.

Cahier de recette ou cahier de recettage : que faut-il dire ?

Vous avez probablement entendu les deux. La confusion vient du fait que la phase elle-même peut être appelée « la recette » ou « le recettage », les deux étant corrects et synonymes.

En revanche, dans la littérature professionnelle, c’est « cahier de recette » qui s’impose. OpenClassrooms, les blogs spécialisés, les éditeurs de logiciels de test, les agences digitales : tous parlent du cahier de recette. « Cahier de recettage » existe à l’oral et dans certains contextes internes, mais reste minoritaire à l’écrit.

Notre conseil : utilisez « cahier de recette » dans vos documents officiels, vos contrats et vos livrables. C’est le terme métier reconnu. Vous pouvez parler de « recettage » pour désigner la phase ou le processus, mais pas pour nommer le document.

Quand rédiger le cahier de recette dans un projet ?

Erreur classique : démarrer la rédaction du cahier de recette à la fin de la phase de développement, quand le livrable arrive. Trop tard.

La bonne pratique consiste à commencer la rédaction dès la phase de spécifications fonctionnelles. Pourquoi ? Parce que les cas de test découlent directement des cas d’utilisation. Si vous attendez la fin du développement pour les rédiger, vous risquez :

• D’oublier des fonctionnalités qui semblaient évidentes lors des specs.
• De manquer de temps pour des tests sérieux avant la mise en production.
• De découvrir des incohérences dans les specs trop tard pour les corriger sans douleur.

Selon la méthode projet, le timing varie un peu :

• En cycle en V : le cahier de recette est rédigé en parallèle des spécifications fonctionnelles, puis enrichi tout au long du développement.
• En mode agile : chaque user story embarque ses propres critères d’acceptation, qui constituent la base du cahier de recette. Celui-ci se construit sprint après sprint.

Dans les deux cas, le cahier doit être prêt et validé avant le démarrage effectif des tests, idéalement avec une relecture conjointe MOA / MOE pour valider la couverture fonctionnelle.

Que doit contenir un cahier de recette ?

Il n’existe pas de norme officielle, mais une structure type s’est imposée dans la pratique. Un cahier de recette complet contient les sections suivantes.

1. L’introduction et le contexte

• Présentation du projet et de ses objectifs.
• Périmètre fonctionnel couvert par les tests (et ce qui en est explicitement exclu).
• Glossaire des termes spécifiques au projet.
• Liste des parties prenantes et leurs rôles (chef de projet, testeurs métier, équipe technique, validateurs).

2. La stratégie de test

• Types de tests prévus : fonctionnels, non régression, performance, sécurité, ergonomie.
• Environnement de recette utilisé (URL, accès, jeux de données, comptes utilisateurs).
• Outils mobilisés pour le suivi des anomalies (Jira, Mantis, Redmine, ou un simple Google Sheet pour les petits projets).
• Planning des campagnes de tests.

3. Les critères d’acceptation

C’est la partie qui définit les conditions à remplir pour valider la recette : taux de réussite minimum, gravité maximale tolérée, périmètre obligatoire à 100 %. Sans ces critères, impossible de trancher objectivement à la fin.

4. Les cas de test détaillés

C’est le cœur du document, généralement sous forme de tableau. Pour chaque cas de test, on retrouve :

• Identifiant unique (ex : CT-001).
• Fonctionnalité testée et lien vers la spécification correspondante.
• Criticité : bloquant, majeur, mineur.
• Pré-requis : état initial du système, données nécessaires.
• Étapes du scénario, numérotées et précises.
• Résultat attendu : ce qu’il doit se passer.
• Résultat obtenu : ce qu’il s’est réellement passé.
• Statut : OK, KO, en cours, non testé.
• Responsable du test et date d’exécution.
• Commentaire / pièce jointe en cas d’anomalie (capture d’écran, log).

5. Le suivi et la synthèse

• Tableau de bord des résultats (nombre de tests passés, échoués, en attente).
• Liste des anomalies détectées avec leur criticité.
• Synthèse de fin de campagne.
• Décision de validation (acceptation, acceptation sous réserve, refus).

Comment rédiger un bon cas de test : la méthode

C’est là que beaucoup de cahiers de recette pèchent. Des cas de test mal écrits, c’est des tests inexploitables, des résultats ambigus, et au final des bugs qui passent en production.

Voici les règles à respecter pour chaque cas de test.

Soyez atomique. Un cas de test couvre une et une seule fonctionnalité, ou un et un seul parcours utilisateur. Si vous testez à la fois la connexion et le passage de commande dans le même cas, vous ne saurez plus quoi corriger en cas d’échec.

Soyez précis sur les données. « Saisir un email valide » ne suffit pas. Indiquez test.recette@chef-de-projet.fr. Tout testeur, même externe au projet, doit pouvoir rejouer le test à l’identique.

Décrivez le résultat attendu de façon mesurable. « L’utilisateur reçoit un message » est trop vague. Préférez : « Un message de confirmation s’affiche en haut de page avec le texte exact : Votre compte a été créé avec succès ».

Couvrez les cas nominaux et les cas d’erreur. Pour chaque fonctionnalité, prévoyez au minimum : le cas où tout se passe bien (chemin heureux), un cas avec données invalides, un cas avec donnée manquante, et un cas limite (valeur extrême).

Exemple complet de cas de test, pour une fonctionnalité de création de compte :

CT-005 : Création de compte avec email déjà existant
Pré-requis : un compte existe déjà avec l’email test@cdp.fr.
Étapes :

1. Cliquer sur « Créer un compte » depuis la page d’accueil.
2. Saisir l’email test@cdp.fr.
3. Saisir le mot de passe Test1234!.
4. Cliquer sur « Valider ».

Résultat attendu : la création est refusée. Un message rouge apparaît sous le champ email : « Cette adresse est déjà utilisée ». Aucun email de confirmation n’est envoyé.

Avec ce niveau de précision, n’importe quel testeur peut exécuter le cas sans avoir à interpréter quoi que ce soit.

Les erreurs à éviter dans la rédaction

Quelques pièges classiques, observés sur la majorité des projets qui dérapent en phase de recette :

• Rédiger le cahier seul, dans son coin. Un cahier de recette doit être co-construit avec le métier. Sans leur regard, vous passez à côté de cas d’usage évidents pour eux, mais invisibles depuis la spec.
• Confondre couverture exhaustive et couverture utile. Tester toutes les combinaisons possibles est mathématiquement impossible. Concentrez-vous sur les parcours critiques (ceux qui touchent au chiffre d’affaires, à la sécurité, à la conformité réglementaire).
• Oublier les tests de non-régression. Quand une nouvelle fonctionnalité est livrée, elle peut casser quelque chose d’existant. Un cahier de recette sérieux prévoit toujours une campagne de non-régression sur les parcours sensibles.
• Négliger l’environnement de test. Un environnement de recette mal isolé, avec des données partagées avec la production ou des comptes mutualisés, c’est la garantie de résultats faussés.
• Valider sans procès-verbal. Un cahier de recette terminé doit déboucher sur un PV de recette signé. C’est ce qui clôt juridiquement la phase et déclenche les jalons contractuels.

Quel outil utiliser pour son cahier de recette ?

Le choix de l’outil dépend de la taille du projet et de la maturité de votre organisation.

Pour un petit projet (moins de 50 cas de test), un simple Google Sheet ou un fichier Excel suffit largement. L’avantage : tout le monde sait s’en servir, et le partage est immédiat. C’est d’ailleurs la solution utilisée par la majorité des PME et des agences digitales.

Pour un projet de taille moyenne (50 à 500 cas de test), Notion ou Airtable offrent un bon compromis entre lisibilité, collaboration et structuration. On y gère les statuts, les responsables, les pièces jointes, et on peut filtrer par criticité.

Pour un projet d’envergure (au-delà de 500 cas, ou avec un environnement réglementé), les outils dédiés à la gestion des tests prennent tout leur sens : Xray (intégré à Jira), TestRail, Squash TM, HP ALM / Quality Center. Comptez entre 15 et 100 euros par utilisateur et par mois selon la solution. L’investissement se justifie surtout par la traçabilité, l’automatisation des rapports et l’historique des campagnes.

Le bon réflexe : choisir un outil proportionné au projet. Inutile de déployer TestRail pour un site vitrine de 12 pages.

En bref : ce qu’il faut retenir

Le cahier de recette est le document central de la phase de validation d’un projet informatique. Bien rédigé, il vous évite les mauvaises surprises en production et sécurise la relation contractuelle entre MOA et MOE.

Trois principes à garder en tête :

1. Commencez tôt : la rédaction démarre avec les spécifications, pas à la livraison.
2. Soyez précis : un cas de test doit pouvoir être exécuté à l’identique par n’importe quel testeur, sans interprétation.
3. Faites simple sur l’outil : un Google Sheet bien tenu vaut mille fois un outil sophistiqué mal renseigné.

Et vous, à quel moment commencez-vous à rédiger votre cahier de recette ? Avez-vous déjà été pris au dépourvu par une recette mal préparée ? Partagez votre retour en commentaire.