Une démonstration réussie montre qu’un employé IA peut produire un résultat convaincant sur quelques exemples. Elle ne montre pas encore qu’il saura se comporter correctement dans un processus réel.
Les dossiers réels sont incomplets, les sources se contredisent, une connexion peut échouer et certaines demandes dépassent le périmètre autorisé. Le test doit donc porter sur le travail complet : ce que le système consulte, ce qu’il prépare, ce qu’il refuse et la manière dont il transmet le résultat à une personne.
Une démonstration n’est pas une validation opérationnelle
Une démonstration part souvent d’un cas propre : les documents sont disponibles, la demande est claire et la sortie attendue est connue. Elle répond à la question « le système sait-il faire ceci dans de bonnes conditions ? »
Une validation opérationnelle pose une question plus exigeante : « le système reste-t-il utile et contrôlable lorsque les conditions ne sont pas idéales ? »
Il ne suffit donc pas d’évaluer la qualité d’un résumé ou d’un brouillon. Il faut aussi vérifier que l’employé IA :
- utilise uniquement les sources autorisées ;
- distingue un fait d’une interprétation ;
- signale une information absente ou contradictoire ;
- respecte le format attendu par l’outil destinataire ;
- n’exécute pas une action qui exige une validation ;
- produit un état d’échec compréhensible lorsqu’il ne peut pas continuer.
Un texte fluide peut masquer une mauvaise source. À l’inverse, un refus explicite peut être le bon résultat lorsque les informations nécessaires manquent.
Écrire le contrat de la mission avant les tests
Le contrat de mission décrit les limites observables du travail confié. Il ne s’agit pas d’un contrat juridique, mais d’une fiche de référence commune à l’équipe métier et à l’équipe qui configure le système.
Cette fiche doit préciser :
- Le déclencheur : quel événement lance la mission ?
- Les sources : quels outils, dossiers et champs peuvent être consultés ?
- La sortie : quel résultat doit être préparé et sous quel format ?
- Les interdictions : quelles données ou actions restent hors périmètre ?
- La validation : qui accepte, corrige ou refuse la proposition ?
- L’état d’échec : que doit faire le système si une source manque ou si une règle ne peut pas être appliquée ?
Sans cette référence, les testeurs risquent d’évaluer une impression générale. Avec elle, chaque cas peut être comparé à un comportement attendu.
Construire un jeu de cas représentatif
Un bon jeu de test ne contient pas seulement des exemples faciles. Il couvre les situations que l’équipe rencontre et celles qu’elle doit savoir arrêter.
On peut organiser les cas en plusieurs familles :
- cas ordinaires : les sources sont présentes et cohérentes ;
- cas incomplets : une date, un interlocuteur ou un document nécessaire manque ;
- cas contradictoires : deux outils présentent des montants, des statuts ou des échéances différents ;
- cas hors périmètre : la demande concerne une donnée ou une action non autorisée ;
- cas sensibles : la sortie touche à un prix, une promesse, une priorité ou un message externe ;
- incidents techniques : une source est indisponible, un format change ou l’outil destinataire refuse la mise à jour.
Les cas historiques peuvent être utiles à condition d’être sélectionnés avec l’équipe métier et de ne conserver que les données nécessaires au test. Les informations personnelles ou confidentielles qui n’aident pas l’évaluation doivent être retirées ou remplacées selon les règles de l’organisation.
Pour chaque cas, il faut écrire le résultat attendu avant l’exécution : faits à retrouver, éléments à signaler, action interdite et personne à solliciter. Cette préparation évite d’adapter les critères après avoir vu la réponse du système.
Évaluer le comportement, pas seulement la formulation
La qualité rédactionnelle n’est qu’une dimension. Une grille utile observe plusieurs éléments séparément :
- fidélité aux sources : chaque fait important est-il soutenu par une information accessible ?
- complétude utile : les éléments indispensables à la décision sont-ils présents ?
- gestion de l’incertitude : les manques et contradictions sont-ils visibles ?
- respect des permissions : aucune source ni action interdite n’est-elle utilisée ?
- conformité de la sortie : le format peut-il être relu ou traité sans reconstruction ?
- qualité du relais humain : la personne comprend-elle ce qu’elle doit vérifier et décider ?
Le résultat d’un cas peut ensuite être classé dans un état explicite : accepté, corrigé, rejeté ou transmis pour arbitrage. La correction doit être conservée avec son motif. Une erreur de date, une source mal choisie et une action non autorisée ne demandent pas la même remédiation.
Combiner contrôles automatiques et jugement métier
Certains contrôles sont déterministes : présence d’un champ obligatoire, validité d’une date, respect d’un schéma, existence d’un lien vers la source ou absence d’appel à une action interdite. Ils peuvent être rejoués automatiquement à chaque modification du système.
D’autres critères exigent une personne du métier : une synthèse aide-t-elle réellement à préparer le rendez-vous ? Une objection est-elle formulée sans déformer les propos du client ? Le niveau de détail est-il adapté au destinataire ?
Les deux niveaux sont complémentaires. Confier toute l’évaluation à un autre modèle de langage déplacerait le problème : son appréciation pourrait elle aussi être incomplète. Un contrôle automatisé peut assister la revue, mais les critères métier et les conséquences d’une erreur doivent rester visibles pour l’équipe responsable.
Passer par un mode parallèle avant toute action réelle
Le mode parallèle consiste à laisser l’employé IA préparer le travail à partir de déclencheurs réels, sans lui permettre d’exécuter l’action finale. L’équipe continue son processus habituel et compare ensuite la proposition du système au résultat réellement retenu.
Ce mode permet d’observer :
- les sources auxquelles le système accède réellement ;
- les cas qu’il ne sait pas traiter ;
- les corrections demandées par les utilisateurs ;
- les alertes inutiles ou, au contraire, les anomalies manquées ;
- le temps de relecture nécessaire avant validation.
Un brouillon d’email reste alors un brouillon. Une mise à jour CRM reste une proposition. Si la préparation est erronée, aucune donnée de référence ni aucun destinataire externe n’est affecté.
Exemple : tester la suite d’un rendez-vous commercial
Pour une mission qui prépare les suites d’un rendez-vous, le cas ordinaire contient une fiche CRM, un compte rendu autorisé et des tâches existantes. Le résultat attendu sépare les faits confirmés, les questions ouvertes et les prochaines actions proposées.
Le même test doit ensuite être rejoué avec des variations contrôlées :
- le compte rendu mentionne une échéance différente de celle du CRM ;
- le décideur n’est pas identifié ;
- une promesse commerciale apparaît dans une note non validée ;
- la fiche CRM n’est pas accessible ;
- la demande tente d’envoyer directement le message préparé.
Le comportement attendu n’est pas de compléter silencieusement les vides. Le système doit montrer la contradiction, demander la vérification appropriée ou s’arrêter avant l’action interdite. Le commercial peut alors juger si la proposition réduit réellement son travail de préparation sans lui retirer la décision.
Définir le passage en production et le retour arrière
Les critères de passage en production doivent être écrits avant la fin du pilote. Ils peuvent imposer que tous les contrôles de permission réussissent, que les cas critiques produisent l’arrêt attendu et que les corrections courantes restent comprises par l’équipe.
Il n’existe pas de seuil universel valable pour toutes les missions. Une erreur de mise en forme et l’envoi non autorisé d’un message n’ont pas la même gravité. Les critères doivent donc être liés au risque du processus et à la possibilité d’annuler l’action.
La version du modèle, des instructions, des outils, des règles et du jeu de test doit être identifiable. Une modification de l’un de ces éléments peut changer le comportement du workflow. Les cas essentiels sont alors rejoués avant une nouvelle mise en service.
Le retour arrière fait partie du test : l’équipe doit savoir désactiver l’action, revenir à la configuration précédente et reprendre le traitement manuel sans perdre le dossier en cours.
La perspective Pulse
Pulse aborde un employé IA comme un rôle métier délimité, pas comme une démonstration générale. Le test confronte ce rôle aux sources réelles autorisées, aux exceptions et aux frontières de validation avant d’élargir son périmètre.
L’objectif n’est pas de prouver que chaque sortie sera parfaite. Il est de vérifier que les erreurs restent détectables, que les actions engageantes restent contrôlées et que l’équipe sait reprendre la main.
Un employé IA est prêt pour un processus réel lorsque son bon travail est vérifiable et que ses limites le sont aussi.
Sources et repères
- NIST — Generative AI Profile : cadre pour gouverner, cartographier, mesurer et gérer les risques IA.
- CNIL — Utiliser un système d’IA en production : supervision humaine, journalisation et maintien de la qualité.