Cahier de recette : le document qui décrit les scénarios à dérouler et les résultats attendus pour valider qu'un système répond à ses exigences (OpenClassrooms). Automatiser un cahier de recette, c'est transformer ces scénarios en tests rejouables à l'identique à chaque livraison, sans écrire de code : c'est le principe même du test de non-régression.
Un cahier de recette bien rédigé ne se périme pas : c'est son exécution qui s'arrête. Au lancement du projet, l'équipe déroule les 80 cas de test en trois jours. Six mois plus tard, les livraisons passent au rythme d'une par quinzaine et la fenêtre de recette dure deux heures. On teste ce qui vient d'être livré, on ne rejoue plus l'acquis, et la régression passe entre les deux. Cet article distingue ce qui peut être automatisé sans code de ce qui doit rester humain, et détaille la méthode pour passer d'un document à une campagne de non-régression qui se rejoue à chaque livraison.
L'essentiel en une page (définition, automatisation sans code, grille de choix d'un outil) : Test de non-régression automatisé, sans code.
Votre cahier de recette se réduit à la moitié des cas faute de temps ? Delta-QA enregistre vos parcours en naviguant et rejoue l'intégralité du cahier à chaque livraison, sans code. Essayer Delta-QA gratuitement →
Pourquoi un cahier de recette manuel ne suit plus le rythme des livraisons
Un cahier manuel a un coût d'exécution constant : le dérouler prend le même temps à la cinquantième livraison qu'à la première. Son utilité, elle, augmente avec la fréquence des livraisons, puisque chaque mise en production risque de casser un parcours qui fonctionnait. Quand l'écart entre ces deux courbes devient trop grand, les équipes coupent dans la couverture : on exécute les cas du périmètre livré, on abandonne le reste.
Le risque se déplace alors exactement là où on ne regarde plus. Un tunnel de paiement refait est testé en détail ; la page de compte client, touchée par la même refonte de composant, n'est rejouée par personne. La DSI d'Inria, qui a industrialisé les tests de non-régression de son système d'information, dresse le même constat : refaire les tests à chaque changement est répétitif, coûteux en temps et source d'erreurs ; leur automatisation a supprimé ces aléas (JRES 2019).
La bonne question n'est donc pas « faut-il mieux rédiger son cahier ? » mais « combien de fois par an chaque cas mérite-t-il d'être rejoué ? ». Tout cas dont la réponse est « à chaque livraison » est un candidat direct à l'automatisation.
Ce qu'on peut automatiser dans un cahier de recette, et ce qui reste humain
Tout ce qui se rejouerait à l'identique peut être automatisé sans code ; ce qui demande un jugement reste à la personne qui recette. La frontière passe entre la vérification et l'appréciation.
| Vérification typique d'un cahier | Exemple concret | Automatisable sans code ? |
|---|---|---|
| Parcours critiques | Commande complète, inscription, recherche puis réservation | Oui : parcours enregistré, rejoué et comparé |
| Rendu des pages clés | Page d'accueil, fiche produit, à chaque largeur d'écran | Oui : capture comparée à la référence |
| États d'une même page | Formulaire vide, en erreur, validé ; menu ouvert | Oui : chaque état enregistré comme scénario |
| Cohérence multi-navigateurs | Le paiement marche sous Chrome, et sous Safari ? | Oui : même scénario, navigateurs différents |
| Pertinence d'un contenu | Le nouveau texte d'erreur est-il clair ? | Non : jugement humain |
| Décision finale | La livraison est-elle acceptable, en connaissance de cause ? | Non : c'est la recette, et elle reste humaine |
Concrètement, la plupart des cahiers que nous voyons contiennent 60 à 80 % de cas rejouables. C'est la partie qui consomme le plus de temps en recette manuelle, parce qu'elle est répétitive. C'est aussi celle où la fatigue produit les faux « OK » : cocher la ligne sans refaire vraiment la manipulation. Pour rédiger ou fiabiliser le document lui-même, le guide de référence reste utile : Cahier de recette informatique : le guide complet.
De cahier de recette à campagne de non-régression : la méthode en 5 étapes
La migration se fait sur le cahier existant, sans le réécrire : chaque cas devient soit un scénario automatisé, soit un cas qui reste manuel parce qu'il exige un jugement.
- Trier le cahier. Marquez chaque cas « à rejouer à chaque livraison » ou « jugement ponctuel ». Le premier lot part en automatisation, le second reste dans le document manuel, qui devient plus court et enfin exécuté en entier.
- Enregistrer les parcours en naviguant. Avec un outil sans code, le scénario « rechercher un produit, l'ajouter au panier, payer en 3-D Secure » s'enregistre comme on le déroule. Aucune ligne de code, aucun framework à installer.
- Capturer les états qui comptent. Un formulaire vide, en erreur et validé sont trois scénarios distincts. Ajoutez les largeurs d'écran critiques (mobile, tablette, bureau) et les navigateurs de votre audience.
- Rejouer à chaque livraison candidate. La campagne complète s'exécute en préproduction avant chaque mise en production. Elle tourne aussi périodiquement en production, pour les changements qui ne passent pas par vos déploiements : CMS, widgets tiers, mises à jour de dépendances côté navigateur.
- Qualifier chaque écart. Le rapport montre ce qui a changé entre la référence et la livraison. À l'équipe de trancher : régression à corriger, ou évolution voulue qui devient la nouvelle référence.
Chez Delta-QA, la comparaison est portée par une IA déterministe, pas un LLM : un algorithme propriétaire, sans modèle appris, qui donne le même verdict à chaque exécution et ne signale que ce qu'un œil humain remarquerait. Pourquoi ce critère compte pour une recette : un outil qui varie d'une exécution à l'autre réintroduit exactement l'aléa que l'automatisation devait supprimer. Sur le rôle de la QA dans cette migration : Automatiser les tests sans développeur.
Rejouer 80 cas de test avant chaque mise en production ? Enregistrez vos parcours une fois dans Delta-QA ; la campagne se rejoue seule et le rapport côte à côte montre chaque écart. Essayer Delta-QA gratuitement →
Combien de temps prend l'automatisation, et quand devient-elle rentable
Comptez une demi-journée pour les parcours critiques, une à deux journées pour un cahier complet : c'est le temps d'enregistrer les scénarios en naviguant, puis de qualifier les premiers écarts. Le calcul de rentabilité est ensuite arithmétique. Un cahier de 40 cas à 10 minutes chacun coûte environ 7 heures par exécution complète. À une livraison par quinzaine, l'automatisation est remboursée avant la fin du premier mois ; chaque exécution suivante est gagnée.
Deux nuances honnêtes complètent ce calcul. D'abord, la maintenance existe : chaque évolution d'interface voulue demande de valider la nouvelle référence, quelques minutes par page. C'est le prix normal d'une campagne qui reste alignée sur le produit. Ensuite, tout n'est pas automatisable le premier jour, et ce n'est pas grave : une campagne qui couvre les parcours critiques dès le premier mois protège déjà l'essentiel du chiffre d'affaires.
FAQ
Peut-on automatiser un cahier de recette sans savoir coder ?
Oui. Les outils d'enregistrement et de rejeu capturent les scénarios en naviguant dans l'application, puis les comparent automatiquement à une référence validée. Le cahier de recette existant sert de plan : chaque cas « à rejouer à chaque livraison » devient un scénario enregistré.
Quelle différence entre la recette et le test de non-régression ?
La recette valide une livraison précise, souvent dans sa globalité et avec un jugement humain. Le test de non-régression vérifie, à chaque livraison, que les parcours déjà validés fonctionnent toujours. Les deux coexistent : la recette statue, la non-régression protège l'acquis.
Que faire des cas de test qui changent à chaque livraison ?
Ils relèvent souvent du test de confirmation de la nouvelle fonctionnalité et restent manuels. Quand l'interface évolue durablement, la référence du scénario concerné se met à jour en validant le nouveau rendu une fois ; les exécutions suivantes repartent de cette nouvelle base.
Un cahier de recette automatisé remplace-t-il le testeur ?
Non. L'automatisation exécute les vérifications répétitives et signale les écarts ; la qualification de ces écarts, la pertinence des contenus et la décision finale GO/NO-GO restent humaines. Le testeur gagne le temps des exécutions mécaniques pour le consacrer à l'exploration et au jugement.
Par quoi commencer quand le cahier existe déjà ?
Par les parcours qui touchent le chiffre d'affaires ou un engagement réglementaire : commande, paiement, inscription, contact. Enregistrés en premier, ils couvrent la majorité du risque avec une minorité des cas. Le reste du cahier suit au fil des semaines, sans deadline.
Votre cahier de recette mérite mieux qu'une exécution sur deux. Créez un compte gratuit, enregistrez vos parcours critiques et laissez Delta-QA rejouer la campagne complète à chaque livraison. Essayer Delta-QA gratuitement →