L’interface de l’agent est son cadre d’exécution

OpenAI présente Codex comme un agent d’ingénierie logicielle dans le cloud, capable de lire des fichiers, de les modifier et d’exécuter des tests dans un environnement isolé ; Anthropic documente des hooks capables d’inspecter et de refuser les appels d’outils avant leur exécution.⁴³ Ce ne sont pas des détails secondaires. C’est le produit.

La zone de prompt capte l’attention parce qu’elle ressemble à l’interface. La vraie interface de l’agent se trouve autour d’elle : accès aux outils, règles de permission, chargement de la mémoire, capture des traces, exigences de preuve, contrôles de reprise et barrières de publication. C’est cette couche qui détermine le comportement de l’agent une fois que l’utilisateur cesse de taper.

Un produit agentique ne devient pas fiable parce que son texte d’espace réservé est mieux rédigé. Il devient fiable lorsque la surface qui entoure le modèle transforme l’intention en travail gouverné.

TL;DR

L’interface de l’agent est la couche opérationnelle. Le chat peut recueillir l’intention, mais c’est la surface environnante qui décide ce que l’agent peut voir, ce qu’il peut faire, ce qu’il doit prouver et le moment où un humain doit intervenir. Microsoft a décrit l’interaction humain-IA comme un comportement qui se déploie dans le temps, et le NIST présente la fiabilité comme une qualité que les équipes intègrent à la conception, au développement, à l’usage et à l’évaluation.¹²

L’UX des agents ne peut donc pas s’arrêter à la conception conversationnelle. L’interface doit encoder l’autorité, la mémoire, les limites des outils, les preuves et l’exigence de qualité. Si l’interface ne porte pas ces contraintes, l’agent les improvisera.

Le design agentique est un design de surface de contrôle nomme la surface visible. Le cadre ci-dessous nomme la couche opérationnelle qui la sous-tend.

Points clés

Pour les équipes produit : - Traitez la zone de prompt comme une surface de collecte, pas comme la surface opérationnelle. - Concevez les chemins de permission, de trace, de mémoire, de preuve et de reprise de l’agent avant de polir le chat.

Pour les concepteurs-développeurs : - Placez les règles de qualité là où l’agent agit : avant les appels d’outils, après les modifications, avant la publication et au moment de conclure. - Rendez l’état invisible suffisamment inspectable pour qu’un humain reste responsable du résultat.

Pour les équipes qui adoptent des agents : - Demandez-vous si l’interface montre ce que l’agent a vu, modifié, ignoré et vérifié. - Ne prenez pas une conclusion fluide pour une preuve de travail gouverné.

L’interface décide ce que l’agent peut devenir

Chaque exécution d’agent commence par une intention utilisateur, mais l’intention ne détermine pas seule le comportement.

Le comportement de l’agent dépend aussi de ceci :

Ces couches modifient le travail autant que le modèle. Le même modèle se comporte différemment selon qu’il peut exécuter des tests, seulement modifier des fichiers, voir une barrière de publication, citer ses sources ou être bloqué par une barrière d’arrêt qui empêche une conclusion prématurée.

L’équipe produit qui traite ces couches comme de simples « paramètres » se trompe de médium. Les paramètres restent à l’extérieur du travail. Les couches d’interface d’un agent donnent sa forme au travail.

Les principes d’interaction humain-IA de Microsoft formulent un point plus ancien, mais utile : les systèmes d’IA doivent communiquer leur état, permettre la correction et répondre aux échecs au fil de l’interaction.¹ Les agents rendent cette exigence plus nette, car le système peut agir entre deux interventions de l’utilisateur. L’interface ne peut plus se contenter de dire : « Le modèle a répondu. » Elle doit dire : « Le système a agi sous ces contraintes. »

L’accès aux outils est une question de design d’interface

L’accès aux outils paraît technique. C’est aussi de l’UX.

Un agent qui ne peut répondre qu’à partir de sa mémoire a un type d’interface. Un agent capable de rechercher dans des fichiers en a un autre. Un agent qui peut exécuter des commandes shell, modifier du code, ouvrir des navigateurs, appeler des API et déployer du logiciel a besoin d’un contrat différent avec l’utilisateur.

Le Model Context Protocol décrit un schéma courant : les applications d’IA se connectent à des systèmes externes comme des fichiers locaux, des bases de données, des outils et des flux de travail.⁵ Cette connexion élargit les capacités, mais la capacité ne suffit pas à produire la qualité. Chaque nouvel outil ajoute une question à laquelle l’interface doit répondre :

Une liste d’outils enfouie dans la configuration ne peut pas porter cette responsabilité. L’utilisateur a besoin d’une surface qui rende l’autorité des outils lisible pendant que le travail avance.

