Critères d'acceptation et d'évaluation

Objectif

Les critères d'acceptation et d'évaluation sont les mesures qui rendent vérifiable par un tiers le jugement porté sur une solution. Ils répondent à deux questions. Quand une seule solution est sur la table, la question est binaire: satisfait-elle les conditions que les parties prenantes ont posées pour l'accepter? Quand plusieurs candidates restent en lice, la question est comparative: laquelle apporte le plus de valeur et sur quelles mesures le constate-t-on? Les deux usages tiennent dans une seule technique parce qu'ils se construisent sur le même matériau, les attributs de valeur. Seule la forme de l'évaluation change avec le nombre de candidates.

La technique produit deux livrables selon l'usage. Du côté acceptation, une liste d'énoncés vérifiables rattachés aux exigences ou aux récits utilisateurs qu'ils qualifient, chacun rédigé pour se solder par une réussite ou un échec, puis le relevé des résultats de la recette utilisateur. Du côté évaluation, une grille qui croise les attributs de valeur pondérés et les solutions candidates, dont chaque colonne se solde par un total pondéré, puis le classement qui en sort. Les deux se rédigent avant l'objet qu'ils jugent. Un critère écrit après coup enregistre ce que la solution fait déjà: il ne peut plus rien faire échouer.

La valeur de la technique tient à ce qu'elle déplace la discussion dans le temps. Sans critère écrit, l'acceptation se négocie à la livraison, quand le budget est dépensé et que le rapport de force est défavorable à celui qui découvre le problème. Avec un critère écrit, elle se négocie à la définition, quand la correction coûte une phrase. Le même déplacement vaut pour l'évaluation: les poids accordés aux attributs sont une déclaration de ce que l'organisation valorise, et la grille les pose pendant qu'ils sont encore discutables.

Usage

Quand l'utiliser

• Obligation contractuelle: la réception et le paiement dépendent d'une condition écrite que les deux parties peuvent vérifier.
• Recette utilisateur à préparer: chaque exigence doit devenir un énoncé qui se tranche en réussite ou en échec.
• Plusieurs solutions à départager: progiciels, variantes de conception ou offres concurrentes se comparent sur des mesures communes.
• Backlog agile à préparer: une méthode agile peut demander que toute exigence s'exprime en critères testables.
• Exigence non fonctionnelle à qualifier: un seuil de temps de réponse, de disponibilité ou de volumétrie la rend vérifiable.
• Priorités à arbitrer entre besoins divers: des mesures communes classent des demandes que rien ne rendait comparables.

Quand ne pas l'utiliser

• Besoin encore en exploration: aucun énoncé stable à rendre vérifiable, cadrer d'abord le besoin en atelier.
• Choix dominé par l'incertitude: la valeur des candidates dépend d'événements futurs, passer par l'analyse décisionnelle, qui traite le risque.

Description

Le matériau commun aux deux usages est l'attribut de valeur. Le BABOK le définit comme une caractéristique d'une solution qui détermine ou influence substantiellement sa valeur pour les parties prenantes. Il le présente comme une décomposition de la proposition de valeur en parties constitutives, sur laquelle les parties prenantes se sont accordées. Le guide en donne six familles d'exemples: la capacité à fournir une information donnée, la capacité à exécuter ou à soutenir une opération donnée, les caractéristiques de performance et de réactivité, l'applicabilité de la solution dans des situations et des contextes donnés, la disponibilité de fonctions et de capacités données, ainsi que l'utilisabilité, la sécurité, l'évolutivité et la fiabilité. Il charge le business analyst de s'assurer que la définition de chaque attribut est admise par toutes les parties prenantes.

Le nombre de solutions en jeu décide de la forme que prend l'évaluation. Une seule candidate appelle un seuil et un verdict binaire; plusieurs appellent une échelle et un classement. Les deux pistes partent des mêmes attributs et se séparent à l'étape suivante.

Définir les attributs de valeur

Les attributs se dérivent de la proposition de valeur et des objectifs métier. Une liste recopiée du catalogue de fonctions d'un produit ramène l'évaluation à ce que ce produit sait faire, ce qui avantage son fournisseur. Une grille se tient à quelques attributs, quatre à huit dans la plupart des cas: au-delà, chaque poids devient trop petit pour peser et la grille additionne du bruit.

