Fiabiliser : mesurer plutôt que supposer
Passer de « ça a l’air de marcher » à « je sais que ça marche » : construire un jeu de cas, définir un critère de réussite, mesurer une modification, et détecter une régression avant les utilisateurs.
À la fin de ce chapitre, vous saurez
- Construire un jeu de cas de référence à partir de vos vrais échecs
- Choisir un critère de réussite vérifiable
- Mesurer l’effet d’une modification au lieu de l’estimer
- Détecter une régression avant vos utilisateurs
Dans ce chapitre
Tout le monde teste sur trois exemples, trouve que « ça marche bien », et déploie. Puis un utilisateur signale un cas raté, on ajuste l’instruction, ça répare — et ça casse ailleurs, sans que personne le voie.
Ce chapitre décrit la sortie de cette boucle. Il vaut autant pour une demande écrite dans l’application que pour un service en production : les mécanismes sont identiques, seule l’automatisation change.
Pourquoi l’intuition ne suffit pas
Trois raisons, indépendantes.
Vous testez sur les cas que vous avez en tête, c’est-à-dire les cas typiques. Les échecs se produisent sur les cas atypiques, ceux auxquels vous ne pensez pas.
Les modifications interagissent. Ajouter une contrainte au début d’une instruction change le comportement sur des cas sans rapport apparent. Sans mesure, cet effet est invisible.
Votre jugement dérive. Une réponse que vous auriez trouvée médiocre en janvier vous paraît correcte en mars, parce que vous vous êtes habitué. Sans critère écrit, il n’y a pas de point fixe.
La parade est toujours la même : un jeu de cas, un critère écrit, un score.
Construire le jeu de cas
C’est une après-midi de travail, et c’est le meilleur investissement de tout ce chapitre.
Vingt cas suffisent pour commencer. Cinquante sont confortables. Deux cents relèvent d’un service en production avec des enjeux réels.
La composition compte plus que le nombre.
| Part | Type | Rôle |
|---|---|---|
| 25 % | Cas faciles | Détecter les régressions grossières |
| 50 % | Cas ordinaires | Représenter l’usage réel |
| 25 % | Cas difficiles ou déjà ratés | C’est là que se joue la mesure |
Le dernier quart est celui qui vaut quelque chose. Un jeu composé uniquement de cas faciles donne 100 % en permanence et ne mesure rien.
Définir le critère de réussite
C’est l’étape que les gens sautent, et c’est celle qui décide de tout.
Trois familles, par ordre de fiabilité décroissante.
Le critère exact
La sortie doit valoir précisément quelque chose : une catégorie, un nombre, une valeur booléenne, un JSON conforme à un schéma.
C’est le cas idéal : la mesure est automatique, indiscutable, instantanée. Chaque fois que vous pouvez ramener une tâche à une sortie contrainte — voir le chapitre 7 —, vous gagnez la capacité de la mesurer.
La liste de critères vérifiables
La sortie est un texte libre, mais on peut lister ce qu’elle doit contenir et ce qu’elle ne doit pas contenir.
Pour un compte rendu de réunion :
- Contient une section « décisions » — oui / non
- Chaque action a un responsable nommé — oui / non
- Ne contient aucun nom absent de la transcription — oui / non
- Fait moins d’une page — oui / non
- N’emploie pas la première personne — oui / non
Cinq critères binaires donnent un score sur cinq, reproductible, et défendable devant un tiers. C’est le format à privilégier dans la grande majorité des cas.
L’évaluation par un modèle
Un second appel à Claude évalue la sortie du premier. Utile quand la qualité est irréductible à une liste — le ton, la pertinence, la fluidité.
Trois conditions pour que ce soit sérieux.
Donnez une grille, pas une note globale. « Note sur dix » ne vaut rien. « Ces cinq critères sont-ils respectés, un par un, avec justification » vaut quelque chose.
Étalonnez l’évaluateur. Faites-le noter vingt cas que vous avez notés vous-même. S’il est d’accord avec vous quinze fois sur vingt, il est utilisable avec prudence. Cinq fois sur vingt, il ne mesure rien.
Ne l’utilisez pas seul sur les décisions importantes. Il détecte les tendances, il ne remplace pas une relecture.
Mesurer une modification
Le protocole tient en cinq lignes, et il est le même pour une instruction écrite à la main que pour un service.
- Faire tourner la version actuelle sur le jeu complet. Noter le score : c’est le point de référence.
- Faire une seule modification.
- Rejouer le jeu complet.
- Comparer, cas par cas — pas seulement le total.
- Garder ou revenir en arrière.
Deux points sur lesquels tout se joue.
Une modification à la fois. Si vous en faites trois et que le score monte, vous ne savez pas laquelle a servi, et vous en gardez peut-être une qui nuit.
Cas par cas, pas seulement le total. Un score qui passe de 78 à 80 peut cacher cinq cas améliorés et quatre cassés. Ce sont ces quatre-là qui vous intéressent : ils désignent l’effet de bord.
Détecter une régression
Une fois le jeu constitué, il sert à trois moments.
Quand vous modifiez une instruction. Le protocole ci-dessus.
Quand vous changez de modèle. C’est le moment où le jeu de cas prend toute sa valeur. Un modèle plus récent est généralement meilleur en moyenne, et pas nécessairement sur votre tâche : les instructions rédigées pour contourner une faiblesse ancienne deviennent parfois contre-productives. Rejouer le jeu avant de basculer prend une heure et évite une découverte publique.
Périodiquement, sans rien changer. Le monde bouge : vos entrées changent de nature, vos documents de référence vieillissent. Une exécution mensuelle du jeu, sur un service qui compte, révèle les dérives lentes.
Fiabiliser un tri de demandes entrantes
La situation
Un service client trie automatiquement les demandes entrantes en six catégories. Le tri fonctionne « plutôt bien », mais personne ne sait à quel point, et chaque ajustement se fait à l’aveugle.
Le jeu de cas
Trois cents demandes réelles du mois précédent, catégorisées à la main par deux personnes du service. Les vingt-deux cas de désaccord entre les deux relecteurs ont été discutés, puis conservés à part : ce sont les cas ambigus, et ils révèlent que la définition des catégories était floue. Corriger la définition a été le premier gain, avant toute modification de la demande.
Critère exact : la catégorie prédite est-elle la bonne. Score de départ : 84 %.
Ce que la mesure a révélé
L’analyse cas par cas montre que les erreurs ne sont pas réparties. Deux catégories concentrent 70 % des échecs, et pour une raison précise : leurs définitions se recouvrent partiellement.
Personne ne l’aurait vu sur un score global.
Les modifications
Une seule à la fois, chacune rejouée sur les trois cents cas.
Préciser la frontière entre les deux catégories confuses, avec deux exemples contrastés : 84 → 91 %.
Ajouter une catégorie « autre » avec obligation de justifier : 91 → 93 %, et surtout, les erreurs restantes deviennent visibles au lieu d’être rangées de force.
Demander la catégorie avant la justification plutôt qu’après : 93 → 92 %. Modification annulée — c’est exactement le genre de conclusion qu’on ne peut pas obtenir à l’intuition, et qui contredit la règle générale du raisonnement avant la conclusion.
Le suivi
Le jeu tourne chaque nuit. Un mois plus tard, le score chute à 88 % : une nouvelle offre commerciale a généré un type de demande qui n’existait pas dans le jeu. Détecté en une nuit, corrigé en une heure, et vingt nouveaux cas ajoutés au jeu.
Sans la mesure, la dérive aurait été découverte par un client mécontent.
Ce qu’il faut retenir
Vérifier que c’est passé
3 questions. Rien n’est enregistré, rien n’est envoyé : c’est pour vous.
Vos vingt cas
Prenez une tâche que vous confiez régulièrement à Claude. Rassemblez vingt entrées réelles : cinq faciles, dix ordinaires, cinq qui ont déjà mal fonctionné. Pour chacune, écrivez trois à cinq critères vérifiables par oui ou non. Faites tourner votre demande actuelle sur les vingt et notez le score. C’est votre point de référence — tout ce que vous ferez ensuite se mesurera contre lui.
Un indice, si vous bloquez
Les cinq cas qui ont mal fonctionné valent les quinze autres réunis. Si vous n’en avez pas, c’est que vous ne relisez pas assez.