Recettage informatique : définition, étapes et cahier de recette

En résumé

Le recettage informatique est la phase de test et de validation d’un logiciel, d’un site web ou d’une application avant sa mise en production. Il vérifie que le produit livré est conforme au cahier des charges et aux besoins métiers.

• Trois types de recette : fonctionnelle (les fonctionnalités répondent au besoin), technique (performance, sécurité, compatibilité), utilisateur ou UAT (validation par le client ou la MOA).
• Cinq étapes : préparation du cahier de recette, exécution des tests, signalement des anomalies, correction et tests de non-régression, signature du procès-verbal (PV).
• Livrable final : le PV de recette signé, qui autorise la mise en production (le go-live).
• Ce qui distingue le recettage des tests unitaires : il valide le produit entier face aux besoins métiers, pas une portion de code isolée.

Le recettage informatique décide si un logiciel part en production ou retourne en correction. C’est la dernière barrière avant le go-live. D’ailleurs, c’est là que se jouent la conformité au cahier des charges, la stabilité technique et la satisfaction des utilisateurs finaux.

Nous sommes un studio de développement web. Nous recettons nos livrables projet après projet, du cahier de recette jusqu’à la signature du PV. Ce guide couvre la définition, les types de recette, les cinq étapes, le cahier de recette (avec un modèle à télécharger) et trois cas concrets de ce qu’un recettage teste réellement.

Qu’est-ce que le recettage informatique ?

Le recettage informatique est aussi appelé recette. C’est la phase de test et de validation d’un produit logiciel avant sa mise en production. Il vérifie que le logiciel, le site web ou l’application livré est conforme au cahier des charges et répond aux besoins métiers.

Le recettage intervient à la fin du développement. Cependant, il se prépare bien plus tôt. Le cahier de recette liste les cas de test. Il s’écrit dès la phase de conception, à partir du cahier des charges. En méthode agile, la recette ne se fait pas en une seule fois à la fin : elle a lieu à chaque fin de sprint, sur les fonctionnalités livrées.

L’objectif n’est pas de prouver que le logiciel fonctionne. C’est de trouver ce qui ne fonctionne pas, avant vos utilisateurs. Une anomalie corrigée en recette coûte une fraction de ce que coûte la même anomalie découverte en production.

Recette, recettage, tests unitaires : quelles différences ?

Recette et recettage désignent la même chose. La validation du produit final face aux besoins métiers. Les tests unitaires, eux, vérifient une portion de code isolée, pas le produit entier.

La différence tient à la question posée. Les tests, unitaires ou d’intégration, répondent à « le code fonctionne-t-il correctement ? ». Le recettage répond à « le produit répond-il au cahier des charges et aux besoins du client ? ». Un logiciel peut passer tous ses tests unitaires et échouer en recette, parce qu’il fait bien ce qu’on a codé, mais pas ce dont le métier a besoin.

Type de vérification	Ce qu’elle valide	Qui la réalise
Test unitaire	Une fonction ou un composant isolé	Développeur
Test d’intégration	La communication entre modules	Développeur ou QA
Recette fonctionnelle	La conformité au besoin métier	Testeurs QA, métiers
Recette utilisateur (UAT)	L’ergonomie et l’usage réel	Client, MOA

Cette distinction structure tout le cycle de développement logiciel: les tests sécurisent le code au fil de l’écriture, la recette valide le produit avant de le livrer.

Quels sont les types de recette informatique ?

Le recettage se décline en quatre types complémentaires : la recette fonctionnelle, la recette technique, la recette utilisateur et la recette d’intégration. Chacune couvre un angle différent du produit.

Recette fonctionnelle

La recette fonctionnelle vérifie que chaque fonctionnalité prévue au cahier des charges existe et réagit comme prévu. On déroule des scénarios :

• Ajouter un article au panier
• Valider un formulaire
• Générer un export.

Si le scénario ne produit pas le résultat attendu, c’est une anomalie fonctionnelle.

Recette technique

La recette technique teste tout ce qui n’est pas fonctionnel :

• La performance
• La sécurité
• La compatibilité multi-navigateurs
• La montée en charge
• Et la conformité réglementaire.

