Transformez un besoin logiciel en vérifications concrètes : exemples de critères d’acceptation, cas d’erreur et organisation de la recette en PME.
« Le responsable doit pouvoir valider un devis » laisse plusieurs décisions ouvertes. Peut-il modifier le montant ? Que voit le commercial après validation ? Que se passe-t-il si une autre personne a déjà refusé ce devis ? Ces questions méritent une réponse avant que l’équipe construise l’écran.
Les critères d’acceptation décrivent les conditions dans lesquelles une fonctionnalité convient à son usage prévu. Atlassian les présente comme des conditions vérifiables associées au besoin. Ils servent à faire discuter le métier et le développement sur des situations observables.
Partir d’une décision utilisateur
Décrivez qui agit, dans quelle situation et pour obtenir quel résultat. Gardez une formulation compréhensible pour la personne qui utilisera le logiciel. « En tant que responsable commercial, je valide un devis prêt à être envoyé » constitue un point de départ, à préciser par des exemples.
Dans un scénario fictif, l’entreprise veut réserver la validation au responsable du dossier. Elle exige aussi que le devis conserve la version des lignes effectivement approuvées. Ce sont deux règles différentes : l’une concerne les droits, l’autre la traçabilité.
Si les personnes présentes ne s’accordent pas sur la règle, notez la décision en attente et son responsable. Une phrase volontairement vague transmet le désaccord à la phase de recette, où il coûte davantage de travail à résoudre.
Écrire des exemples dont le résultat est observable
Un format « contexte, action, résultat » fonctionne sans outil spécialisé. Pour chaque cas, l’équipe doit pouvoir préparer les données, réaliser l’action et constater ce qui s’est passé.
| Contexte | Action | Résultat attendu dans cet exemple |
|---|---|---|
| Devis complet, responsable autorisé | Valider | Statut validé et identité du valideur enregistrés |
| Commercial sans droit de validation | Tenter de valider | Action refusée sans modification du devis |
| Ligne de devis modifiée après ouverture de l’écran | Confirmer la validation | Nouvelle lecture demandée avant approbation |
| Devis déjà validé | Répéter la même action | Aucune seconde notification de validation |
| Service de notification indisponible | Valider | Validation conservée et notification en attente visible |
Cette dernière ligne correspond à un choix métier illustratif. Certaines entreprises choisiront un comportement différent. L’intérêt du tableau est de rendre ce choix explicite, afin de le tester.
Remplacer les adjectifs par une mesure convenue
« Rapide », « intuitif » ou « sécurisé » indiquent une intention. Ils doivent être accompagnés de conditions lorsque la recette doit prononcer une acceptation.
Pour la rapidité, décrivez l’opération, le volume de données et l’environnement de mesure. Pour une exportation, précisez les colonnes attendues et les cas où le fichier devient trop volumineux. Pour les droits, nommez les rôles autorisés et les informations qu’un autre rôle ne doit jamais voir.
Ne choisissez pas un chiffre uniquement parce qu’il semble professionnel. Un délai doit refléter le besoin du parcours et être techniquement mesurable. Consignez la méthode d’essai pour éviter qu’une équipe mesure sur quelques lignes pendant que l’autre teste l’historique complet.
Distinguer la fonctionnalité et les règles communes
Les critères d’un devis ne couvrent pas à eux seuls la qualité de tout le produit. Les équipes peuvent aussi définir des règles communes de livraison : tests exécutés, documentation mise à jour ou vérification des accès.
La Definition of Done décrite par Atlassian aide à formaliser ces attentes transversales. Gardez les exigences propres au parcours près de la fonctionnalité et les exigences communes dans un endroit partagé. Répéter partout la même longue liste la rend difficile à maintenir.
Préparer la recette avec les utilisateurs
Désignez les personnes qui testeront et celles qui pourront accepter le résultat. Prévoyez leurs comptes et les données d’essai. Une recette menée uniquement par l’administrateur technique peut manquer les problèmes rencontrés par un utilisateur ordinaire.
Classez chaque observation : règle prévue mais non respectée, besoin ambigu ou nouvelle demande. Cette distinction permet de corriger un défaut sans perdre la trace d’un changement de périmètre. Le traitement contractuel de ces catégories reste celui convenu avec le prestataire.
Avant la mise en service, conservez le résultat des essais et les écarts encore ouverts. Pour chacun, indiquez l’impact connu, la décision prise et la personne qui l’assume. Cela évite de confondre une fonctionnalité acceptée avec une anomalie simplement reportée.
Vous pouvez intégrer ces éléments à votre cahier des charges de logiciel sur mesure. Pour cadrer un développement logiciel au Maroc, envoyez-nous un parcours métier et les situations qui posent problème aujourd’hui. Nous pourrons préciser les premières conditions de recette.