Le hook PreToolUse de Claude Code montre la brique primitive. Un hook peut recevoir le nom de l’outil et son entrée avant l’exécution, puis autoriser, refuser, demander, différer ou modifier l’appel.³ Ce mécanisme doit faire partie du modèle mental de la conception d’interface d’agent. L’interface devrait exposer le même point de décision à l’utilisateur, au bon niveau d’abstraction.

Les lectures à faible risque peuvent passer discrètement. Les commandes shell destructrices exigent davantage de friction. Les publications publiques nécessitent une barrière finale. Les changements qui touchent les clients exigent un audit. La bonne interface ne demande pas à l’utilisateur de tout approuver. Elle donne à chaque action le degré de cérémonie qu’elle mérite.

La mémoire fait partie du produit

Dans les produits agentiques, la mémoire arrive souvent comme de l’infrastructure : fenêtres de contexte, fichiers, résumés, bases vectorielles, caches, instructions de projet et systèmes de récupération. L’utilisateur vit ces systèmes comme du comportement produit.

Quand un agent se souvient du standard de design, le produit paraît cohérent. Quand il oublie une contrainte énoncée 40 minutes plus tôt, le produit paraît négligent. Quand il récupère une consigne obsolète, le produit semble hanté par une vieille décision.

La mémoire a besoin d’une interface, parce qu’elle déplace la responsabilité. L’utilisateur ne peut pas superviser ce qu’il ne peut pas inspecter.

L’interface devrait distinguer au moins quatre états de mémoire :

Sans cette distinction, l’utilisateur doit déduire la qualité de la mémoire à partir du comportement de l’agent. C’est l’inverse de ce qu’il faut. L’interface devrait révéler assez d’état mémoire pour permettre à l’utilisateur d’intervenir avant que l’agent ne bâtisse sur une prémisse fausse.

Le même raisonnement vaut pour une philosophie personnelle ou d’équipe. Une doctrine de qualité cachée dans un prompt survivra peut-être à une longue exécution, ou peut-être pas. Une doctrine encodée dans des compétences, des hooks, des modèles, des vérifications et des barrières de conclusion possède davantage de points d’appui. Le modèle peut encore manquer quelque chose. La couche opérationnelle peut rattraper davantage d’écarts, parce que la règle vit là où le travail se fait.

La preuve transforme la sortie en travail

La réponse finale est l’unité de preuve la plus faible d’une exécution d’agent.

Une réponse finale peut affirmer que les tests sont passés alors qu’aucun test n’a été lancé. Elle peut dire que les citations ont été vérifiées alors que la source ne soutient pas l’affirmation. Elle peut annoncer un déploiement réussi pendant que la route publique renvoie un 404 depuis le cache. Une prose fluide peut masquer l’échec.

La preuve doit devenir une surface. L’utilisateur devrait voir l’affirmation, son support et l’écart :

Cette surface de preuve modifie le comportement de l’agent. Quand le système sait que la conclusion exige des preuves, l’agent cherche de quoi prouver pendant la tâche au lieu de rédiger un résumé confiant à la fin.

La barrière de preuve existe pour cette raison. Elle force l’agent à relier ses affirmations à un comportement observé. Les traces d’exécution d’agent sont le contrat d’exécution pousse le même argument plus loin : la trace contient plus de vérité que la réponse finale, car elle conserve le chemin.

Le AI Risk Management Framework du NIST compte ici parce que la fiabilité intervient dans la conception, le développement, l’usage et l’évaluation, pas seulement dans le choix du modèle.² La preuve est le point où ces phases rencontrent l’écran de l’utilisateur.

La reprise appartient au flux principal

Les interfaces d’agents traitent souvent l’échec comme une exception. Le travail agentique rend l’échec ordinaire.

Une requête de recherche ne trouve rien. Un test échoue. Une barrière de permission bloque. Une vérification de traduction détecte une divergence de format. Un déploiement réussit, mais un CDN sert un HTML obsolète. Une bonne interface ne panique pas dans ces états. Elle rend la reprise évidente.

La reprise demande cinq contrôles :

Le chemin de reprise devrait se trouver près des surfaces de trace et de preuve. L’utilisateur ne devrait pas avoir à copier une commande échouée depuis une transcription, deviner le dossier de travail et reconstruire manuellement l’état de l’agent. L’interface connaît déjà l’étape échouée. Elle devrait proposer l’action responsable suivante.

Ce principe vaut aussi pour le travail de contenu. Lorsqu’une barrière de qualité de traduction échoue, l’interface devrait montrer la locale concernée, le segment en échec, la raison et le chemin de réparation. Lorsqu’une page publique échoue à la vérification en production, l’interface devrait indiquer si l’application a échoué, si la base de données a échoué ou si le cache en périphérie a servi une sortie obsolète. L’agent ne devrait pas déclarer une publication terminée tant que le chemin visible par l’utilisateur ne fonctionne pas.

