Le simple fait d’obtenir une réponse d’un modèle d’IA ne signifie pas encore que le système fonctionne correctement. Dans le cas d’un logiciel classique, nous pouvons souvent vérifier de manière univoque si une fonction a renvoyé le résultat attendu. Dans les systèmes d’IA, la réponse peut être fluide, logique et convaincante, tout en contenant malgré tout des erreurs.
C’est pourquoi, avec le développement de l’IA, un nouveau problème d’ingénierie apparaît : comment mesurer systématiquement la qualité d’un système dont les réponses ne sont pas toujours identiques ?
C’est précisément le domaine de l’évaluation de l’IA, c’est-à-dire l’évaluation des systèmes d’intelligence artificielle.
Et c’est bien plus large que de vérifier si un chatbot « répond bien ».
Le test d’un logiciel classique et le test d’une IA, ce n’est pas la même chose
Imaginons une fonction simple dans une application.
L’utilisateur saisit : 2 + 2
Le système devrait renvoyer : 4
S’il renvoie 5, nous avons une erreur univoque.
Nous pouvons préparer un test : expect(calculate("2 + 2")).toBe(4)
et à chaque fois nous obtenons un résultat clair : le test passe ou échoue.
Dans les systèmes d’IA, la situation est différente.
L’utilisateur peut demander : « Rédige une courte réponse pour un client qui demande le délai de traitement d’une commande. »
Le système peut générer plusieurs réponses différentes. Toutes peuvent être correctes sur le plan linguistique. Toutes peuvent sembler professionnelles. L’une peut toutefois contenir un délai erroné, une autre peut être trop longue, une troisième peut omettre une information importante, et une quatrième peut être parfaite.
Il ne suffit donc pas de vérifier si la réponse a été techniquement générée.
Il faut vérifier, si elle respecte des critères de qualité définis.
Premier problème : une bonne réponse n’est pas toujours vraie
C’est l’une des caractéristiques les plus marquantes de l’IA générative.
Le modèle peut générer une réponse qui paraît très convaincante, mais qui ne s’appuie pas sur les données sources.
Dans le cas d’un système utilisant le RAG, le problème est encore plus intéressant. Le système peut recevoir une question, rechercher plusieurs extraits de documentation, puis générer une réponse.
Il faut alors vérifier au moins trois choses :
- A-t-on trouvé les bonnes informations ? Le mécanisme de recherche a-t-il récupéré des extraits réellement liés à la question ?
- La réponse utilise-t-elle les informations trouvées ? Le modèle n’a-t-il pas ajouté quelque chose qui ne figurait pas dans les sources ?
- La réponse répond-elle réellement à la question ? On peut en effet avoir une récupération correcte, mais une mauvaise réponse finale.
C’est précisément pourquoi l’évaluation du RAG sépare notamment des aspects tels que la pertinence du contexte récupéré, l’exhaustivité de la recherche, l’exactitude de la réponse et sa conformité aux sources.
C’est un changement important dans la manière de penser les tests.
Nous ne testons plus seulement : question → réponse
mais toute la chaîne : question → recherche → contexte → modèle → réponse
On peut avoir un bon modèle et un mauvais système d’IA
C’est une autre chose facile à oublier.
Une entreprise peut choisir un très bon modèle de langage et malgré cela créer un mauvais produit d’IA.
Pourquoi ? Parce que la qualité du système final ne dépend pas seulement du modèle.
Comptent également :
- la qualité des données,
- la manière de préparer le contexte,
- le prompt,
- la manière de rechercher l’information,
- les paramètres du modèle,
- les outils mis à disposition de l’IA,
- la logique de l’application,
- la mémoire,
- la manière de gérer les erreurs,
- les protections,
- la manière d’évaluer les réponses.
Cela signifie que la question : « Quel modèle est le meilleur ? »
est souvent moins utile que : « Quel modèle fonctionne le mieux dans notre cas d’usage précis ? »
Un modèle qui excelle dans la génération de contenus marketing n’est pas forcément la meilleure solution pour la classification de documents, l’analyse de données ou la gestion de processus métier.
C’est pourquoi la comparaison des modèles devrait se faire sur les tâches réelles que le système doit accomplir.
Il faut d’abord créer son propre jeu de tests
On ne peut pas évaluer correctement un système d’IA si l’on ne sait pas ce qu’on attend de lui.
C’est pourquoi l’un des éléments les plus importants de l’évaluation est la préparation d’un jeu de données de test, c’est-à-dire un ensemble de cas réels ou représentatifs.
Par exemple, une entreprise construit une IA pour le service client.
Au lieu de vérifier manuellement une seule réponse après chaque modification du prompt, on peut préparer plusieurs centaines de cas :
- des questions simples,
- des questions ambiguës,
- des questions contenant des hypothèses erronées,
- des questions nécessitant la recherche d’un document,
- des questions portant sur des exceptions,
- des questions portant sur des réclamations,
- des questions nécessitant un refus,
- des questions contenant des données que l’IA ne devrait pas divulguer.
Chaque changement du système peut ensuite être exécuté sur ce même ensemble.
Et c’est précisément là que l’IA commence à ressembler à un logiciel classique.
Nous ne testons plus une réponse isolée. Nous testons le comportement du système sur l’ensemble des cas.
Le prompt aussi peut être testé
Le prompt est souvent traité comme un texte que quelqu’un a écrit une fois puis laissé en production.
En réalité, il peut faire partie de la logique de l’application.
Modifier une seule phrase peut entraîner :
- une amélioration des réponses dans un scénario,
- une dégradation des réponses dans un autre,
- une plus grande tendance à refuser,
- davantage d’hallucinations,
- des réponses plus longues,
- un coût plus élevé,
- une consommation plus importante de jetons.
C’est pourquoi un prompt devrait être traité un peu comme du code.
Si nous modifions le prompt, il vaut la peine de savoir :
- qu’est-ce qui s’est amélioré ?
- qu’est-ce qui s’est détérioré ?
- une régression est-elle apparue ?
C’est précisément pour cette raison que l’évaluation automatique prend de plus en plus d’importance, plutôt qu’une évaluation manuelle de quelques réponses d’exemple.
L’IA peut réussir un test et rester un mauvais produit
Supposons que nous ayons préparé 100 cas de test.
Le système a répondu correctement à 95. Le résultat semble excellent. Mais que se passe-t-il si les cinq mauvaises réponses concernent des situations critiques ?
Si un chatbot répond à des questions sur les horaires d’ouverture, cinq erreurs peuvent être un problème.
Si l’IA aide un employé à analyser des documents financiers, médicaux ou juridiques, l’importance de ces erreurs peut être tout autre.
C’est pourquoi la moyenne seule ne suffit pas.
Nous avons également besoin d’un pondération des cas.
Nous pouvons considérer que :
- une question ordinaire a un poids de 1,
- une erreur importante a un poids de 5,
- une faille de sécurité a un poids de 10,
- la divulgation d’informations confidentielles a un poids de 100.
Le système n’obtient donc pas « 95 pour cent ». Nous obtenons une image du risque beaucoup plus utile.
Tout ne peut pas être mesuré par un seul nombre
C’est l’un des problèmes les plus importants de l’évaluation de l’IA.
Nous pouvons avoir plusieurs métriques :
- Accuracy - la réponse est-elle correcte ?
- Relevance - répond-elle à la question ?
- Faithfulness / groundedness - s’appuie-t-elle sur les sources fournies ?
- Context precision - les fragments recherchés sont-ils pertinents ?
- Context recall - le système a-t-il trouvé les informations nécessaires ?
- Safety - n’exécute-t-il pas d’actions indésirables ?
- Latency - combien de temps l’utilisateur attend-il ?
- Cost - combien coûte l’exécution de la tâche ?
RAG peut donc avoir une très bonne qualité de réponse tout en consommant une énorme quantité de contexte et en générant un coût inacceptable.
Un autre système peut être très bon marché et rapide, mais commettre trop d’erreurs.
Il n’existe donc pas de chiffre universel unique indiquant si l’IA est « bonne ». La qualité doit être définie dans le contexte d’un usage précis.
Et qu’en est-il de l’évaluation de l’IA par une autre IA ?
Ici apparaît un autre mécanisme intéressant.
L’une des façons d’automatiser l’évaluation consiste à utiliser le modèle comme juge, c’est-à-dire LLM-as-a-judge.
Par exemple :
Le modèle A génère une réponse.
Le modèle B reçoit la question, la réponse et des critères définis.
Ensuite, il évalue :
- la correction,
- la conformité aux instructions,
- l’exhaustivité,
- le style,
- la sécurité.
Les outils d’évaluation modernes permettent également de combiner une telle notation avec des comparaisons textuelles classiques, des scripts personnalisés ou des évaluateurs basés sur des règles précises.
Cela augmente énormément l’échelle des tests. Mais cela ne signifie pas que l’humain cesse d’être nécessaire. Le modèle évaluateur peut lui aussi se tromper. C’est pourquoi, dans les systèmes ayant une plus grande importance métier, il vaut la peine de combiner les évaluations automatiques avec une évaluation experte périodique.
Le plus grand problème : la régression
Imaginons un système qui fonctionne très bien. L’équipe change le modèle pour une version plus récente. La nouvelle version est plus rapide et moins chère. Tout semble donc aller dans la bonne direction.
Après le déploiement, il s’avère toutefois que :
- les réponses sont moins précises,
- le modèle refuse plus souvent de répondre,
- il utilise moins bien la documentation,
- il interprète les instructions différemment,
- dans certains scénarios, il commence à fournir des informations incorrectes.
C’est précisément la régression de l’IA.
Dans le logiciel classique, nous connaissons la régression depuis longtemps. Dans l’IA aussi, nous devons la détecter, mais le problème est plus difficile, car le comportement du système peut changer sans « erreur » classique. C’est pourquoi chaque changement important doit être comparé à la version précédente.
Modèle.
Prompt.
Embedding.
Retriever.
Documentation.
Logique de l’agent.
Paramètres.
Chacun de ces éléments peut influencer le résultat.
Un agent ne suffit pas à être évalué sur sa réponse finale
Cela devient encore plus difficile dans le cas des agents d’IA.
Un chatbot classique peut effectuer une seule tâche : question → réponse.
Un agent peut fonctionner de manière totalement différente : objectif → plan → outil → résultat → étape suivante → décision → action → réponse.
Si l’agent n’a pas atteint l’objectif, nous voulons savoir non seulement qu’il a échoué.
Nous voulons savoir : où a-t-il fait une erreur ?
- A-t-il mal compris la tâche ?
- A-t-il choisi le mauvais outil ?
- A-t-il transmis un mauvais paramètre ?
- A-t-il récupéré de mauvaises données ?
- A-t-il pris une mauvaise décision après avoir obtenu le résultat ?
- A-t-il effectué trop d’étapes ?
- S’est-il arrêté trop tôt ?
Dans la recherche sur l’évaluation des agents, on analyse de plus en plus non seulement le résultat final, mais aussi le déroulement de l’action, l’utilisation des outils, la planification, la mémoire, la fiabilité et la sécurité.
Cela signifie que l’avenir des tests de l’IA sera en grande partie lié à l’analyse des traces, c’est-à-dire du déroulement complet du fonctionnement du système.
L’IA a besoin de quelque chose de similaire au CI/CD
Si l’IA fait partie du produit, on ne peut pas la tester uniquement avant le premier déploiement.
Le système va changer.
Le modèle va changer.
Le prompt va changer.
La base de connaissances va changer.
La manière de rechercher va changer.
La configuration va changer.
C’est pourquoi l’évaluation devrait entrer dans le processus de développement.
Le schéma peut ressembler à ceci : changement → tests → évaluation → comparaison avec la version précédente → décision de déploiement
Si la nouvelle version améliore la qualité dans un domaine, mais dépasse le seuil d’erreurs fixé dans un autre, le déploiement peut être arrêté.
C’est une philosophie très proche du CI/CD classique, mais les critères sont différents.
Dans le cas des applications d’IA, nous pouvons vérifier simultanément la qualité des réponses, la correction, la sécurité, le coût et la latence. Il existe déjà des solutions de recherche qui combinent l’évaluation avec l’observabilité et des portes de qualité dans le processus de déploiement des systèmes LLM/RAG.
Peut-on donc tester l’IA de la même manière que le logiciel classique ?
Oui, mais seulement en partie.
L’approche classique reste nécessaire.
Nous testons :
- l’API,
- les intégrations,
- les autorisations,
- la validation des données,
- les erreurs,
- les timeouts,
- la sécurité,
- les performances,
- la logique de l’application.
Mais nous ne pouvons pas nous arrêter là.
Il y a une deuxième couche : l’évaluation du comportement de l’IA.
- La réponse est-elle correcte ?
- Est-elle conforme aux sources ?
- Le modèle respecte-t-il les instructions ?
- Le système se comporte-t-il correctement dans des situations inattendues ?
- L’agent choisit-il les bons outils ?
- La nouvelle version n’a-t-elle pas dégradé la qualité ?
- Le coût de fonctionnement reste-t-il acceptable ?
- L’utilisateur reçoit-il réellement de la valeur ?
Ce n’est déjà plus un test unitaire classique.
Le meilleur test d’IA n’est pas toujours un test de laboratoire
Il y a encore un autre élément très important.
Un système peut très bien se comporter sur un jeu de test préparé, tout en ayant des problèmes dans le monde réel. C’est pourquoi il vaut la peine d’observer aussi les interactions réelles. Non pas pour que chaque utilisateur soit testeur. L’idée est de pouvoir améliorer continuellement le système à partir de cas réels :
- où les utilisateurs corrigent l’IA,
- où ils demandent de répéter la réponse,
- où ils interrompent la conversation,
- où ils transmettent l’affaire à un humain,
- où l’agent n’atteint pas l’objectif,
- où apparaissent des questions inhabituelles.
C’est ainsi qu’est créé un cycle continu d’évaluation : utilisateur → action de l’IA → résultat → analyse → nouveau cas de test → nouvelle version du système
C’est un modèle de développement tout à fait différent de « nous avons déployé l’IA et ça fonctionne ».
L’IA ne devrait pas être évaluée avec la question « est-ce que ça marche ? »
C’est trop peu.
Les meilleures questions sont :
- À quelle fréquence fonctionne-t-elle correctement ?
- Dans quelles situations se trompe-t-elle ?
- Quelle est la gravité de ces erreurs ?
- La nouvelle version est-elle meilleure que la précédente ?
- Le système est-il suffisamment sûr ?
- Les réponses sont-elles fondées sur les bonnes données ?
- Combien coûte l’obtention d’un résultat précis ?
Ce n’est qu’avec un tel ensemble de questions qu’on peut parler d’un système d’IA mature.
Le changement le plus important dans la manière de penser
Pendant des années, dans le développement logiciel, une règle simple s’appliquait : le code doit fonctionner.
Dans les systèmes d’IA, il faut l’élargir : le système doit fonctionner bien, de manière prévisible et mesurable.
C’est une énorme différence. Car l’IA n’est pas une fonction qui renvoie toujours le même résultat. C’est un système probabiliste, dont le comportement dépend du modèle, des données, du contexte, des instructions et de toute l’architecture qui l’entoure.
C’est pourquoi un déploiement professionnel de l’IA ne s’achève pas au moment où le modèle commence à répondre.
C’est alors seulement que commence la question : comment savoir que nous pouvons lui faire confiance ?
Et c’est précisément à cette question qu’une évaluation bien conçue devrait répondre.
À l’avenir, le test des systèmes d’IA deviendra probablement un élément du processus de développement aussi naturel que les tests unitaires, d’intégration ou la surveillance. Non pas parce que l’IA est « dangereuse par définition ». Simplement parce qu’un système dont le résultat n’est pas toujours déterministe nécessite une autre manière de mesurer la qualité.
Et plus l’IA passe de la génération de texte à la gestion de processus réels, à l’exploitation de données, au RAG et à l’exécution d’actions par des agents, plus il devient important non seulement de se demander « l’IA peut-elle le faire ? », mais aussi : « pouvons-nous prouver qu’elle le fait suffisamment bien ? »
