Contrôler une automatisation IA avant de la laisser travailler

Tracer le périmètre et les conséquences

Dessinez le processus tel qu’il doit fonctionner : entrée, traitement, résultat attendu et responsable de la validation. Dans notre exemple, l’entrée est une demande fictive ; le traitement propose une catégorie et un brouillon ; la sortie est soumise à une personne. L’envoi au client reste une étape séparée, hors du périmètre du premier essai.

Cette séparation rend les conséquences plus lisibles. Une mauvaise catégorie peut retarder un traitement. Un brouillon inexact peut être corrigé avant l’envoi. Une action irréversible exécutée automatiquement demande un niveau de contrôle différent. Ne regroupez pas ces situations sous un même indicateur de réussite : elles ne portent pas le même coût d’erreur.

Écrivez aussi les situations que le système ne traite pas. Une pièce jointe illisible, une demande qui manque de contexte ou une instruction inhabituelle peuvent être orientées vers un examen manuel. Cette sortie doit exister dans votre processus, dans l’interface et dans les consignes données à l’IA. Si toutes les demandes doivent obligatoirement recevoir une réponse confiante, vous rendez l’incertitude difficile à gérer.

Le périmètre peut évoluer après les essais. Gardez néanmoins une version datée pour savoir ce qui a été contrôlé. Une démonstration d’un brouillon ne justifie pas, à elle seule, l’ajout d’un envoi automatique.

Construire un jeu d’essai qui montre les différences

Un jeu d’essai utile contient des situations que vous souhaitez distinguer. Pour notre assistant fictif : demande simple, informations manquantes, message avec deux besoins, doublon, contenu hors périmètre et texte qui tente de modifier les consignes du traitement. Ne choisissez pas uniquement des cas propres qui reproduisent votre première démonstration.

Décrivez pour chaque cas le résultat acceptable avant de lancer le système. Il n’est pas toujours nécessaire de rédiger une réponse idéale mot pour mot. Vous pouvez exiger une catégorie parmi une liste, la mention d’une information manquante et l’absence d’envoi. Ces critères facilitent une revue sans vous enfermer dans une seule formulation.

Utilisez d’abord des données fictives ou anonymisées de manière appropriée. Si vous reprenez des exemples réels, les droits d’accès et les règles de conservation doivent être examinés dans votre contexte. Ne diffusez pas le jeu d’essai comme un simple fichier de démonstration s’il contient des informations confidentielles.

Un petit jeu sert à découvrir des défauts et à comparer des versions. Il ne permet pas d’annoncer un taux de fiabilité général. Ajoutez de nouveaux cas à mesure que les erreurs deviennent connues, et gardez certains exemples pour vérifier que la correction d’un problème n’en crée pas un autre.

Faites défiler le tableau horizontalement pour lire toutes les colonnes.

Distinguer la qualité du texte et celle du processus

Le brouillon peut sembler convaincant alors que le processus a perdu une demande. À l’inverse, toutes les étapes techniques peuvent fonctionner tandis que la réponse contient un engagement erroné. Examinez donc deux ensembles de critères : le contenu produit et le chemin suivi pour le produire.

Pour le contenu, regardez les faits conservés, les informations ajoutées, le ton et la capacité à demander une précision. Pour le processus, vérifiez la trace de la demande, le statut affiché, la visibilité d’un échec et la personne qui doit intervenir. Un simple message « terminé » ne suffit pas si personne ne sait ce qui a été transmis ou ce qui reste à faire.

Le cadre de gestion des risques de l’IA du NIST propose de considérer les risques dans la conception, l’usage et l’évaluation des systèmes. Le profil consacré à l’IA générative complète ce cadre. La fiche pratique de cet article s’en inspire pour poser des questions de contrôle ; elle ne constitue ni une certification NIST ni une application exhaustive du cadre.

La bonne grille est celle que votre équipe peut réellement remplir. Commencez avec quelques critères observables, puis ajoutez ceux que les essais rendent nécessaires. Si deux personnes évaluent un même cas différemment, clarifiez le critère avant de chercher un chiffre moyen. Leur désaccord peut montrer une attente mal définie.

Prévoir les exceptions et la reprise humaine

Un processus utilisable doit dire qui reprend une demande et avec quelles informations. « Contacter l’administrateur » reste vague si cette personne ne voit ni le message initial ni l’étape qui a échoué. Préparez un écran ou un journal qui présente le contexte nécessaire, sans révéler plus de données que le rôle ne l’autorise.

Dans notre exemple, une demande incertaine passe au statut « à examiner ». La personne chargée du suivi peut lire l’entrée, la catégorie proposée et la raison du blocage. Elle peut corriger le brouillon ou poursuivre manuellement. Le processus ne doit pas présenter cette intervention comme une anomalie honteuse : c’est une partie prévue du fonctionnement.

