Projet & méthode.

Recette

Aussi appelérecette fonctionnellephase de recettetests d'acceptationUAT

Définition

La vérification, par les utilisateurs, que le logiciel livré fait ce qui était convenu.

C’est quoi une recette en informatique ? C’est la phase où les utilisateurs vérifient, scénario par scénario, que le logiciel livré fait ce qui était convenu dans le cahier des charges, avant de l’accepter.

Elle se déroule dans un environnement dédié, avec des données proches de la réalité, et aboutit à un procès-verbal qui liste les anomalies et autorise, ou non, la mise en production.

Les niveaux de test et ce que chacun évite

On teste du plus petit morceau au logiciel entier, et chaque niveau attrape ce que le précédent ne peut pas voir.

NiveauCe qu’il vérifieCe qu’il évite
UnitaireUne règle ou une fonction isolée, comme le calcul d’une remise.Une règle de calcul fausse, qui passe inaperçue tant qu’on ne la déclenche pas.
IntégrationLes morceaux ensemble : base de données, paiement, e-mail, outils tiers.Une liaison qui fonctionne en démonstration et casse au premier cas réel.
Bout en boutUn parcours entier, de l’écran à la base de données, enchaîné comme le ferait un utilisateur.Des étapes qui marchent une à une et échouent une fois enchaînées.
RecetteLe logiciel face à ce qui était convenu, sur des scénarios métier et des données proches de la réalité.Découvrir après la livraison qu’un besoin n’est pas couvert.

Les trois premiers niveaux reviennent à l’équipe qui construit le logiciel. Le dernier revient à ceux qui s’en serviront : c’est lui qu’on appelle la recette, ou recette fonctionnelle quand elle porte sur les parcours métier.

Ce que coûte un test raté. Un défaut trouvé à un niveau bas se corrige là où il est apparu. Le même défaut trouvé en production touche de vrais utilisateurs et de vraies données : il faut corriger le code, puis réparer ce qu’il a déjà abîmé. Nous ne chiffrons pas ce surcoût : les ratios de coût souvent cités n’ont pas de source primaire que nous ayons retrouvée, comme nous l’expliquons dans notre guide de la recette.

Critères d’acceptation, formes de recette et contrats

Critère d’acceptation ou cas de test. Les deux se confondent souvent. Le syllabus ISTQB « Certified Tester Foundation Level Specialist, Acceptance Testing » (v1.0, 2019) les sépare : un critère d’acceptation est un énoncé mesurable, vrai ou faux, qui dit quoi vérifier ; les cas de test en découlent et décrivent comment le vérifier. Écrire les critères avant le développement évite la discussion de fin de projet sur ce qui avait été promis.

Plusieurs formes. Le même syllabus distingue notamment la recette utilisateur, la recette contractuelle, la recette réglementaire et les phases alpha et bêta. La découpe française courante (fonctionnelle, technique, utilisateur) ne recouvre pas cette classification. Mettez-vous d’accord sur les mots avant de signer.

Le vocabulaire des contrats. Le CCAG-TIC 2021, annexé à l’arrêté du 30 mars 2021 publié sur legifrance.gouv.fr, enchaîne opérations de vérification, décision après vérification, puis admission. Il n’oblige que les marchés publics, mais les contrats privés s’en inspirent. Deux points à retenir : le texte parle de vérification d’aptitude et de vérification de service régulier, jamais de « VABF » ; et c’est la décision d’admission qui fait courir les délais de garantie.

Ce qu’il faut prévoir. Qui teste, pendant combien de temps, sur quelles données, comment une anomalie est classée et sous quel délai elle est corrigée. Une recette réussie n’est pas une recette sans anomalie : c’est une recette où chaque écart a été vu, classé et traité.

Comment nous menons une recette

Trois incidents de nos propres projets en disent plus qu’une méthode affichée.

Un contrôle peut se tromper sans le dire. Un de nos contrôles automatiques annonçait un lien sur 67 pages sur 67 ; il n’y en avait que 46, car le contrôle comptait aussi la ligne de code chargée de chercher ce lien. Un autre annonçait un remplissage de pages à 93 %, sur des pages visiblement vides. Ce que nous en retenons : un résultat vert se recoupe avec ce que l’on voit à l’écran.

Un test qui ne fait rien réussit toujours. Le 11 septembre 2026, un test répondait « aucun conflit » alors que la commande de fusion du code refusait de s’exécuter : l’erreur était étouffée par une instruction qui force la réussite. Un test qui passe sans rien faire ressemble exactement à un test qui passe.

Un site qui se construit sans erreur ne prouve rien sur la base de données. Le 19 septembre 2026, une migration de base de données, appliquée avec le mauvais rôle, s’est arrêtée à mi-chemin. Depuis, chaque migration est d’abord rejouée dans une transaction annulée à la fin, puis seulement appliquée pour de bon.

La recette dans un projet de logiciel sur mesure

Les critères naissent des règles écrites. Sur un projet de logiciel métier sur mesure, un document de cadrage est rédigé avec les personnes qui appliquent les règles au quotidien, puis validé avant la première ligne de code. C’est lui qui permet d’écrire les critères d’acceptation de la recette.

La recette n’est pas le premier regard du client. Une démonstration a lieu chaque vendredi pendant le projet, et chaque règle est couverte par un test. Trente jours de corrections suivent la livraison.

Pour un logiciel déjà en place. La reprise et la maintenance d’une application existante commencent par lire le code avant d’accepter. Le devis est gratuit et plafonné.

Voir aussi.

← Tous les termes du glossaire

Démarrer

Un projet en tête ? Un brief, un devis, sous 24 h.

Décrivez le projet en quelques minutes. On revient avec une première lecture honnête, un ordre de grandeur et les premiers risques. Pas de PowerPoint, juste une réponse claire.