On définit ce que 'bon' veut dire pour un usage donné.
Evals et fiabilité
Comprendre pourquoi les produits IA sérieux ont besoin d'évaluations continues et non de simples démos impressionnantes.
🫏 Commence par la BD, c'est plus rigolo ! 🫏 Cette notion existe aussi en BD 🫏 Cette notion existe aussi en BD « IA et le coup de chance » — lire l'histoire →
On crée un jeu de cas représentatifs et critiques.
On mesure les réponses, les refus, les citations, les délais ou la structure produite.
Une démo, c'est la story Insta. L'éval, c'est la vraie vie
- Une démo te montre le meilleur moment, comme un montage trop bien coupé d'un youtubeur. Ça cache les ratés.
- Une « éval », c'est un gros contrôle : on prépare plein de questions, faciles ET vicieuses, et on compte les réponses justes.
- On note pas juste « ça marche » : on vérifie l'exactitude, si l'IA refuse les trucs dangereux, si elle cite ses sources, si le format est bon.
- À chaque mise à jour, on rejoue tout le contrôle. Sinon une amélioration peut casser un autre truc sans qu'on le voie : c'est une « régression ».
Imagine un correcteur d'orthographe pour tes devoirs. En démo, il corrige trois phrases parfaites. Mais une vraie éval lui balance 500 phrases tordues, avec des mots rares et des pièges. C'est là qu'on voit s'il est vraiment fiable, pas juste impressionnant dans la pub.
Quand une appli IA te fait une démo qui claque, garde l'esprit critique : une démo est choisie pour briller. Avant de faire confiance pour un truc qui compte (un devoir, une info santé, un conseil), teste-la toi-même sur des cas que tu connais déjà. Si elle se plante sur ce que tu maîtrises, méfie-toi du reste.
Une moyenne flatteuse peut mentir : 95 % de réussite, ça veut dire 5 % d'échecs, et c'est peut-être là que sont les cas graves.
Mesure si « ça marche en démo » veut dire « c'est fiable »
On fait passer le modèle sur un jeu de tests et on lit le score. Change la difficulté (démo / réaliste / piégeux) pour voir la fiabilité chuter.
6 cas tests. Plus ils ressemblent au réel, plus la mesure est honnête.
Sous le capot Pour les curieux : ce qui se passe à l'intérieur
Tape pour explorer Replier
D'abord, on se met d'accord sur ce qui compte comme une bonne réponse
Avant de noter, la maîtresse explique ce qu'il faut faire : écrire proprement, donner la bonne réponse, dire "je ne sais pas" quand on ne sait pas. Si on ne sait pas ce qu'on note, la note ne veut rien dire ! L'IA c'est pareil : on décide d'abord ce qu'est une bonne réponse.
Des questions faciles, mais aussi des questions pièges
Pour bien tester un copain, on lui pose des questions faciles ET des questions très dures, même des questions piège. Si on ne pose que des questions trop faciles, on croit qu'il sait tout alors que non. On donne à l'IA plein d'exemples, du facile au super dur.
Une bonne moyenne peut cacher une grosse bêtise
Imagine que tu réussis 9 exercices sur 10, ta moyenne est super ! Mais l'exercice raté, c'était "ne touche pas le feu". Une belle moyenne peut cacher une grosse bêtise dangereuse. On regarde donc QUELLES réponses sont ratées, pas juste le total.
À chaque nouvelle version, on refait tous les tests
Quand tu apprends un nouveau truc, tu oublies parfois quelque chose que tu savais avant. Pour l'IA, c'est pareil : une nouvelle version peut mieux faire une chose mais en casser une autre. Alors on refait tous les exercices à chaque fois, pour repérer les bêtises avant les gens.
On fixe les critères avant de noter
Comme un barème de contrôle distribué à l'avance : exactitude, ton, sources citées, format attendu, et savoir refuser quand il le faut. Sans critères clairs (le "référentiel"), un score ne veut rien dire. On définit d'abord ce qu'est une bonne réponse pour cet usage précis.
Des cas réalistes ET des cas piégeux (adversariaux)
On rassemble des exemples vrais : les fréquents, mais aussi les cas limites et les cas "adversariaux" (pensés exprès pour piéger, comme un troll qui essaie de casser l'appli). Un jeu de tests trop propre donne une fausse confiance, exactement comme réviser seulement les exercices faciles avant un exam.
Le score moyen cache parfois un échec critique
On mesure plusieurs choses : exactitude, refus, temps de réponse, format. Mais 95 % de réussite peut cacher les 5 % qui contiennent un cas grave (par ex. donner un conseil dangereux). Comme une moyenne de 16 qui cache un zéro à l'épreuve éliminatoire : on regarde QUELS cas échouent, pas juste la moyenne.
On rejoue tous les tests à chaque version
Une régression, c'est quand une mise à jour améliore un point mais en casse un autre, comme un patch de jeu vidéo qui répare un bug et en introduit un nouveau. On relance tout le jeu de tests à chaque version pour attraper ces régressions avant qu'elles n'arrivent aux utilisateurs.
Qu'est-ce qu'une bonne réponse, pour cet usage ?
Avant de mesurer, il faut s'accorder sur les critères : exactitude, ton, citations, format, refus attendus. Sans définition claire, le score ne veut rien dire.
Des cas représentatifs… et piégeux
On rassemble des exemples réels : faciles, fréquents, mais aussi limites et adversariaux. Des tests trop propres donnent une fausse confiance.
Score global, mais aussi échecs critiques
On mesure plusieurs choses (exactitude, refus, délai, structure). Attention : une moyenne flatteuse peut masquer un cas grave isolé.
Rejouer à chaque version
Une nouvelle version peut améliorer un point et en casser un autre. On rejoue le jeu de tests pour attraper les régressions avant les utilisateurs.
L'analogie qui aide à retenir
Réussir une fois au tableau ne veut pas dire qu'on connaît tout son contrôle.
Une démo, c'est ta meilleure story Insta ; une éval, c'est regarder toute la pellicule, ratés compris.
Une démo montre le meilleur moment ; une éval regarde aussi les erreurs, les oublis et les cas difficiles.
Le coeur de l'idée
Pour faire confiance à la machine, on regarde plein de réponses, pas juste sa plus belle.
On fait confiance à une IA quand sa qualité est mesurée sur plein de cas, pas quand elle a juste fait une belle démo.
La confiance dans un produit IA vient d'une qualité mesurée, pas d'une impression de magie.
Le mécanisme, découpé étape par étape
On prépare plein de questions tests pour la machine : des faciles et des très dures.
On regarde ses réponses et on compte combien elle réussit.
Une démo montre son meilleur moment, comme un bon jour au tableau.
Une vraie vérif regarde aussi ses erreurs et les questions pièges.
Décide d'abord ce que veut dire une « bonne » réponse pour ton appli (juste, bien sourcée, bon format).
Rassemble plein de cas à tester : les faciles, les réalistes et les pièges.
Mesure les réponses : exactitude, refus quand il faut, sources citées, vitesse.
À chaque nouvelle version, rejoue tous tes tests pour vérifier que rien n'a cassé.
Définis ce que « bon » signifie pour ton usage : exactitude, ton, citations, format, refus attendus.
Constitue un jeu de cas représentatifs ET piégeux : fréquents, réalistes, limites et adversariaux.
Mesure plusieurs choses : exactitude, refus pertinents, citations correctes, format, délai.
Rejoue ce jeu de tests à chaque version pour détecter les régressions avant les utilisateurs.
Exemples très concrets Où tu retrouves ça dans le monde réel
Tape pour explorer Replier
Comme un contrôle de maths complet, pas juste un exercice où on a eu de la chance.
On lui pose plein de devinettes, même les plus difficiles, pour voir si elle se trompe.
Si elle range tes jouets, on vérifie tous les jouets, pas juste un seul bien rangé.
Tester un chatbot d'aide aux devoirs sur 100 questions pour voir s'il se trompe en maths comme en histoire.
Vérifier qu'une appli qui résume tes cours cite bien les bons passages et n'invente rien.
Contrôler qu'un filtre de modération d'un jeu en ligne bloque vraiment les insultes sans censurer tout le monde.
Vérifier qu'un assistant documentaire d'entreprise cite bien les bons passages des procédures.
Mesurer si une nouvelle version d'un copilote de code casse moins de cas que la précédente.
Contrôler qu'un agent de support respecte mieux les étapes de sécurité (vérification d'identité, escalade).
Points de vigilance Ce qu'il ne faut pas confondre
Tape pour explorer Replier
Une bonne note peut cacher une grosse erreur sur une question importante.
Si on pose juste des questions faciles, on croit qu'elle est super alors que non.
Il faut de vraies questions, pas seulement des questions trop simples.
Un score global flatteur peut masquer un échec grave et isolé.
Les tests doivent évoluer avec l'appli et de vrais exemples, pas rester figés.
Des cas trop propres donnent une fausse confiance ; il faut aussi des cas réels et piégeux.
Un score global peut cacher des échecs métier graves.
Les evals doivent vivre avec le produit, les données et les versions.
Il faut des cas réels et adversariaux, pas seulement des exemples trop propres.
Remplace les fausses idées par les bonnes
On corrige les réflexes faux que beaucoup gardent, pour ancrer une image mentale juste et solide.
On croit que si elle réussit une fois, elle réussit tout.
En vrai, il faut lui poser plein de questions pour en être sûr.
On croit qu'une belle démo veut dire qu'elle ne se trompe jamais.
En vrai, une belle démo montre juste son meilleur moment.
On croit qu'on vérifie une seule fois et c'est fini.
En vrai, il faut revérifier chaque fois qu'elle change.
« La démo était incroyable, donc l'appli est fiable. »
Une démo montre le meilleur moment. La fiabilité se prouve sur des centaines de cas, pièges compris.
« 95 % de bonnes réponses, c'est suffisant. »
Pas forcément. Les 5 % d'échecs peuvent être les cas les plus graves. Regarde QUELS cas ratent.
« On teste une fois et c'est bon pour toujours. »
Non. On rejoue les tests à chaque version et on en ajoute avec de vrais cas du quotidien.
« Si la démo est bluffante, le produit est fiable. »
Faux. Une démo montre le meilleur cas. La fiabilité se prouve sur beaucoup de cas, dont les pièges.
« Un bon score global suffit. »
Non. Une moyenne flatteuse peut cacher un échec métier grave et isolé. Il faut regarder les cas critiques.
« On fait les evals une fois, c'est réglé. »
Non. Les evals vivent avec le produit : on les rejoue à chaque version et on les enrichit avec de vrais cas.
À la fin, ce sont ces idées qui doivent rester
Si tu peux les redire sans relire la fiche, l'essentiel est acquis.
Réussir une fois ne veut pas dire qu'elle réussit toujours.
On en pose beaucoup, des faciles et des dures.
On regarde aussi quand elle se trompe.
À chaque fois qu'elle change, on reteste.
À la fin, ce sont ces idées qui doivent rester
Si tu peux les redire sans relire la fiche, l'essentiel est acquis.
La confiance vient des tests, pas d'une démo qui claque.
Mets aussi les questions difficiles, pas que les faciles.
95 % de réussite peut cacher 5 % de gros bugs graves.
Une nouvelle version peut casser ce qui marchait avant.
À la fin, ce sont ces idées qui doivent rester
Si tu peux les redire sans relire la fiche, l'essentiel est acquis.
La confiance vient d'une qualité mesurée.
Pas seulement des exemples trop propres.
Un échec grave isolé peut compter plus que le score global.
Pour attraper les régressions à temps.
Les questions qu'on se pose souvent
Des réponses courtes et claires, sans jargon, pour lever les doutes.
C'est quoi une « eval » ?
Un ensemble de tests qui mesurent, sur des cas précis, si le système répond vraiment bien — au-delà d'une simple démo.
Pourquoi pas juste une démo ?
Une démo montre le meilleur moment. Une éval regarde aussi les erreurs, les oublis et les cas difficiles, sur beaucoup d'exemples.
C'est quoi une régression ?
Quand une nouvelle version améliore un point mais en casse un autre. On rejoue les tests pour la détecter avant les utilisateurs.
Un score de 95 %, c'est fiable ?
Pas forcément. Les 5 % restants peuvent contenir des cas métier graves. Il faut regarder QUELS cas échouent, pas seulement la moyenne.
La suite, pensée comme une montée en compréhension
On monte d'un cran à chaque étape, toujours avec la même promesse de clarté.