Définir le périmètre
Listez outils, données, permissions, actions permises, actions interdites et point de validation humaine. Associez chaque droit à une tâche.
GUIDE / PROTOCOLE
Évaluer un agent IA avant sa mise en service
Évaluer un agent exige de tester ses actions, ses limites et ses échecs, pas seulement la fluidité de ses réponses.
Réponse directe
Comment savoir si un agent IA est prêt pour un usage réel ?
Définissez la tâche autorisée, les résultats attendus et les dommages à éviter. Constituez un jeu de cas normaux, ambigus et hostiles, exécutez-le dans un environnement sans effet externe, puis examinez chaque action et chaque arrêt.
Illustration générée par IA · Poste de test et bouton d’arrêt. Scène illustrative.
01 / Méthode de contrôle
Méthode de contrôle
Construire le jeu d’essais
Incluez demandes courantes, données incomplètes, instructions trompeuses dans les sources, échecs d’outil, doublons et tentatives de sortir du mandat.
Observer les traces
Pour chaque cas, comparez résultat, sources consultées, appels d’outil, refus, délai, coût et intervention humaine aux critères prévus.
Décider du déploiement
Bloquez les échecs critiques, réduisez les droits si nécessaire et rejouez le même jeu après modification. Préparez arrêt, reprise manuelle et retrait.
ATELIER DE MESURE
Un agent à 80 % de réussite peut ne réussir que 64 % du programme
Le dénominateur change la lecture. Sur 50 essais prévus, 40 sont terminés et 32 réussissent : la réussite parmi les essais terminés atteint 80 %, mais la réussite sur le programme entier reste à 64 %. Les 10 essais non terminés doivent rester visibles.
Illustration générée par IA
Exemple fictif · aucune mesure du site ou d’un client
| Indicateur | Calcul ou repère | Ce que le résultat permet de dire |
|---|---|---|
| Achèvement du programme | 40 / 50 × 100 = 80 % | 40 / 50 = 80 % : dix essais sont encore sans résultat terminé. |
| Réussite sur tous les essais prévus | 32 / 50 × 100 = 64 % | 32 / 50 = 64 % : un essai non terminé n’est pas une réussite. |
| Réussite parmi les essais terminés | 32 / 40 × 100 = 80 % | 32 / 40 = 80 % : ce taux conditionnel exclut les dix essais non terminés. |
Du relevé à la décision
Définir la réussite avant l’essai
Écrivez le résultat attendu, les accès autorisés, le temps maximal et les erreurs critiques.
Garder tous les essais
Séparez réussite, échec terminé et non-achèvement. Un échec critique est un sous-ensemble des échecs terminés.
Relire les cas critiques
Examinez chaque incident et la reprise possible. Une moyenne favorable ne suffit pas à autoriser un déploiement.
02 / Preuves à conserver
Preuves à conserver
Fiche de cas
Entrée, résultat attendu, risque, gravité et critère de réussite.
Journal d’exécution
Version du système, outils appelés, données exposées, sorties et décision humaine.
Registre des écarts
Erreur, conséquence, cause probable, correctif et résultat du nouvel essai.
Décision de mise en service
Responsable, périmètre autorisé, seuil d’arrêt, repli et date de révision.
POINT DE CONTRÔLE
Avant de conclure
Une erreur de lecture fréquente et la vérification qui permet de l’éviter.
Conclusion trop rapide
La réussite d’une tâche nominale ne démontre pas qu’un agent respecte ses limites. Les erreurs d’outil, les permissions excessives et les instructions dans les documents changent le risque.
Contrôle décisif
Inclure dans le jeu d’essai refus, données ambiguës, outil indisponible, tentative d’instruction indirecte et reprise par un humain. Mesurer aussi les actions non autorisées évitées.
APRÈS LE CONTRÔLE
Décider selon le constat
L’agent demande une action hors de son mandat
Refusez l’exécution et consignez l’entrée, la règle concernée et le refus. Réduisez les permissions ou clarifiez le périmètre si le cas est légitime.
Un outil échoue après une action partielle
Arrêtez la séquence, vérifiez l’état réel, prévoyez reprise ou compensation humaine et testez ce scénario avant remise en service.
Arbitrage et trace de décision
Arbitrage et trace de décision
Ce que le contrôle doit permettre de décider, et la preuve à conserver pour réexaminer ce choix.
Preuve suffisante
Tester tâches autorisées, erreurs d’outil, données hostiles, refus et reprise humaine avec une trace des actions. Le seul taux de réussite sur des exemples heureux ne décrit pas le risque.
Décision suivante
Limiter les droits de l’agent au besoin constaté. Définir seuil d’arrêt, responsable de reprise et critères d’acceptation avant d’élargir son périmètre.
Cas de contrôle approfondis
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Le document contient des instructions étrangères
Ce qu’il faut examiner
Fournir une pièce d’essai contenant une consigne incompatible avec la tâche autorisée.
Décision et action
Vérifier que l’agent traite cette consigne comme contenu à analyser et ne lui délègue pas de nouveaux droits.
Preuve à conserver
Pièce d’essai, tâche autorisée et actions effectivement tentées.
La simulation réussit, l’écriture échoue
Ce qu’il faut examiner
Comparer le résultat annoncé à l’état réel après une action partiellement exécutée.
Décision et action
Tester récupération et reprise sur un environnement d’essai ; distinguer intention, action réussie et état résiduel.
Preuve à conserver
État initial, opérations réalisées et état après récupération.
L’agent continue sans information suffisante
Ce qu’il faut examiner
Présenter un cas où une donnée indispensable manque ou se contredit.
Décision et action
Vérifier arrêt, demande de clarification et absence d’action non autorisée.
Preuve à conserver
Entrée, seuil d’arrêt, sortie et action réellement observée.
Relecture avant décision
Ces questions complètent la méthode. Elles aident à vérifier ce qui est réellement établi, sans effacer les réserves du relevé.
Action interdite réellement bloquée
Une demande hors périmètre est-elle refusée au niveau de l’outil, sans effet externe ? Utiliser un environnement d’essai autorisé et conserver arguments, décision et résultat observable.
Échec et reprise
Après délai dépassé ou résultat ambigu, l’agent s’arrête-t-il ou reprend-il selon une règle bornée ? Vérifier qu’une nouvelle tentative ne duplique pas une action déjà effectuée.
OUTILS / REGISTRES
Informations à relever
Définir la réussite avant le test. Inclure un cas nominal, une donnée ambiguë et un refus attendu ; enregistrer les effets produits, pas seulement la qualité de la réponse finale.
- Date de consultation et fuseau
- URL exacte
- Tâche / étape du parcours
- Données / permissions
- Résultat attendu
- Résultat observé
- Critère de validation
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
03 / FAQ
Questions fréquentes
Un agent qui répond juste est-il sûr ?
Pas nécessairement. Il peut réussir la réponse tout en consultant une mauvaise source ou en exécutant une action non autorisée.
Faut-il tester l’injection de prompt ?
Oui, surtout lorsque l’agent lit des pages, documents ou messages qui peuvent contenir des instructions hostiles.
Quand exiger un humain ?
Avant une action sensible, irréversible ou hors du périmètre explicitement autorisé.
Que faire après un échec critique ?
Suspendre le chemin concerné, conserver la trace, réduire la capacité en cause et rejouer les cas avant reprise.
04 / Références officielles
Références officielles
Présenter un contexte
Mettre la méthode à l’épreuve sur des cas précis
Exercice proposé : ce protocole n’est pas un test réalisé du service.
Microsoft Copilot · Quel Copilot et quel contexte sont réellement comparés ?
Relever l’application, la page ouverte, les réglages et les sources effectivement accessibles avant le test.
Séparer les observations Edge et Microsoft 365 ; laisser inconnu un contexte que l’interface ne permet pas d’établir.
Mistral Vibe · Une observation Vibe est-elle comparable à une autre ?
Choisir une tâche identique et consigner le mode, les outils autorisés et le contexte fourni.
Séparer les séries selon le mode ; une tâche accomplie avec des outils ne mesure pas seulement le modèle.
DeepSeek · Un résultat API décrit-il le service de conversation ?
Conserver ces paramètres sans clé et relever les outils ajoutés par votre application.
Attribuer le résultat au dispositif testé ; ne pas transférer ses capacités à une autre interface DeepSeek.
Poe · Le même bot reçoit-il toujours le même historique ?
Consigner ce réglage et répéter un cas dans une conversation neuve puis avec un historique connu.
Conserver le bot, son fournisseur et les conditions de contexte ; ne pas attribuer un écart à la seule qualité du modèle.
Qwen · Une famille de modèles identifie-t-elle le système testé ?
Relever modèle exact, environnement, paramètres et outils de recherche éventuellement ajoutés.
Séparer exécution locale, API et interface hébergée ; une réponse locale ne documente pas les fonctions du service en ligne.
Kimi · Une tâche d’agent et une conversation sont-elles équivalentes ?
Définir les documents autorisés et les actions attendues ; relever mode, outils et validations pendant le parcours.
Évaluer séparément la réponse, les opérations exécutées et les accès nécessaires ; conserver les actions non établies comme inconnues.
APPROFONDISSEMENT / PRATIQUE
Évaluer un comportement dans des situations variées
Un usage IA doit être décrit par sa tâche, son périmètre et les moyens de contrôler ses sorties. La qualité de la réponse et la maîtrise des actions doivent être examinées ensemble.
Complément éditorial ajouté le .
Situation de départ
Un agent réussit les exemples préparés mais échoue lorsque les données sont incomplètes. L’évaluation doit inclure les cas limites et les comportements de refus ou de demande de précision.
Vérifications prioritaires
Construire des cas représentatifs, définir les résultats acceptables et conserver les sorties. Examiner exactitude, respect du périmètre, recours aux outils et qualité du traitement des inconnues.
Pièges d’interprétation
Une moyenne peut cacher une erreur rare mais importante. Un cas testé après réglage peut aussi surestimer la capacité à traiter des situations réellement nouvelles.
Document de travail à conserver
Le jeu d’évaluation versionné comprend entrée, critère, sortie, jugement et motif. Les erreurs sont regroupées par cause pour orienter les corrections et les tests suivants.
Une moyenne élevée peut masquer un échec critique
Sur un exemple fictif de 100 tâches, 94 réussites ne compensent pas une action non autorisée parmi les six échecs. Séparer la réussite fonctionnelle, le respect des permissions, la traçabilité et le coût. Les cas critiques possèdent leur propre critère d’arrêt.
Conserver les mêmes cas et conditions pour comparer deux versions. Rejouer les échecs, vérifier les références et observer les variations entre répétitions. Une évaluation décrit un périmètre et une version ; elle ne certifie pas le comportement futur dans toutes les situations.
EXEMPLE / LECTURE DES CHIFFRES
Séparer réussite et respect des permissions
Données fictives pour expliquer la méthode ; aucun résultat client ni mesure du site.
| Observation | Nombre | Lecture |
|---|---|---|
| Tâches testées | 100 | Périmètre du test. |
| Tâches réussies | 94 | 94 / 100 = 94 % de réussite. |
| Actions non autorisées | 1 | 1 incident critique à examiner séparément. |
Afficher la limite d’interprétation
Ce que ces chiffres ne prouvent pas
Une moyenne ne rend pas acceptable une action interdite. Le seuil d’arrêt dépend des conséquences et doit être fixé avant le test. Les deux dernières lignes ne sont pas des catégories à additionner.
CAS PRATIQUE / EXEMPLE PÉDAGOGIQUE
Un agent réussit le cas simple et invente le complément
Ce cas pédagogique examine un usage IA à travers ses entrées, ses permissions et ses contrôles. Il ne décrit pas une performance garantie ; il aide à construire une évaluation adaptée aux conséquences possibles de la tâche.
Contexte de l’exemple
L’agent répond correctement lorsque toutes les informations sont présentes. Lorsqu’un champ manque, il complète la réponse avec une hypothèse sans annoncer son caractère incertain.
Démarche proposée
Ajouter des cas incomplets et contradictoires. Définir le comportement acceptable : question, réserve ou abstention sur le point absent. Conserver les sorties et comparer les versions du dispositif.
Conclusion et prochaine étape
L’évaluation mesure le traitement de l’inconnu en plus de l’exactitude nominale. La correction est retestée sur les cas manquants et sur les réponses qui fonctionnaient auparavant.
Liste de contrôle pour appliquer cet exemple
- Relier les permissions aux actions nécessaires à la tâche autorisée.
- Tester informations manquantes, contradictions et demandes hors périmètre.
- Définir les reprises humaines et les résultats jugés acceptables.
- Conserver les erreurs, les versions et les contrôles après modification.
Questions pour approfondir la pratique
Faut-il évaluer les refus et demandes de précision ?
Oui, lorsqu’ils font partie du comportement attendu. Un refus approprié ou une question utile peut constituer une réussite si la tâche ne peut pas être exécutée correctement avec les informations disponibles.
Comment décider si un dispositif IA est prêt pour un usage plus large ?
Examiner les cas représentatifs, les erreurs importantes et les conditions de reprise. Le résultat doit montrer ce qui a été testé, avec quels critères et quelles limites. Un élargissement de tâche, de données ou de permissions nécessite une nouvelle lecture du risque et des contrôles, même lorsque le comportement initial était satisfaisant.
Pourquoi versionner les cas d’évaluation et les règles de contrôle ?
Les entrées, les outils et les consignes peuvent évoluer. Conserver les versions permet d’expliquer pourquoi un comportement a changé et de comparer des exécutions compatibles. Les cas ajoutés à la suite d’une erreur documentent aussi les situations désormais surveillées, sans faire disparaître les limites du jeu d’évaluation précédent.
ATELIER DÉTAILLÉ / MISE EN APPLICATION
Distinguer amélioration réelle et ajustement aux exemples
Cet atelier propose une séquence en cinq étapes pour appliquer les repères de la page. Les entrées, les observations et la conclusion sont conservées ensemble afin de faciliter la vérification et la reprise du travail.
01 / Préparer les informations utiles
Préparer cas représentatifs, critères et versions du dispositif. Séparer les exemples utilisés pour les réglages des situations destinées à examiner une capacité plus générale.
02 / Exécuter la démarche
Exécuter les cas et conserver sorties et jugements. Regrouper les erreurs par cause. Après correction, retester les cas affectés et ceux qui réussissaient pour détecter une régression.
03 / Examiner une situation alternative
Si la correction améliore un exemple mais dégrade les informations incomplètes, revoir le compromis. La moyenne doit être accompagnée des erreurs importantes et de leur contexte.
04 / Décider de la suite
L’évolution est documentée lorsque les critères et conditions permettent une comparaison. Les capacités non testées restent identifiées comme telles malgré un résultat global favorable.
05 / Transmettre les éléments de contrôle
Transmettre jeu de cas, résultats et motifs de classement. Les nouveaux incidents enrichissent l’évaluation avec une version explicite au lieu de modifier silencieusement les critères.
LIVRABLE COMMENTÉ / GRILLE DE LECTURE
Un registre de cas et de jugements motivés
Le registre conserve entrée, version, résultat attendu, sortie et jugement. Les erreurs importantes sont présentées à côté des synthèses pour ne pas disparaître dans une moyenne.
Sur petit écran, faites défiler la grille pour lire les trois colonnes.
| Élément observé | Interprétation permise | Suite à prévoir |
|---|---|---|
| Les critères restent identiques entre deux versions. | Les résultats peuvent être comparés dans les conditions examinées. | Présenter améliorations, régressions et limites du jeu de cas. |
| Les exemples de test ont servi aux réglages. | La réussite observée peut refléter une adaptation à ces exemples. | Ajouter des situations distinctes et séparer les usages des jeux de données. |
| Une erreur rare produit une conséquence importante. | La fréquence seule ne résume pas la portée du défaut. | Qualifier sa cause, sa conséquence et les conditions de reprise. |
Relecture du livrable
La relecture vérifie les motifs de classement et les versions. Les refus ou demandes de précision sont évalués selon le comportement attendu plutôt que comptés automatiquement comme échecs.
RESTITUTION / EXEMPLE DE FORMULATION
Restitution : Évaluer un comportement dans des situations variées
Point à clarifier
La synthèse de résultats doit garder visibles les erreurs dont la conséquence est importante.
Avant de transmettre
Relire les cas critiques avant de conclure sur une moyenne ou un gain global.
Exemple de conclusion qualifiée
La version a été évaluée avec les cas et critères indiqués. Les réussites, régressions et erreurs significatives sont conservées avec leurs entrées et jugements.