🚀 Agent IA : test de la reprise en main (2026)

Une approbation n'est pas une preuve de contrôle

Quelqu'un peut approuver parce qu'il a compris la proposition et vérifié les éléments pertinents. Il peut aussi approuver par habitude, sous pression, ou parce que l'interface rend la vérification difficile à repérer. Le résultat visible est le même : un clic sur « Approuver ». Les causes, elles, ne le sont pas.

C'est pour ça que les enquêtes du type « Faites-vous confiance à l'agent ? » ne mesurent pas ce qui compte ici. Elles capturent une perception déclarée, pas un comportement face à une information manquante. Pour améliorer l'interface, il faut regarder un geste vérifiable : la personne ouvre-t-elle la règle avant de valider ? Peut-elle expliquer ce que risque une validation erronée ?

Le bon objet de test est le moment réversible

Le test doit porter sur une décision limitée et sur l'instant juste avant l'exécution. Tant que le remboursement reste un brouillon, le réviseur peut encore vérifier la règle, modifier la proposition ou arrêter le processus. Une fois l'action envoyée, revenir en arrière peut exiger du support, coûter de l'argent, et abîmer la relation client.

Il faut donc cadrer clairement :

• La décision proposée : ce que l'agent veut faire, avec son montant ou son périmètre.
• L'élément manquant : la preuve ou la règle que le réviseur doit consulter.
• Le premier geste correct : l'action attendue avant toute approbation.
• Le point d'arrêt : le moment après lequel l'action devient difficile ou impossible à inverser.
• Le coût d'une erreur : conséquences financières, opérationnelles, juridiques ou humaines.

Ce cadrage force une question simple et utile : quelle information doit empêcher une approbation tant qu'elle n'a pas été vérifiée ? Tout détail qui ne change pas la décision risque d'ajouter du bruit.

1. Décrire le scénario dans un fichier

Les intentions notées pendant une réunion se prêtent mal à l'évaluation. Un scénario structuré permet de comparer des essais et de repérer les ambiguïtés avant d'inviter des participants.

Par exemple :

{
"id": "remboursement-01",
"decision": "Approuver un remboursement de 42 €",
"etat_agent": "Brouillon prêt, rien n'a été envoyé",
"interruption": "avant l'envoi",
"information_manquante": "Délai de remboursement : 30 jours après livraison",
"premiere_action_attendue": "ouvrir la clause de la politique",
"echec": "la personne approuve sans ouvrir la clause"
}

Le critère principal n'est pas de savoir si la personne dit faire confiance. L'enjeu est de vérifier si elle consulte la clause avant de valider. Faites lire le scénario à un collègue qui n'a pas contribué à l'écriture. S'il ne sait pas dire qui décide, ni ce qu'un clic incorrect déclencherait, clarifiez avant de lancer l'exercice.

2. Présenter une interface, pas une diapositive

Une diapositive raconte un parcours ; une interface le rend testable. Une petite page suffit : afficher le brouillon, masquer la clause derrière un lien, proposer un bouton d'approbation. Quand on clique sur le lien, la règle apparaît et l'événement est enregistré. Quand on clique sur le bouton, l'approbation est enregistrée.

La maquette n'a pas besoin de déclencher un vrai remboursement. Elle doit surtout représenter fidèlement le moment où la décision se prend, pas toute l'architecture de l'agent. Un serveur minimal en Python, avec la bibliothèque standard, peut convenir : gardez-le isolé et ne lui confiez aucune action réelle.

Avant de faire passer des participants, validez le protocole : ouvrez la page, déclenchez les deux actions, vérifiez qu'elles apparaissent bien dans le journal. Si l'événement « clause consultée » n'apparaît pas quand vous le faites vous-même, inutile de mettre la responsabilité sur les participants.

3. Enregistrer les actions, pas seulement les impressions

Chaque événement devrait contenir au minimum un identifiant de session, l'action et une date ou heure. Vous pourrez ainsi analyser l'ordre des gestes et le temps écoulé avant la première action pertinente. Le taux de validations sans consultation compte, mais le délai compte aussi : une preuve disponible techniquement, mais rarement trouvée dans les conditions de travail normales, restera inefficace.

Prévoyez des événements séparés, par exemple : « clause ouverte », « approbation demandée », « proposition modifiée », « processus interrompu ». Définissez ce que ces événements signifient avant d'analyser. Un journal de clics ne mesure pas automatiquement la compréhension, la qualité du jugement, ni le taux d'erreur en production.

Attention aux prototypes trop simplifiés : si le verdict est calculé à partir de l'ensemble du fichier de journal, un clic d'une session précédente peut fausser le résultat. Ajoutez un identifiant de session et calculez le verdict par session. Pour un test ponctuel, effacer le journal entre essais peut dépanner, mais ce n'est pas une approche robuste pour enchaîner plusieurs sessions.

4. Lire un script fixe, puis se taire

Le facilitateur influence déjà les résultats dès qu'il suggère où cliquer ou reformule la règle. Préparez une consigne neutre, par exemple : « Ceci est un brouillon. Rien n'a encore été envoyé. Validez quand vous êtes prêt. » Puis laissez la personne agir.

