Une initiative numérique peut être techniquement déployée sans être prête pour autant à être approuvée par les métiers. L’inverse est également possible : le résultat semble utile, mais une dépendance, une autorisation ou une exception importante reste à traiter. La cause tient souvent au fait que les parties prenantes donnent des sens différents au mot « terminé ».
Définir les critères d’acceptation avant de commencer permet de convenir du résultat attendu, de la manière de le vérifier et de la personne habilitée à le valider. Cette démarche ne remplace ni la définition du périmètre ni les tests techniques : elle relie le besoin métier à une décision d’acceptation observable. Ce cadre aide les responsables produit, métier et technologie à réduire les désaccords et à repérer les lacunes avant la livraison.
Distinguer objectifs, périmètre et critères d’acceptation
Ces trois éléments répondent à des questions différentes. L’objectif explique pourquoi le travail est lancé et quel changement est recherché. Le périmètre délimite ce qui sera pris en charge et ce qui est exclu. Les critères d’acceptation décrivent les conditions vérifiables qui permettent de décider si un résultat précis répond à ce qui a été convenu.
Par exemple, un objectif pourrait être de permettre aux clients de consulter le statut de leurs commandes. Le périmètre peut inclure un écran de consultation des commandes actives, tout en excluant la modification de l’adresse de livraison. Un critère d’acceptation pourrait préciser qu’après la saisie d’un identifiant valide, le statut correspondant et sa date de mise à jour s’affichent. Cet exemple ne prescrit pas la façon de créer l’écran et ne définit pas, à lui seul, l’ensemble du projet : il délimite une condition qui doit pouvoir être vérifiée.
Avant de rédiger les critères, vérifiez que l’objectif est compréhensible et que les limites du périmètre sont explicites. Si un besoin n’est pas inclus, ne le laissez pas implicite. Le clarifier évite qu’une attente exprimée plus tard soit considérée comme un défaut d’une livraison qui ne l’avait jamais prévue.
Rédiger des conditions observables sans imposer de solution
Un critère utile peut être vérifié au moyen d’une action, d’un résultat observable ou d’une preuve convenue. Évitez les expressions telles que « facile à utiliser », « rapide » ou « fonctionne correctement » si leur sens n’est pas précisé dans le contexte du produit. Ce sont des intentions utiles, mais elles laissent place à des interprétations incompatibles.
Au lieu d’écrire « la consultation doit être intuitive », définissez la tâche que la personne doit pouvoir accomplir et le résultat qui confirme qu’elle l’a menée à bien. Si l’objectif concerne les performances, l’accessibilité ou la sécurité, traduisez chaque attente en une condition pertinente pour le cas traité et précisez comment elle sera évaluée. N’inventez pas de seuils par commodité : convenez des valeurs avec les personnes qui connaissent le besoin et les contraintes.
Il est également préférable de ne pas imposer une solution technique lorsque les métiers ont seulement besoin d’un résultat. « Utiliser un bouton bleu » relève généralement d’un choix de conception, et non d’une condition d’acceptation fonctionnelle. En revanche, « la personne peut lancer la consultation depuis la page des commandes » décrit une capacité vérifiable sans écarter inutilement d’autres possibilités de mise en œuvre.
Une formulation pratique peut comporter quatre éléments :
- Contexte : la situation ou le type d’utilisateur concerné.
- Action : ce qui doit se produire ou la tâche qui doit pouvoir être effectuée.
- Résultat : la réponse, le changement ou l’information qu’il faut pouvoir observer.
- Vérification : la preuve qui permettra de confirmer le résultat.
Tous les critères n’ont pas besoin de suivre exactement la même structure. L’essentiel est que les équipes métier, produit et technologie les comprennent de façon cohérente et puissent expliquer comment distinguer une acceptation d’un écart.
Inclure les parcours, les exceptions, les autorisations et les dépendances
Le parcours principal constitue un bon point de départ, mais il ne suffit généralement pas. Une définition qui ne couvre que le cas idéal peut laisser sans réponse la conduite à tenir face à des données invalides, à l’absence de résultats, à des autorisations insuffisantes ou à l’indisponibilité d’un service externe. Incluez les cas limites qui modifient le résultat attendu, le risque ou la décision d’approbation.
Pour repérer ces situations, parcourez l’expérience du point de vue des utilisateurs et des équipes opérationnelles :
- Que se passe-t-il si une donnée nécessaire est absente ou présente un format non accepté ?
- Quelles informations chaque profil peut-il consulter et quelles actions lui sont interdites ?
- Comment signale-t-on l’absence de résultats ou l’échec d’une opération ?
- Quelle dépendance externe peut empêcher la validation et qui doit la résoudre ?
- Existe-t-il des états intermédiaires, comme une demande en attente, qui doivent être distingués d’une confirmation ?
Il n’est pas nécessaire d’énumérer toutes les situations imaginables. Donnez la priorité aux exceptions qui touchent à la sécurité, à la conformité, à la continuité des opérations, à l’expérience ou au périmètre. Si une dépendance n’est pas disponible au moment de l’acceptation, convenez à l’avance des preuves alternatives admissibles et du risque qui restera à traiter. Une démonstration utilisant des données préparées, par exemple, ne vaut pas automatiquement validation d’une intégration réelle : cette différence doit être clairement établie.
Désigner les responsables et les preuves avant de commencer
Un critère sans responsable de validation peut relancer le débat au moment de la livraison. Pour chaque condition, déterminez qui exprime le besoin, qui effectue ou coordonne la vérification et qui prend la décision d’acceptation. Dans certaines équipes, ces rôles sont confiés à des personnes différentes ; dans d’autres, ils peuvent être cumulés. L’essentiel est que l’autorité chargée d’approuver ne soit pas ambiguë.
Définissez également les preuves qui permettront de prendre la décision : examen du comportement, journal, démonstration, résultat de test ou confirmation d’une personne responsable. La preuve doit correspondre au critère. Une capture d’écran peut montrer une page, sans démontrer que les autorisations sont correctement appliquées. Un test technique peut confirmer une réponse, sans établir que les informations sont compréhensibles pour l’utilisateur visé.
Un modèle succinct pour chaque critère peut inclure :
- Identifiant et description : une condition unique et concrète, sans termes vagues.
- Contexte et périmètre : l’utilisateur, l’état ou la situation couverts, ainsi que les exceptions exclues.
- Responsable de l’acceptation : la personne ou la fonction qui prend la décision.
- Méthode et preuve : la manière de vérifier le résultat et l’endroit où il sera consigné.
- Statut et observations : accepté, en attente ou non accepté, avec le motif et la prochaine étape.
Le modèle ne doit pas devenir une fin en soi. Si le suivi n’aide pas à décider, à coordonner ou à conserver les preuves, simplifiez-le.
Gérer les changements et repérer les ambiguïtés
Les critères peuvent évoluer lorsque de nouvelles informations apparaissent. Pour éviter les surprises, consignez ce qui a changé, qui l’a approuvé et les effets sur le périmètre, les priorités, les dépendances et la date prévue. Distinguez un critère clarifié, qui explicite une attente déjà convenue, d’un nouveau critère qui ajoute un comportement. Le second peut élargir le périmètre et exige une décision : il ne doit pas modifier silencieusement la définition de « terminé ».
Avant d’accepter une livraison, recherchez les signes d’ambiguïté. Des expressions comme « doit être complet », « le cas échéant » ou « sans erreur » ne précisent pas ce qu’il faut vérifier. Les critères qui mélangent plusieurs résultats indépendants, n’ont pas de responsable, dépendent d’un tiers sans plan prévu ou ne précisent pas la conduite à tenir en cas d’échec sont également des signaux d’alerte. Séparez les conditions combinées, précisez le résultat et convenez de la gestion des dépendances.
Si les équipes métier et technologie ne s’accordent pas sur un critère, revenez au besoin et au risque auxquels il répond. Demandez quelle preuve ferait évoluer la décision et quelle autre option pourrait satisfaire l’objectif sans imposer une solution trop tôt. Si le désaccord ne peut pas être résolu avant le démarrage, consignez la question comme une décision en attente, désignez un responsable et fixez une échéance. Ne la dissimulez pas dans une formule générique.
Un bon critère d’acceptation ne garantit pas à lui seul la réussite d’une initiative, mais il rend l’approbation plus prévisible. Lorsque chaque condition exprime un résultat observable, qu’elle a un responsable et qu’elle s’appuie sur des preuves adaptées, les équipes peuvent repérer les désaccords plus tôt, distinguer les défauts des changements de périmètre et décider plus clairement si un résultat est réellement terminé.