La recette utilisateur vérifie qu’une application permet aux personnes visées d’accomplir leurs tâches selon les critères convenus. Elle prépare une décision de mise en service appuyée sur des résultats observables. Une démonstration réussie ne remplace pas les essais menés par les utilisateurs.
Pour un portail client, un outil de gestion ou une application terrain, commencez à préparer la recette pendant le cadrage. Notre guide du projet d’application sur mesure présente la place de cette validation dans la livraison.
Ce que la recette vérifie, et ses limites
L’équipe technique teste le fonctionnement du code, les échanges et les contrôles prévus. La recette utilisateur ajoute une question opérationnelle : une personne autorisée peut-elle terminer son travail avec les informations et les exceptions réelles de son rôle?
Elle ne remplace pas les tests de sécurité, de charge, de sauvegarde ou l’évaluation d’accessibilité. Ces vérifications ont leurs méthodes et leurs responsables. La décision de lancement doit réunir leurs résultats lorsque ces dimensions font partie du périmètre.
Une session peut révéler une anomalie, une règle d’affaires oubliée, un besoin de formation ou une nouvelle demande. Les distinguer évite de traiter toute difficulté comme un bogue ou, à l’inverse, de refuser une correction nécessaire en la qualifiant d’évolution.
Nommer les personnes et les décisions
- Responsable d’affaires : arbitre les priorités et accepte les parcours.
- Utilisateurs représentatifs : exécutent les scénarios dans leurs conditions de travail.
- Responsable de recette : organise les sessions, les données et le suivi.
- Équipe technique : analyse les anomalies, corrige et fournit une version identifiable.
- Responsables spécialisés : valident sécurité, données, exploitation ou accessibilité selon le mandat.
Réservez le temps des participants avant la fin du développement. Prévoyez une personne capable de trancher les cas où deux équipes appliquent aujourd’hui des règles différentes. La recette ne résout pas à elle seule une responsabilité opérationnelle indéfinie.
Préparer l’environnement et les données
Utilisez une version connue dans un environnement de validation. Vérifiez les comptes, rôles, navigateurs, appareils et connexions nécessaires. Les notifications et transactions de test doivent atteindre les destinations de test prévues. Une dépendance simulée doit être signalée : elle ne prouve pas qu’un échange réel fonctionne.
Préparez des données représentatives sans exposer inutilement des renseignements personnels. Incluez un dossier normal, un dossier incomplet, un doublon et les exceptions importantes. Gardez une méthode pour revenir à l’état initial afin de répéter les essais après correction.
Écrire des scénarios que quelqu’un peut reproduire
Partez des exigences du cahier des charges. Chaque scénario doit préciser un rôle, un état initial, des données, des actions et un résultat attendu. Évitez « tester le formulaire » : la formule ne dit pas ce qui doit se produire.
Exemple illustratif : connecté comme client A, ouvrir une demande en brouillon, ajouter un document autorisé, enregistrer, puis rouvrir la demande sur un autre appareil pris en charge. Le document doit être retrouvé une seule fois et rester inaccessible au client B. La preuve doit couvrir la persistance et le contrôle d’accès.
Grille de recette prête à copier
Copiez ce tableau dans votre outil de suivi. Ajoutez les colonnes « version », « testeur », « date », « preuve » et « numéro d’anomalie ». Les lignes sont illustratives : adaptez-les aux règles réellement approuvées.
| ID | Scénario et précondition | Résultat attendu | Statut |
|---|---|---|---|
| REC-01 | Client autorisé, demande valide : enregistrer puis rouvrir. | Champs et pièces confirmés présents, sans doublon. | À exécuter |
| REC-02 | Champ obligatoire absent : tenter l’envoi. | Envoi bloqué, erreur compréhensible, données déjà saisies conservées. | À exécuter |
| REC-03 | Utilisateur sans permission : ouvrir un dossier non autorisé. | Accès refusé sans divulguer les données du dossier. | À exécuter |
| REC-04 | Système destinataire indisponible : transmettre une demande. | État en attente ou erreur explicite; reprise selon la règle convenue, sans doublon. | À exécuter |
| REC-05 | Parcours au clavier sur appareil pris en charge. | Actions accessibles et position du focus visible pendant le parcours. | À exécuter |
Utilisez des statuts distincts : à exécuter, réussi, échoué, bloqué et non applicable avec justification. Un scénario bloqué par un accès manquant n’est pas réussi. Une capture d’écran peut aider, mais la preuve utile décrit aussi les données, la version et le résultat.
Tester les exceptions et les conditions d’usage
Reproduisez les interruptions, les enregistrements répétés, les changements de rôle, les fichiers refusés et les sessions expirées. Vérifiez les langues prévues, les formats de dates et les messages d’erreur. Pour une application mobile ou terrain, incluez les conditions réseau convenues au périmètre.
Les vérifications préliminaires d’accessibilité du W3C peuvent aider à repérer des obstacles simples. Le W3C précise qu’elles ne constituent pas une évaluation complète. Préparez une validation adaptée au niveau d’accessibilité retenu pour le projet.
Traiter les anomalies et décider du lancement
Pour chaque échec, notez les étapes, le résultat attendu, le résultat observé et l’effet sur le travail. Convenez de la gravité selon cet effet : blocage d’un parcours essentiel, exposition de données, résultat erroné ou gêne limitée. La priorité de correction est une décision explicite, pas seulement une couleur dans un tableau.
Après correction, rejouez le scénario et les parcours voisins susceptibles d’être touchés. Conservez l’historique de l’anomalie. Avant le lancement, examinez les scénarios non exécutés, les défauts ouverts, les vérifications spécialisées et la préparation de l’exploitation.
Le responsable désigné peut accepter, accepter avec des réserves documentées ou reporter. Une réserve doit nommer son effet, une solution temporaire acceptable, son propriétaire et sa date de traitement convenue. Un résultat bloquant ne doit pas disparaître derrière un taux global de réussite élevé.
Passer de la recette à une mise en service maîtrisée
Préparez le soutien, les instructions, la surveillance et le retour arrière avec la version acceptée. L’approbation de la recette et l’autorisation de déploiement peuvent relever de décisions différentes : consignez-les. Réservez aussi une validation courte après lancement sur les parcours autorisés.
Hamdi Services prévoit les tests, la documentation et le transfert de connaissances dans la préparation du lancement; le soutien est défini dans la proposition. Présentez-nous votre application sur mesure et les parcours que votre équipe doit pouvoir accepter.
Photo de banque d’images : Jakub Zerdzicki / Pexels. Illustration du sujet; elle ne représente pas une équipe ou un mandat de Hamdi Services.