La conception agentique est une conception de surfaces de contrôle

La plupart des travaux d’interface autour de l’IA traitent encore l’agent comme une zone de texte plus intelligente. La conception agentique part d’un autre principe : dès qu’un logiciel peut agir dans la durée, appeler des outils, toucher à des fichiers, dépenser de l’argent ou modifier un état en production, le problème de conception devient un problème de surface de contrôle.

La conception agentique consiste à rendre un logiciel autonome visible, interruptible, inspectable, réversible et digne de confiance. Le produit n’est pas la transcription du chat. Le produit, c’est la surface qui permet à un humain de comprendre ce que fait l’agent, de décider ce qu’il peut faire ensuite et de vérifier ce qu’il a déjà fait.

Ce cadre compte, car les agents n’échouent pas comme des formulaires, des tableaux de bord ou des copilotes ordinaires. Un formulaire échoue au moment de l’envoi. Un tableau de bord échoue en affichant des données périmées. Un copilote échoue en proposant un mauvais texte. Un agent échoue par son mouvement : il prend la mauvaise branche, choisit le mauvais outil, passe à côté de la bonne preuve, perd le contexte, abuse de ses permissions, s’arrête trop tôt ou réussit localement tout en affaiblissant le produit dans son ensemble.

La conception doit passer du polissage du prompt au contrôle opérationnel.

TL;DR

La conception agentique n’est pas une « UX pour l’IA » abstraite. C’est la conception de surfaces de contrôle pour des systèmes qui agissent. Microsoft avait déjà présenté l’interaction humain-IA comme un problème distinct de conception d’interface plusieurs années avant les agents de code actuels, et Google PAIR conserve le même fil conducteur centré sur l’humain dans ses recommandations de conception pour l’IA.¹² Les produits d’agents modernes rendent ce besoin plus net : OpenAI décrit Codex comme un agent cloud qui travaille dans un environnement isolé, tandis que Claude Code expose des points d’accroche capables d’intercepter les appels d’outils avant leur exécution.⁵⁴

La conséquence pratique : les produits agentiques ont besoin de surfaces pour l’état, les permissions, les traces, la mémoire, les preuves, le retour arrière et la supervision. Le chat peut rester une entrée. Il ne peut pas rester toute l’interface.

Points clés

Pour les designers produit : - Concevez l’état de l’agent avant de concevoir la saisie du prompt. L’utilisateur doit savoir si l’agent planifie, agit, est bloqué, attend, vérifie ou a terminé. - Traitez la revue des permissions comme un flux de travail principal. Un appel d’outil risqué ne doit pas ressembler à une simple interruption de chat.

Pour les personnes qui construisent des agents : - Journalisez assez de détails d’exécution pour alimenter une surface de trace. Les noms d’outils ne suffisent pas ; la surface a besoin des arguments, sorties, états de sortie, chemins de fichiers et effets de bord. - Faites de l’interruption et de la récupération des primitives de premier plan. Un utilisateur doit pouvoir mettre un agent en pause, l’inspecter, le rediriger, revenir en arrière ou le dupliquer sans lire toute la transcription.

Pour les équipes qui adoptent des agents : - Ne mesurez pas la qualité de l’interface à la fluidité du chat. Mesurez plutôt si l’opérateur peut répondre : que s’est-il passé, pourquoi, avec quelle permission et avec quelles preuves ? - Gardez le jugement esthétique dans la boucle. Une action correcte d’un agent peut malgré tout nuire à la cohérence, à la dignité ou à la qualité du produit.

L’utilisateur a changé

L’utilisateur d’un produit agentique n’est plus seulement une personne qui rédige des prompts. Il devient opérateur.

Une personne qui formule des prompts demande une réponse. Un opérateur supervise un processus. La première se demande si le texte sonne juste. Le second se demande si le système a touché les bons fichiers, utilisé les bonnes sources, respecté les bonnes contraintes et s’est arrêté au bon moment.

Cette différence transforme l’interface. Les zones de prompt optimisent l’expression. Les surfaces de contrôle optimisent l’état, le risque, le timing et la preuve.