C’est elle qui vérifie que votre application tient 2 000 utilisateurs simultanés sans s’effondrer, et que les données personnelles sont protégées.

Recette utilisateur (UAT / VABF)

La recette utilisateur, ou User Acceptance Testing, est réalisée par le client ou la MOA (maîtrise d’ouvrage). Elle valide l’ergonomie et l’adéquation au métier réel, dans des conditions proches de la production. On parle aussi de VABF (vérification d’aptitude au bon fonctionnement).

Recette d’intégration

La recette d’intégration vérifie que les différents modules communiquent correctement entre eux. Dans une application avec des API, des microservices et des bases de données interconnectées, elle détecte les incohérences d’échange de données que les tests isolés ne voient pas.

Quelles sont les 5 étapes du recettage informatique ?

Le recettage informatique suit cinq étapes, du cahier de recette jusqu’au procès-verbal de validation. Chaque étape mobilise un acteur précis.

Étape	Livrable	Acteur responsable
1. Préparation	Cahier de recette	Product owner
2. Exécution	Rapport de tests	Testeurs QA
3. Signalement	Fiches de bugs priorisées	QA et développeurs
4. Correction	Nouvelle build	Développeur senior
5. Validation	PV signé	Client et chef de projet

1. La préparation du cahier de recette

Le product owner rédige le cahier de recette. Ce document liste tous les cas de test à vérifier, chacun avec l’action à réaliser, les données d’entrée et le résultat attendu. Sans lui, les testeurs avancent à l’aveugle.

2. L’exécution des tests

Les testeurs QA déroulent les cas de test, sur différents appareils et navigateurs. Ils vérifient deux niveaux : les tests fonctionnels (le besoin métier) et les tests techniques (stabilité, sécurité, performance).

3. Le signalement des anomalies

Chaque anomalie est consignée dans un bug tracker, avec un niveau de gravité :

• Bloquant (une fonctionnalité essentielle est inutilisable)
• Majeur (contournement possible)
• Ou mineur (cosmétique).

La priorisation détermine l’ordre des corrections.

4. La correction et les tests de non-régression

Les développeurs corrigent les anomalies par ordre de priorité, en commençant par les bloquants. Chaque correction déclenche un test de non-régression. On revérifie que le correctif n’a rien cassé ailleurs. Cette boucle courte, proche de ce que permet le déploiement progressif, réduit le risque à chaque itération.

5. La validation et le procès-verbal

Une fois les anomalies bloquantes corrigées, le client et le chef de projet signent le procès-verbal de recette (PV, ou PVR). Ce document atteste la conformité au cahier des charges et autorise la mise en production, éventuellement assortie de réserves mineures.

Comment rédiger un cahier de recette ?

Un cahier de recette efficace décrit chaque cas de test de façon à ce que n’importe quel membre de l’équipe puisse l’exécuter sans ambiguïté. Il contient, pour chaque test : un identifiant, le scénario, les données d’entrée, le résultat attendu, le résultat obtenu, le statut et un commentaire.

Les colonnes essentielles d’un cahier de recette :

• Identifiant du test (pour la traçabilité)
• Scénario (l’action à réaliser)
• Données d’entrée (ce qu’on saisit)
• Résultat attendu (la référence)
• Résultat obtenu (ce que le test produit réellement)
• Statut (conforme, non conforme, bloquant)
• Commentaire (contexte pour le développeur)

La précision du cahier conditionne la qualité de la recette. Un cas de test vague produit un rapport de bug inexploitable. Un cas de test précis permet à un développeur de reproduire l’anomalie en quelques minutes.

Pour gagner du temps, utilisez notre modèle de cahier de recette prêt à l’emploi, conçu pour les équipes produit et les chefs de projet.

Ce qu’un recettage réel teste vraiment : trois cas chiffrés

La plupart des guides décrivent le recettage en théorie. Voici ce qu’il teste concrètement sur trois types de projets, avec les critères réels que nous validons.

Application mobile de mobilité urbaine (cas Écovélo)