Chaque attribut reçoit une définition écrite qui dit comment on le mesure. Le mot « utilisabilité » ne tranche rien tant que la définition ne précise ni la tâche, ni le profil d'utilisateur, ni le seuil. Quand la solution est un logiciel, la norme ISO/IEC 25010 donne un modèle de qualité du produit logiciel où l'utilisabilité, la sécurité, l'évolutivité et la fiabilité sont décomposées en caractéristiques et sous-caractéristiques mesurables, ce qui épargne d'en réinventer le sens à chaque projet. La correspondance avec les mots du BABOK n'est pas terme à terme: l'édition 2023 traite l'utilisabilité sous le nom de capacité d'interaction et range l'évolutivité parmi les sous-caractéristiques de la flexibilité. Pour une solution qui n'est pas un logiciel, ces définitions se construisent au cas par cas. Les mêmes attributs alimentent les exigences non fonctionnelles, où ils portent déjà leurs seuils. Le glossaire fige le vocabulaire pour que deux évaluateurs lisent le même mot de la même façon. Pour les attributs qu'aucun instrument ne mesure directement, le BABOK renvoie au jugement d'expert ou à des techniques de notation.

Écrire un critère d'acceptation vérifiable

Un critère d'acceptation est un énoncé dont on peut établir qu'il est vrai ou faux. Le BABOK indique que les critères d'acceptation sont exprimés sous une forme testable, que cela peut demander de décomposer l'exigence jusqu'à une forme atomique pour qu'un cas de test puisse s'écrire et que la vérification passe souvent par les tests d'acceptation utilisateur, ce que l'on appelle couramment la recette. La norme ISO/IEC/IEEE 29148 range le caractère vérifiable parmi les propriétés d'une exigence bien formée, et un critère invérifiable laisse l'exigence aussi imprécise qu'avant.

Un seuil chiffré qualifie une exigence non fonctionnelle: le calcul de la paie mensuelle s'achève en moins de cinq minutes. Une clause de réception qualifie une obligation contractuelle: plafond de coût de mise en œuvre, délai de mise en service, niveau de service dû. Un scénario rédigé en « étant donné, quand, alors » qualifie un récit utilisateur, forme que les équipes agiles emploient parce qu'elle se transpose directement en cas de test.

Le piège le plus fréquent est le critère qui reformule l'exigence sans rien y ajouter. « Le système gère les salaires » ne devient vérifiable qu'une fois posées la donnée d'entrée, l'action et le résultat attendu. Le critère sans seuil se tranche à la livraison, au bénéfice de celui qui parle le plus fort: « le système est rapide » n'oppose rien à un fournisseur qui juge son produit rapide. Le critère rédigé par le fournisseur mesure ce que le fournisseur sait déjà faire. Le critère gelé par contrat coûte le plus cher: le BABOK tient les critères d'acceptation pour nécessaires quand les exigences expriment des obligations contractuelles, et il relève que ces critères peuvent, à ce titre, être difficiles à modifier pour des raisons juridiques ou politiques. Un critère devenu inadéquat se traite par avenant, dans la procédure de gestion des changements convenue au contrat: on documente l'écart constaté, son effet sur le prix et sur le délai, puis les deux parties signent. La réécriture unilatérale est sans effet sur ce qui est dû.

Construire un critère d'évaluation

Un critère d'évaluation est une échelle. Le BABOK le décrit comme un paramètre mesurable sur une échelle continue ou discrète, dont la définition ouvre la mesure à diverses méthodes, dont le benchmarking ou le jugement d'expert. Le guide ajoute que définir des critères d'évaluation peut amener à concevoir les outils et les instructions de l'évaluation elle-même, ainsi que la façon d'en enregistrer et d'en traiter les résultats.

Trois décisions font la grille, toutes prises avant de voir les résultats. Le choix des attributs retenus dit sur quoi l'on juge. La pondération dit ce qui compte le plus: des poids dont la somme fait 1.00 répartissent l'importance et enregistrent le jugement de valeur des parties prenantes. Quand les poids se discutent sans converger, on les dérive de comparaisons deux à deux avec le processus d'analyse hiérarchique plutôt que de les négocier en bloc. L'échelle de notation, par exemple de 1 à 5, dit sa direction: sur le coût, la note haute revient au moins cher, et une grille muette sur ce point se lit à l'envers.

