Sommaire
- Définir le résultat avant de tester les écrans
- Préparer un environnement où les essais se répètent
- Six tests pour le parcours métier principal
- Six tests pour les conditions réelles de travail
- Six tests pour la prise en main et la reprise
- Transformer un échec en décision
- Conserver un dossier de décision exploitable
Une démonstration convaincante suit un parcours préparé. La recette vérifie si vos équipes peuvent accomplir le travail convenu, avec des données réalistes, les bons accès et des erreurs à gérer. Voici 18 scénarios de départ et une méthode pour décider de la mise en ligne d’une application sur mesure.
Portée de cette grille
Ces exemples de recette métier ne constituent ni un audit de sécurité complet, ni une certification d’accessibilité, ni un contrat universel. Choisissez les cas pertinents avec l’équipe de réalisation et ajoutez les risques propres à vos opérations.
Définir le résultat avant de tester les écrans
Partez d’un parcours complet : recevoir une demande, l’attribuer, approuver une décision, informer la bonne personne et retrouver la preuve. Une page qui s’ouvre ne démontre pas que cette chaîne fonctionne. Précisez qui valide le résultat et quel problème empêcherait la mise en ligne.
Prenons un distributeur fictif : l’entrepôt doit enregistrer un colis reçu et les ventes doivent consulter son nouveau statut. Le résultat attendu est une fiche unique, correctement rattachée au dossier, avec un changement de statut traçable. Un message de confirmation vert ne suffit pas. Cet exemple explique la méthode; il ne décrit pas un résultat client de Daillac.
Consignez ces résultats dans le cahier des charges de l’application. Le cahier des charges aide à définir le périmètre et à obtenir un devis. Le dossier de recette sert ensuite à valider la livraison.
Préparer un environnement où les essais se répètent
- Noter la version de l’application, l’environnement, le navigateur, la langue et la date.
- Créer des comptes d’essai distincts : client, employé, gestionnaire et administrateur.
- Employer des dossiers et fichiers fictifs; éviter de copier des données personnelles dans un environnement non maîtrisé.
- Écrire l’état de départ et le résultat attendu avant chaque essai.
- Désigner qui corrige, qui reprend le test et qui décide de la mise en ligne.
Une fiche d’essai comporte un identifiant, un objectif métier, des préconditions, des actions, un résultat attendu, un résultat observé et une preuve. Associez captures et journaux à la version testée. Lorsqu’une nouvelle version arrive, un résultat déjà réussi peut devoir être repris si le composant modifié touche le parcours.
Six tests pour le parcours métier principal
TableauGrille de départ : les dossiers et les responsabilités · bloc partageable
| Scénario | Preuve attendue | |
|---|---|---|
| 01 · Demande complète | Envoyer une demande valide et la suivre jusqu’à sa destination. | Un identifiant unique, les bons champs et le responsable attendu. |
| 02 · Information manquante | Omettre un renseignement métier obligatoire. | Erreur claire, saisie conservée et absence de dossier final incomplet. |
| 03 · Double envoi | Envoyer deux fois ou reprendre après une réponse incertaine. | Une opération métier, ou une règle explicite de traitement des doublons. |
| 04 · Frontière entre clients | Avec le compte A, tenter de consulter le dossier du client B. | Accès refusé sans exposition des renseignements de B. |
| 05 · Approbation | Préparer une modification comme employé et l’approuver comme gestionnaire. | Le rôle prévu approuve; l’identité et l’action sont traçables. |
| 06 · Dates et export | Exporter des dates, des noms accentués et des montants décimaux. | Valeurs compréhensibles dans la langue, le fuseau et le format convenus. |
Une règle de doublon ne devrait pas dépendre uniquement d’un bouton désactivé. Après un délai d’attente, le navigateur peut reprendre une requête que le serveur a déjà enregistrée. Demandez comment l’application reconnaît une opération répétée. Le responsable métier doit préciser quand deux demandes similaires sont des dossiers distincts et quand elles sont des doublons.
Six tests pour les conditions réelles de travail
TableauGrille de départ : les personnes et les intégrations · bloc partageable
| Scénario | Preuve attendue | |
|---|---|---|
| 07 · Petit écran | Effectuer le parcours principal sur les appareils mobiles convenus. | Champs et actions utilisables sans perte d’information essentielle. |
| 08 · Clavier et erreurs | Remplir le formulaire sans souris, avec une valeur invalide. | Position du focus visible, contrôles accessibles et correction compréhensible. |
| 09 · Français et anglais | Changer de langue puis reprendre le parcours pertinent. | Libellés, messages et destination adaptés; données conservées selon la règle prévue. |
| 10 · Notification répétée | Livrer deux fois le même événement d’intégration dans le système d’essai. | Aucune tâche, facture ou notification dupliquée involontairement. |
| 11 · Panne d’un service | Rendre une connexion d’essai indisponible, puis la rétablir. | État en attente ou en échec visible et reprise contrôlée. |
| 12 · Modifications simultanées | Faire modifier un même dossier par deux personnes autorisées. | Règle de conflit documentée, sans perte silencieuse du travail. |
Lorsqu’une connexion échoue, distinguez un dossier en attente d’un refus définitif. L’équipe doit savoir si elle doit patienter, corriger une information ou contacter le soutien. Une erreur générique laisse la décision opérationnelle sans réponse, même si le problème technique est enregistré dans un journal.
Les ressources d’évaluation du W3C rappellent le rôle de l’évaluation humaine en complément des outils. Un essai au clavier est utile pour la recette; sa réussite ne démontre pas à elle seule la conformité en accessibilité.
Six tests pour la prise en main et la reprise
TableauGrille de départ : l’exploitation · bloc partageable
| Scénario | Preuve attendue | |
|---|---|---|
| 13 · Restauration | Restaurer une sauvegarde contrôlée dans l’environnement d’essai convenu. | Les dossiers choisis et leurs relations sont récupérables. |
| 14 · Livraison défaillante | Répéter la procédure prévue lorsqu’une mise en ligne échoue. | Responsable de décision, étapes de reprise et traitement des données modifiées. |
| 15 · Vide et chargement | Consulter une liste vide et un parcours qui charge lentement. | Distinction entre aucun résultat, traitement en cours et échec. |
| 16 · Fichiers | Essayer des fichiers autorisés et un fichier hors des règles prévues. | Limites claires, accès autorisés et refus compréhensible. |
| 17 · Retrait des accès | Désactiver un utilisateur d’essai et vérifier les accès concernés. | Application vérifiable de la politique de révocation documentée. |
| 18 · Suivi des soumissions | Terminer une demande avec les paramètres de mesure autorisés. | Réception métier et trace opérationnelle distinctes d’une simple consultation. |
Le référentiel OWASP ASVS fournit une base pour vérifier les contrôles de sécurité techniques d’une application. Fixez la version et le périmètre retenus lorsque ces exigences font partie du mandat. Cette grille métier complète ce travail; elle ne remplace pas une vérification de sécurité spécialisée.
Transformer un échec en décision
Reprenons le dossier fictif Q-1042. La demande apparaît dans l’application, mais la connexion comptable dépasse son délai d’attente. Une fiche utile identifie le dossier enregistré, montre l’intégration en attente et prouve que la reprise ne crée pas une deuxième fiche. Si l’équipe ne distingue pas « enregistré » de « non enregistré », le parcours reste ouvert à la recette.
- Un blocage empêche un parcours requis, expose des données non autorisées ou rend la reprise dangereuse.
- Une anomalie importante possède un contournement convenu, un responsable et une date de reprise du test.
- Un défaut visuel peut être reporté s’il n’empêche pas l’usage et si la décision est consignée.
Il s’agit d’une convention de travail proposée. Entendez-vous sur ces catégories avant la revue afin que le fournisseur et les opérations ne classent pas un même défaut différemment. Ne supprimez pas un résultat échoué après correction : ajoutez le nouveau test et conservez l’historique.
Conserver un dossier de décision exploitable
Rassemblez les scénarios convenus, les résultats par version, les anomalies ouvertes, les contournements acceptés, les consignes d’exploitation et le responsable de décision. Séparez la mise en ligne d’une demande d’évolution ultérieure. Si une nouvelle règle apparaît pendant les essais, précisez si elle corrige le fonctionnement convenu ou élargit le périmètre initial.
Joignez ces fiches aux prochaines demandes d’évolution de votre application web sur mesure. L’équipe qui prépare le devis retrouvera les parcours validés et les exceptions encore ouvertes.
IllustrationScène éditoriale d’un employé d’entrepôt testant une application sur tablette lors du balayage d’un colis · bloc partageable
Questions fréquentes
Qui doit réaliser la recette?+
Les utilisateurs métier valident les résultats attendus avec le soutien de l’équipe de réalisation. Les développeurs préparent comptes et preuves; une personne responsable du processus examine la décision de lancement.
Ces 18 tests suffisent-ils pour toute application?+
Non. Il s’agit d’une grille de départ. Paiements, données réglementées et intégrations complexes exigent des scénarios supplémentaires et des vérifications spécialisées.
Toute anomalie doit-elle bloquer le lancement?+
Appliquez les règles de gravité convenues. Consignez le contournement, la personne qui l’accepte et la correction prévue. Un accès non autorisé aux données n’est pas un simple défaut visuel.
Une analyse de sécurité réussie vaut-elle acceptation?+
Non. La sécurité et la recette métier répondent à des questions différentes. Les parcours, les responsabilités, les données et la reprise doivent aussi être vérifiés.
Quand écrire les critères d’acceptation?+
Pendant le cadrage, puis les préciser avant la livraison. Attendre la dernière démonstration rend la distinction entre anomalie et nouveau besoin plus difficile.
Préparer une mise en ligne vérifiable
Apportez vos parcours essentiels, le cahier des charges et la liste des intégrations. Nous pouvons cadrer les preuves à réunir avant le lancement.
D
