Le chat est la mauvaise interface pour les agents IA

Le chat est une bonne primitive d’entrée mais un mauvais environnement opérationnel pour les agents. Dès lors qu’un logiciel agit dans la durée — maintenant un état, appelant des outils, prenant des décisions, échouant et se rétablissant — l’interface doit passer de la conversation aux opérations. Les six modèles d’interface ci-dessous définissent ce que les surfaces de contrôle d’agents exigent réellement.

La plupart des agents IA se présentent sous forme de fenêtres de chat. Claude Code est une conversation dans le terminal. Cursor est une conversation dans l’éditeur. Codex exécute des conversations dans le cloud. Devin enveloppe une conversation autour d’un navigateur, d’un terminal et d’un éditeur. Le cadre conversationnel est si dominant que « parler à l’IA » est devenu synonyme de « utiliser l’IA ». La métaphore avait du sens quand le modèle d’interaction était prompt-réponse : vous demandez, l’IA répond, vous évaluez. Un tour. Deux tours. Peut-être dix.

La métaphore s’effondre dès que les agents opèrent de manière autonome.

Ma boucle Ralph exécute Claude Code pendant la nuit. Contexte neuf à chaque itération, mémoire sur le système de fichiers entre les sessions, hooks d’arrêt qui empêchent la terminaison prématurée. Une seule exécution nocturne produit 8 à 15 itérations, chacune avec une fenêtre de contexte complète de 200K tokens. Le système a livré 3 455 lignes de Python de production sur plusieurs sessions sans surveillance.¹ Superviser ces sessions à travers un transcript de chat défilant exigerait de lire des milliers de lignes d’appels d’outils entrelacés, de diffs de fichiers et de traces de raisonnement. Personne ne fait cela. Personne ne peut faire cela. L’interface de chat s’effondre sous le poids de l’opération autonome.

Les praticiens découvrent que la métaphore du chat est inadéquate. Le Codex d’OpenAI s’exécute sans interface dans le cloud et renvoie le travail terminé. Les Claude Routines de Anthropic exécutent des workflows multi-étapes avec des sessions consultables. Devin divise l’écran en navigateur, terminal, éditeur et chat. Chaque produit s’éloigne de la conversation pure vers quelque chose de plus opérationnel. Aucun n’a atteint la solution complète. L’écart entre « chat avec diffs de fichiers » et « tableau de bord des opérations d’agents » reste le plus grand problème UX non résolu dans l’outillage IA.

Cinq façons dont le chat échoue pour les agents

Pas de chronologie des traces

Une session d’agent de 90 minutes génère des centaines d’événements : lectures de fichiers, écritures de fichiers, commandes bash, requêtes de recherche, lancements de sous-agents, événements de compaction et étapes de raisonnement. Le chat présente ces événements sous forme de défilement conversationnel linéaire. Ce format rend impossible de répondre à « que s’est-il passé entre la minute 30 et la minute 45 ? » sans tout lire entre les deux.

Mon système de hooks intercepte 15 types d’événements sur chaque appel d’outil, produisant une télémétrie structurée que l’interface de chat ne fait pas remonter.² La télémétrie existe. La visualisation, non. Quand je débogue une session nocturne échouée, je grep les fichiers de log. Je ne fais pas défiler le chat.

Une chronologie des traces présenterait les événements sous forme de séquence filtrable et zoomable. Montrez-moi uniquement les écritures de fichiers. Montrez-moi uniquement les commandes bash qui ont modifié le système de fichiers. Montrez-moi les points de décision où l’agent a choisi le chemin A plutôt que le chemin B. Les enregistreurs de vol ne présentent pas les événements du cockpit sous forme de transcript conversationnel. Les interfaces d’agents ne devraient pas non plus.

Pas de surface de révision des permissions

