Une devinettePour commencerCas d'ouverture
Réfléchis une secondeEssaie de répondrePosez votre intuition
Ton copain te trouve une fois à cache-cache. Est-ce qu'il est vraiment fort, ou il a eu de la chance ?
Pense à ta réponse, même si tu n'es pas sûr. La suite te dira si tu avais vu juste.
Un correcteur d'orthographe corrige trois phrases parfaites en démo. Que se passe-t-il face à 500 phrases tordues ?
Prends dix secondes pour répondre dans ta tête. Tu compareras avec la suite.
Trois exemples passent parfaitement en réunion. Qu'est-ce qui vous dit que l'assistant tiendra face aux 300 vraies questions de vos clients ?
Formulez d'abord votre réponse, même approximative : la comparer à la suite fixe bien mieux les acquis.
Regarde ça bougerVois-le en actionLe concept en mouvement
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.
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.
Comment ça marcheComment ça marcheLa mécanique
Une étape à la foisLe mécanisme, étape par étapeLe mécanisme, étape par étape
Réussir une fois, ça compte pas vraiment
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.
Une démo, c'est la story Insta. L'éval, c'est la vraie vie
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é.
Une démo bluffante ne prouve pas un produit fiable
Définissez ce que « bon » signifie pour votre usage : exactitude, ton, citations, format, refus attendus.
Constituez un jeu de cas représentatifs ET piégeux : fréquents, réalistes, limites et adversariaux.
Mesurez plusieurs choses : exactitude, refus pertinents, citations correctes, format, délai.
Rejouez ce jeu de tests à chaque version pour détecter les régressions avant les utilisateurs.
Des exemples pour toiDes exemples concretsExemples concrets
Tu l'as déjà croiséOù tu le retrouvesOù vous le retrouvez en situation
Un exemple pour toi
C'est comme une devinette à la récré. Si ton copain devine une seule fois où tu te caches, ça ne prouve rien. Mais s'il te trouve à chaque cache-cache, dans plein d'endroits différents, là tu sais qu'il est vraiment fort !
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é.
Cas concret
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.
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.
Cas concret
Vous déployez un assistant qui répond aux clients par e-mail à partir de votre base documentaire. En réunion, trois exemples passent nickel. Mais une éval sérieuse lui soumet 300 vraies questions, dont des cas limites (clients agressifs, demandes hors périmètre, questions juridiques sensibles). C'est là qu'on découvre s'il invente des réponses ou s'il cite les bons documents.
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).
Attention aux piègesÀ éviterÀ éviter
Ce qu'on croit, et ce qui est vraiIdées reçues et pièges à éviterIdées reçues et risques à anticiper
-
On croit que
On croit que si elle réussit une fois, elle réussit tout.
En vrai
En vrai, il faut lui poser plein de questions pour en être sûr.
-
On croit que
On croit qu'une belle démo veut dire qu'elle ne se trompe jamais.
En vrai
En vrai, une belle démo montre juste son meilleur moment.
-
On croit que
On croit qu'on vérifie une seule fois et c'est fini.
En vrai
En vrai, il faut revérifier chaque fois qu'elle change.
Les pièges à retenir
- 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.
-
On croit que
« La démo était incroyable, donc l'appli est fiable. »
En réalité
Une démo montre le meilleur moment. La fiabilité se prouve sur des centaines de cas, pièges compris.
-
On croit que
« 95 % de bonnes réponses, c'est suffisant. »
En réalité
Pas forcément. Les 5 % d'échecs peuvent être les cas les plus graves. Regarde QUELS cas ratent.
-
On croit que
« On teste une fois et c'est bon pour toujours. »
En réalité
Non. On rejoue les tests à chaque version et on en ajoute avec de vrais cas du quotidien.
Les pièges à retenir
- 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.
-
Idée reçue
« Si la démo est bluffante, le produit est fiable. »
Réalité
Faux. Une démo montre le meilleur cas. La fiabilité se prouve sur beaucoup de cas, dont les pièges.
-
Idée reçue
« Un bon score global suffit. »
Réalité
Non. Une moyenne flatteuse peut cacher un échec métier grave et isolé. Il faut regarder les cas critiques.
-
Idée reçue
« On fait les evals une fois, c'est réglé. »
Réalité
Non. Les evals vivent avec le produit : on les rejoue à chaque version et on les enrichit avec de vrais cas.
Points de vigilance
- 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.
Ce que je retiensÀ retenirÀ retenir
L'essentiel, en quatre idéesL'essentiel, en quatre idéesL'essentiel, en quatre points
La phrase à garder
Pour faire confiance à la machine, on regarde plein de réponses, pas juste sa plus belle.
- Pas qu'un bon jour Réussir une fois ne veut pas dire qu'elle réussit toujours.
- Plein de questions On en pose beaucoup, des faciles et des dures.
- On compte les ratés On regarde aussi quand elle se trompe.
- On revérifie souvent À chaque fois qu'elle change, on reteste.
La phrase à garder
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.
- Mesurer, pas frimer La confiance vient des tests, pas d'une démo qui claque.
- Des cas qui piègent Mets aussi les questions difficiles, pas que les faciles.
- La moyenne ment 95 % de réussite peut cacher 5 % de gros bugs graves.
- Rejouer à chaque maj Une nouvelle version peut casser ce qui marchait avant.
Message clé
La confiance dans un produit IA vient d'une qualité mesurée, pas d'une impression de magie.
- Mesurer, pas impressionner La confiance vient d'une qualité mesurée.
- Des cas réels et piégeux Pas seulement des exemples trop propres.
- Moyenne ≠ sécurité Un échec grave isolé peut compter plus que le score global.
- Rejouer à chaque version Pour attraper les régressions à temps.
Je m'entraîneJe valideÉvaluation
Je teste ce que j'ai comprisJe teste ce que j'ai comprisValidez vos acquis
Valider : Evals et fiabilité
4 questions. Il faut 70 % de bonnes réponses pour maîtriser la fiche. Tu as le droit de te tromper et de réessayer.
Pour les curieuxPour aller plus loinPour aller plus loin
Si tu veux en savoir plusCreuser le sujetApprofondir et poursuivre
Sous le capot, pour les curieux
C'est quoi "réussi" ?
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.
Plein d'exercices
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.
La moyenne ment
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.
On recommence
À 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.
Sous le capot
Définir le "bon"
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.
Jeu de tests
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.
Mesure
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.
Non-régression
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.
Sous le capot : les briques techniques
Définir le « bon »
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.
Jeu de tests
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.
Mesure
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é.
Non-régression
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.
Les questions que tu te poses peut-être
- Est-ce que la machine peut se tromper ?
- Oui ! Comme toi parfois en classe. C'est justement pour ça qu'on lui fait passer plein d'exercices : pour voir où elle se trompe et l'aider à faire mieux.
- Elle est plus forte que moi ?
- Sur certaines choses elle va très vite, mais elle fait aussi des fautes. Toi tu réfléchis pour de vrai. Et c'est toujours une grande personne qui vérifie ses réponses.
- Pourquoi on lui pose autant de questions ?
- Parce qu'une seule bonne réponse, ça ne suffit pas pour être sûr. Comme un gâteau : il faut goûter plusieurs fois pour savoir s'il est toujours bon !
Questions fréquentes
- 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.
Pour continuer
-
Lis l'histoire en BD, c'est plus rigoloCette notion existe aussi en BDCette notion existe aussi en BD IA qui réfléchit tout haut - Fiche à suivre Fine-tuning et alignement Pour mesurer si l'adaptation améliore vraiment le comportement.
- Fiche à suivre Latence, coût et cache Parce qu'un système fiable doit aussi être rapide et abordable.
- Fiche à suivre Agents vs workflows Pour évaluer aussi les systèmes plus autonomes (Niveau 2).
SourcesSourcesSources vérifiées