Interface d'un agent IA : les règles qui évitent le chaos

Une bonne interface d'agent IA ne cherche pas à montrer toutes les pensées du modèle. Elle montre ce que l'agent comprend, ce qu'il va faire, ce qu'il attend, les droits qu'il utilise, l'état réel du travail et la preuve finale. Son rôle est de rendre l'autonomie lisible, interruptible et vérifiable sans transformer chaque action en formulaire.

Le chatbot classique attend une question puis affiche une réponse. Un agent peut chercher, créer un fichier, appeler un outil, modifier une application et demander une validation au milieu d'une mission. Cette différence change toute l'interface.

Si tu reprends une simple fenêtre de chat, l'utilisateur ne sait plus si l'agent réfléchit, agit, attend une permission ou a réellement terminé. Si tu exposes chaque détail technique, tu crées un tableau de bord illisible. L'enjeu est de montrer le bon niveau de contrôle au bon moment.

Voici les règles pour concevoir cette couche sans perdre la vitesse qui rend les agents utiles.

Le vrai travail de l'interface

L'interface doit répondre à six questions en permanence :

1. Qu'est-ce que l'agent pense devoir accomplir ?

2. Quelle action exécute-t-il maintenant ?

3. Quel système ou quelle donnée utilise-t-il ?

4. Pourquoi a-t-il besoin de moi ?

5. Quel est l'état réel du résultat ?

6. Comment arrêter, corriger ou reprendre ?

Ces questions paraissent simples. Pourtant, beaucoup de produits affichent seulement une animation et une phrase du type "Je m'en occupe". C'est rassurant pendant dix secondes, puis inquiétant dès que la mission touche un email, un paiement, un fichier client ou un environnement de production.

Notre guide sur les agents qui contrôlent un ordinateur décrit la couche d'exécution. Ici, on s'intéresse à la couche qui permet à un humain de comprendre et gouverner cette exécution.

Principe 1 : afficher l'intention avant l'action

Avant une mission longue ou sensible, l'agent doit reformuler son objectif en une phrase observable.

Mauvais :

Je vais gérer ton dossier

Meilleur :

Je vais lire les 12 factures, relever fournisseur, date, montant et TVA, puis créer un tableau brouillon sans modifier les fichiers sources

Cette phrase fixe le périmètre, le livrable et la limite. Elle permet de détecter une mauvaise compréhension avant que l'agent parte dans la mauvaise direction.

Ne transforme pas chaque demande en étape de confirmation. Pour une action réversible et locale, l'agent peut commencer. L'intention doit devenir un résumé visible, pas un péage systématique.

Principe 2 : séparer plan, progression et preuve

Ces trois objets répondent à des questions différentes.

Le plan

Il explique les grandes étapes prévues. Trois à six étapes suffisent. Un plan de trente lignes simule le contrôle sans aider l'utilisateur.

La progression

Elle indique l'étape en cours et les événements utiles : source inaccessible, fichier manquant, nouvel écart ou validation nécessaire.

La preuve

Elle montre le résultat observable : fichier créé, brouillon présent, ticket mis à jour, URL en ligne ou données vérifiées.

Une barre à 100 % n'est pas une preuve. Elle décrit l'état interne de l'interface, pas l'état du système externe.

Cette séparation rejoint la méthode d'évaluation d'un agent IA : la trajectoire explique comment l'agent a travaillé, mais seul l'outcome confirme que la mission a réussi.

Principe 3 : demander une validation au moment utile

Une interface trop prudente demande "continuer ?" après chaque étape. Une interface trop agressive agit puis explique. Le bon compromis dépend de l'impact.

Demande une validation quand l'action :

• envoie ou publie un contenu important

• dépense de l'argent

• partage une donnée sensible

• modifie des permissions ou la sécurité

• supprime une donnée difficile à récupérer

• crée un engagement légal ou commercial

• change fortement le périmètre demandé

Pour une lecture, un calcul, un brouillon ou un fichier local réversible, l'agent peut généralement avancer sans interruption.

La spécification MCP sur les outils recommande une interface qui garde l'humain dans la boucle et présente des confirmations pour les opérations. La spécification MCP Sampling prévoit aussi la possibilité de revoir, modifier ou refuser une génération et des appels d'outils imbriqués.

La confirmation doit nommer précisément :

• l'action

• la destination

• les données transmises

• l'effet attendu

• ce qui est réversible

"Autoriser ?" ne suffit pas.

Principe 4 : rendre les permissions compréhensibles

Les noms techniques de scopes ou d'API ne disent rien à la plupart des utilisateurs. Traduis-les en capacités concrètes.

Au lieu de :

Scope mail.write requis

Affiche :

Autorise la création de brouillons dans Gmail. Aucun email ne sera envoyé sans validation séparée

Une permission persistante doit être visible dans les réglages, révocable et reliée aux missions qui l'utilisent. L'utilisateur doit pouvoir distinguer trois niveaux : lire, préparer, agir.

