Une fenêtre de chat n’est pas une interface conversationnelle

Une entreprise ajoute un assistant à son portail interne. Une coordinatrice commerciale l’essaie avec sa première vraie question de la journée : où en est la commande du distributeur du Nord ? L’assistant répond par un paragraphe du centre d’aide expliquant ce que signifient, en général, les statuts de commande. Elle reformule avec le numéro de commande. Il répond qu’il n’a pas accès aux données de commande. Elle ferme le panneau et ouvre l’écran des commandes, comme avant.

Quelques mois plus tard, le bilan du projet constate une faible adoption. On en conclut que les collaborateurs ne sont pas prêts pour les outils conversationnels. La vraie conclusion, c’est qu’on ne leur en a pas donné.

On leur a donné une fenêtre de chat posée sur des documents, au lieu de la poser sur le référentiel et sur les actions. Une conversation est utile quand l’interlocuteur sait qui vous êtes, voit les faits et peut agir sur eux. Une fenêtre de chat qui n’a rien de tout cela n’est qu’un champ de recherche qui répond par des phrases complètes.

Là où le chat ajouté comme fonctionnalité échoue

Il ne voit pas le référentiel. L’assistant répond à partir de documents sur le processus, pas à partir du processus lui-même. Il sait expliquer ce que veut dire « partiellement expédiée ». Il ne sait pas vous dire lesquelles de vos commandes le sont.

Il ne sait pas qui pose la question. Le responsable d’entrepôt et le directeur financier obtiennent la même réponse à la même question, alors qu’ils ont besoin de choses différentes et n’ont pas le droit de voir les mêmes informations. Sans identité, pas de pertinence, et aucun moyen sûr de montrer des données réelles.

Soit il ne peut pas agir, soit il agit sans demander. La première version est une impasse : « vous pouvez modifier la date de livraison dans le module des commandes ». L’échec inverse est pire : un assistant branché directement sur les opérations d’écriture, si bien qu’une phrase mal comprise devient une commande modifiée sans que personne ne l’ait regardée.

Il n’a pas de fil. Chaque conversation repart de zéro. L’échange de la veille sur le même client a disparu, et rien de ce qui a été demandé ou décidé n’est rattaché à la commande concernée : la personne suivante recommence elle aussi depuis le début.

On le juge comme une fonctionnalité, pas comme du travail. Le succès se mesure en messages envoyés. La seule question qui compte, combien de tâches ont été accomplies plus vite ou avec moins d’erreurs, n’est jamais posée.

Ce dont une interface conversationnelle a besoin

Un ancrage dans le modèle de l’entreprise. La réponse à « où en est cette commande ? » doit venir de la commande elle-même : ses lignes, sa livraison, sa facture, sa réclamation en cours. Il faut pour cela un modèle de l’activité que la conversation peut interroger, et c’est précisément ce qu’apporte une ontologie. Pourquoi cela fonctionne mieux qu’une recherche dans les documents, c’est le sujet de rechercher dans l’ontologie.

Une identité et des droits appliqués côté serveur. La conversation hérite des droits de la personne qui la mène. Le modèle ne reçoit jamais de données que cette personne n’a pas le droit de voir, et cette règle s’applique là où vivent les données, pas au moyen d’une consigne dans un prompt qu’une question habile suffit à contourner.

Des actions sous forme de propositions. « Décale la livraison à jeudi et préviens le client » doit produire une modification et un message préparés, présentés à la personne avec les sources utilisées, et exécutés seulement lorsqu’elle confirme. Les étapes critiques attendent l’approbation de quiconque est habilité à la donner. C’est autour de ce principe qu’est conçue la couche Logique agentique de Hurukan : un agent propose, une personne décide de tout ce qui compte.

Un fil rattaché au référentiel. La conversation est conservée avec la commande, le dossier ou le fournisseur dont elle traitait, pour que la personne suivante voie ce qui a été demandé, décidé et fait.

Un passage net vers l’écran. Certaines choses vont plus vite dans un tableau. Une bonne interface conversationnelle sait quand ouvrir la bonne vue, filtres déjà appliqués, plutôt que de lire à voix haute une longue liste.

Dans la conception de Hurukan, la conversation est une porte d’entrée vers le même référentiel, les mêmes agents et les mêmes approbations, et non un produit distinct avec sa propre copie de la vérité. Les intégrations avec Microsoft 365 Copilot, Claude et ChatGPT sont prévues, pas encore disponibles ; l’objectif est que chacun puisse parler au système depuis les outils qu’il utilise déjà, tandis que les faits, les droits et les approbations restent en un seul endroit. Les propositions qui appellent une décision arrivent dans une seule boîte d’approbation, décrite sur la page Décisions et tâches.

Un test à faire dès aujourd’hui

Prenez l’assistant dont vous disposez déjà, ou celui qu’on vous propose. Rassemblez cinq questions qu’un vrai collaborateur a posées à un collègue cette semaine ; copiez-les depuis la messagerie ou le chat telles qu’elles ont été écrites. Soumettez chacune à l’assistant et notez-le sur quatre points :

1. A-t-il répondu à partir de données en temps réel, ou d’un document décrivant le processus ?
2. Savait-il qui posait la question ? Posez la même question sous deux profils aux rôles différents.
3. Pouvait-il préparer l’étape suivante, et a-t-il demandé avant de faire quoi que ce soit d’important ?
4. Demain, un collègue pourra-t-il voir ce qui a été demandé et fait, rattaché au référentiel ?

Si la plupart des réponses sont négatives, vous avez une fenêtre de chat. C’est très bien pour chercher dans un manuel, mais ce n’est pas une nouvelle façon de travailler. Les mêmes quatre points valent lorsque les mains sont occupées et que la conversation se fait à voix haute, ce qui est le sujet de la voix quand les mains sont occupées.