Les logiciels traditionnels peuvent masquer le processus, car l’utilisateur déclenche directement la plupart des changements d’état. Un bouton dit « Envoyer ». L’utilisateur clique. L’application envoie. Les logiciels agentiques insèrent un environnement d’exécution décisionnel entre l’intention et l’action. L’utilisateur demande un résultat, et le système choisit un chemin. L’interface doit révéler assez de ce chemin pour que l’utilisateur reste responsable du résultat.

Les recommandations de Microsoft sur l’interaction humain-IA vont dans ce sens. Elles couvrent le comportement des systèmes d’IA tout au long de l’interaction : définir les attentes, s’adapter au contexte social, afficher l’état, permettre la correction et gérer les échecs.¹ Cette leçon ancienne s’applique très bien aux agents, mais les agents en relèvent les enjeux, car le comportement de l’IA ne s’arrête plus à une recommandation. Il peut devenir un appel d’outil.

La conception agentique commence par l’état

Une bonne conception agentique rend l’état visible avant de demander la confiance.

Un agent a plus d’états que « réflexion » et « terminé » :

La plupart des produits de chat replient tous ces états dans un seul indicateur animé. Un indicateur dit que le système ne s’est pas arrêté. Il ne dit pas si l’agent lit, écrit, attend, réessaie ou est coincé.

L’état agentique demande un vocabulaire plus riche. La surface doit montrer la phase actuelle, la dernière action significative, la prochaine action prévue et la raison pour laquelle l’agent n’a pas fini. Une bonne surface d’état réduit l’anxiété de l’utilisateur, car elle remplace le mystère par un mouvement inspectable.

La vraie difficulté de conception tient à la densité. Un agent sérieux peut générer des milliers d’événements pendant une exécution longue. Tout afficher crée du bruit. Tout cacher crée une confiance aveugle. La surface de contrôle doit résumer par défaut et se déplier à la demande.

La permission est une matière de conception

La permission n’est pas une page de paramètres. C’est l’une des matières centrales de la conception agentique.

Les agents agissent au moyen de l’autorité que l’utilisateur leur accorde. Écritures de fichiers, commandes shell, actions dans le navigateur, appels API, étapes de déploiement, opérations de paiement et actions affectant des clients n’ont pas le même niveau de risque. L’interface doit rendre ce risque lisible au moment de la décision.

La référence des points d’accroche de Claude Code montre la forme primitive de cette idée : un point d’accroche PreToolUse peut inspecter une commande Bash et renvoyer une décision qui refuse une opération destructrice avant l’exécution de l’appel d’outil.⁴ Ce mécanisme révèle la forme de conception. Une surface de contrôle peut trier les opérations en attente par niveau de risque, afficher la commande ou la charge utile complète de l’outil, expliquer la raison de l’appel et permettre à l’utilisateur d’approuver, refuser, différer ou réécrire la demande.

Le basculement essentiel : la revue des permissions doit devenir une file d’attente, pas une interruption.

Les interruptions fonctionnent pour une ou deux décisions. Elles échouent quand l’agent effectue 40 opérations au fil d’une tâche longue. Une file d’attente de permissions permet à l’utilisateur d’approuver par lots les actions à faible risque, de suspendre les actions à haut risque et d’examiner tout le profil de risque au même endroit. L’utilisateur cesse d’être tiraillé entre la lecture de la prose de l’agent et l’évaluation des commandes.

La présentation du risque demande aussi du goût. Bordures rouges, icônes d’avertissement et frictions modales peuvent aider. Elles peuvent aussi habituer l’utilisateur à approuver les alertes machinalement lorsque tout paraît urgent. L’interface doit réserver l’alarme visuelle aux actions irréversibles ou visibles de l’extérieur. Une recherche en lecture seule ne doit pas porter le même costume qu’une migration de base de données en production.

La trace est la nouvelle architecture de l’information

La conception agentique a besoin d’une architecture de trace.

Une trace est l’enregistrement ordonné de ce que l’agent a fait : prompts, appels d’outils, arguments, fichiers lus, fichiers modifiés, commandes exécutées, sources ouvertes, sorties de tests, décisions de permission, nouvelles tentatives et preuves finales. Une transcription de chat peut contenir des morceaux de cet enregistrement, mais une transcription n’est pas une architecture de l’information. C’est un simple défilement.

La surface de trace doit répondre rapidement à quatre questions :