Le principe du moindre privilège doit aussi apparaître dans l'interface. Si l'agent a seulement besoin de lire un calendrier, ne demande pas le droit de supprimer des événements.

Principe 5 : traiter l'attente comme un état normal

Un agent peut attendre un fichier, une connexion, une décision ou la réponse d'un service externe. L'interface ne doit pas présenter cette attente comme une erreur vague.

Utilise des états explicites :

• en cours

• en attente de ta réponse

• en attente d'un service

• bloqué

• terminé avec réserve

• terminé et vérifié

Pour chaque attente, donne une seule action claire. Par exemple : "Connecte Google Drive pour lire le dossier" ou "Choisis la version du contrat à utiliser".

Le protocole MCP appelle ce mécanisme l'elicitation : un serveur peut demander une information à l'utilisateur au milieu d'une interaction. La spécification Elicitation insiste sur deux points utiles : montrer quel serveur demande l'information et permettre à l'utilisateur de revoir sa réponse avant envoi.

Principe 6 : montrer les outils sans exposer tout le bruit

L'utilisateur n'a pas besoin de lire chaque appel technique. Il a besoin de savoir quelles sources et applications ont été utilisées.

Un bon résumé de mission peut afficher :

• sources consultées

• applications modifiées

• fichiers créés

• actions externes déclenchées

• éléments ignorés

• erreurs rencontrées

Garde le détail brut dans une trace développable pour le diagnostic. L'écran principal doit rester lisible.

L'approche ressemble à un reçu bancaire : le résultat principal est visible, mais chaque ligne peut être inspectée en cas de doute.

Principe 7 : construire une vraie reprise en main

Un bouton "Stop" qui ne fait rien pendant trente secondes détruit la confiance. L'interruption doit être une capacité du système, pas seulement un élément visuel.

Prévois quatre actions différentes :

Mettre en pause

L'agent termine l'opération atomique en cours, puis attend. Aucun nouveau travail ne démarre.

Annuler

La mission s'arrête et les actions non appliquées sont abandonnées.

Revenir en arrière

Le système restaure un état récupérable quand c'est possible. Cette capacité demande un historique ou des opérations idempotentes. Elle ne peut pas être inventée par l'interface.

Corriger la direction

L'utilisateur modifie l'objectif sans devoir recommencer toute la mission. L'agent conserve les résultats valides et explique ce qu'il recalcule.

Pour les actions externes irréversibles, montre clairement que "annuler" ne peut pas rappeler un email déjà envoyé ou récupérer un paiement exécuté.

Principe 8 : faire de la preuve un objet de première classe

Le dernier écran ne doit pas dire seulement "Terminé". Il doit montrer ce qui existe maintenant.

Exemples :

• lien vers le document créé

• aperçu du brouillon

• capture du nouvel état

• identifiant du ticket

• URL publique et statut HTTP

• nombre de lignes traitées et exceptions

• reçu de l'outil externe

La preuve doit venir du système concerné. La phrase de l'agent n'est qu'un commentaire.

Pour un agent déployé en entreprise, notre guide déployer un agent IA sans perdre le contrôle recommande déjà de limiter les droits et tracer les actions. L'interface transforme ces garde-fous en informations utilisables par une personne normale.

Principe 9 : utiliser les composants visuels seulement quand ils aident

Tout ne mérite pas une carte, un graphique ou un écran plein. La documentation OpenAI sur les règles d'interface des plugins recommande d'utiliser cartes, carrousels et vues plein écran quand l'interaction visuelle améliore réellement le workflow.

Utilise :

• une table pour comparer plusieurs résultats

• une timeline pour une mission longue

• une carte pour un objet actionnable

• un formulaire pour une donnée structurée

• un aperçu pour valider un document ou un message

Reste en texte quand une phrase et un lien suffisent. Une interface agentique n'est pas meilleure parce qu'elle contient plus de panneaux.

Principe 10 : préserver l'état entre les interactions

Une mission peut durer plus longtemps qu'une conversation. L'interface doit conserver :

• l'objectif

• les choix de l'utilisateur

• les validations données

• les éléments déjà traités

• les preuves produites

• la prochaine action

La référence OpenAI des interfaces expose par exemple un état de composant persistant et recommande de l'enregistrer après chaque interaction significative. Le principe dépasse un fournisseur : si l'utilisateur rouvre la mission, il ne doit pas deviner ce qui s'est passé.

Attention à ne pas confondre persistance et mémoire illimitée. Stocke ce qui sert à reprendre la mission, avec une durée et une possibilité de suppression claires.

Les cinq écrans minimaux

Tu peux couvrir beaucoup de produits avec cinq états d'interface.

1. Brief

Objectif reformulé, périmètre, livrable et limites.

2. Exécution

Étape en cours, progression utile, sources et bouton de pause.

3. Demande

Question ou confirmation précise, raison, effet et options.

4. Blocage

Cause vérifiée, travail déjà conservé et action nécessaire.

5. Résultat

