La recette utilisateur

Qu'est-ce que l'UAT (recette utilisateur) ?

Le référentiel le plus précis sur le sujet est le syllabus Certified Tester Foundation Level de l'ISTQB, dans sa version 4.0.1 de septembre 2024. Il classe le test d'acceptation parmi les niveaux de test et énonce qu'il porte sur la validation et sur la démonstration que le système est prêt pour le déploiement, autrement dit qu'il répond aux besoins métier de l'utilisateur. Le syllabus ajoute qu'idéalement, il devrait être réalisé par les utilisateurs prévus (ISTQB, CTFL v4.0.1, § 2.2.1).

Le même référentiel distingue plusieurs formes de test d'acceptation, dont la recette utilisateur n'est qu'une :

• le test d'acceptation utilisateur (UAT) proprement dit ;
• le test d'acceptation opérationnelle, côté exploitation ;
• le test d'acceptation contractuelle et réglementaire ;
• les tests alpha et bêta.

En français, « recette » et « recette utilisateur » sont les termes d'usage. « Recette métier » insiste sur l'acteur ; « UAT » s'est imposé dans les projets internationaux.

Valider n'est pas vérifier

C'est la distinction la plus utile de tout le sujet, et l'ISTQB la pose dès son premier chapitre : tester comporte de la vérification — contrôler que le système satisfait aux exigences spécifiées — et de la validation — contrôler qu'il répond aux besoins des utilisateurs et des autres parties prenantes dans son environnement opérationnel (ISTQB, CTFL v4.0.1, § 1.1).

Un système peut donc passer tous les tests de vérification et échouer à la validation : conforme au cahier des charges, inutilisable dans le travail réel. C'est exactement ce que la recette utilisateur est censée détecter — et ce qu'elle n'attrape pas quand elle est conduite par l'équipe projet sur des scénarios écrits par l'équipe projet.

Comment conduire une recette utilisateur qui serve à quelque chose

1. Faire tester par de vrais utilisateurs, choisis pour leur représentativité — y compris les profils les moins à l'aise avec l'outil, qui révèlent les points de friction que les experts ne voient plus.
2. Partir de cas réels, pas de scripts : un dossier complexe de l'an dernier en dit plus long que dix scénarios nominaux.
3. Tester sur des données réalistes. Une recette sur jeu de données propre valide un système qui n'existera jamais.
4. Qualifier les anomalies avec le métier, pas seulement par gravité technique : une lenteur sur l'écran le plus utilisé de la journée pèse plus qu'un bug sur une fonction trimestrielle.
5. Prononcer la recette explicitement, avec la liste des anomalies restantes et le nom de celui qui en assume le report après le go-live.

L'ordre de grandeur de l'effort surprend souvent. Pour sa conversion vers SAP Cloud ERP, Swarovski a mobilisé plus de 600 participants pour environ 25 000 tests, sur deux ans de préparation (SAP News Center, juillet 2026).

Ce que la recette utilisateur ne dit pas

Une recette prononcée ne garantit pas l'adoption. Elle se déroule dans des conditions qui ne sont pas celles du travail réel : utilisateurs volontaires, attention pleine, accompagnement à portée de main, absence de pression de délai.

Le jour du go-live, la plupart de ces conditions disparaissent : le volume, la pression de délai et la dispersion des utilisateurs changent d'échelle, même lorsqu'un dispositif d'hypercare est en place. C'est pourquoi les difficultés qui apparaissent en hypercare portent rarement sur des fonctions défaillantes, et presque toujours sur des enchaînements que personne n'avait regardés dans leur continuité.

Deux compléments utiles : faire tester au moins un processus de bout en bout par une personne qui ne l'a jamais vu, et prévoir que l'aide sera disponible dans l'outil au démarrage. Une plateforme d'adoption digitale permet de construire ces guides pendant la recette, à partir des parcours que les testeurs viennent de valider.

Quand la recette n'a pas joué son rôle

Deux dossiers publics donnent l'ordre de grandeur de ce que coûte un démarrage raté — sans que les documents officiels en attribuent explicitement la cause à la recette. Le conseil municipal de Birmingham a déployé un nouveau système financier Oracle en avril 2022 ; le gouvernement britannique a estimé en octobre 2023 à 100 millions de livres le coût de remise en état (gov.uk), et les commissaires nommés sur place évoquaient en janvier 2024 environ 50 millions de livres supplémentaires pour une ré-implémentation complète (gov.uk).

Revlon, de son côté, a écrit noir sur blanc dans son rapport annuel 10-K de l'exercice 2018 que son chiffre d'affaires avait été affecté négativement par des perturbations de niveau de service dans son usine d'Oxford, en Caroline du Nord, consécutives au lancement d'un nouvel ERP SAP — avec des coûts substantiels engagés pour y remédier (SEC, formulaire 10-K, mars 2019).

Conclusion

La recette utilisateur est le moment du projet où l'on valide que le système répond au besoin réel, et non à sa description. Confiée à l'équipe projet sur des scénarios nominaux, elle perd toute cette valeur.

Elle reste toutefois un exercice en conditions protégées. Ce qu'elle valide, c'est que le système est déployable — pas qu'il sera adopté.

Questions fréquentes