Construire un jeu de tests en une journée

Un jeu de tests permet de décider un changement de modèle, un changement de palier ou une modification de prompt en deux heures au lieu d'un projet. C'est le seul investissement dont le rendement croît avec le temps.

Sans lui, chaque évolution devient une discussion d'opinion. Quelqu'un trouve que c'est mieux, quelqu'un d'autre trouve que non, et la décision se prend au grade plutôt qu'aux chiffres.

Avec lui, la même question se tranche : on relance, on compare, on décide. Le coût d'entrée est une journée. Le gain se reprend à chaque génération de modèle, soit deux à trois fois par an, indéfiniment.

Question, réponse attendue, source, seuil : ces quatre colonnes suffisent, et chacune traite un problème distinct. Retirer l'une d'elles rend le jeu inexploitable.

La question doit être formulée comme un utilisateur réel la poserait, avec ses approximations. Une question bien rédigée par l'équipe technique ne teste rien : elle mesure la performance sur un cas qui ne se produira pas.

La réponse attendue est le point le plus exigeant. Elle doit être suffisamment précise pour qu'on puisse trancher automatiquement, ou à défaut en dix secondes de lecture. « Une bonne réponse » n'est pas une réponse attendue.

La source indique le document d'où l'information doit provenir. Elle permet de distinguer deux échecs très différents : le système n'a pas trouvé le bon document, ou il l'a trouvé et a mal répondu. Ce sont deux corrections opposées.

Le seuil fixe le taux d'erreur acceptable pour cette famille de questions. Il transforme un résultat en décision.

Un jeu de tests qui n'est pas alimenté par les incidents réels se périme en trois mois. Le mécanisme d'alimentation compte autant que le jeu initial.

La règle que j'applique est unique et tient en une phrase : toute réponse fausse signalée par un utilisateur devient une ligne du jeu de tests, le jour même. Pas d'analyse, pas de réunion, juste l'ajout.

Ce réflexe a deux effets. Le jeu grossit exactement là où le système est faible, ce qui est la seule croissance utile. Et il devient impossible de réintroduire une erreur déjà corrigée, ce qui est le bénéfice le plus sous-estimé.

J'ajoute une limite haute : au-delà de cent cinquante cas, le jeu devient long à relancer et cesse d'être utilisé. Il faut alors le scinder par famille de tâches, ce qui rejoint le routage décrit dans Claude 3 : choisir le palier.

Une fois le jeu constitué, quatre décisions qui prenaient des semaines se prennent en une demi-journée. C'est ce qui justifie la journée d'investissement initial.

Changer de modèle devient une comparaison mesurée plutôt qu'un pari. Descendre de palier pour économiser devient une décision instruite. Modifier le prompt système cesse d'être un jeu de hasard où l'on corrige un cas en en cassant deux autres. Et arbitrer entre récupération et fenêtre longue devient une question de chiffres.

Ces quatre décisions reviennent en permanence sur un système en exploitation. Une équipe qui les traite en une demi-journée avance ; une équipe qui les traite en réunion recule.

C'est pour cette raison que je considère le jeu de tests comme le premier livrable d'un projet, avant même la première réponse correcte. Le cadre complet figure dans l'évaluation continue.

« Nos réponses ne sont pas vérifiables automatiquement, donc un jeu de tests est impossible » : c'est l'objection la plus fréquente, et elle est fausse dans la quasi-totalité des cas. Elle confond vérification automatique et vérification rapide.

Beaucoup de réponses ne se comparent pas caractère par caractère. Mais presque toutes se vérifient en dix secondes de lecture par quelqu'un qui connaît le domaine. Trente cas relus en cinq minutes constituent un jeu de tests parfaitement exploitable.

J'ajoute un intermédiaire utile : vérifier automatiquement ce qui est vérifiable, le document cité, la présence d'un chiffre, l'absence de refus, et relire à la main le reste. Voir mesurer l'adoption, pas la satisfaction.