Définissez également ce qui se passe en cas d’indisponibilité. La demande est-elle conservée ? Un nouvel essai risque-t-il de créer un doublon ? Quel statut permet de distinguer « pas encore traité » de « traité mais non validé » ? Ces questions se posent avant de relancer automatiquement. Une reprise rapide qui répète une action peut aggraver l’erreur initiale.

Pour le premier atelier, gardez les actions externes désactivées. Simulez la panne, vérifiez le statut et faites reprendre le cas par une personne qui n’a pas construit la démonstration. Si elle doit vous demander oralement chaque étape, la procédure de reprise mérite encore du travail.

Fiche de recette d’un processus IA

Version et date :
Responsable du processus :
Entrées acceptées :
Actions autorisées :
Actions soumises à validation humaine :
Situations hors périmètre :

Pour chaque cas d’essai :
- Situation et données fictives utilisées
- Résultat attendu et critères de refus
- Résultat observé et erreur éventuelle
- Statut visible après le traitement
- Personne chargée de la reprise
- Correction apportée et nouveau contrôle

Décision de fin de recette : usage limité / nouvel essai / arrêt.
Limites connues et date prévue de réexamen :

Comparer une modification sans changer tout le test

Quand vous modifiez une consigne, conservez les mêmes cas d’essai pour observer son effet. Si vous changez en même temps le modèle, les données, le format et les critères, vous pourrez difficilement expliquer pourquoi le résultat est différent. Limitez les changements au problème que vous cherchez à résoudre.

Supposons que le brouillon ajoute une date absente du message. Vous pouvez préciser qu’une date manquante doit être signalée, puis relancer les cas concernés et quelques cas ordinaires. Vérifiez que cette correction n’a pas rendu le système incapable de reprendre une date pourtant fournie. L’amélioration doit se lire dans les résultats, pas seulement dans la nouvelle formulation du prompt.

Notez le temps de vérification humaine. Un processus qui produit vite mais exige une reprise lourde peut rester peu utile dans votre activité. Cette observation ne signifie pas que l’IA ne sert à rien ; elle peut vous conduire à réduire la tâche, mieux structurer les entrées ou conserver une étape manuelle.

Conservez les résultats nécessaires pour comparer les versions, avec une politique de conservation adaptée à vos données. Le journal de recette n’a pas à devenir un entrepôt permanent de messages clients. Sa fonction est de soutenir une décision et de permettre de comprendre une erreur connue.

Ouvrir un usage limité avec des règles explicites

La fin d’une recette ne signifie pas que vous devez tout automatiser. Vous pouvez autoriser uniquement la préparation de brouillons, sur un type de demande précis, avec une vérification systématique. Décrivez cette règle dans le fonctionnement quotidien et vérifiez qu’elle correspond aux permissions réelles du système.

Choisissez les informations qui permettent de suivre l’usage : demandes à examiner, corrections fréquentes, échecs techniques et temps de reprise. Ne collectez pas des indicateurs simplement parce qu’un tableau peut les afficher. Chaque signal doit aider une personne à comprendre un problème ou à prendre une décision.

Préparez une manière de suspendre le traitement et de revenir à la procédure manuelle. La personne responsable doit pouvoir le faire sans reconstruire toute l’installation. Testez cette interruption, puis la reprise, dans l’environnement d’essai. Une fonction d’arrêt jamais utilisée en recette demeure une hypothèse sur laquelle vous comptez.

Enfin, choisissez ce qui déclenche une nouvelle vérification : changement d’outil, nouveau type de demande, évolution des documents sources ou erreur inattendue. La validation appartient à un périmètre et à une version. Elle n’est pas acquise pour toutes les utilisations futures du même système.

Questions à trancher avant l’usage réel

Combien de cas faut-il tester ? Le nombre dépend des situations, des conséquences et des exigences de votre contexte. Un petit atelier permet de découvrir des erreurs ; il ne suffit pas à certifier un usage sensible. Si vous ne pouvez pas décrire les cas importants, commencez par cartographier le processus plutôt que choisir un seuil arbitraire.

Une validation humaine suffit-elle ? Elle doit être réalisable et éclairée. Si la personne n’a pas les informations, le temps ou l’autorité nécessaires, le bouton de validation n’apporte pas le contrôle attendu. Donnez-lui la possibilité de corriger et de refuser, avec une procédure compréhensible.

Faut-il automatiser l’envoi dès que les brouillons paraissent bons ? Traitez cette évolution comme une nouvelle décision. L’envoi change les conséquences d’une erreur. Il exige de revoir les permissions, les exceptions, le suivi et le besoin de validation. Dans l’exercice de ce guide, les brouillons restent soumis à relecture.

Par où commencer demain ? Prenez un processus limité, écrivez ses sorties acceptables et provoquez une information manquante. Si vous retrouvez la demande, comprenez le blocage et savez la reprendre, vous disposez d’un premier résultat concret. Ajoutez ensuite les situations qui rendent votre activité différente d’une démonstration standard.