Le score pondéré d'une case est le poids multiplié par la note; le total d'une candidate est la somme de sa colonne. Ce total classe les candidates sans décider à leur place. Un écart de quelques centièmes entre deux totaux, sur des notes de 1 à 5, ne porte aucune certitude: on l'éprouve en déplaçant d'un cran le poids le plus discutable pour voir si le classement tient.

Le biais le plus courant est la pondération fixée une fois les notes connues, pour retrouver la candidate que l'on préférait déjà. Le remède est l'ordre des opérations: les poids d'abord, en séance et à découvert, les notes ensuite. Le second biais est le seuil éliminatoire noyé dans la moyenne. Une condition indispensable, hébergement des données en Suisse ou conformité réglementaire, se pose en présélection et écarte la candidate qui y échoue; pondérée parmi les autres, elle se laisse compenser par de bonnes notes ailleurs et cesse d'être indispensable.

La grille d'évaluation partage sa mécanique avec la matrice de décision, où la notation pondérée est traitée pour elle-même. L'évaluation des fournisseurs applique cette mécanique au choix d'un prestataire. Ce qui leur appartient en propre est le point de départ: les dimensions de la grille sont des attributs de valeur admis par les parties prenantes et dérivés de la proposition de valeur.

Dérouler la technique

1. Décomposer la proposition de valeur en un jeu court d'attributs et écrire la définition mesurable de chacun.
2. Faire admettre ces définitions par toutes les parties prenantes concernées, avant d'en tirer le moindre critère.
3. Compter les solutions en jeu, ce qui décide de la piste: seuil et verdict pour une seule, échelle et classement pour plusieurs.
4. Piste acceptation: traduire chaque attribut en énoncés vérifiables, décomposés jusqu'à ce qu'un cas de test puisse s'écrire.
5. Piste évaluation: pondérer les attributs à découvert, figer les poids, puis noter chaque candidate sur des preuves.
6. Exécuter l'évaluation: recette utilisateur d'un côté, notation et agrégation de l'autre.
7. Consigner les résultats et les rattacher aux exigences qu'ils qualifient, pour que la trace survive à la livraison.

Considérations IA

Le premier usage rentable est la mise en forme testable. À partir d'une exigence rédigée en prose, un modèle de langage la décompose en énoncés atomiques, propose pour chacun la donnée d'entrée, l'action et le résultat attendu et signale ceux qui restent invérifiables faute de seuil. Il repère aussi les critères qui en contiennent deux, dont l'énoncé porte un « et » qui rend le verdict ambigu quand une moitié passe et l'autre échoue. Sur un backlog, il produit une première passe de scénarios en « étant donné, quand, alors » que l'équipe corrige plus vite qu'elle ne les écrirait.

Sur la piste évaluation, le gain passe par l'outil de calcul. Un modèle écrit la formule ou le script qui recalcule les totaux pondérés, balaie une plage de poids et signale le rang qui bascule au premier centième déplacé. L'exécution de ce script garantit le résultat; le calcul qu'un modèle fait de tête reste peu fiable et se recompte. Un modèle relit aussi la grille pour y trouver deux attributs qui mesurent la même chose ou une échelle dont la direction contredit son intitulé.

Ce que l'IA ne fait pas tient à la nature de la technique. Elle ne fixe pas les poids: ils portent le jugement de valeur des parties prenantes, et l'automatiser supprime la seule chose que la grille existe pour rendre explicite. Elle ne prononce pas l'acceptation: le verdict engage celui qui l'émet, et une réussite produite par un modèle n'engage personne. Elle ne connaît pas les conditions implicites du métier, celles qu'une caisse de compensation, un réviseur ou un régulateur appliquera sans les avoir écrites et qu'un utilisateur expérimenté énonce en trois minutes d'entretien. Les jeux d'essai d'une recette de paie ou de dossiers clients contiennent des données personnelles: ils ne partent pas dans un service tiers non maîtrisé, et l'outil retenu doit traiter ces données conformément à la LPD.

Exemples

Une PME vaudoise de logistique, trente-quatre collaborateurs, remplace son logiciel de salaires. Les parties prenantes ont admis quatre attributs de valeur: coût, fonctionnalité, utilisabilité et performance. Trois offres restent en lice après présélection.

