Pourquoi l'UAT échoue malgré des apparences de succès
Lors de nombreux cycles d'UAT, tous les scénarios sont marqués comme réussis, mais deux semaines après la mise en production, des dizaines de tickets sont ouverts. Ce n'est pas paradoxal ; c'est le résultat direct de tests conçus autour des écrans.
Un test axé sur l'écran demande "Est-il possible de créer un enregistrement ?". Un test axé sur le processus demande "Un agent peut-il recevoir une demande, identifier que le client existe sous un autre nom, vérifier son éligibilité dans le système central, ouvrir un dossier, le transférer à une autre partie et le clore — alors que le client est dupliqué dans le système ?". Le second scénario révèle ce que le premier manque.
Ce guide présente la structure d'UAT conçue pour la deuxième question. La relation avec les autres phases du projet est décrite dans le Guide d'implémentation Salesforce.
Prérequis essentiels avant de commencer
- Un environnement stable qui ne reçoit pas de déploiements en cours de cycle, à l'exception des correctifs bloquants approuvés.
- Des données de test d'une envergure et d'une complexité similaires à celles de la production.
- Des utilisateurs avec des autorisations réelles — pas d'administrateur pour tout le monde. La moitié des problèmes d'autorisation ne sont découverts que lorsque le testeur possède le profil approprié.
- Des critères d'acceptation définis pour chaque processus métier essentiel.
- Un mécanisme unique de signalement des anomalies, avec un minimum de champs obligatoires.
L'élément le plus souvent ignoré est le troisième, et c'est celui qui génère les incidents les plus embarrassants le jour de la mise en production.
Comment construire un scénario qui identifie les problèmes
Un bon scénario commence par un persona et un état initial, et non par un clic. Une structure efficace se présente comme suit :
- Qui — Rôle et autorisation précis.
- État initial — Quelles informations existent dans le système avant le début du scénario.
- Que se passe-t-il — L'événement commercial qui déclenche le processus.
- Ce que le testeur fait — Au niveau de l'action métier, et non du clic.
- Le résultat attendu — Y compris ce qui s'est passé dans d'autres systèmes.
- Ce qui ne devrait pas se produire — L'enregistrement n'est pas exposé à ceux qui ne devraient pas le voir, la notification n'est pas envoyée deux fois.
Le sixième point distingue une liste de contrôle d'une démarche de test professionnelle.
Six familles de scénarios à inclure impérativement
| Famille | Exemple de scénario | Ce qu'elle révèle |
|---|---|---|
| Parcours nominal | Processus de bout en bout | La faisabilité du processus |
| Exception métier | Annulation, crédit, retour à une étape précédente | Une logique construite dans une seule direction |
| Données problématiques | Client en double, nom en hébreu et en anglais, champ vide | Mappage et nettoyage insuffisants |
| Autorisations | Utilisateur tentant d'accéder à un enregistrement d'une autre unité | Des failles dans le modèle d'exposition |
| Échec d'intégration | Le système cible est indisponible | Gestion des erreurs, boucles, duplication |
| Volume | Opération groupée sur un grand nombre d'enregistrements | Limitations de performance et d'automatisation |
L'absence d'une famille entière de cette liste est un signe que le test offrira une fausse sécurité.
Classification de la criticité — la condition pour gérer le cycle
Sans une classification convenue, chaque anomalie semble urgente et la décision de passer en production devient un débat. Un modèle à quatre niveaux est suffisant :
| Niveau | Définition | Impact sur la mise en production |
|---|---|---|
| Bloquant | Impossible de finaliser un processus métier essentiel, pas de contournement | Bloquant |
| Grave | Le processus est possible avec un contournement lourd ou des données erronées sont enregistrées | Bloquant, sauf approbation explicite |
| Modéré | Inconfort significatif, contournement raisonnable | Non bloquant, entre dans le plan de correction |
| Mineur | Texte, ordre des champs, amélioration | Collecté pour la prochaine vague |
Règle importante : la classification est déterminée par le responsable du processus en collaboration avec l'équipe technique, et non par la personne qui a signalé l'anomalie.
Conditions de passage en production
Elles sont formulées avant le début du cycle et non à la fin :
- Zéro anomalie bloquante ouverte.
- Toute anomalie grave a été close ou approuvée par écrit avec un plan de contournement et un délai de correction.
- Tous les processus métier essentiels ont été exécutés lors du deuxième cycle sans nouvelle défaillance.
- Les responsables de processus ont donné leur approbation écrite.
- Un plan de retour arrière a été testé, pas seulement rédigé.
Exemple illustratif : un fonds de pension
Ce scénario est hypothétique et à des fins d'illustration. Un fonds de pension a testé un processus de gestion des demandes des affiliés. Le premier cycle d'UAT s'est déroulé presque entièrement sans encombre. L'équipe a remarqué que tous les testeurs utilisaient un profil étendu, car l'attribution des profils précis avait été retardée.
Lors du deuxième cycle, avec les profils réels, onze anomalies ont été découvertes : des agents ne voyaient pas les enregistrements des affiliés transférés entre les parcours, un bouton d'approbation d'exception apparaissait pour ceux qui n'étaient pas qualifiés, et un rapport de charge renvoyait des résultats partiels pour les chefs d'équipe. Aucune des anomalies n'était liée aux fonctionnalités testées lors du premier cycle — toutes concernaient le modèle d'exposition.
La conclusion pratique adoptée fut la suivante : aucun cycle d'UAT n'est lancé avant que tous les participants n'utilisent le profil avec lequel ils travailleront en production.
Erreurs de gestion qui augmentent le coût du cycle
- Le déploiement de versions en plein milieu du cycle, ce qui annule la validité des tests déjà effectués.
- Des testeurs qui signalent des anomalies sur WhatsApp et par e-mail en parallèle du système de suivi.
- Des scénarios rédigés au niveau du clic, ce qui transforme chaque modification de l'interface en une mise à jour de la documentation.
- La réduction du deuxième cycle sous la pression des délais – c'est pourtant ce cycle qui révèle les régressions.
Ces schémas apparaissent aux côtés d'autres défaillances dans le Guide des erreurs courantes, et la responsabilité de chacun d'eux est définie dans le Guide des rôles de l'équipe projet Salesforce.
Lors du remplacement d'un système existant
Dans un projet de remplacement, l'UAT assume un deuxième rôle : la comparaison. Les mêmes dix scénarios sont exécutés dans les deux systèmes, et les résultats sont comparés champ par champ. C'est l'outil le plus efficace pour détecter les lacunes de mappage avant qu'elles ne deviennent des lacunes de confiance. L'ordre des opérations pour une telle transition est détaillé dans le Guide de remplacement du CRM par Salesforce.
Ce qu'il reste après le cycle
Les scénarios d'UAT ne sont pas un document à usage unique. Ils constituent la base des tests de régression pour chaque future version et la meilleure source de matériel de formation, car ils sont rédigés dans le langage du processus et non dans celui du système. Les conserver dans un format réutilisable est l'investissement le moins coûteux que l'on puisse faire pour l'année à venir.