La recette d’une application web est la phase pendant laquelle le client vérifie que ce qui a été livré correspond à ce qui était attendu, avant de l’accepter et de la mettre en production. Elle repose sur trois documents : un plan de test qui fixe la stratégie, un cahier de recette qui liste les cas de test concrets, et un suivi des anomalies qui qualifie chaque écart. Elle se termine par une décision formelle, le procès-verbal de recette, prise sur des critères de sortie convenus à l’avance.
Une recette bien menée ne consiste pas à « cliquer partout pour voir si ça marche ». C’est un travail organisé, qui mobilise le métier et qui conditionne directement la qualité du démarrage. Voici la méthode, étape par étape.
Qu’est-ce que la recette, et que vérifie-t-elle ?
Le mot vient du vocabulaire industriel : « recetter », c’est réceptionner un ouvrage en vérifiant sa conformité. Dans un projet numérique, la recette couvre plusieurs dimensions :
- La conformité fonctionnelle : chaque fonctionnalité fait ce que décrivent les user stories et leurs critères d’acceptation.
- Les processus de bout en bout : une commande peut être saisie, validée, préparée, facturée, sans rupture entre les étapes.
- Les intégrations : les données circulent correctement avec l’ERP, le CRM, la comptabilité ou la plateforme e-commerce.
- Les droits d’accès : chaque rôle voit et modifie exactement ce qu’il doit.
- Les exigences non fonctionnelles : performance, sécurité, accessibilité, compatibilité avec les navigateurs et les appareils utilisés.
Les marchés publics utilisent un vocabulaire plus formel, que l’on retrouve dans certains contrats privés. Le CCAG-TIC distingue la vérification d’aptitude, qui contrôle que la solution a les caractéristiques pour remplir les fonctions prévues, et la vérification de service régulier, qui contrôle son bon fonctionnement en conditions normales d’exploitation. Par défaut, d’après l’article 32 du CCAG-TIC 2021, la régularité du service s’observe pendant trente jours, sauf stipulation contraire du marché. Cette logique en deux temps (« ça fait ce qu’il faut », puis « ça tient dans la durée ») est utile dans tout projet.
Qui fait quoi pendant la recette ?
La recette n’est pas le premier contrôle qualité : c’est le dernier. L’équipe de développement doit livrer un produit déjà testé. L’article de Ham Vocke sur la pyramide des tests le rappelle : la base de la qualité, ce sont de nombreux tests automatisés rapides (tests unitaires, tests d’intégration), complétés par un petit nombre de tests de bout en bout et par des tests exploratoires manuels.
| Acteur | Responsabilité | Livrable |
|---|---|---|
| Équipe de développement | Tests automatisés, tests de non-régression, correction des anomalies | Version livrée en recette avec ses notes de version |
| Responsable produit (client) | Priorisation, arbitrage des anomalies, décision finale | Procès-verbal de recette |
| Référents métier | Exécution des cas de test, qualification des écarts | Cahier de recette complété |
| Utilisateurs finaux | Sessions d’usage encadrées sur les processus critiques | Retours d’ergonomie et cas oubliés |
| Chef de projet (prestataire) | Organisation, suivi, reporting quotidien | Tableau de suivi des anomalies |
Le point critique est presque toujours la disponibilité des référents métier. Une recette planifiée pendant la clôture comptable ou la haute saison commerciale échoue, non parce que l’outil est mauvais, mais parce que personne n’a le temps de le tester.
Plan de test et cahier de recette : que mettre dedans ?
Le plan de test : la stratégie
Le plan de test répond à la question « comment allons-nous vérifier ? ». Il tient en quelques pages et contient :
- Le périmètre : ce qui est testé dans cette recette, et ce qui ne l’est pas.
- Les environnements : un environnement de recette distinct de la production, aussi proche d’elle que possible.
- Les données de test : jeux de données représentatifs, anonymisés si ce sont des données réelles de personnes.
- Les rôles et le calendrier : qui teste quoi, quand, avec quel temps réservé.
- La classification des anomalies et les délais de correction associés.
- Les critères d’entrée (ce qui doit être prêt pour commencer) et de sortie (ce qui permet de conclure).
Le cahier de recette : les cas concrets
Le cahier de recette répond à la question « que vérifions-nous, précisément ? ». Chaque cas de test comporte un identifiant, un objectif, des préconditions, des étapes, un résultat attendu, puis le résultat obtenu et le statut (conforme, non conforme, bloqué).
Si le projet a été mené avec des user stories et des critères d’acceptation bien écrits, le cahier de recette est déjà à moitié rédigé : chaque scénario « Étant donné / Quand / Alors » est un cas de test. Il reste à ajouter les scénarios de bout en bout, qui enchaînent plusieurs fonctionnalités comme le fera un utilisateur un lundi matin.
Pensez aussi aux cas que personne ne décrit spontanément : un client sans adresse e-mail, une commande annulée après expédition, un utilisateur qui change de service, un import de fichier mal formé, deux personnes qui modifient la même fiche en même temps.
Comment qualifier et suivre les anomalies ?
Une anomalie est un écart entre le résultat attendu et le résultat obtenu. Toutes ne se valent pas : les classer permet de concentrer l’énergie sur ce qui empêche réellement de travailler.
| Gravité | Définition | Exemple | Effet sur la mise en production |
|---|---|---|---|
| Bloquante | Un processus essentiel est impossible, sans contournement | Impossible de valider une commande | Bloque la mise en production |
| Majeure | Fonction importante dégradée, contournement possible mais coûteux | Le PDF du devis ne contient pas les remises | Correction avant ou juste après, selon le contournement |
| Mineure | Gêne limitée, sans impact sur le résultat | Libellé tronqué, tri par défaut peu pratique | Planifiée dans un sprint suivant |
| Évolution | Le comportement est conforme au besoin validé, mais on voudrait autre chose | « Il faudrait aussi un export par région » | Va dans le backlog, priorisée à part |
La dernière ligne est essentielle. Beaucoup de tensions en fin de projet viennent d’évolutions déguisées en anomalies. Les distinguer calmement, critère d’acceptation à l’appui, protège à la fois le planning et la relation.
La fiche d’anomalie qui fait gagner du temps
Une anomalie mal décrite coûte un aller-retour, parfois trois. Une bonne fiche contient :
- un titre explicite (« Remise client B non appliquée sur les commandes de plus de 120 unités ») ;
- l’environnement, le navigateur et le compte utilisé ;
- les étapes exactes pour reproduire ;
- le résultat attendu et le résultat obtenu ;
- une capture d’écran ou une courte vidéo ;
- la gravité proposée.
Le cycle de vie est simple : ouverte, qualifiée, en correction, livrée en recette, vérifiée puis close (ou rouverte). Le testeur qui a ouvert l’anomalie est celui qui la clôt.
Recette continue ou recette finale ?
Dans un projet mené en cycle en V, toute la recette arrive à la fin, au moment où corriger coûte le plus cher. Dans un projet agile, on recette à chaque sprint : les fonctionnalités terminées sont montrées en démonstration puis vérifiées par le métier sur l’environnement de recette. C’est ce que nous décrivons dans notre méthode et dans notre article sur la livraison à chaque sprint.
La recette continue ne supprime pas la recette finale ; elle la raccourcit. Avant la mise en production, une recette de bout en bout reste indispensable pour vérifier les processus complets, les volumes réels, les intégrations et la reprise des données. Si l’application remplace un outil existant, elle inclut la vérification de la migration de données : comptages, contrôles par échantillon, totaux comptables.
Les tests non fonctionnels à ne pas oublier
Ces tests sont souvent laissés de côté, car aucun utilisateur ne les demande explicitement. Ils font pourtant la différence en production.
- Performance : temps de réponse des écrans les plus utilisés, avec un volume de données réaliste. Pour les pages publiques, les seuils des Core Web Vitals de Google donnent des repères : affichage du contenu principal en 2,5 secondes ou moins, réactivité aux interactions en 200 millisecondes ou moins.
- Sécurité : contrôle des droits (un utilisateur ne doit pas accéder aux données d’un autre en modifiant une adresse), gestion des sessions, validation des saisies. Le guide de test de l’OWASP sert de référence pour les tests d’intrusion.
- Accessibilité : navigation au clavier, contrastes, libellés des champs, selon les critères des WCAG 2.2.
- Compatibilité : navigateurs et terminaux réellement utilisés, y compris la tablette durcie de l’atelier ou le vieux poste de l’accueil.
- Exploitation : sauvegarde et restauration testées, supervision, journaux exploitables.
Quand peut-on dire que la recette est terminée ?
La recette se termine quand les critères de sortie définis dans le plan de test sont atteints, pas quand le calendrier l’impose. Des critères typiques :
- Tous les cas de test prioritaires ont été exécutés.
- Aucune anomalie bloquante n’est ouverte.
- Chaque anomalie majeure restante a un contournement documenté et une date de correction.
- Les scénarios de bout en bout passent avec des données représentatives.
- Les utilisateurs clés ont été formés et le support de démarrage est organisé.
Le procès-verbal de recette acte la décision : acceptation, acceptation avec réserves (listées et datées) ou refus. Il marque généralement le début de la période de garantie, pendant laquelle le prestataire corrige les écarts par rapport au besoin validé. Une mise en production réussie s’accompagne enfin d’un vrai travail d’adoption, que nous détaillons dans notre article sur la conduite du changement.
Vous préparez la réception d’une application web sur mesure ou souhaitez cadrer la recette dès le départ ? Écrivez-nous : nous vous aidons à construire un plan de test adapté à vos processus.