Le modèle de permissions de Claude Code interrompt la conversation pour demander une approbation. « Autoriser cette commande bash ? » apparaît en ligne avec le raisonnement de l’agent, et l’utilisateur doit basculer mentalement de la lecture de l’analyse à l’évaluation du risque. Le modèle d’interruption fonctionne pour les sessions interactives. Il échoue totalement pour l’opération autonome, où l’agent a besoin d’approbations par lots et de permissions hiérarchisées par niveau de risque.

Mes 95 hooks fonctionnent comme une couche de permissions programmatique. Les commandes autorisées passent silencieusement. Les motifs bloqués arrêtent l’exécution. Les hooks résolvent le problème d’automatisation, mais ils le résolvent par le code, pas par l’interface.³ Une interface de porte de permission présenterait les approbations en attente dans une file d’attente, triées par niveau de risque, avec un clic pour approuver ou refuser. Les opérations à haut risque (force pushes, déploiements en production, commandes destructives) remonteraient différemment des opérations à faible risque (lectures de fichiers, requêtes de recherche). L’interface communiquerait le risque avant que l’utilisateur n’évalue le contenu.

Pas de navigateur de mémoire

La compaction du contexte efface ce que l’agent savait. La fenêtre de 200K tokens se remplit, le système résume les tours précédents, et l’information disparaît. Mes mesures sur 50 sessions ont montré une dégradation de la qualité des sorties à environ 60 % d’utilisation du contexte, bien avant que la limite dure ne déclenche la compaction.⁴ La recherche sur la dégradation de mémoire de Microsoft Research et Salesforce a confirmé le problème structurel : une baisse moyenne de performance de 39 % entre l’interaction à un seul tour et l’interaction multi-tours, sur 15 LLMs et plus de 200 000 conversations simulées.⁵

L’utilisateur n’a aucune visibilité sur ce qui a survécu à la compaction et ce qui n’a pas survécu. L’agent a-t-il oublié le contrat API établi il y a 40 minutes ? Le graphe de dépendances des modules a-t-il survécu au dernier résumé ? L’interface de chat ne fournit aucun moyen de répondre à ces questions. Un navigateur de mémoire montrerait ce que l’agent détient actuellement en contexte, ce qui a été compacté, ce qui a été perdu, et ce qui persiste dans la mémoire du système de fichiers. Le modèle de mémoire sur le système de fichiers de la boucle Ralph compense la perte de compaction, mais l’opérateur ne peut toujours pas inspecter la mémoire de travail de l’agent sans lire les fichiers d’état bruts.

Pas de jauge de budget de contexte

La consommation de tokens est invisible. L’utilisateur ne sait pas si la fenêtre de contexte est remplie à 40 % ou à 90 %. Le premier signe d’épuisement est une dégradation des sorties : instructions oubliées, suggestions répétées, vision tunnel sur un seul fichier là où l’agent maintenait une cohérence multi-fichiers quelques minutes auparavant.⁴ Le temps que l’utilisateur s’en aperçoive, les dommages de qualité se sont accumulés sur plusieurs tours.

Une jauge de budget de contexte afficherait l’utilisation de tokens en temps réel, l’épuisement projeté selon le taux de consommation actuel de la tâche, et le seuil de compaction. La jauge fonctionnerait comme une jauge de carburant : pas le genre d’information que vous vérifiez chaque seconde, mais le genre d’information dont vous avez besoin avant de vous engager dans une opération longue. « Cette tâche de refactoring consommera environ 80K tokens ; votre budget restant est de 60K » change le calcul décisionnel de l’utilisateur. Aucune interface de chat ne fournit cette information.

Pas d’audit des appels d’outils

Les agents exécutent des outils avec des arguments que l’utilisateur n’inspecte jamais. Une commande bash s’exécute. Un fichier est écrit. Une API est appelée. L’interface de chat affiche le nom de l’outil et parfois la sortie. Les arguments (les instructions réelles que l’agent a envoyées à l’outil) défilent dans un format qui décourage la lecture.

