L'interface après le chatbot
La boîte qui a appris à tout le monde à poser des questions
Le chatbot a fait quelque chose d'important. Il a donné aux gens ordinaires un moyen de toucher un modèle puissant sans apprendre une nouvelle interface de contrôle. Tapez une demande. Recevez une réponse. Demandez à nouveau. Cette simplicité comptait. Elle a rendu l'IA moins semblable à un instrument de laboratoire et plus à un collègue qui avait trop lu et qui, de temps en temps, inventait des choses avec une excellente posture. Pendant un temps, la boîte de texte vide a été exactement la bonne porte.
Puis les équipes ont essayé de faire passer du travail sérieux par cette porte. Rédiger une politique, vérifier un dossier, comparer des fournisseurs, préparer un plan de soins, trier un incident, examiner un contrat, enquêter sur une plainte, établir un calendrier, rapprocher des données sources. La boîte de discussion pouvait aider, mais l'interaction commençait à grincer. L'état important vivait dans un transcript qui défilait. Les preuves sources étaient mélangées à la conversation. Les actions étaient cachées dans la prose. Les corrections apparaissaient comme des messages supplémentaires. L'utilisateur devait se souvenir de ce qui avait été décidé, de ce qui était encore un brouillon, et de quelle réponse avait discrètement supplanté une autre. L'interface était devenue une réunion sans procès-verbal.
La discussion est une bonne interface pour demander, explorer et négocier le sens. C'est une interface faible pour opérer. Le travail a besoin d'état, de structure, de contrôles, de provenance, de comparaison, d'annulation, d'approbation, de contraintes et de visibilité partagée. Un flux de travail sérieux ne peut pas dépendre de quelqu'un qui fait défiler vers le haut pour savoir si le modèle a promis d'utiliser l'ancien tableur ou le nouveau. Ce n'est pas de la collaboration. C'est de l'archéologie avec un curseur.
L'interface après le chatbot n'abandonnera pas le langage. Le langage est trop utile. Elle mettra le langage à sa juste place : comme un mode d'entrée et de sortie parmi les formulaires, les tableaux, les chronologies, les cartes, les canevas, les inspecteurs, les curseurs, les panneaux de sources, les files d'attente, les approbations et les simulations. L'avenir n'est pas moins conversationnel. Il est moins piégé dans la conversation.
La discussion cache l'état à la vue de tous
Le transcript est un mécanisme de stockage séduisant parce qu'il semble complet. Tout ce qui a été dit est là. Le problème est que le travail n'est pas simplement ce qui a été dit. Le travail a des états. Une clause est un brouillon ou acceptée. Une source est dans le périmètre ou hors périmètre. Une tâche est bloquée ou prête. Un risque est ouvert ou atténué. Un nombre provient d'un fichier, d'une hypothèse ou d'un calcul. Une décision a été proposée, rejetée, remontée ou appliquée. La discussion peut mentionner ces états, mais mentionner n'est pas gérer.
Lorsque l'état n'existe que dans la conversation, les utilisateurs deviennent la machine à états. Ils doivent se souvenir que la deuxième réponse était meilleure que la première, que le modèle a utilisé le mauvais jeu de données jusqu'à ce qu'il soit corrigé, que le dernier paragraphe nécessite encore une relecture juridique, que le tableau est définitif sauf pour deux lignes, et que l'action ne doit pas encore être exécutée. Les gens peuvent le faire pour un court échange. Ils ne peuvent pas le faire de manière fiable au sein d'une équipe, sur un mois, ou dans un processus réglementé. Les humains excellent dans le sens. Ce sont de médiocres bases de données avec des sentiments.
L'interface post-conversation rend l'état visible. Elle affiche l'ensemble de travail actuel, les modifications acceptées, les questions non résolues, le statut des sources, la confiance, les approbations, les échéances et les actions suivantes. Elle sépare la conversation de l'artefact. L'utilisateur peut discuter d'un contrat en langage naturel, mais la surface du contrat montre quelles clauses ont changé. L'utilisateur peut demander un projet de plan de soins, mais la surface du plan montre les médicaments, les risques, les rendez-vous, les preuves et les conflits non résolus. La conversation aide. L'interface tient le score.
Cette séparation protège également la collaboration. Un collègue qui rejoint plus tard ne devrait pas avoir besoin de lire quarante messages pour savoir ce qui a changé. Un auditeur ne devrait pas avoir besoin de toute la discussion pour voir la décision. Un gestionnaire ne devrait pas se fier à la dernière réponse du modèle comme enregistrement. L'artefact a besoin de son propre état, de sa version et de sa provenance. La conversation peut raconter le travail. Elle ne devrait pas être le seul endroit où le travail existe.
La réponse n'est pas une meilleure bulle de discussion
De nombreuses améliorations des chatbots tentent de rendre la bulle plus intelligente : citations, boutons, mémoire, suggestions, pièces jointes, appels de fonction, voix, avatars, formatage plus utile. Cela peut améliorer l'expérience. Cela ne résout pas le décalage plus profond. Un flux de travail n'est pas une pile de messages avec des accessoires. C'est un ensemble d'objets, de contraintes, de décisions et d'actions qui évoluent au fil du temps.
Prenons l'analyse des achats. Une interface de discussion peut résumer les fournisseurs, comparer les critères et répondre aux questions. Utile. Mais l'utilisateur a également besoin d'un tableau comparatif, d'une pondération ajustable, de documents sources, de conflits, de notes de risque, du statut d'approbation, de contraintes budgétaires et d'un enregistrement exportable. Si tout cela est compressé dans une conversation, l'utilisateur dépense de l'énergie à reconstruire une structure que le système aurait pu afficher directement. C'est ainsi qu'un assistant devient un tableur très articulé qui refuse d'être un tableur.
Ou prenons la réponse aux incidents. La discussion peut aider à poser des questions de diagnostic et à rédiger des mises à jour. Mais les intervenants ont besoin d'une chronologie, d'hypothèses ouvertes, de systèmes affectés, de responsables, de preuves, de décisions, de communications et d'actions réversibles. Une transcription de discussion est trop linéaire pour un travail de crise parallèle. Elle mélange la spéculation avec les faits confirmés, à moins d'être soigneusement gérée. Elle rend difficile la vision de ce qui est encore inconnu. Pendant un incident, l'interface devrait réduire la charge cognitive, pas transformer la réponse en concours de profondeur de défilement.
La meilleure direction est celle des surfaces de tâches. Chaque surface donne au modèle un rôle dans un modèle de travail reconnaissable : rédaction, comparaison, enquête, rapprochement, planification, révision, acheminement, simulation. Le langage reste disponible, mais la surface fournit les objets et les contrôles dont la tâche a naturellement besoin. L'utilisateur ne demande plus au chatbot de devenir l'application entière. L'application devient capable d'IA là où la tâche en bénéficie.
L'initiative mixte a besoin de poignées
Les interfaces d'IA sont souvent décrites comme relevant de l'initiative mixte : l'humain et le système prennent tour à tour la direction. Cette expression est utile, mais elle peut devenir floue. L'initiative mixte exige des poignées. L'utilisateur doit pouvoir définir le périmètre, épingler des faits, rejeter des hypothèses, choisir des sources, modifier la tolérance au risque, figer des parties d'un artefact, demander des alternatives, comparer des versions et approuver des actions. Le système doit pouvoir proposer, avertir, poser des questions de clarification, s'abstenir et expliquer pourquoi il lui faut davantage de preuves.
Dans le chat, beaucoup de ces poignées deviennent des mots. Ne modifiez pas la deuxième section. Utilisez uniquement ces sources. Soyez plus prudent. Conservez le tableau mais ajustez la notation. Expliquez la différence entre les versions trois et quatre. Cela fonctionne jusqu'au jour où cela ne fonctionne plus. Des instructions en prose peuvent être manquées, mal comprises, contredites ou enterrées. Un contrôle qui compte à plusieurs reprises doit devenir visible. Si un utilisateur doit dire cinq fois ne touchez pas à ce paragraphe, l'interface a besoin d'un verrou, pas d'un paragraphe plus obéissant à propos des verrous.
De bonnes poignées réduisent la charge des invites. Un sélecteur de périmètre vaut mieux qu'un paragraphe expliquant le périmètre. Un panneau de sources vaut mieux que de coller sans cesse des noms de fichiers. Un curseur de risque vaut mieux que des adjectifs vagues comme prudent ou audacieux lorsque le domaine peut définir ce qu'ils signifient. Un diff de versions vaut mieux que de demander ce qui a changé. Un bouton d'approbation structuré vaut mieux que appliquez ceci, mais uniquement les parties sûres. Le langage reste la couche flexible. Les contrôles portent l'intention répétée.
Les poignées rendent aussi la responsabilité plus claire. Si l'utilisateur a sélectionné des sources, l'enregistrement peut le montrer. Si le système a ignoré une source exclue, c'est un défaut. Si un réglage de risque était élevé, la revue en aval peut comprendre pourquoi le modèle a suggéré une option plus agressive. Si une action exigeait une approbation, l'interface peut prouver qui l'a approuvée et sur quelles preuves. Ce n'est pas de la bureaucratie d'interface. C'est la différence entre la collaboration et des impressions avec un bouton d'envoi.
Les sources doivent être des objets, pas des décorations
Les citations dans le chat sont un début, mais elles sont souvent trop faibles pour un travail sérieux. Une note de bas de page à la fin d'un paragraphe généré ne dit pas à l'utilisateur quelle affirmation vient de quelle source, si la source était à jour, si une meilleure source a été exclue ou si deux sources étaient en conflit. Elle peut rassurer plus qu'informer. Une citation peut devenir un petit costume d'autorité si l'interface ne permet pas à l'utilisateur d'inspecter la relation avec la source.
Les interfaces post-conversation traitent les sources comme des objets. Elles affichent l'ensemble des sources, leur fraîcheur, les autorisations, les champs extraits, les passages contradictoires, le niveau de confiance et la lignée. Elles permettent aux utilisateurs d'inclure, d'exclure, d'épingler, de comparer et de contester les sources. Elles montrent quand une affirmation n'est pas étayée. Elles distinguent les documents officiels des documents de fond, des notes utilisateur, des valeurs déduites et des suppositions du modèle. Une source n'est pas un lien décoratif. C'est un participant au travail.
Cela importe parce que les systèmes d'IA échouent souvent à la frontière entre information disponible et information justifiée. Ils peuvent produire une réponse fluide à partir de preuves faibles. Ils peuvent mélanger des documents anciens et récents. Ils peuvent traiter un brouillon comme une politique. Ils peuvent déduire un chiffre qui aurait dû être calculé. L'interface doit rendre ces frontières visibles. Elle doit aider l'utilisateur à se demander : qu'avez-vous utilisé, qu'avez-vous écarté, qu'est-ce qui se contredit, qu'est-ce qui manque, et qu'est-ce qui changerait si cette source était retirée.
Lorsque les sources deviennent des objets, la relecture devient plus rapide et plus efficace. Un avocat peut voir quelle clause étaye un amendement proposé. Un clinicien peut voir quelle observation a façonné un plan. Un ingénieur peut voir quelle ligne de journal étaye un diagnostic. Une équipe d'approvisionnement peut voir quel document de fournisseur a contribué à un score. L'utilisateur ne lit plus de la prose en espérant que le système de récupération invisible s'est bien comporté. L'espoir est agréable. Ce n'est pas une stratégie de gestion des sources.
De la réponse à l'artefact
L'unité naturelle du chatbot est une réponse. L'unité naturelle du travail est souvent un artefact. Un rapport, un plan, un contrat, un calendrier, un dossier, une fiche modèle, une note de décision, un registre des risques, une requête, une conception, un budget ou un ticket de service a une structure qui dépasse une simple réponse. Il a des sections, des champs, des responsables, des statuts, des dépendances, des versions et des publics. L'interface après le chatbot traite la sortie de l'IA comme une modification proposée à un artefact, et non comme l'artefact lui-même.
Cette distinction change l'interaction. Au lieu d'accepter une réponse entière, l'utilisateur peut accepter un paragraphe, rejeter une affirmation, épingler une source, diviser une tâche, modifier un champ, demander des alternatives pour une section ou appliquer une transformation à des lignes sélectionnées. Le système peut mettre en évidence les parties incertaines, marquer les affirmations non étayées, montrer ce qui a changé et conserver les options rejetées. L'utilisateur travaille avec un objet, pas avec une transcription.
La conception « artefact d'abord » prend également en charge l'automatisation partielle. Le modèle peut rédiger le résumé, mais pas la recommandation. Il peut extraire des champs, mais pas soumettre le dossier. Il peut proposer des modifications de calendrier, mais pas en informer les participants. Il peut classer les risques, mais pas approuver les mesures d'atténuation. L'interface peut rendre ces limites explicites. Une interface de discussion peut indiquer qu'elle ne prendra pas telle ou telle action. Une surface de tâches peut empêcher l'action à moins que le bon contrôle, le bon rôle et les bonnes preuves ne soient présents.
L'annulation devient centrale. Lorsque l'IA agit sur des artefacts, les utilisateurs ont besoin d'opérations réversibles, de diffs, d'instantanés et d'enregistrements des modifications appliquées. Les personnes sont plus disposées à expérimenter lorsqu'elles peuvent voir et annuler les modifications. Elles le sont moins lorsque le modèle produit un remplacement poli de l'ensemble et que le seul moyen de récupération consiste à copier un message précédent. Le contrôle de version n'est pas ici un luxe de développeur. C'est un modèle de conception pour le courage.
La personnalisation n'est pas la même chose que la mémoire
De nombreux chatbots s'appuient sur la mémoire pour améliorer leur utilité. Souviens-toi de mes préférences. Souviens-toi de mes projets. Souviens-toi de mon ton. La mémoire peut aider, mais les interfaces post-conversation nécessitent une distinction plus rigoureuse entre la personnalisation, l'état de la session, le contexte organisationnel et l'enregistrement faisant autorité. Le fait qu'un modèle se souvienne qu'un utilisateur aime les résumés courts est différent du fait qu'un dossier de cas enregistre qu'une décision a été approuvée. Mélanger ces éléments, c'est ainsi que la commodité devient une preuve par accident.
Pour un travail sérieux, l'interface doit montrer ce dont elle se souvient et pourquoi. Les préférences personnelles doivent être modifiables et à faible risque. Le contexte du projet doit être visible et limité. Les enregistrements faisant autorité doivent être régis. Les faits sensibles ne doivent pas devenir une mémoire ambiante simplement parce qu'ils sont apparus dans une conversation. Un utilisateur doit pouvoir demander au système pourquoi il se comporte d'une certaine manière et voir si la réponse provient d'une préférence, d'une politique, de l'historique, des données sources ou d'une inférence du modèle.
La mémoire a aussi besoin d'oubli. Une hypothèse annulée ne doit pas hanter les recommandations futures. Une source de brouillon ne doit pas devenir un contexte permanent. Une correction passée de l'utilisateur ne doit pas s'appliquer en dehors de son domaine. Une contrainte temporaire de projet doit expirer. Les interfaces de discussion rendent souvent la mémoire magique. Les interfaces de travail ont besoin d'une mémoire suffisamment terne pour être administrée. La mémoire terne est celle qui évite d'avoir à expliquer à un client pourquoi une note privée du trimestre dernier est réapparue dans le brouillon public de ce trimestre.
L'interface post-conversation sépare donc les contrôles de mémoire. Ce qui est épinglé pour cette tâche. Ce qui est enregistré pour cet artefact. Ce qui est une préférence personnelle. Ce qui est une politique organisationnelle. Ce qui est temporaire. Ce qui est supprimé. Ce qui est hérité. L'utilisateur ne doit pas avoir besoin d'effectuer un exorcisme par invite. Il doit avoir des contrôles.
L'interface devient une surface de gouvernance
À mesure que l'IA passe de la réponse aux questions à la structuration du travail, l'interface devient une surface de gouvernance. Elle décide ce que les utilisateurs peuvent voir, ce qu'ils peuvent ignorer, quelles valeurs par défaut semblent normales, quelles actions nécessitent une approbation, quelles preuves sont affichées, quelle incertitude est admise et quels enregistrements survivent. La gouvernance n'est pas seulement un texte de politique. C'est aussi la forme de l'écran.
Cela rend la conception d'interface plus conséquente que ce que de nombreuses organisations ne l'imaginent. Un panneau de sources masqué affaiblit l'examen. Un badge de confiance vague crée une fausse précision. Un chemin d'approbation par défaut augmente le biais d'automatisation. Un diff manquant transforme le texte généré en exercice de confiance. Une voie d'escalade enterrée décourage le soin. Un bouton d'action lumineux peut surpasser un paragraphe de prudence. Les écrans ont une politique, même lorsqu'ils portent un gris neutre.
Les bonnes interfaces de gouvernance rendent visibles les frictions importantes. Elles ralentissent les actions irréversibles. Elles exigent des preuves pour les changements conséquents. Elles montrent le contexte manquant. Elles gardent les suggestions rejetées disponibles pour examen. Elles séparent l'état de brouillon de l'état appliqué. Elles facilitent l'escalade lorsque le système est incertain. Elles ne culpabilisent pas l'utilisateur pour avoir refusé l'automatisation. La meilleure interface d'IA peut parfois être celle qui dit « preuves insuffisantes », puis donne à l'utilisateur une prochaine étape productive.
C'est aussi là que l'accessibilité compte. Une surface d'IA post-chat ne peut pas supposer que chaque utilisateur veut de longs paragraphes, des tableaux denses ou des astuces clavier cachées. Elle doit prendre en charge le balayage visuel, le contrôle au clavier, les lecteurs d'écran, un focus clair, des libellés compréhensibles et un comportement prévisible. Le travail sérieux est fait par des gens fatigués lors de journées ordinaires. L'interface doit les aider, pas leur faire passer un petit parcours d'obstacles cognitifs en l'appelant innovation.
Pourquoi le chat va rester
Rien de tout cela ne signifie que le chat disparaît. Il restera précieux parce que le langage est l'interface la plus flexible dont disposent les humains. Nous l'utilisons pour expliquer des objectifs, négocier l'ambiguïté, demander pourquoi, décrire des exceptions et inventer de nouvelles tâches. Le chat est particulièrement utile au début du travail, lorsque l'utilisateur ne connaît pas encore la structure. Il est aussi utile en périphérie, là où des contrôles fixes deviendraient un musée de toutes les exceptions possibles.
L'erreur consiste à traiter le chat comme l'état final universel parce qu'il a été la démo universelle. Le premier tableur n'a pas éliminé les systèmes comptables. La première barre de recherche n'a pas éliminé l'architecture de l'information. La première interface cartographique n'a pas éliminé les logiciels logistiques. Les primitives d'interface utiles deviennent des éléments d'outils plus riches. Le chat est une primitive. Puissante, certes, mais une primitive.
Le monde post-chat sera plein d'hybrides. Un planificateur avec conversation à côté d'une chronologie. Un éditeur de contrat avec suggestions au niveau des clauses et preuves sourcées. Une console de support avec réponses rédigées, niveau de confiance, vérifications de politique et historique client. Une surface clinique avec contexte patient, propositions de plan, signaux de risque et contrôles d'examen. Un outil de données où le langage génère une requête, mais où le résultat vit dans un tableau avec traçabilité et validation. Le modèle devient présent dans tout l'espace de travail sans forcer tout le travail dans un transcript.
Ceci est plus difficile à construire qu’une fenêtre de discussion. Cela exige de comprendre le domaine, les objets, les rôles des utilisateurs, les modes de défaillance et les enregistrements qui comptent. Cela exige de la rigueur en matière de conception. Cela exige de refuser les fonctionnalités qui rendent la démonstration impressionnante tout en rendant le travail en production ambigu. Mais c’est la direction que doivent prendre les interfaces d’IA sérieuses. Le chatbot a rendu le modèle accessible. La prochaine interface doit le rendre exploitable.
La leçon
L’interface qui succède au chatbot n’est pas un chatbot plus soigné. C’est un espace de travail où se rencontrent le langage, les commandes, les artefacts, les sources, l’état et les enregistrements. Elle permet de demander, mais aussi d’inspecter. Elle permet aux modèles de proposer, mais pas de décider en silence. Elle permet aux utilisateurs d’accepter des éléments, de rejeter des hypothèses, d’épingler des sources, de comparer des versions, d’annuler des modifications et d’approuver des actions avec des preuves. Elle transforme le modèle d’une boîte qui parle en un participant à un flux de travail encadré.
La discussion a appris aux gens que l’IA pouvait être conversationnelle. C’était une leçon nécessaire. La prochaine leçon est que la conversation n’est pas la même chose que le travail. Le travail a une mémoire, une forme, une propriété, un risque et des conséquences. L’interface doit honorer ces éléments au lieu de les cacher dans une transcription. L’avenir parlera encore. Il montrera aussi ses sources, exposera son état, se souviendra de ses décisions et donnera aux utilisateurs des prises assez solides pour orienter.