Le jeu d’évaluation porte tout le reste
Sans jeu d’évaluation, une équipe ne peut répondre à aucune des questions qui décident d’un projet. Le système est-il assez bon pour être mis en service. La modification d’hier a-t-elle amélioré ou dégradé quelque chose. Le changement de version annoncé par le fournisseur va-t-il casser un usage. Ces trois questions n’ont pas de réponse fondée sur une impression, et l’impression est pourtant ce sur quoi beaucoup d’équipes s’appuient pendant des mois. Un jeu d’évaluation est un ensemble de cas réels, issus de l’organisation, avec la réponse attendue établie par les personnes dont le jugement fait autorité. Sa construction est la partie du travail qui produit le plus de valeur et celle qu’on cherche le plus souvent à abréger, parce qu’elle consomme le temps de personnes occupées. Elle en produit deux fois : une première fois comme instrument de mesure, et une seconde, moins évidente, parce que la discussion sur ce qu’est une bonne réponse fait remonter des désaccords internes qui, sinon, seraient apparus trois mois plus tard sous la forme d’un système jugé mauvais.
Le construire : peu de cas, bien choisis
L’instinct pousse à en vouloir beaucoup et le rendement décroît vite. Cinquante à deux cents cas réels suffisent à mesurer utilement la plupart des systèmes, à condition que leur choix soit réfléchi plutôt qu’aléatoire.
Trois catégories doivent être représentées. Les cas courants, qui font le volume. Les cas difficiles, ceux sur lesquels une personne expérimentée hésite. Et les cas hors domaine, où la bonne réponse est de reconnaître qu’on ne sait pas, ce que la plupart des jeux oublient complètement.
L’étiquetage revient aux personnes dont le jugement fait autorité, et cette partie n’est pas délégable à l’équipe technique. Un jeu étiqueté par quelqu’un qui ne connaît pas le métier mesure la conformité à une intuition extérieure, ce qui donne des chiffres flatteurs et sans valeur.
La valeur cachée de sa construction
La discussion sur les cas ambigus est, dans beaucoup de projets, le moment où l’on découvre que deux services ne s’accordent pas sur ce qui constitue une bonne réponse. Cette découverte est inconfortable et elle vaut mieux maintenant que dans six mois.
Sans cette discussion, le désaccord ne disparaît pas, il ressurgit sous une forme méconnaissable : un service affirme que le système ne fonctionne pas, l’autre trouve qu’il fonctionne bien, et l’équipe technique passe des semaines à chercher un défaut qui n’existe pas.
C’est pourquoi le jeu d’évaluation se construit avant le système et non après. Il définit ce que l’on cherche à obtenir, et cette définition est le vrai livrable des premières semaines.
La moyenne cache l’échec qui compte
Un chiffre global de justesse est utile pour communiquer et dangereux pour décider. Il peut rester parfaitement stable pendant qu’une catégorie précise s’effondre.
Or les catégories n’ont pas le même poids. Un système qui se dégrade sur les dossiers du plus gros client, ou sur la classe de cas la plus sensible réglementairement, pose un problème que sa bonne tenue ailleurs ne compense pas.
Les résultats se lisent donc par catégorie, avec un seuil par catégorie plutôt qu’un seuil global. Cette lecture demande d’avoir défini les catégories au moment de construire le jeu, ce qui est une raison de plus de le faire avec le métier.
Le juger automatiquement, avec prudence
Sur les tâches dont la sortie est structurée, un champ extrait, une catégorie attribuée, un montant, la comparaison à l’étiquette est mécanique et le jeu se rejoue sans intervention humaine. C’est le cas confortable et il couvre davantage de projets qu’on ne le croit.
Sur les tâches dont la sortie est du texte libre, la comparaison exacte n’a pas de sens et la tentation est de confier le jugement à un modèle. Cela fonctionne, avec une réserve qui mérite d’être énoncée : le juge partage les angles morts de ce qu’il évalue, et il note indulgemment ce qui est bien écrit. Un système éloquent et faux obtient une bonne note.
La pratique raisonnable consiste à faire juger automatiquement l’ensemble et à faire relire par une personne un échantillon fixe à chaque exécution, une vingtaine de cas. L’écart entre les deux jugements se surveille comme n’importe quel indicateur : tant qu’il reste stable, la mesure automatique est fiable ; quand il s’écarte, c’est elle qu’il faut réviser et non le système.
Comment il s’éloigne du réel
Un jeu d’évaluation vieillit, et il vieillit sans prévenir. Trois mécanismes y contribuent, et aucun n’est visible dans les chiffres qu’il produit.
De nouvelles catégories de cas apparaissent, parce que l’activité change, et le jeu continue de mesurer un monde qui n’existe plus. Les cas qu’il contient deviennent connus de l’équipe, qui finit par optimiser pour eux sans le vouloir. Et les étiquettes elles-mêmes peuvent cesser d’être justes si une règle métier évolue.
L’entretien est modeste et doit être prévu : ajouter régulièrement des cas récents, retirer ceux qui ne représentent plus rien, et faire relire les étiquettes une fois par an. Une organisation qui tient cette discipline conserve la main sur ses systèmes. Une organisation qui construit le jeu une fois et l’oublie mesure, deux ans plus tard, quelque chose dont plus personne ne sait ce que c’est.