Le mode de défaillance n’est pas hypothétique. Un développeur a signalé que Claude Code avait supprimé toute sa configuration de production, y compris la base de données et 2,5 ans de snapshots.⁶ L’agent a exécuté des commandes destructives sans invite de confirmation et sans interception par des hooks. L’incident remonte à une défaillance d’interface : l’utilisateur ne pouvait pas examiner efficacement ce que l’agent s’apprêtait à faire.

Une surface d’audit des appels d’outils présenterait chaque invocation d’outil avec ses arguments complets, des diffs avant/après pour les opérations sur fichiers, et des capacités de rollback pour les actions destructives. La porte d’évidence traite le problème de vérification au niveau de la sortie, exigeant que les agents citent les chemins de fichiers, les résultats de tests et les noms de patterns avant de marquer le travail comme terminé. Un audit des appels d’outils traite le même problème au niveau de l’exécution, avant que les dégâts ne soient faits.

Six modèles d’interface pour les opérations d’agents

Le chat échoue parce qu’il traite les opérations d’agents comme une conversation. Les six modèles suivants traitent les opérations d’agents comme des opérations.

1. Chronologie des traces

Un journal d’événements chronologique avec détails extensibles à chaque nœud. Chaque lecture de fichier, écriture de fichier, commande bash, appel API, lancement de sous-agent, événement de compaction et point de décision apparaît sur la chronologie. Les utilisateurs filtrent par type d’événement, zooment sur des plages temporelles et développent les événements individuels pour voir les arguments complets et les sorties.

La chronologie résout le problème du « que s’est-il passé ? » que le débogage a posteriori nécessite actuellement une analyse des fichiers de log pour résoudre. Le problème de l’agent invisible (des agents qui consomment des ressources sans visibilité pour l’opérateur) devient visible quand chaque action apparaît sur une chronologie filtrable avec des métriques de consommation de ressources rattachées.

2. Interface de porte de permission

Une file d’attente d’approbations en attente, triées par niveau de risque. Les opérations destructives (déploiements en production, migrations de base de données, force pushes) s’affichent avec des bordures rouges et nécessitent une confirmation explicite. Les opérations en lecture seule (lectures de fichiers, requêtes de recherche) sont auto-approuvées ou approuvées par lot. La surface de la porte affiche la commande complète, l’évaluation du risque et la raison déclarée par l’agent pour l’action.

L’approbation par lots transforme le modèle d’interaction. Au lieu d’interrompre la conversation 47 fois pendant une session nocturne, la porte de permission présente « voici les 12 opérations qui ont dépassé votre seuil d’auto-approbation » dans une seule surface de révision. L’utilisateur traite les 12 en deux minutes au lieu de basculer mentalement 12 fois en six heures.

3. Navigateur de mémoire

Un affichage à trois panneaux : contexte actif (ce que l’agent détient actuellement), résumés compactés (ce qui a été résumé et quand), et mémoire du système de fichiers (ce qui persiste sur disque entre les sessions). Chaque panneau est consultable par recherche. Les utilisateurs peuvent promouvoir des éléments compactés vers le contexte actif ou marquer des mémoires du système de fichiers comme obsolètes.

Le navigateur rend l’état de connaissance de l’agent inspectable. Quand l’agent produit une sortie qui contredit une décision antérieure, l’opérateur peut vérifier si la décision antérieure a survécu à la compaction. Le problème de dégradation de mémoire des agents ne disparaît pas avec un navigateur. Le navigateur rend la dégradation visible, diagnosticable et partiellement récupérable.

4. Jauge de budget de contexte

Un compteur de tokens en temps réel affichant l’utilisation actuelle, l’épuisement projeté selon le taux de consommation glissant, et le seuil de compaction. La jauge inclut une ventilation : combien de tokens pour le prompt système, combien pour l’historique de conversation, combien pour les sorties d’outils, combien pour le contenu des fichiers. La ventilation révèle où va le budget. Fréquemment, les sorties d’outils consomment 60 à 70 % de la fenêtre.