Cette surface se relie directement à la barrière de preuve. Une réponse finale qui dit « les tests sont passés » doit pointer vers la commande de test et son état de sortie. Un article public qui cite un papier doit pointer vers la source exacte et l’alignement avec l’affirmation. Un rapport de migration qui affirme une parité doit pointer vers le parcours utilisateur précis qui fonctionne encore.

Les recherches récentes sur les traces d’exécution vont dans le même sens. Dans Les traces d’exécution des agents sont le contrat d’exécution, j’ai soutenu que la réponse finale est l’unité de confiance la plus faible. La trace est plus solide, car elle conserve le chemin qui relie l’intention, l’action et la preuve.

La mémoire a besoin d’un navigateur

La conception agentique a aussi besoin d’une conception de la mémoire.

Les agents transportent du contexte dans le temps. Une partie se trouve dans la fenêtre active. Une autre dans des résumés compactés. Une autre encore dans des fichiers, notes, bases vectorielles, bases de données ou instructions de projet. Une partie disparaît. L’utilisateur voit rarement la frontière.

Cette invisibilité crée un échec de conception. Quand un agent contredit une décision précédente, l’utilisateur ne peut pas savoir s’il n’est pas d’accord, s’il a oublié, s’il a mal résumé ou s’il n’a jamais chargé la mémoire pertinente. Le chat donne à la mémoire une impression de continuité, même lorsque l’environnement d’exécution a changé ce que le modèle peut voir.

Un navigateur de mémoire doit exposer trois couches :

Ce navigateur n’a pas besoin de révéler une chaîne de pensée privée. Il doit révéler la mémoire opérationnelle : instructions, contraintes, chemins de sources, décisions, artefacts et résumés que le système utilisera pour guider de futures actions.

La recherche appartient à la même famille de conception. Le résultat grep/vector de l’article précédent montrait que la qualité de recherche dépend de l’environnement d’exécution, du chemin de livraison et de la capacité du modèle à fermer la boucle d’outil, pas seulement du récupérateur.⁶ Si la recherche vit dans l’environnement d’exécution, sa visibilité doit vivre dans l’interface. L’utilisateur doit savoir ce que l’agent a cherché, ce qu’il a manqué, ce qu’il a ouvert et pourquoi la requête suivante a changé.

Superviser n’est pas microgérer

Les produits agentiques présentent souvent la supervision humaine comme une friction. Une bonne conception agentique traite la supervision comme le produit.

Le NIST décrit l’AI Risk Management Framework comme une manière d’intégrer les considérations de fiabilité dans la conception, le développement, l’utilisation et l’évaluation des systèmes d’IA.³ Cette formulation compte. La fiabilité n’intervient pas seulement au moment de l’entraînement du modèle. Elle intervient au moment de la conception, de l’usage et de l’évaluation.

Pour les agents, superviser signifie que l’utilisateur peut :

• voir ce que fait l’agent ;
• interrompre avant une action irréversible ;
• inspecter le chemin de preuve ;
• récupérer après une branche échouée ;
• comparer des branches alternatives ;
• approuver ou refuser l’artefact final ;
• comprendre ce qui reste non vérifié.

La microgestion demande à l’utilisateur d’approuver chaque frappe. La supervision lui donne le bon contrôle à la bonne altitude. Un ingénieur senior n’a pas besoin de surveiller chaque lecture de fichier. Il doit en revanche voir une migration de base de données proposée, une nouvelle tentative après un test échoué, une affirmation publique modifiée ou une commande qui touche l’état de production.

Les bonnes surfaces de supervision préservent le flux en sortant les détails à faible risque de la voie principale et en mettant au premier plan les moments à haut risque. Le défi de conception n’est pas « plus de visibilité ». Le défi, c’est une visibilité calibrée.

La couche du goût compte toujours

La conception agentique peut satisfaire toutes les exigences opérationnelles et pourtant sonner faux.

Une file d’attente de permissions peut exposer les bons faits tout en donnant à l’utilisateur l’impression d’être puni. Une chronologie de trace peut contenir chaque événement tout en rendant la compréhension impossible. Un navigateur de mémoire peut afficher chaque élément stocké tout en détruisant la confiance de l’utilisateur par l’encombrement. Un indicateur d’état peut dire la vérité tout en donnant l’impression que le système est cassé.

