Voici un scénario que nous observons constamment. Une équipe construit un flux de travail d’IA — rédaction de contenu, classification des demandes d’assistance ou génération d’e-mails commerciaux. Il fonctionne bien la première semaine. L’équipe est ravie et le déploie.
Trois mois plus tard, quelque chose semble dérailler. La qualité des résultats baisse, les clients se plaignent et les équipes commerciales cessent de l’utiliser. Personne ne sait quand ni pourquoi la situation a changé.
La cause est presque toujours la même : personne ne mesurait les performances. Le flux de travail qui fonctionnait la première semaine a pu se détériorer progressivement, le modèle sous-jacent a pu changer, les prompts dériver ou la distribution des données d’entrée évoluer. Sans mesure, vous ne découvrez le problème que lorsque les utilisateurs se plaignent — et, à ce stade, leur confiance est déjà entamée.
La solution consiste à mettre en place des évaluations — une mesure systématique de la qualité des résultats produits par l’IA. Elles sont généralement considérées comme un sujet réservé à l’ingénierie, mais toute équipe qui utilise des flux de travail d’IA en a besoin. Leurs principes fondamentaux sont par ailleurs accessibles sans écrire de code.
Cet article explique ce que sont les évaluations, pourquoi elles sont importantes et comment les mettre en place pour n’importe quel flux de travail d’IA sans être ingénieur.
Les évaluations ne sont pas un exercice de compte rendu sans conséquence. Une évaluation utile conduit à une décision : déployer, suspendre, revenir en arrière ou enquêter. Si un score ne peut pas modifier l’action de l’équipe, simplifiez l’évaluation jusqu’à ce qu’il le puisse.
Ce que sont les évaluations (et ce qu’elles ne sont pas)
Une évaluation permet de mesurer systématiquement la qualité des résultats de votre IA par rapport à des exemples que vous maîtrisez.
Les composants :
- Un jeu de données. Un ensemble d’entrées (les éléments que votre IA traite).
- Un comportement attendu. Ce que vous souhaitez que l’IA fasse avec ces entrées.
- Une méthode de notation. La manière de déterminer si l’IA a correctement exécuté la tâche.
- Une exécution et un rapport. Le jeu de données est traité, chaque résultat est noté, puis les conclusions sont synthétisées.
L’objectif est de pouvoir poser de manière reproductible la question suivante : « L’IA fait-elle ce que j’attends, avec le niveau de qualité requis ? » — et de repérer tout changement dans la réponse.
Les évaluations ne sont pas :
- Des tests ponctuels pendant la phase de construction initiale.
- Des vérifications ponctuelles quand quelque chose semble dérailler.
- Des retours d’utilisateurs (utiles, mais réactifs, lents et biaisés).
- De simples impressions (« le résultat semble correct »).
De véritables évaluations sont exécutées à intervalles réguliers, sur un ensemble défini d’entrées et selon une notation cohérente. Elles fournissent un signal même lorsque personne ne se plaint.
Pourquoi les outils destinés aux ingénieurs sont inadaptés à la plupart des équipes
Si vous recherchez « évaluations de LLM » sur Google, vous trouverez des articles sur des outils tels que Promptfoo, LangSmith, Braintrust ou Helicone. Ces outils sont excellents, mais ils sont conçus pour les ingénieurs qui déploient à grande échelle des produits fondés sur des LLM.
Pour la plupart des équipes qui utilisent des flux de travail d’IA — marketing, vente, opérations ou assistance — ces outils sont trop complexes. Il faut une solution plus simple : une manière de mesurer un flux de travail précis sans devoir maîtriser toute une chaîne d’outils.
La bonne nouvelle : avec une feuille de calcul et un LLM, vous pouvez le faire. Pas aussi sophistiqué que LangSmith, mais suffisamment pour détecter la plupart des problèmes de qualité.
Les quatre modèles d’évaluation
Il existe quatre modèles d’évaluation courants. Chacun convient à un type de flux de travail différent.
Modèle 1 : Correspondance exacte
Utilisez-le lorsque la réponse correcte est unique.
Exemple de flux de travail : classer les demandes d’assistance client en huit catégories.
Jeu de données : 50 demandes associées à leur catégorie correcte. Notation : la réponse de l’IA correspond à la catégorie correcte (1 point) ou non (0 point). Résultat : pourcentage de réponses correctes.
Cela fonctionne bien pour la classification, l’extraction, les sorties structurées simples.
Modèle 2 : Comparaison avec un modèle de référence
Utilisez-le lorsque vous avez une réponse connue à laquelle comparer.
Exemple de flux de travail : rédiger des descriptions de produits.
Jeu de données : 30 produits avec des “descriptions de référence” que vous avez écrites. Notation : dans quelle mesure la description de l’IA correspond-elle à la référence selon des critères tels que l’exactitude, le ton et l’exhaustivité ?
Vous pouvez effectuer cette notation manuellement (une personne lit les deux textes et leur attribue une note de 1 à 5) ou à l’aide d’un LLM utilisé comme juge (modèle suivant). La comparaison avec une référence de qualité constitue la méthode de référence pour les flux de travail éditoriaux.
Modèle 3 : LLM comme juge
Utilisez-le lorsque le résultat peut prendre de nombreuses formes valides, mais que sa qualité reste évaluable.
Exemple de flux de travail : générer des e-mails commerciaux personnalisés.
Jeu de données : 30 profils de prospects. Notation : un LLM joue le rôle de juge — à partir de l’entrée et du résultat, il attribue des notes selon des critères tels que la précision du contenu, le professionnalisme, la longueur et le respect du ton.
L’utilisation d’un LLM comme juge est puissante, mais exige une conception rigoureuse du prompt. Voici un modèle courant :
You are evaluating a sales email for quality. Score it on these dimensions:
1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?
For each dimension, give the score and a one-sentence reason.
Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}
Prospect profile: [input]
Email to evaluate: [output]
Le LLM utilisé comme juge offre une cohérence difficile à atteindre avec des évaluateurs humains : un seul modèle, un seul prompt et une application uniforme. Toutefois, un juge qui n’a jamais été vérifié ne fournit qu’un second avis de qualité inconnue. Il faut donc l’étalonner correctement avant de l’utiliser :
- Prenez 50 exemples que votre équipe a déjà étiquetés (réussite/échec ou note selon votre échelle). Réutilisez des cas réels issus de votre file d’attente d’évaluation ; n’inventez pas de cas synthétiques.
- Appliquez le juge aux mêmes 50 exemples et mesurez le taux de concordance. Au-delà d’environ 85 %, vous pouvez lui confier les contrôles courants tout en maintenant une vérification humaine sur un échantillon. Entre environ 70 % et 85 %, examinez chaque désaccord : la grille d’évaluation est presque toujours trop vague ; précisez-la, puis relancez le test. En dessous d’environ 70 %, le juge mesure autre chose que votre équipe ; ne lui confiez aucune décision automatisée.
- Examinez la direction des erreurs, pas seulement leur taux. Un juge qui accepte de mauvais résultats est dangereux ; un juge qui rejette de bons résultats est seulement contraignant. Définissez votre seuil en conséquence.
- Réétalonnez le juge sur 20 à 30 nouveaux exemples chaque fois que vous changez le modèle, le prompt ou la grille d’évaluation — chacun de ces changements peut modifier silencieusement le taux de concordance.
Ces plages constituent notre protocole de départ recommandé, et non une loi universelle. Le point non négociable est que l’étalonnage ait lieu avant que les scores du juge ne déclenchent une quelconque action.
Modèle 4 : Vérification de propriété
Utilisez-le lorsque vous pouvez traduire la notion de « bon résultat » en propriétés précises et vérifiables.
Exemple de flux de travail : générer des titres de produits pour une boutique en ligne.
Jeu de données : 50 produits. Propriétés à vérifier sur chaque sortie :
- Longueur de 30 à 70 caractères.
- Inclut le nom de la marque.
- Inclut au moins l’un des attributs clés du produit.
- N’utilise aucun terme marketing interdit (« extraordinaire », « meilleur », « révolutionnaire »).
Chaque propriété donne lieu à un test binaire. Le score correspond au pourcentage de propriétés respectées sur l’ensemble des résultats.
Les vérifications de propriétés conviennent parfaitement aux contraintes structurées qui doivent toujours être respectées. Rapides à exécuter, elles détectent des dérives précises.
Comment mettre en place votre première évaluation
Voici une configuration pratique et accessible aux non-ingénieurs :
Étape 1 : Choisir le flux de travail
Choisissez un seul flux de travail. Ne tentez pas de tout évaluer à la fois. Retenez celui dont la qualité vous préoccupe le plus ou celui qui a le plus d’impact.
Exemple : « l’IA qui classe par sujet les demandes d’assistance client entrantes ».
Étape 2 : Construire le jeu de données
Créez une liste de 20 à 50 exemples représentatifs. Incluez :
- Des cas faciles (qui relèvent clairement de la catégorie A).
- Des cas difficiles (pourraient être A ou B).
- Des cas limites (qui ne correspondent clairement à aucune catégorie).
- Des variations courantes (différentes formulations de la même intention).
Consignez-les dans une feuille de calcul ou dans Google Sheets :
| ID | Entrée | Sortie attendue |
|---|---|---|
| 1 | « Mon mot de passe ne fonctionne pas » | « accès-compte » |
| 2 | « Je veux annuler mon abonnement » | « facturation » |
| 3 | « Votre dernière mise à jour a perturbé mon flux de travail » | « bug » |
| … | … | … |
Ce jeu de données est votre ensemble d’évaluation. Il ne devrait pas changer souvent — son objectif est d’être une référence stable.
Étape 3 : Définir la notation
Pour chaque exemple, qu’est-ce qui compte comme une réponse correcte ? Soyez précis.
Pour la classification : correspondance exacte sur la catégorie. Pour le contenu : une note de 1 à 5 sur chacune de 2 à 4 dimensions nommées. Pour l’extraction : chaque champ correct/incorrect.
Formalisez la grille de notation, puis appliquez-la de manière cohérente.
Étape 4 : Exécuter le flux de travail sur le jeu de données
Exécutez votre flux de travail d’IA sur chaque exemple du jeu de données. Consignez le résultat dans une nouvelle colonne.
Pour la classification, vous pouvez utiliser une fonction telle que l’intégration GPT de Google Sheets ou effectuer des copier-coller manuels.
Pour les flux de travail plus complexes, importez les entrées dans un outil tel que Promptfoo ou exécutez simplement un traitement par lots une fois par semaine.
| ID | Entrée | Attendu | Réel |
|---|---|---|---|
| 1 | … | « accès-compte » | « accès-compte » |
| 2 | … | « facturation » | « facturation » |
| 3 | … | « bug » | « demande-de-fonctionnalité » |
| … | … | … | … |
Étape 5 : Noter
Pour la correspondance exacte : ajoutez une colonne « correspondance » contenant 1 si Attendu = Réel et 0 dans le cas contraire. La somme vous donne le nombre de réponses correctes.
Pour le LLM utilisé comme juge : exécutez le prompt d’évaluation pour chaque résultat et consignez les notes.
Pour la vérification de propriétés : testez chaque propriété séparément, puis agrégez les résultats.
Tableau de bord minimal viable
Pour une première évaluation, suivez peu de critères, mais veillez à ce que chacun puisse conduire à une action.
| Dimension | Question | Seuil de passage | Action si en dessous du seuil |
|---|---|---|---|
| Exactitude | Le flux de travail a-t-il produit la bonne réponse ou classification ? | 90 % | Examiner les échecs avant le déploiement |
| Sécurité | A-t-il évité le contenu interdit, les affirmations non soutenues ou les actions risquées ? | 100 % | Bloquer le déploiement |
| Format | A-t-il renvoyé la structure attendue ? | 95 % | Corriger le prompt ou le schéma avant le déploiement |
| Utilité | Un utilisateur accepterait raisonnablement cette sortie ? | 4/5 en moyenne | Réviser les exemples ou les instructions |
| Régression | Les échecs connus sont-ils restés corrigés ? | 100 % | Bloquer le déploiement |
Le tableau de bord doit désigner un responsable et définir une règle de déploiement. « En dessous de 90 % d’exactitude, le responsable produit doit effectuer une vérification » est plus utile que « suivre l’exactitude ».
Étape 6 : Résumer
Un tableau de résumé comme :
| Date de l’évaluation | Score | Notes |
|---|---|---|
| 2026-05-01 | 47/50 (94 %) | Référence initiale. 3 erreurs : demandes 8, 23 et 41. |
| 2026-05-08 | 46/50 (92 %) | Stable. 4 erreurs. |
| 2026-05-15 | 44/50 (88 %) | Baisse. Nouvelles erreurs sur les demandes 12 et 35. |
Au fil du temps, cela vous donne une trajectoire de qualité. Les chutes déclenchent une enquête.
Étape 7 : Planifier
Exécutez l’évaluation à intervalles réguliers. Une fréquence hebdomadaire suffit pour la plupart des flux de travail. Après toute modification des prompts ou du modèle, exécutez-la avant le déploiement.
Une habitude hebdomadaire de 30 minutes. Fixez un bloc récurrent dans votre calendrier. Ne le sautez pas.
Le tableau de bord associé à cet article est conçu pour cette première exécution hebdomadaire.
Ajouter un contrôle préalable au déploiement
Les évaluations sont particulièrement utiles lorsqu’elles précèdent un changement. Pour tout flux de travail d’IA qui touche les clients, les données opérationnelles ou les décisions de l’équipe, instaurez un contrôle préalable au déploiement :
- Référence. Le score du flux de travail actuellement en production est enregistré.
- Version candidate. Un nouveau prompt, modèle, outil ou une nouvelle étape du flux de travail est exécuté sur le même jeu d’évaluation.
- Comparaison. Le candidat doit préserver les scores de sécurité et de régression, et ne doit pas réduire le score principal au-delà de la tolérance convenue.
- Décision. Déployer, suspendre, réviser ou revenir en arrière. Enregistrez la raison.
- Vérification post-déploiement. Réexécutez sur un petit échantillon de cas réels après le lancement.
Ce contrôle n’a pas besoin d’être automatisé dès le premier jour. Une feuille de calcul associée à un approbateur désigné suffit si elle empêche systématiquement les changements non mesurés d’être mis en production.
Que faire lorsque les scores baissent
L’objectif des évaluations est de détecter la détérioration de la qualité. Lorsqu’elle se produit, vous enquêtez.
Une enquête simple :
Étape 1 : Identifier les cas en échec. Quel problème précis s’est produit ?
Étape 2 : Chercher des motifs. Les échecs sont-ils regroupés (entrées similaires) ? Ou dispersés (types d’entrées différents) ?
Étape 3 : Diagnostiquer.
- Motif → probablement une faiblesse spécifique (problème de prompt, connaissance manquante).
- Dispersé → probablement une détérioration générale de la qualité (changement de modèle, dérive).
Étape 4 : Hypothétiser la cause.
- Le modèle sous-jacent a-t-il changé récemment ? Vérifiez le journal des changements du fournisseur.
- Le prompt a-t-il changé récemment ? Rétablissez la version précédente et testez-la.
- La distribution des données d’entrée a-t-elle changé ? Examinez les données récentes.
- Le jeu de données est-il devenu obsolète ? Actualisez les exemples.
Étape 5 : Tester la solution. Effectuez une seule modification, puis relancez l’évaluation. Le score s’est-il rétabli ?
Cette approche systématique remplace la panique et les conjectures.
Construire le jeu de données au fil du temps
Votre jeu de données initial est un point de départ. Améliorez-le au fil du temps en :
Ajoutant des cas de défaillance réels. Lorsqu’un cas réel concernant un client ou un utilisateur produit un mauvais résultat, ajoutez-le au jeu d’évaluation. Il devient alors un test de régression qui permettra de détecter cette défaillance précise si elle se reproduit.
Supprimant les cas obsolètes. Lorsque votre flux de travail évolue, certains cas de test deviennent obsolètes. Supprimez-les.
Élargissant la couverture. Si votre jeu d’évaluation comporte 20 demandes « accès-compte » et une seule demande « facturation », il est déséquilibré. Rééquilibrez-le.
Ajoutant des cas limites à mesure que vous les trouvez. Nouveaux motifs de plaintes clients, nouvelles fonctionnalités de produit, nouvelles catégories.
Un bon jeu de données d’évaluation est vivant — il reflète la réalité actuelle, pas la réalité historique.
Erreurs courantes
Voici quelques pratiques qui font échouer les programmes d’évaluation :
Erreur 1 : Construire une évaluation parfaite avant de commencer. Un jeu de données de 50 exemples avec une notation élaborée est intimidant à construire. Un jeu de données de 10 exemples avec une notation simple est réalisable aujourd’hui. Commencez petit. Itérez.
Erreur 2 : Évaluer uniquement les scénarios nominaux. Une série d’exemples faciles ne révèle pas les défaillances réelles. Incluez des cas difficiles, des cas limites et des cas dont les échecs antérieurs sont connus.
Erreur 3 : Dérive du jeu d’évaluation. Mettre à jour le jeu d’évaluation chaque fois que le flux de travail change prive le score de sa signification. Le jeu d’évaluation doit changer rarement, même si le flux de travail évolue plus souvent. L’objectif est de mesurer le flux de travail, pas l’évaluation.
Erreur 4 : Faire aveuglément confiance au LLM utilisé comme juge. Les juges LLM présentent des biais et accordent trop de poids aux caractéristiques superficielles, telles que la longueur ou le format. Étalonnez régulièrement le juge par rapport à l’évaluation humaine. Si vous êtes en désaccord avec lui, retravaillez son prompt.
Erreur 5 : Noter sans action. Exécuter des évaluations hebdomadaires mais ne jamais agir sur les données est du théâtre. L’objectif est de détecter et de corriger les problèmes. Si une baisse ne déclenche pas d’enquête, vous perdez votre temps.
Erreur 6 : Évaluer un seul critère. « Mon évaluation affiche 95 % d’exactitude ! » — mais la qualité de la réponse s’est peut-être dégradée, le temps de réponse a pu augmenter ou le taux d’hallucinations s’élever. Suivez plusieurs critères lorsqu’ils sont pertinents.
Outils qui aident (mais ne sont pas requis)
Si vous souhaitez aller au-delà des feuilles de calcul, plusieurs options sont accessibles :
Promptfoo. Outil open source configurable en YAML, qui s’exécute sur votre ordinateur ou dans votre chaîne d’intégration continue. Il est excellent pour tester et comparer des prompts.
Braintrust. Plateforme hébergée d’évaluation dotée d’une interface utilisateur soignée. Plus coûteuse, mais puissante.
LangSmith. Solution étroitement liée aux flux de travail LangChain, pertinente si vous utilisez cet écosystème.
Helicone. Journalisation et analyse des appels LLM, avec des capacités d’évaluation.
OpenAI Evals. Cadre open source davantage destiné aux développeurs.
Pour la plupart des équipes sans ingénieurs, une feuille de calcul associée à ChatGPT ou Claude suffit. Promptfoo est l’outil spécialisé le plus accessible pour passer à l’étape suivante.
Un programme d’évaluation sur 4 semaines
Pour une équipe partant de zéro, un plan réaliste :
Semaine 1 : Choisir et définir.
- Choisir un flux de travail.
- Construire un jeu de données de 20 exemples.
- Définir la notation (correspondance exacte, juge LLM ou propriétés).
Semaine 2 : Première référence.
- Exécuter l’évaluation. Enregistrer le score de référence.
- Identifier toute défaillance évidente.
- Ne pas changer quoi que ce soit pour l’instant — juste observer.
Semaine 3 : Itérer.
- Faire un changement que vous pensez améliorer la qualité.
- Réexécuter l’évaluation.
- Le score a-t-il augmenté, diminué ou stagné ? En rechercher la cause.
Semaine 4 : Planifier.
- Planifier les exécutions hebdomadaires.
- Documenter le processus d’évaluation.
- Informer l’équipe sur ce que signifient les scores et ce qui déclenche une action.
Après quatre semaines, vous disposez d’une évaluation opérationnelle. Vous pouvez ensuite étendre le programme à d’autres flux de travail, enrichir le jeu de données et affiner la notation.
Le changement culturel
Les évaluations exigent davantage un changement de culture qu’une évolution technique. Les équipes habituées à déployer des flux de travail d’IA « parce qu’ils semblent fonctionner » doivent adopter une culture de la mesure.
Le changement implique :
Être prêt à voir les chiffres baisser. Parfois, un changement auquel vous étiez enthousiaste nuit à la qualité. Les évaluations vous le diront. Vous devez être prêt à revenir en arrière.
Investir dans l’étalonnage. Pendant le premier mois d’une nouvelle évaluation, prévoyez du temps pour ajuster le jeu de données, la notation et les prompts. C’est un investissement.
Adopter un réflexe « avant/après ». Toute modification importante d’un flux de travail d’IA passe par l’évaluation avant sa mise en production. Cette pratique devient progressivement naturelle.
Maintenir les exigences de qualité. Lorsque les scores baissent, corrigez le problème ou revenez à la version précédente. Ne déployez pas une version de qualité dégradée au seul motif que les délais sont serrés.
Ce changement culturel est la partie la plus difficile. Une fois qu’il est en place, l’outillage devient simple.
Un flux de travail, vingt exemples, trente minutes par semaine
Les évaluations font la différence entre des flux de travail d’IA auxquels vous pouvez faire confiance dans la durée et ceux qui dérivent progressivement vers la médiocrité sans que personne ne s’en aperçoive.
Pour commencer, vous n’avez besoin ni d’ingénieurs, ni d’une expertise en apprentissage automatique, ni d’outils sophistiqués. Il vous faut un flux de travail qui mérite d’être mesuré, un petit jeu de données, une méthode de notation et une demi-heure par semaine.
Choisissez un flux de travail cette semaine. Construisez une évaluation de 20 exemples. Exécutez-la et examinez le résultat. Relancez-la la semaine suivante. Observez la rigueur que cette pratique instaure.
Dans six mois, les équipes qui pratiquent ces évaluations disposeront de flux de travail d’IA réellement améliorés. Les autres auront des flux qui sembleront identiques à ceux d’il y a six mois — mais dont les performances se seront dégradées.