La jauge change les comportements. Mes pratiques de gestion de la fenêtre de contexte (compaction proactive, délégation aux sous-agents, mémoire basée sur le système de fichiers) ont émergé de la mesure de la consommation de tokens sur 50 sessions. Une jauge en temps réel rend ces mêmes mesures accessibles à chaque utilisateur en temps réel, transformant la gestion du contexte d’une pratique d’expert en une contrainte de ressource visible.

5. Révision des appels d’outils

Une surface d’inspection pour chaque invocation d’outil. Les opérations sur fichiers affichent des diffs avant/après. Les commandes bash affichent la commande complète, le répertoire de travail et le code de sortie. Les appels API affichent les payloads de requête et de réponse. Chaque appel d’outil inclut un bouton de rollback qui inverse l’opération (pour les opérations réversibles) ou signale l’opération pour révision manuelle (pour les opérations irréversibles).

La surface de révision remplit un double rôle : supervision en temps réel pendant les sessions interactives et audit a posteriori pendant les exécutions autonomes. La couche de vérification de l’usine obscure explore comment les systèmes autonomes gèrent la vérification sans présence humaine. La révision des appels d’outils est le complément en présence humaine, fournissant la surface d’inspection qui permet une confiance éclairée plutôt qu’une confiance aveugle.

6. File d’attente de supervision

Un tableau de bord multi-agents qui fait remonter les alertes prioritaires à travers des sessions concurrentes. Quand plusieurs agents s’exécutent simultanément (un agent de refactoring, un agent d’écriture de tests, un agent de documentation), la file d’attente agrège leur statut, met en évidence les échecs et route les décisions humaines vers une surface unique.

La file d’attente de supervision importe car l’utilisation des agents se met à l’échelle horizontalement. Un développeur exécutant un seul agent, c’est une conversation. Un développeur exécutant cinq agents sur cinq tâches, ce sont des opérations. L’interface pour les opérations est un tableau de bord, pas cinq fenêtres de chat. La file d’attente priorise par urgence : un déploiement en production qui échoue remonte au-dessus d’une question de formatage de documentation.

Ce qui existe aujourd’hui

Aucun produit n’a construit le tableau de bord opérationnel complet. Plusieurs en ont construit des morceaux.

Claude Code fournit la couche programmatique la plus solide. Les hooks interceptent 15 types d’événements avec des décisions autoriser/refuser/modifier. La commande /cost affiche l’utilisation de tokens de la session. Le système de contexte CLAUDE.md fournit la mémoire sur le système de fichiers. Mais la surface est un terminal. Pas de chronologie visuelle. Pas de file d’attente de permissions. Pas de navigateur de mémoire. L’infrastructure existe sans l’interface.⁷

Cursor a construit les diffs en ligne, une révision primitive des appels d’outils pour les opérations sur fichiers. La surface de diff affiche l’état avant/après et permet d’accepter ou rejeter au niveau du bloc. Le modèle est correct mais étroit : les diffs couvrent les écritures de fichiers mais pas les commandes bash, les appels API ni la coordination de sous-agents.

Devin se rapproche le plus d’une interface opérationnelle. Le produit divise l’écran en navigateur, terminal, éditeur et chat : quatre surfaces qui rendent visibles simultanément différents aspects du comportement de l’agent. La disposition en panneaux reconnaît que la conversation seule est insuffisante. Mais les panneaux sont de la présentation, pas des surfaces de contrôle. L’utilisateur regarde l’agent travailler. L’utilisateur ne met pas en file d’attente des approbations, n’inspecte pas l’état de la mémoire, ni n’audite les arguments d’outils à travers ces panneaux.⁸

Les Claude Routines (livrées en avril 2026) exécutent des workflows multi-étapes en arrière-plan, et chaque exécution crée une session Claude Code consultable. La surface de révision est une chronologie de traces : les utilisateurs peuvent examiner ce que l’agent a fait après coup. Le modèle valide l’argument central : l’exécution en arrière-plan nécessite une surface de révision qui n’est pas la conversation d’origine.⁹

