Votre application est livrée. Le formulaire s’ouvre, les boutons répondent et une démonstration semble concluante. Reste une question : le parcours fonctionne-t-il avec les règles, les données et les exceptions de votre entreprise ? Un cahier de recette informatique permet de répondre à cette question en reliant chaque besoin à un test observable.
Ce guide propose une méthode de préparation, un exemple de demande d’achat et un modèle Excel gratuit. Il s’adresse aux responsables métier et aux chefs de projet qui doivent examiner un livrable avant de l’accepter.
Qu’est-ce qu’un cahier de recette informatique ?
Le cahier de recette est le document qui décrit les vérifications à réaliser sur un logiciel, une application ou une évolution. Pour chaque scénario, il précise les conditions de départ, les actions à exécuter et le résultat attendu. Pendant la recette, l’équipe y consigne le résultat obtenu, les preuves et les anomalies.
Il sert à préparer une décision d’acceptation à partir de critères explicites. L’ISTQB définit les tests d’acceptation par leur relation avec les besoins des utilisateurs, les exigences et les processus métier. Une recette ne se limite donc pas à vérifier que les écrans sont accessibles.
Par exemple, « le responsable peut approuver une demande » reste trop vague. Un critère testable serait : « une demande de 800 € soumise par un collaborateur du service A apparaît dans la liste du responsable de ce service ; après approbation, elle passe à l’état Approuvée et conserve l’identité du décideur ». Le montant et la règle sont ici des hypothèses pédagogiques à adapter.
Cahier des charges, plan de recette et procès-verbal : quelles différences ?
| Document | Question à laquelle il répond | Exemple de contenu |
|---|---|---|
| Cahier des charges | Que doit permettre la solution ? | Une dépense nécessite l’accord du responsable et, au-delà d’un seuil défini, un second avis. |
| Plan de recette | Comment organise-t-on les vérifications ? | Périmètre, environnement, participants, calendrier et critères de sortie. |
| Cahier de recette | Quels cas exécuter et avec quels résultats ? | Scénarios, données de test, résultats attendus, preuves et verdicts. |
| Procès-verbal de recette | Quelle décision est prise sur le livrable examiné ? | Version concernée, périmètre accepté, réserves éventuelles et décision des responsables. |
Ces éléments peuvent être réunis dans un même dossier sur un petit projet. L’essentiel est de pouvoir remonter d’un test au besoin correspondant. Notre guide du cahier des charges informatique explique comment formuler ces exigences en amont.
Comment préparer une recette utile en six étapes
1. Identifier la version et le périmètre
Notez la version de l’application, l’environnement utilisé et les fonctionnalités incluses. Une recette réalisée avant la dernière correction ne prouve pas le fonctionnement de la version corrigée. Précisez également les exclusions : une vérification du formulaire ne couvre pas automatiquement l’envoi vers la comptabilité.
2. Répartir les responsabilités
Le référent métier définit les résultats attendus et examine les écarts. Les utilisateurs représentatifs exécutent les parcours qui leur sont confiés. L’équipe technique prépare l’environnement, analyse les anomalies et livre les corrections. Le responsable du projet consolide les résultats et fait prendre la décision par les personnes désignées.
Cette répartition doit être connue avant de commencer. La personne qui constate une anomalie doit savoir où la signaler ; celle qui livre une correction doit savoir qui vérifiera son effet.
3. Préparer les comptes et les données
Utilisez des comptes de test distincts pour le demandeur, le responsable et l’administrateur. Prévoyez des dossiers complets, incomplets, refusés et déjà traités. Des données fictives suffisent souvent : un fournisseur d’essai, une pièce jointe sans information personnelle et des montants choisis pour tester les règles.
Vérifiez aussi les effets externes. Une recette ne doit pas envoyer par erreur une commande réelle ou des notifications à des clients. Isolez les connecteurs ou utilisez les environnements de test disponibles.
4. Écrire des cas courts et reproductibles
Un cas de test doit pouvoir être exécuté par une autre personne sans explication orale supplémentaire. Indiquez le rôle, le dossier de départ, les actions dans leur ordre et le résultat vérifiable. Évitez « vérifier que tout fonctionne » : cette formulation ne permet ni de constater un écart précis ni de rejouer le test.
5. Prévoir les limites et les exceptions
Testez le parcours nominal, puis les situations qui changent le résultat : justificatif absent, refus motivé, montant exactement égal au seuil, compte sans droit, double clic et indisponibilité d’un système tiers. Pour une règle « au-delà de 1 000 € », les cas 999 €, 1 000 € et 1 001 € vérifient la frontière du seuil : seul le dernier doit déclencher l’étape supplémentaire.
6. Fixer les conditions d’acceptation
Définissez ce qui empêche l’acceptation, qui peut accepter une réserve et comment elle sera suivie. Un nombre élevé de tests réussis ne compense pas un accès indu aux données ou l’impossibilité d’exécuter une opération essentielle. Le taux de réussite aide à lire l’avancement ; il ne prend pas la décision à la place des responsables.
Exemple rempli : une application de demandes d’achat
Le scénario suivant est illustratif. Une entreprise fictive exige un justificatif et l’accord du responsable de service pour toute demande. Au-delà de 1 000 € HT, la finance intervient ensuite. Un refus exige un motif. Aucune de ces règles ne constitue une obligation générale ni un paramétrage Softyflow imposé.
| Cas | Action et donnée de départ | Résultat attendu |
|---|---|---|
| REC-01 — Parcours courant | Soumettre une demande complète de 800 €, puis l’approuver avec le compte du responsable. | Le statut devient Approuvée ; la décision est rattachée au dossier et au responsable. |
| REC-02 — Pièce absente | Soumettre une demande sans justificatif. | La soumission est bloquée avec un message explicite ; aucun circuit d’approbation n’est lancé. |
| REC-03 — Seuil exact | Faire approuver une demande de 1 000 € HT. | L’accord du responsable termine le circuit, puisque l’avis finance est prévu strictement au-delà du seuil. |
| REC-04 — Second niveau | Faire approuver par le responsable une demande de 1 001 € HT. | Le dossier attend l’avis finance ; il n’est pas encore approuvé définitivement. |
| REC-05 — Refus | Refuser une demande en indiquant « devis à revoir ». | Le motif est visible pour le demandeur ; aucune étape finance n’est ouverte. |
| REC-06 — Accès interdit | Avec un compte non habilité, essayer d’ouvrir le dossier et d’appeler l’action d’approbation. | La lecture et l’action sont refusées ; masquer le bouton seul ne suffit pas. |
Complétez ces cas par une vérification des reprises : après un refus, le demandeur peut-il corriger le dossier ? La nouvelle soumission conserve-t-elle la précédente décision tout en ouvrant un nouvel examen ? Si une intégration échoue, le dossier affiche-t-il un état compréhensible et une action de reprise ?
Pour les usages mobiles, exécutez les scénarios sur les appareils prévus : saisie d’un montant, ajout d’une pièce, lecture du motif de refus et action d’approbation. Un écran qui s’adapte à la largeur du téléphone ne prouve pas, à lui seul, que le parcours est utilisable.
Télécharger le modèle de cahier de recette informatique Excel
Télécharger le modèle Excel de cahier de recette (.xlsx) — accès direct, sans formulaire.
Le classeur contient un mode d’emploi, un onglet de cadrage, huit scénarios préparés, une trame vierge de trente cas, un registre d’anomalies et une synthèse. Les scénarios préparés portent la mention « Non exécuté » : ils donnent un exemple de rédaction, sans prétendre qu’un logiciel a été testé.
- Adaptez le cadrage : version, environnement, rôles, périmètre et conditions d’acceptation.
- Rédigez vos tests dans la trame : référence du besoin, préconditions, actions et résultat attendu.
- Exécutez les cas : notez ce qui a réellement été observé, le verdict, le testeur, la date et la preuve.
- Reliez les écarts aux anomalies : attribuez un responsable et identifiez la version de correction.
- Rejouez les cas concernés : une correction déclarée livrée reste à vérifier.
- Examinez la synthèse : complétez ensuite la décision et les réserves éventuelles dans le cadrage.
La synthèse calcule l’avancement des cas renseignés dans la trame vierge. Elle n’exécute aucun test et ne prononce pas l’acceptation. Les exemples sont exclus des indicateurs pour ne pas donner une impression de progression avant le début de votre recette.
Comment suivre les anomalies sans perdre la trace du test ?
Donnez un identifiant à chaque anomalie et reliez-le au cas qui l’a révélée. Décrivez le résultat attendu, le résultat observé, les données utilisées et l’environnement. Une capture ou un journal peut compléter la description, mais doit rester accessible aux personnes chargées du traitement.
Distinguez la gravité de l’impact et la priorité de correction. Un défaut d’affichage peut devenir prioritaire s’il rend une décision illisible sur l’appareil utilisé par toute une équipe. À l’inverse, la fréquence d’un défaut ne suffit pas à mesurer son impact sur la confidentialité ou l’intégrité des données.
Après une correction, conservez l’observation initiale et ajoutez le résultat du nouveau passage. Vérifiez également les parcours voisins : modifier une règle de seuil peut affecter d’autres montants. La traçabilité exige de savoir quel test a été exécuté sur quelle version, pas seulement de remplacer une cellule rouge par une cellule verte.
Passer du besoin métier à une application vérifiable
Une recette est plus simple lorsque les états, les rôles et les décisions ont été définis dès la conception. Le guide de l’application métier montre comment articuler processus, données, accès et intégrations.
Pour un projet Softyflow, préparez quelques dossiers représentatifs et leurs résultats attendus. Ils serviront à discuter du développement de votre application métier, puis à examiner le pilote. Si vous utilisez Flowy AI pour décrire le besoin et préparer une application, gardez ces mêmes scénarios pour vérifier le résultat obtenu.
Présenter votre processus et vos critères de recette à l’équipe Softyflow.
Questions fréquentes sur le cahier de recette
Qui doit rédiger le cahier de recette ?
Le référent métier et les personnes chargées des tests le préparent ensemble. L’équipe technique aide à définir les données, les comptes et l’environnement. Les responsables de l’acceptation doivent valider les critères avant l’exécution.
Excel suffit-il pour réaliser une recette ?
Excel peut convenir à un périmètre limité et à une équipe qui maîtrise les versions du fichier. Un outil partagé devient utile lorsque les campagnes, les intervenants et les anomalies se multiplient. Le modèle proposé sert à structurer une première campagne.
Combien de cas de test faut-il prévoir ?
Il n’existe pas de nombre universel. Couvrez les exigences retenues, les différents rôles, les branches du processus et les situations à fort impact. Ajoutez des cas lorsque plusieurs résultats sont possibles pour une même fonctionnalité.
Peut-on accepter une application avec des anomalies ?
Une acceptation avec réserves peut être envisagée selon le cadre du projet. Les responsables doivent identifier les écarts acceptés, leurs conséquences, les corrections attendues et leur suivi. Le pourcentage de tests réussis ne suffit pas à justifier cette décision.
Le cahier de recette remplace-t-il les tests techniques ?
Non. Il organise l’examen du livrable au regard des besoins et des critères d’acceptation. Les tests de code, d’intégration, de sécurité ou de charge conservent leur rôle et doivent être prévus selon les caractéristiques du projet.
