Rédiger les exigences pour les projets logiciels crée souvent un fossé de communication. Les développeurs parlent en code. Les parties prenantes métier parlent en valeur. Les critères d’acceptation (CA) se situent au milieu, agissant comme un pont entre ce qui est nécessaire et ce qui est construit. Quand ce pont est construit avec du jargon technique, il devient instable. Les membres de l’équipe non techniques ne peuvent pas vérifier si le travail est correct. Les parties prenantes perdent confiance dans le processus. Ce guide explique comment rédiger des critères d’acceptation sans jargon technique, assurant clarté, collaboration et livraison de qualité.
🧩 Qu’est-ce que les critères d’acceptation ?
Les critères d’acceptation définissent les conditions que doit satisfaire un produit logiciel pour être accepté par un utilisateur ou une partie prenante. Ce ne sont pas une liste de fonctionnalités, mais plutôt une définition des limites. Ils répondent à la question : « À quoi ressemble le travail terminé ? ». Dans le contexte d’une histoire utilisateur, les CA fournissent les détails nécessaires pour garantir que l’équipe de développement comprend la portée.
Les critères d’acceptation efficaces doivent être :
- Clairs :Aucune ambiguïté. Tout le monde lit le même sens.
- Vérifiables :Vous pouvez rédiger un cas de test pour les vérifier.
- Précis :Ils utilisent des chiffres et des états concrets, et non des termes vagues.
- Accessibles :Ils sont rédigés dans un langage que toute l’équipe comprend.
🗣️ Pourquoi le jargon technique nuit à la collaboration
Lorsque les développeurs rédigent des critères d’acceptation, il y a une tendance naturelle à décrire les détails de l’implémentation. Cela se produit parce qu’ils connaissent le fonctionnement du système. Toutefois, décrire la solution avant que le problème ne soit résolu introduit un risque. Cela limite la flexibilité et crée de la confusion pour ceux qui ne codent pas.
Le coût des malentendus
Pensez à une situation où une partie prenante lit une exigence et lui attribue un sens différent de celui du développeur. Cette divergence entraîne des reprises de travail. Les reprises de travail gaspillent du temps et du budget. Elles retardent également la mise en production de la valeur. Éviter le jargon réduit les chances que cet écart se produise.
- Développeurs :Pourraient se concentrer sur les champs de base de données plutôt que sur les résultats pour l’utilisateur.
- Testeurs QA :Ne sauraient peut-être pas comment vérifier le comportement sans comprendre la structure de l’API.
- Propriétaires métier :Pourraient approuver l’histoire en pensant qu’elle répond à leurs besoins, pour ensuite se rendre compte qu’elle ne les répond pas.
Termes techniques courants à éviter
Pour garder les critères accessibles, certains mots doivent être remplacés par des équivalents en langage courant. L’objectif est de décrire le comportement, et non le mécanisme.
- Évitez : « Mettre à jour l’enregistrement de la base de données. »
Utilisez : « Enregistrer les informations du client. » - Évitez : « Appelez le point de terminaison de l’API. »
Utilisez : « Envoyez la requête au serveur. » - Évitez : « Affichez le composant. »
Utilisez : « Affichez le bouton à l’écran. » - Évitez : « Lancez une exception. »
Utilisez : « Affichez un message d’erreur. »
📝 Principes des exigences en langage clair
Écrire sans jargon exige de la discipline. Cela suppose que vous vous éloigniez de la solution technique et que vous vous concentriez sur l’expérience utilisateur. Les principes suivants aident à maintenir cette orientation.
1. Concentrez-vous sur le comportement, pas sur l’implémentation
Décrivez ce que fait le système, pas comment il le fait. Le système doit gérer la logique interne. L’utilisateur s’intéresse au résultat. Si le système change sa structure interne de base de données, l’utilisateur ne doit pas s’en apercevoir. Par conséquent, les critères d’acceptation ne doivent pas mentionner la base de données.
- Mauvais : « Insérez une ligne dans la table des commandes. »
- Bon : « Créez un nouveau dossier de commande dans le système. »
2. Utilisez le voice active
La voix passive rend floue qui fait quoi. La voix active clarifie l’action. Elle rend les critères plus faciles à lire et à comprendre.
- Mauvais : « Le bouton doit être cliqué par l’utilisateur. »
- Bon : « L’utilisateur clique sur le bouton. »
3. Définissez des nombres précis
Des mots comme « rapide », « nombreux » ou « bientôt » sont subjectifs. Ils entraînent des débats sur ce qui constitue un succès. Utilisez des valeurs mesurables à la place.
- Mauvais : « La page doit se charger rapidement. »
- Bon :« La page se charge en moins de 3 secondes. »
4. Éviter les hypothèses
Ne supposez pas que l’utilisateur connaît le fonctionnement du système. Énoncez les conditions explicitement. Si une étape est nécessaire pour effectuer une action, indiquez-la comme précondition.
- Mauvais : « Vous pouvez supprimer le fichier. »
- Bon : « Si un fichier est sélectionné, l’utilisateur peut le supprimer. »
🧪 Le modèle Given-When-Then (simplifié)
L’une des façons les plus efficaces d’écrire des critères d’acceptation non techniques est le format Given-When-Then. Cette structure est souvent associée au développement piloté par le comportement, mais elle convient également aux exigences exprimées en langage courant. Elle divise le scénario en contexte, action et résultat.
Décomposition du modèle
- Étant donné : L’état initial ou le contexte. Que se passe-t-il avant l’action ?
- Lorsque : L’action effectuée par l’utilisateur ou le système. Qu’est-ce qui déclenche le changement ?
- Alors : Le résultat attendu. Que se passe-t-il après l’action ?
Scénario d’exemple : Connexion
Imaginez une histoire utilisateur concernant la connexion à un compte sécurisé. Une version technique pourrait mentionner les jetons de session. Une version en langage courant se concentre sur l’expérience.
- Étant donné : L’utilisateur est sur l’écran de connexion.
- Lorsque : L’utilisateur saisit un e-mail et un mot de passe valides, puis clique sur « Se connecter ».
- Alors : L’utilisateur est redirigé vers la page d’accueil.
Cette structure oblige l’auteur à réfléchir au déroulement des événements plutôt qu’à la structure du code. Elle est facile à lire et à vérifier pour un analyste métier.
📊 Comparaison entre version technique et version en langage courant
Voir des exemples côte à côte aide à clarifier la différence. Le tableau ci-dessous montre comment traduire les exigences techniques en langage centré sur l’utilisateur.
| ❌ Version technique | ✅ Version en langage courant |
|---|---|
| Lorsque l’utilisateur soumet le formulaire, exécutez une requête POST vers /api/submit avec un chargement JSON. | Lorsque l’utilisateur clique sur « Envoyer », les informations sont envoyées au système. |
| Assurez-vous que la transaction de base de données est annulée si la connexion expirée. | Si la connexion échoue, le système ne sauvegarde pas les données et demande à l’utilisateur de réessayer. |
| Validez l’entrée selon le modèle regex pour l’email. | Assurez-vous que l’adresse e-mail est correctement formatée avant de sauvegarder. |
| Renvoyez une erreur HTTP 404 si l’identifiant de la ressource n’existe pas. | Affichez un message indiquant que l’élément demandé ne peut pas être trouvé. |
| Nettoyez les cookies de session lors de la déconnexion. | Supprimez l’état de connexion lorsque l’utilisateur clique sur « Déconnexion ». |
🤝 Le rôle de la collaboration
Rédiger les critères d’acceptation est rarement une tâche individuelle. Elle nécessite des apports du propriétaire du produit, de l’équipe de développement et du service qualité. La collaboration garantit que le langage courant est précis et que les contraintes techniques sont respectées sans être explicites.
Préparation de la discussion
Avant d’écrire les critères finaux, rassemblez des informations. Demandez aux parties prenantes métier ce dont elles ont besoin. Demandez aux développeurs ce qui est réalisable. Cette préparation réduit les échanges ultérieurs.
- Revoyez la documentation existante : Vérifiez s’il existe déjà des fonctionnalités similaires.
- Identifiez les cas limites : Que se passe-t-il si l’internet tombe en panne ? Et si l’utilisateur entre des données incorrectes ?
- Fixez des contraintes : Y a-t-il des limites de temps ou des exigences de sécurité à respecter ?
Affinement des critères
Une fois le brouillon prêt, faites-le revue avec l’équipe. Utilisez les critères comme point de discussion, et non comme contrat définitif. Cela permet des ajustements en fonction de nouvelles découvertes techniques.
- Parcours : Lisez les critères à voix haute. Ont-ils un sens pour une personne non technique ?
- Interrogation : Posez des questions du type « Et si ? » pour tester les limites.
- Tests : Faites tester par un testeur d’essayer de rédiger un cas de test basé sur les critères. S’ils ont du mal, les critères sont trop flous.
🛠️ Gérer les cas limites sans complexité
Les cas limites sont des scénarios qui ne se produisent pas souvent mais doivent fonctionner quand ils surviennent. Les décrire sans jargon peut être difficile. L’essentiel est de décrire l’expérience utilisateur pendant l’erreur, et non le code d’erreur lui-même.
Cas limites courants
- Erreur de réseau : « Si la connexion internet est perdue, le système enregistre les données localement et informe l’utilisateur. »
- Entrée non valide : « Si l’utilisateur tape des lettres dans le champ du numéro de téléphone, le système affiche une erreur et met en évidence le champ. »
- Données manquantes : « Si un champ obligatoire est vide, le système empêche l’enregistrement et demande les informations. »
- Problèmes de permissions : « Si l’utilisateur n’a pas accès, le système masque le bouton. »
En vous concentrant sur la réaction visible, vous gardez les critères accessibles. Le développeur sait comment mettre en œuvre la correction en coulisse.
📈 Mesurer le succès et la qualité
Comment savez-vous si vos critères d’acceptation fonctionnent ? Vous les mesurez par la qualité du travail livré et l’efficacité du processus.
Indicateurs de bons critères
- Moins de reprises : L’équipe construit la bonne chose du premier coup.
- Tests plus rapides : Les testeurs peuvent vérifier l’histoire rapidement sans demander de clarification.
- Validation claire : Les parties prenantes peuvent confirmer que le travail est terminé sans confusion.
- Moins d’ambiguïté : Moins de questions surgissent pendant la phase de développement.
Définition de fait vs. Critères d’acceptation
Il est important de distinguer les critères d’acceptation de la Définition de fait (DoD). La DoD s’applique à chaque tâche individuelle, indépendamment de la fonctionnalité. Elle inclut des éléments comme la revue de code, les contrôles de sécurité et les tests unitaires. Les critères d’acceptation sont spécifiques à l’histoire utilisateur.
- DoD : « Le code est revu, les tests passent et la documentation est mise à jour. »
- AC : « L’utilisateur peut filtrer les produits par plage de prix. »
Les deux sont nécessaires à la qualité. La DoD assure la santé technique. Les AC assurent la valeur métier.
🚧 Erreurs courantes à éviter
Même avec de bonnes intentions, les équipes tombent souvent dans des pièges. Être conscient de ces erreurs courantes aide à maintenir des standards élevés.
Erreur 1 : Être trop vague
Dire « Le système doit être rapide » ne suffit pas. Cela invite au débat. Définissez ce que signifie « rapide » dans votre contexte. Moins de 1 seconde ? Moins de 5 secondes ?
Erreur 2 : Mélanger les critères d’acceptation aux tâches
Ne listez pas les étapes que le développeur doit effectuer. Par exemple, « Créer une nouvelle table de base de données » est une tâche, pas un critère d’acceptation. Le critère est le résultat, pas la méthode.
Erreur 3 : Ignorer les cas négatifs
Écrire uniquement sur ce qui se passe quand tout va bien est incomplet. Un ensemble solide de critères inclut ce qui se passe quand les choses tournent mal. Cela protège l’expérience utilisateur.
Erreur 4 : Utiliser trop de conditions
Si une histoire utilisateur comporte vingt critères d’acceptation, elle pourrait être trop grande. Essayez de la diviser en histoires plus petites. Les histoires plus petites sont plus faciles à comprendre et à tester.
🛡️ Assurer l’accessibilité et la clarté
Un langage simple ne consiste pas seulement à éviter les termes techniques. Il s’agit de rendre le contenu accessible à tous les membres de l’équipe. Cela inclut les personnes ayant des styles d’apprentissage ou des niveaux de maîtrise de la langue différents.
Conseils pour l’accessibilité
- Phrases courtes : Gardez les phrases sous 20 mots quand c’est possible.
- Mots simples : Utilisez un vocabulaire courant plutôt que des termes techniques de l’industrie.
- Aides visuelles : Lorsque c’est possible, joignez des captures d’écran ou des maquettes pour clarifier les critères.
- Terminologie cohérente : Utilisez les mêmes mots pour les mêmes concepts tout au long du projet.
🔄 Le processus de revue
Une fois les critères rédigés, ils doivent être revus. Ce n’est pas une action ponctuelle. Au fur et à mesure que le projet évolue, les critères peuvent nécessiter des mises à jour. Un document vivant garantit que les exigences restent précises.
Liste de vérification de la revue
- Est-il testable ?Pouvons-nous le vérifier par un test ?
- Est-il complet ?Couvre-t-il tous les parcours utilisateur ?
- Est-il clair ?Un nouveau membre de l’équipe peut-il le comprendre ?
- Est-il cohérent ?Correspond-il aux autres histoires dans le backlog ?
🎯 Réflexions finales sur les exigences claires
Rédiger des critères d’acceptation sans jargon technique est un investissement dans le succès du projet. Il comble le fossé entre les besoins métiers et l’exécution technique. Il réduit les erreurs, économise du temps et renforce la confiance entre les parties prenantes. En se concentrant sur un langage simple, des résultats clairs et le comportement des utilisateurs, les équipes peuvent livrer un logiciel de haute qualité qui répond véritablement aux besoins des utilisateurs.
L’effort pour éviter la complexité se traduit par une communication plus fluide et une livraison plus rapide. Lorsque tout le monde comprend l’objectif, l’équipe avance avec confiance. Cette approche conduit à de meilleurs produits et à des équipes plus heureuses.