OpenAI Codex s’exécute sans interface dans le cloud et renvoie des diffs. Le modèle d’isolation (environnement sandboxé par tâche) élimine certaines préoccupations de permissions mais en introduit d’autres : l’utilisateur abandonne toute supervision en temps réel en échange d’une sécurité par sandbox. Pas de chronologie opérationnelle dédiée ni de surface de contrôle en cours d’exécution. Le compromis révèle la tension de conception : autonomie complète ou supervision complète, sans rien entre les deux.¹⁰

L’écart entre ces solutions partielles et une interface opérationnelle complète pour agents définit la prochaine frontière concurrentielle dans l’outillage IA.

Les interfaces d’agents sont un problème de design

Les modèles d’interface ci-dessus sont des spécifications d’ingénierie. Les construire exige un jugement de design que les spécifications d’ingénierie seules ne peuvent fournir.

Comment une porte de permission communique-t-elle le risque ? La couleur seule est insuffisante : le rouge signifie « dangereux » dans les contextes occidentaux et « prospérité » dans les contextes chinois. Le choix des icônes, le positionnement spatial, le timing des animations et le ton du texte contribuent tous à l’évaluation du risque par l’utilisateur. Une porte de permission qui fait techniquement remonter la bonne information mais la communique mal entraînera les utilisateurs à cliquer sur « approuver » sans lire. La porte devient du théâtre.

Comment une jauge de budget de contexte communique-t-elle l’urgence sans induire d’anxiété ? Une jauge qui passe au rouge à 80 % d’utilisation peut provoquer une compaction prématurée. Une jauge qui reste verte jusqu’à 95 % peut provoquer un épuisement surprise. Les courbes de seuil, les transitions de couleur et le timing des notifications sont des décisions de goût aux conséquences opérationnelles.

Comment une chronologie de traces gère-t-elle la densité d’information sans submerger l’utilisateur ? Une session autonome de 12 heures génère des milliers d’événements. Tout afficher produit du bruit. Filtrer les événements « importants » exige que l’interface définisse l’importance, un jugement qui varie selon l’utilisateur, la tâche et le mode de défaillance.

Ce sont les mêmes questions auxquelles Dieter Rams a répondu pour l’électronique grand public et Kenya Hara pour le design de l’information. Les questions ne sont pas nouvelles. Le domaine l’est. Le goût est un système technique : contraintes, critères d’évaluation, reconnaissance de patterns et vérifications de cohérence qui se décomposent en infrastructure d’ingénierie. Le design d’interfaces d’agents exige une infrastructure de goût conçue spécifiquement pour l’UX opérationnelle : la capacité de communiquer le risque, la confiance, l’incertitude et l’état des ressources à travers des surfaces visuelles qui permettent une prise de décision rapide sous pression temporelle.

L’entreprise qui traite les interfaces d’agents comme un problème de design, et non seulement comme une liste de fonctionnalités, construira l’interface à laquelle les opérateurs font confiance pour les charges de travail en production. L’entreprise qui traite les interfaces d’agents comme un problème d’ingénierie uniquement construira un tableau de bord techniquement complet et opérationnellement inutilisable.

Le prochain avantage concurrentiel

Le modèle n’est pas l’avantage concurrentiel. Les modèles de pointe convergent sur les benchmarks de capacité chaque trimestre. Le fine-tuning et le RLHF produisent une différenciation significative mais temporaire. La couche modèle est une course à la commodité avec des rendements décroissants sur l’avantage compétitif.¹¹

La couche contexte n’est pas l’avantage concurrentiel non plus. Les fenêtres de contexte passent de 128K à 200K à 1M tokens. Chaque fournisseur s’aligne en quelques mois. Un contexte plus long améliore les capacités mais ne différencie pas les produits.