Si elle demande ce que dit la clause, ne lui donnez pas la réponse. Vous pouvez rappeler qu'elle peut utiliser l'interface comme elle le ferait en conditions réelles, mais toute aide sur le contenu transforme l'exercice en démonstration guidée. Notez la question, la difficulté et les actions observées : c'est de l'information, pas un moment pour « corriger » le participant.

5. Créer des variantes comparables

Un seul parcours ne dit pas si l'interface sera robuste. Préparez plusieurs variantes en modifiant une dimension à la fois : le libellé du lien, sa visibilité, l'ordre des champs. Gardez la même décision et la même action correcte attendue. Si vous changez aussi le texte, la disposition et la règle, vous ne saurez pas ce qui a réellement changé le comportement.

Écartez les variantes qui rendent la réponse évidente ou celles qui ne peuvent pas échouer. Un test utile doit laisser une vraie place à l'erreur : sinon, vous mesurez seulement la capacité à suivre une instruction. Les outils de génération de texte peuvent aider à produire des formulations à tester, mais chaque variante doit être validée par une personne responsable du contenu et du scénario.

À noter : l'article d'origine indique que l'accès gratuit aux modèles et au serveur MonkeyCode a contribué à la production des variantes et à l'hébergement du prototype. Comme il s'agit d'offres fournies par l'opérateur, elles peuvent évoluer : vérifiez les conditions en vigueur avant de vous appuyer sur un quota ou une fonctionnalité.

6. Tester sur téléphone et avec des aides techniques

Une page pensée pour ordinateur ne représente pas forcément l'usage réel. Testez sur téléphone, d'une seule main, avec ou sans son. Vérifiez si le bouton d'approbation est plus facile à toucher que le lien vers la preuve. Un petit détail comme celui-ci peut révéler un défaut avant le déploiement.

Testez aussi la navigation au clavier, la visibilité du focus, l'ordre de lecture avec un lecteur d'écran et la clarté des libellés. « Approuver » ne dit pas toujours ce qui sera approuvé. « Envoyer le remboursement de 42 € » décrit mieux l'action et son périmètre. Exclure certains réviseurs produit des résultats incomplets et peut masquer un risque.

7. Vérifier la sécurité du prototype

Un serveur conçu pour un exercice n'est pas un service de production. Un prototype accessible sans authentification, sans chiffrement, ou qui écoute sur trop d'interfaces réseau, ne doit pas exposer des données réelles. Utilisez des données fictives, limitez l'accès, vérifiez la durée de conservation des journaux et évitez d'y mettre des données personnelles inutiles.

Même si un hébergement gratuit aide à ouvrir le lien sur téléphone, suivez la documentation de la plateforme et contrôlez ses paramètres réseau. Ne confondez pas « la page est accessible » avec « le dispositif est sûr ». Pour des données personnelles ou un traitement métier réel, faites examiner le dispositif au regard du RGPD et des règles internes applicables. La CNIL propose des ressources sur l'intelligence artificielle et la protection des données.

Ne pas blâmer le réviseur trop tôt

Si quelqu'un approuve sans ouvrir la clause, commencez par regarder le parcours. Le lien est-il visible ? Le libellé explique-t-il pourquoi il faut l'ouvrir ? L'action d'approbation domine-t-elle visuellement ? La personne pensait-elle que l'agent avait déjà vérifié la règle ?

Une erreur qui se répète vient souvent d'une interface qui rend le mauvais geste plus facile, pas d'un manque d'attention individuel.

Après chaque modification, refaites le test. Changer le texte du lien peut aider, mais ce n'est pas une garantie si l'information reste éloignée du bouton ou si le modèle de responsabilité reste flou. L'objectif n'est pas d'obtenir « un clic conforme » une fois : c'est de concevoir un contrôle qui tient dans des conditions d'usage réalistes.

Réduire l'autonomie quand le contrôle n'est pas réel

Si les participants n'arrivent pas à comprendre ce qui sera déclenché, ou si l'action ne peut pas être interrompue à temps, ce n'est pas forcément un simple problème de consigne. Il faudra peut-être renforcer la validation (une deuxième approbation), limiter le montant autorisé, ou retirer à l'agent la capacité d'exécuter l'action.

C'est un arbitrage entre vitesse et maîtrise. Automatiser davantage peut réduire le coût, mais une erreur de remboursement répétée peut annuler le bénéfice : corrections, demandes au support, perte de confiance. Le niveau d'autonomie doit suivre le risque et la solidité des mécanismes de reprise, pas seulement la performance technique du modèle.

Ce que le test ne démontre pas

Cet exercice évalue un passage de relais dans un scénario simulé. Il ne prouve ni la fiabilité globale du modèle, ni sa conformité, ni ses performances en production. Les comportements réels dépendront de variations de données, d'interruptions, de règles métier et d'intégrations que la maquette ne reproduit pas.

Il ne remplace donc pas les tests techniques, ni la supervision en production, ni une analyse de risques, ni un examen réglementaire. Il est aussi peu adapté aux contextes où revenir en arrière est impossible : si l'action est définitive, il faut mettre des garde-fous en amont, pas un exercice d'approbation qui arrive trop tard.