Le goût décide comment la surface porte le risque, la confiance, l’incertitude et la preuve. Le goût est un système technique : contraintes, critères d’évaluation, reconnaissance de motifs et cohérence. La conception agentique a besoin des quatre.

Les contraintes décident ce que l’agent peut faire sans revue. Les critères d’évaluation décident ce que l’artefact final doit prouver. La reconnaissance de motifs repère le flux de travail qui semble réussir mais paraît fragile. La cohérence demande si le travail de l’agent a amélioré tout le produit ou seulement terminé la tâche locale.

Cette dernière question devient plus importante à mesure que les agents coûtent moins cher. L’IA rend la production abondante. L’abondance augmente la valeur du refus, de l’édition, de la cohérence et du goût. La meilleure interface agentique ne maximisera pas les actions. Elle aidera l’opérateur à décider quelles actions méritent d’avoir lieu.

Une checklist minimale de conception agentique

Commencez par sept surfaces :

Aucune de ces surfaces n’exige une interface de science-fiction. La première version peut être faite de tableaux sobres, de lignes extensibles et de filtres ordinaires. Une animation sophistiquée compte moins qu’un état honnête. La surface de contrôle doit dire la vérité rapidement.

La question de conception pour chaque fonctionnalité agentique devient simple :

Que doit voir, décider, interrompre ou vérifier l’humain avant que la prochaine action de l’agent ne devienne réelle ?

Si l’interface ne peut pas répondre à cette question, le produit repose encore sur un théâtre de confiance.

Résumé rapide

La conception agentique est une conception de surfaces de contrôle. Le chat reste utile comme primitive d’entrée, mais le travail autonome a besoin d’un état visible, de files d’attente de permissions, de traces, de navigateurs de mémoire, de surfaces de preuve, de contrôles de récupération et de vues de supervision. Microsoft, Google et le NIST pointent tous vers une conception de l’IA centrée sur l’humain et vers la fiabilité comme responsabilités produit, pas seulement comme propriétés du modèle.¹²³ Les outils agentiques rendent ce point concret : l’environnement d’exécution possède déjà des points d’accroche, des conteneurs, des traces, des fichiers, des commandes et des effets de bord.⁴⁵ L’interface doit rendre ces éléments lisibles.

Le produit agentique gagnant ne sera pas celui qui aura le chat le plus charmant. Ce sera celui qui donnera aux opérateurs la surface la plus claire, la plus nette et la plus fiable pour le travail autonome.

FAQ

La conception agentique est-elle différente de l’AI UX ?

Oui. L’AI UX couvre toute expérience qui utilise l’apprentissage automatique ou l’IA générative. La conception agentique couvre les systèmes qui agissent dans la durée. La différence, c’est l’agentivité : appels d’outils, permissions, changements d’état, mémoire, effets de bord et récupération. Ces propriétés exigent des surfaces de contrôle, pas seulement une microcopie utile ou une saisie de prompt.

Tous les produits agentiques ont-ils besoin des sept surfaces ?

Non. La surface nécessaire doit correspondre au risque. Un assistant de rédaction à faibles enjeux peut avoir besoin d’un état, de preuves et d’un historique de révision. Un agent de code ou d’opérations a besoin de permissions, de traces, de récupération, de mémoire et de supervision. Un agent qui affecte des clients a besoin de contrôles d’audit et d’approbation encore plus solides.

Pourquoi ne pas tout garder dans le chat ?

Le chat est séquentiel et fonctionne uniquement par ajout. Superviser un agent exige un accès direct, du filtrage, de la comparaison, une revue par lots et l’inspection de l’état. Des blocs de chat repliables peuvent améliorer la lisibilité, mais ils ne peuvent pas remplacer une file d’attente de permissions, une chronologie de trace, un navigateur de mémoire ou une surface de récupération.

Quelle surface de contrôle faut-il construire en premier ?

Construisez d’abord la trace. Sans trace, toutes les autres surfaces deviennent des approximations. La trace fournit les données nécessaires aux preuves, permissions, récupérations, audits et supervisions. Un produit peut commencer par un simple tableau d’événements et améliorer la conception au fil du temps.

Références