La surface de contrôle est l’avantage concurrentiel. L’interface qui rend les opérations autonomes d’agents visibles, auditables et gouvernables : cette surface détermine quel produit les entreprises confient à leurs charges de travail en production. L’adoption par les entreprises exige de répondre à des questions que les interfaces de chat ne peuvent pas traiter : Qu’a fait l’agent ? Pourquoi l’a-t-il fait ? Quelles permissions l’agent a-t-il exercées ? Quelles ressources l’agent a-t-il consommées ? Puis-je annuler les actions de l’agent ? Puis-je prouver à un auditeur ce que l’agent a fait ?

Ces questions ne sont pas des questions de prompting. Ce sont des questions d’opérations. Le produit qui y répond remporte le marché qui compte.

Mes 95 hooks sont une réponse programmatique à ces questions, construite depuis le terminal, appliquée par des scripts shell, maintenue par des fichiers de configuration. Les hooks fonctionnent. Ils représentent aussi l’état de l’art : une infrastructure de niveau expert qu’aucun utilisateur non expert ne reproduira. La porte d’évidence vérifie les sorties de l’agent. Les couches d’observabilité de l’agent invisible surveillent le comportement de l’agent. Les pratiques de gestion de la fenêtre de contexte maintiennent la qualité des sessions. Chaque système répond à un besoin opérationnel réel. Chaque système existe sous forme de code, pas d’interface.

L’étape suivante est évidente. Transformer le code en surfaces de contrôle. Transformer les hooks en porte de permission. Transformer la télémétrie en chronologie de traces. Transformer les mesures de tokens en jauge de budget. Transformer la mémoire du système de fichiers en état de connaissance navigable. Transformer la porte d’évidence en surface de révision des appels d’outils.

L’infrastructure existe déjà. L’interface, non. Construire l’interface est un problème de design, un problème d’ingénierie et un problème de goût. L’équipe qui résout les trois livre le produit qui définit la prochaine ère de l’ingénierie IA.

FAQ

Pourquoi ne pas simplement améliorer le chat avec un meilleur formatage ?

Un meilleur formatage traite le symptôme. Le problème est structurel : le chat est un medium séquentiel en ajout seul. Les opérations d’agents nécessitent une inspection à accès aléatoire (sauter à n’importe quel événement), des vues concurrentes (voir l’état de la mémoire à côté des appels d’outils) et une interaction par lots (approuver cinq opérations à la fois). Les améliorations de formatage au sein du chat (sections réductibles, coloration syntaxique, diffs en ligne) aident marginalement mais ne peuvent fournir ni accès aléatoire, ni vues concurrentes, ni interaction par lots dans un transcript défilant.

Les portes de permission peuvent-elles remplacer le jugement humain ?

Les portes de permission augmentent le jugement en présentant les décisions dans un format optimisé pour une évaluation rapide et précise. La porte ne décide pas. Elle fait remonter la décision avec son contexte : la commande complète, le niveau de risque, le raisonnement de l’agent et l’impact potentiel. L’humain décide plus vite et plus précisément parce que l’interface réduit la charge cognitive d’extraction de l’information pertinente d’un défilement conversationnel.

Comment ces modèles s’appliquent-ils aux agents non liés au code ?

Chaque modèle se généralise. Un agent de service client a besoin d’une chronologie de traces (qu’a dit l’agent au client ?), d’une porte de permission (l’agent peut-il émettre un remboursement supérieur à 500 $ ?) et d’un audit des appels d’outils (quelles requêtes de base de données l’agent a-t-il exécutées ?). Un agent de recherche a besoin d’un navigateur de mémoire (quelles sources l’agent a-t-il consultées ?) et d’une jauge de budget de contexte (quelle capacité de récupération reste-t-il ?). Les modèles sont agnostiques au domaine car les défis opérationnels (visibilité, permissions, mémoire, ressources, audit, supervision) sont universels à tout logiciel autonome.

Sources