Livrable, preuve, réserves, actions réalisées et possibilité de corriger.

Ce modèle est plus utile qu'un écran différent pour chaque outil. Il s'adapte à une recherche, une automatisation email, une analyse de fichiers ou une publication.

Exemple : agent de préparation commerciale

Imaginons un agent qui prépare un appel à partir d'un CRM, du site du prospect et des emails récents.

Le brief affiche :

Préparer une fiche d'appel sur Acme à partir du CRM, du site public et des emails du dossier. Créer un brouillon dans le dossier Sales. Ne contacter personne

Pendant l'exécution, l'interface montre trois sources consultées et signale qu'un email est inaccessible.

L'agent demande ensuite :

Deux filiales portent le nom Acme. Laquelle correspond au prospect : France ou UK ?

Le résultat final contient le lien vers la fiche, cinq questions, les sources et une réserve sur le budget absent. Il ne prétend pas avoir qualifié un budget qui n'existe pas.

Cette interface crée de la confiance parce qu'elle expose les limites sans ralentir le travail utile.

Les erreurs classiques

Montrer une fausse progression

Une barre animée sans lien avec le travail réel donne une illusion de précision. Utilise des étapes observables ou reste indéterminé.

Cacher les actions externes

Un message envoyé, un fichier partagé ou une permission accordée doit apparaître clairement dans le reçu final.

Confirmer trop tôt

Demander une validation avant d'avoir préparé le contexte oblige l'utilisateur à décider dans le vide. Prépare le brouillon, puis demande la validation sur l'objet exact.

Afficher toute la chaîne de pensée

Les traces internes sont bruyantes et peuvent contenir des hypothèses fragiles. Montre des décisions, sources, actions et erreurs, pas un monologue mental.

Confondre erreur et besoin d'information

Une donnée manquante n'est pas forcément une panne. Transforme-la en question ciblée et conserve le travail déjà fait.

Dire "terminé" avant la vérification

Un outil peut répondre sans que l'état final soit correct. Relis le système externe et utilise un statut "terminé et vérifié" uniquement après cette lecture.

Mesurer la qualité de l'interface

Teste l'interface sur des missions réelles avec quatre métriques simples.

Temps jusqu'à la compréhension

Une personne doit comprendre l'objectif, l'état et la prochaine action en quelques secondes.

Nombre d'interruptions inutiles

Compte les validations qui n'ont changé aucune décision. Elles signalent une prudence mal placée.

Taux de reprise réussie

Après une fermeture ou un blocage, l'utilisateur retrouve-t-il la mission sans réexpliquer tout le contexte ?

Écart entre statut affiché et état réel

Chaque faux "terminé" est un incident de confiance. C'est la métrique la plus importante.

Ajoute ensuite des tests d'accessibilité, mobile, clavier et lecture d'écran. Une mission agentique peut être longue. L'interface doit rester utilisable dans un état de fatigue ou sur un petit écran.

Limites et risque principal

Une bonne interface ne répare pas une architecture dangereuse. Si l'agent possède trop de droits, ne sait pas annuler ou ne vérifie pas ses actions, aucun bouton ne rendra le système sûr.

L'interface doit refléter les capacités réelles. N'affiche pas "annuler" si l'action externe ne peut pas être annulée. N'affiche pas "privé" si la donnée part vers un fournisseur tiers. N'affiche pas "vérifié" si seul le modèle s'est relu.

Le risque principal est le théâtre de contrôle : beaucoup de statuts, de couleurs et de confirmations, mais aucune garantie technique derrière.

FAQ

Une interface d'agent doit-elle rester un chat ?

Non. Le chat est utile pour formuler l'objectif et corriger la direction. Les tables, aperçus, timelines et formulaires sont meilleurs pour inspecter ou valider des objets structurés.

Faut-il montrer toutes les étapes ?

Montre les étapes importantes, les outils utilisés, les erreurs et les actions externes. Garde les détails techniques dans une trace développable.

Quand demander une confirmation ?

Au moment d'une action à impact : envoi, publication, dépense, partage sensible, permission, suppression ou engagement. Les lectures et brouillons réversibles peuvent avancer sans interruption.

Comment prouver qu'une mission est terminée ?

Relis le système concerné et affiche un artefact ou un état observable : lien, fichier, brouillon, ticket, URL, reçu ou capture.

Quelle différence entre pause et annulation ?

La pause conserve la mission et attend. L'annulation arrête le travail restant. Le retour en arrière est une capacité séparée qui dépend de l'architecture.

Avant de partir

Si cet article t'a donné envie de construire au lieu de juste lire : j'ai condensé le démarrage en un guide d'une soirée. Ton premier agent qui produit du travail réel, étape par étape, sans code. Gratuit, contre ton email. Tu recevras aussi Kryve Weekly quand elle sortira : le condensé hebdo de ce qui compte en IA, sans le bruit.

Recevoir le guide

Un email pour te l'envoyer. Pas de spam, désinscription en un clic.