Sur le projet Écovélo pour Nantes Métropole, la recette a porté sur trois points critiques. Le déverrouillage des vélos en moins de 3 secondes, vérifié sur 50 terminaux Android et iOS. La géolocalisation en temps réel avec une précision inférieure à 10 mètres. La disponibilité de l’API micro-services à 99,5 % lors d’un test de charge simulant 2 000 utilisateurs simultanés. Chaque anomalie bloquante déclenchait une correction et une nouvelle build le jour même.

Plateforme e-commerce PME

Pour une boutique en ligne de 5 000 références, le cahier de recette couvre 4 parcours qui touchent directement au chiffre d’affaires : ajout au panier, paiement par carte, confirmation de commande et email transactionnel. Le test de charge simule 300 commandes simultanées, et un audit d’accessibilité RGAA vérifie la conformité pour les utilisateurs malvoyants. Une recette de ce type dure en moyenne 3 semaines.

Outil métier interne (ERP ou back-office)

Sur un outil de gestion interne, les testeurs sont les futurs utilisateurs : comptables, RH, managers. Ils testent les imports de fichiers, les calculs automatiques et les exports. Un scénario type vérifie qu’une fiche créée par un service est bien visible dans le rapport consolidé, dans le délai attendu. Les anomalies sont classées en bloquant, majeur et mineur.

C’est la différence entre réciter une méthode et l’avoir appliquée. Un recettage utile ne coche pas des cases. Il définit des seuils mesurables, propres au métier, et refuse le go-live tant qu’ils ne sont pas atteints.

Qui réalise le recettage informatique ?

Le recettage mobilise trois profils : le product owner, les testeurs QA et les utilisateurs métiers. Chacun valide un angle différent du produit.

Le product owner porte la conformité au besoin. Il rédige le cahier de recette, arbitre la gravité des anomalies et priorise les corrections. Les testeurs QA structurent les plans de test, exécutent les scénarios et administrent le bug tracker. Les utilisateurs métiers, eux, apportent le regard de celui qui se servira de l’outil au quotidien et repèrent les frictions que personne d’autre ne voit.

Côté prestataire, la qualité de la recette dépend du niveau des développeurs qui corrigent. C’est un argument que nous défendons sur tous nos projets de logiciel sur mesure: des développeurs seniors du premier au dernier jour, pas des juniors sur les corrections critiques. Un bug bloquant mal corrigé en recette rouvre trois anomalies en production.

Quels outils pour le recettage en 2026 ?

Deux familles d’outils structurent un recettage moderne : les bug trackers et les frameworks d’automatisation des tests.

Les bug trackers comme Jira ou Linear centralisent les anomalies, leur priorité et l’avancement des corrections. Ils donnent à toute l’équipe une vision partagée. De plus, ils évitent les doublons et historisent les bugs pour identifier les zones fragiles du code.

Les frameworks d’automatisation comme Cypress ou Playwright simulent des parcours utilisateurs complets, de façon autonome et rapide. Ils libèrent les testeurs des vérifications répétitives et détectent immédiatement une régression après une mise à jour. L’automatisation ne remplace pas la recette manuelle. Elle traite les tests répétitifs et la performance. D’un autre côté, le test manuel reste indispensable pour l’ergonomie, le design et les scénarios métiers complexes.

Recettage et cycle de vie : Agile, cycle en V, CI/CD

La place de la recette dans le projet dépend de la méthode. Exemple :

• En cycle en V, la recette est concentrée en une phase unique, avant le déploiement final.
• En méthode agile, elle a lieu en continu, à chaque fin de sprint, sur les incréments livrés.

Le cycle en V offre une visibilité budgétaire rassurante, mais expose à un risque. Une anomalie majeure découverte tard coûte cher à corriger. L’agile répartit l’effort de test tout au long du projet et détecte les problèmes plus tôt. C’est pour cette raison que nous recettons à chaque sprint plutôt qu’en big bang. Le recettage continu est une assurance contre le défaut découvert trop tard.

En déploiement continu (CI/CD), le recettage devient une étape automatisée du pipeline. Des tests s’exécutent à chaque soumission de code. Une régression bloque la livraison avant qu’elle n’atteigne la production. La discipline des tests avant le code prolonge cette logique en amont, dès l’écriture.