Les marges sont minces. A ne devance C que de vingt centièmes, et son avantage de prix y est exactement effacé par son déficit de fonctionnalité: c'est l'utilisabilité qui la place devant C. Déplacer cinq centièmes du coût vers la fonctionnalité laisse B à 3.80, porte C à 3.65 et fait tomber A à 3.55. La tête tient, le reste du classement s'inverse. Une marge que renverse un cran de pondération mesure la pondération avant de mesurer les offres, et la question posée au décideur devient celle du poids qu'il accorde au prix. L'offre B retenue, les mêmes quatre attributs sont réécrits en conditions d'acceptation pour la recette utilisateur.

Le même attribut change de nature entre les deux tableaux. Dans la grille, une note faible se compense: B l'emporte malgré une performance notée 3. Dans la recette, le seuil remplace l'échelle et aucune moyenne ne vient adoucir un manquement. Ce passage est le moment où l'équipe doit dire ce qui est indispensable, conversation plus rude que la pondération.

Visualisations

La bifurcation entre les deux pistes est une position dans l'espace: deux trajets parallèles qui partent du même matériau et aboutissent à des verdicts de nature différente. Le schéma porte quatre étapes par piste, les attributs de valeur en tête de chacune, le verdict binaire d'un côté et le classement de valeur de l'autre.

La grille pondérée et la liste des verdicts sont faites de lignes et de colonnes: elles sont portées en HTML dans le corps de la fiche, où elles restent lisibles au zoom et accessibles à un lecteur d'écran. Les deux tableaux portent les mêmes quatre attributs et se lisent l'un contre l'autre: le même mot devient une note dans la grille et un seuil dans la recette. Dans le tableau d'acceptation, la colonne de résultat n'accepte que deux valeurs: une case intermédiaire, « partiellement conforme », rouvrirait la négociation que le critère existait pour fermer.

Coût

Outils

Le tableur suffit à la grille d'évaluation et la garde vérifiable et rejouable, ce qui compte quand l'attribution doit se justifier. Les contributions pondérées et les totaux sont des formules, et la sensibilité se fait en changeant une cellule de poids pour voir le classement se recalculer. Une mise en forme conditionnelle distingue la candidate de tête. Sous appel d'offres public, les plateformes de marchés comme simap.ch portent la même grille avec l'horodatage et la trace d'audit qu'exige la procédure.

Du côté acceptation, l'outil de gestion des exigences est le bon endroit: un critère consigné dans le compte rendu d'une séance se perd, alors que rattaché à l'exigence dans l'outil il suit ses changements, se retrouve à la recette et se relie aux cas de test qui le vérifient. Jira avec Xray ou Zephyr, Azure DevOps, Polarion et Jama tiennent cette traçabilité, du critère au cas de test puis au résultat d'exécution. Les outils de gestion de tests portent la campagne de recette elle-même et produisent le relevé des réussites et des échecs que le mandant ou le comité de pilotage signe.

Quand les critères sont rédigés en « étant donné, quand, alors », les outils de développement piloté par le comportement, Cucumber, SpecFlow ou Behave, les exécutent tels quels: le critère devient le test, et la question de savoir si le test correspond au critère disparaît. L'anti-outil est la grille de notation fournie par le candidat, qui pondère les attributs sur lesquels son offre est forte et présente une préférence commerciale comme une évaluation.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.1 Acceptance and Evaluation Criteria: la finalité des deux usages, la définition des attributs de valeur et leurs six familles d'exemples, la forme testable des critères d'acceptation, l'échelle continue ou discrète des critères d'évaluation, ainsi que les forces et les limites reconnues, dont la rigidité contractuelle et la difficulté d'obtenir un accord entre parties prenantes aux besoins divers.
• ISO/IEC/IEEE, ISO/IEC/IEEE 29148:2018, ingénierie des exigences: le caractère vérifiable parmi les propriétés d'une exigence bien formée, qui fonde la testabilité exigée d'un critère d'acceptation.
• ISO/IEC, ISO/IEC 25010:2023, modèle de qualité du produit logiciel: les définitions opérationnelles des qualités que le BABOK cite en exemple, pour les solutions logicielles, avec la capacité d'interaction en lieu et place de l'utilisabilité et l'évolutivité rangée sous la flexibilité.