Comment je juge un système d'IA avant de le laisser sortir.

En 2023, sur un chantier IA, on avait jugé un POC sur un modèle, puis on en a changé pour la suite. Les réponses ont perdu en pertinence et la formulation s'est dégradée. Je n'avais pas d'eval pour le détecter. Les dégâts ont été limités à cinq utilisations, sans impact business, parce qu'on relisait encore les réponses à la main ; sans cette relecture, il aurait fallu attendre qu'un client le remonte.

On a corrigé vite : evals posées, instructions reprises. La conviction qui m'en reste gouverne tout ce que je fais depuis : sans jeu de cas, tout changement devient un pari. Un changement de modèle, une reformulation d'instructions, une mise à jour des données : chacun peut dégrader le système sans que rien ne l'annonce.

La base : 50 à 100 cas réels, tirés de vos vraies situations, annotés par vos experts métier. Pas des exemples inventés pour la démonstration : des cas qui portent les ambiguïtés, les exceptions et le vocabulaire de votre terrain. C'est long à constituer, et c'est exactement pour ça que ça a de la valeur.

L'annotation elle-même est un révélateur. Si deux de vos experts ne sont pas d'accord sur ce qu'est une bonne réponse, aucune eval ne rattrapera ça, et aucun modèle non plus : le problème n'est pas mûr pour l'IA. C'est la première chose que je regarde, avant toute considération technique.

Chaque réponse du système reçoit un verdict : correct, incomplet, faux, ou dangereux. La distinction entre faux et dangereux est le cœur de la grille : une réponse fausse se corrige, une réponse dangereuse, celle qui expose votre client ou votre responsabilité, décide du périmètre.

Le taux de « dangereux » détermine ce que le système a le droit de faire et ce qu'on écrit dans ses instructions, avant tout choix de modèle. Les seuils d'acceptation viennent après, et ils ne se fixent pas entre techniciens : ils se décident avec le métier et, dans les secteurs régulés, avec le juridique.

Le jeu de cas sert deux fois. D'abord pour décider de la sortie : la qualité permet-elle de mettre le système devant vos clients, sur quel périmètre, avec quels garde-fous. Ensuite comme filet permanent : après chaque changement de modèle, d'instructions ou de données, on rejoue les cas et on compare. Ce qui était un pari devient une lecture de résultats.

Et le jeu de cas reste chez vous. C'est ce qui s'est passé chez iAdvize : l'assistant RAG des conseillers comme les widgets d'IA générative ont été jugés sur cas réels annotés avant et après chaque évolution. C'est aussi ce qui reste quand je pars : vos équipes savent faire tourner la méthode sans moi.

La méthode mesure, elle ne crée pas la faisabilité : celle-ci vient de la tâche et du corpus. Si votre documentation ne contient pas la réponse, aucune génération ne l'inventera correctement. Si la tâche demande un jugement que vos propres experts ne formalisent pas, le système ne le formalisera pas non plus.

Et certains problèmes n'ont simplement pas besoin d'IA : chez APRIL, le parcours de souscription est passé de trois semaines à dix minutes sans un seul modèle dans la boucle. Décider si le problème relève de l'IA, c'est l'étape d'avant : celle du cadrage.