L’exigence de qualité n’est pas un prompt

Le code avec l’IA rend l’implémentation moins chère. Quand l’implémentation devient moins chère, le jugement prend plus de valeur.

La question importante passe de « l’agent peut-il fabriquer quelque chose ? » à « cette version mérite-t-elle d’exister ? ». Cette question appartient autant à l’interface qu’au relecteur humain.

L’exigence de qualité apparaît sous forme de contraintes :

• supprimer l’étape inutile ;
• refuser le chemin ingénieux qui affaiblit le produit ;
• préserver la cohérence entre les artefacts ;
• vérifier le chemin public au lieu de célébrer un succès local ;
• protéger les mécanismes privés du texte public ;
• choisir la solution plus petite, plus nette, plutôt que la plus chargée.

Un agent peut recevoir ces valeurs sous forme de prose. La prose aide. Mais à elle seule, elle ne garantit pas le comportement. Ces valeurs doivent prendre des formes opérationnelles : une compétence de blog qui bloque les tournures paresseuses, un vérificateur de citations qui rejette les affirmations non étayées, un vérificateur de publication qui contrôle les pages en production, une barrière d’arrêt qui refuse la conclusion sans preuve et des règles de design qui évitent la dérive visuelle.

L’interface est l’endroit où l’exigence de qualité devient inspectable. L’utilisateur voit ce que le système a refusé, ce qu’il a simplifié, ce qu’il a vérifié et ce qu’il a laissé sans preuve. Cette trace compte, parce que la production des agents ne fera que devenir moins chère. La ressource rare sera le standard qui décide de ce qui reste.

Une carte pratique de l’interface d’agent

Les équipes peuvent commencer par une carte simple. Nul besoin d’un tableau de bord futuriste.

Cette carte fonctionne parce que chaque surface répond à une responsabilité utilisateur. L’utilisateur n’a pas besoin de chaque événement brut. Il a besoin d’assez de visibilité et de contrôle pour rester comptable du résultat.

Cette distinction évite deux erreurs fréquentes. La première cache tout derrière le chat et appelle cela de la magie. La seconde expose chaque événement interne et appelle cela de la transparence. Une bonne conception d’interface d’agent ne fait ni l’un ni l’autre. Elle donne à l’opérateur le bon contrôle au bon moment.

Résumé rapide

L’interface de l’agent est la couche opérationnelle. Le prompt recueille l’intention, mais les outils, les permissions, la mémoire, les traces, les preuves, la reprise et l’exigence de qualité déterminent ce qui se passe réellement. Codex d’OpenAI et les hooks de Claude Code montrent la direction : les produits agentiques incluent déjà des environnements d’exécution, des appels d’outils et des points de décision de politique.⁴³ MCP élargit la connexion entre agents et systèmes externes.⁵ Le NIST et Microsoft fournissent le cadre plus ancien de la confiance et du design humain-IA.²¹

La question produit n’est plus de savoir si l’agent peut répondre. Elle est de savoir si la surface qui l’entoure gouverne assez bien le travail autonome pour qu’un humain puisse lui faire confiance, l’inspecter, l’interrompre, le réparer et signer le résultat.

FAQ

Que signifie « l’interface est le cadre d’exécution » ?

La formule signifie que l’interface ne se contente pas d’afficher la sortie de l’agent. Elle définit la couche opérationnelle autour du modèle : outils, permissions, mémoire, traces, preuves, reprise et standards. Ces éléments façonnent le comportement avant l’apparition de la réponse finale.

Une interface de chat peut-elle encore fonctionner pour les agents ?

Le chat peut fonctionner comme surface de collecte et comme couloir de revue léger. Il échoue lorsqu’il devient la seule surface opérationnelle. Le travail agentique a besoin d’accès non linéaire, de revue des permissions, d’inspection des traces, de visibilité sur la mémoire et de contrôles de reprise.

En quoi est-ce différent de l’ingénierie de prompt ?

L’ingénierie de prompt façonne l’instruction. La conception d’interface façonne l’autorité, l’état et la responsabilité. Un prompt peut demander à un agent de vérifier son travail. Une surface de publication peut exiger une preuve de route en production avant de permettre la clôture de la tâche.

Que devrait construire une équipe en premier ?

Construisez d’abord les surfaces de trace et de preuve. La trace montre ce qui s’est passé. La surface de preuve montre ce qui établit le résultat. Les permissions, la reprise et la mémoire deviennent plus faciles à concevoir une fois que l’équipe peut inspecter le chemin du travail.

Références