Glossaire · Fondamentaux du test
Recette utilisateur (UAT)
En anglais : User acceptance testing
Également appelé : UAT, test d'acceptation utilisateur, tests d'acceptation utilisateur, recette fonctionnelle
Définition
Phase de test finale où de vrais utilisateurs ou représentants métier confirment que le système répond à leurs besoins et peut être accepté pour la mise en production.
La recette utilisateur (UAT, user acceptance testing) est réalisée par les personnes qui utiliseront le système ou en seront propriétaires, et non par l’équipe qui l’a construit. Les utilisateurs métier réalisent des tâches réalistes dans un environnement proche de la production et décident si le logiciel fait le travail dont ils ont besoin. Une UAT réussie se conclut par une validation formelle (sign-off), qui conditionne souvent la mise en production ou la réception contractuelle auprès d’un fournisseur.
Exemple
Une banque remplace son système de demandes de prêt. Avant la mise en service, les conseillers crédit passent une semaine dans l’environnement de recette à traiter des demandes réalistes : un prêt personnel standard, une demande conjointe, un travailleur indépendant aux revenus irréguliers et une demande refusée qui doit générer le bon courrier. Ils vérifient que le workflow correspond à leur façon réelle de travailler, que les rapports répondent aux besoins des managers et que rien n’impose de contournement manuel. Les problèmes sont consignés, triés avec l’équipe projet, puis corrigés ou acceptés avant la validation.
UAT ou test système
| Test système | Recette utilisateur (UAT) | |
|---|---|---|
| Qui | L’équipe QA | Utilisateurs métier, clients, product owners |
| Question | Le système respecte-t-il la spécification ? | Répond-il à nos besoins réels ? |
| Référence | Exigences et conception | Processus métier et critères d’acceptation |
| Focus | Défauts, cas limites, contrôles non fonctionnels | Adéquation à l’usage, utilisabilité en contexte |
Un système peut réussir tous les tests système et échouer pourtant à l’UAT, parce que la spécification elle-même était fausse ou incomplète. C’est pourquoi l’UAT est l’exemple classique de validation (« construisons-nous le bon produit ? ») plutôt que de vérification (« construisons-nous le produit correctement ? »).
Types de tests d’acceptation
- Alpha test : des utilisateurs internes testent chez l’éditeur.
- Bêta test : un groupe restreint d’utilisateurs externes teste dans son propre environnement.
- Recette d’exploitation (OAT, operational acceptance testing) : les équipes d’exploitation vérifient les sauvegardes, la bascule (failover), le monitoring et le déploiement.
- Acceptation contractuelle et réglementaire : vérifie les termes contractuels convenus ou les exigences légales.
Erreurs fréquentes
- Utiliser l’UAT pour trouver des bugs basiques. Si les utilisateurs rencontrent des plantages, c’est que le test système n’était pas terminé. L’UAT doit porter sur l’adéquation, pas sur des défauts que la QA aurait dû détecter.
- Pas de scénarios ni de données préparés. Les utilisateurs métier ont besoin de données réalistes et de scénarios clairs, et les testeurs aident souvent à les rédiger.
- S’y prendre trop tard. Une UAT coincée dans les derniers jours avant la release se réduit généralement à un simple coup de tampon.