Les agents conversationnels, capables d'interagir avec les utilisateurs en langage naturel grâce aux Large Language Models (LLMs), occupent aujourd'hui une place centrale dans les stratégies de relation client de nombreuses entreprises. Pourtant, concevoir un agent performant ne consiste pas simplement à intégrer un LLM dans une application.
Un agent conversationnel fiable repose sur une architecture capable de structurer les échanges, de gérer les erreurs, de garantir la sécurité des interactions et de conserver un comportement prévisible, même lorsque les conversations deviennent complexes.
Dans cette architecture, le LLM n'est pas responsable de la logique de conversation. Son rôle est de comprendre et de produire du langage naturel. Les décisions de pilotage sont prises par un orchestrateur, qui conserve l'état des conversations, sélectionne les actions à exécuter et coordonne les différents composants du système.
Dans cet article, nous allons nous intéresser aux fondations de cette architecture : la conception des dialogues et la construction d'un flux conversationnel robuste.
Thomas François-Raketamanga
Architecture du dialogue
La première étape consiste à définir une architecture de dialogue claire. Une approche efficace repose sur la construction d'une taxonomie d'intentions. Celle-ci fournit à l'orchestrateur une représentation structurée des besoins des utilisateurs et lui permet de déterminer quel comportement adopter face à chaque demande.
La conception d'une taxonomie d'intentions débute par une définition précise du rôle de l'agent conversationnel. Avant même d'identifier les intentions, il est indispensable de définir ce que l'agent doit permettre, à quels utilisateurs il s'adresse et quelles demandes sortent de son périmètre de responsabilité.
Une fois ce périmètre établi, la taxonomie doit être construite à partir des comportements réels des utilisateurs. Les historiques de conversations, les tickets du support client, les recherches effectuées sur le site ou encore les entretiens utilisateurs constituent d'excellentes sources d'information. Leur analyse permet d'identifier les besoins récurrents et les points de friction afin de construire une taxonomie qui reflète les usages réels plutôt que des hypothèses.
Les intentions sont ensuite organisées de manière hiérarchique. On commence par des catégories générales avant de les décliner progressivement en intentions plus spécifiques. Chaque intention doit représenter un objectif utilisateur clairement identifiable, en évitant autant que possible les recouvrements entre intentions.
Pour un agent conversationnel de e-commerce, une hiérarchie peut par exemple prendre la forme suivante :
Commandes → Suivi de commande → « Où est mon colis ? »
Cette taxonomie devient ensuite le référentiel utilisé par l'orchestrateur pour piloter les conversations. Elle lui permet de sélectionner le flux adapté, de déterminer les informations à collecter, de réutiliser les données déjà connues de l'utilisateur et d'orienter les appels vers les outils ou services appropriés.
En structurant les échanges autour d'intentions clairement définies, il devient possible de faire évoluer les capacités de l'agent sans remettre en cause les comportements déjà existants.
Charlotte Ryssen (Coumont)
Digressions et gestion des interruptions
Une conversation réelle est rarement linéaire. Les utilisateurs changent de sujet, reviennent sur une demande précédente ou posent plusieurs questions simultanément. Un agent incapable de gérer ces situations donne rapidement une impression de rigidité, même si la qualité de ses réponses reste élevée.
Pour conserver un comportement cohérent, l'orchestrateur peut représenter une conversation comme un ensemble de fils de conversation indépendants (conversation threads). Chaque fil correspond à un objectif utilisateur et possède son propre contexte, son état ainsi que son niveau d'avancement.
Ainsi, un utilisateur peut demander le suivi d'une commande, puis interrompre cette conversation pour vérifier la disponibilité d'un produit avant de revenir à sa commande. Chacun de ces sujets évolue indépendamment sans perdre son contexte.
Chaque fil passe par différents états, par exemple :
OPENEDPENDING_FOLLOWUPAWAITING_CLARIFICATIONCLOSED
Ces états permettent à l'orchestrateur de conserver une vision claire de la conversation et de reprendre un échange exactement là où il avait été interrompu.
À chaque nouveau message, le LLM intervient comme un composant de compréhension du langage. Son objectif n'est pas de décider de la suite de la conversation, mais d'aider l'orchestrateur à répondre à une question simple :
« À quel fil de conversation ce message appartient-il ? »
Le message peut alors être identifié comme :
- la poursuite d'un fil déjà ouvert ;
- l'ouverture d'un nouveau fil de conversation ;
- le retour vers un ancien fil, détecté grâce à une recherche sémantique ou à un score de pertinence prenant en compte la récence des échanges.
Cette séparation entre compréhension linguistique et orchestration permet de construire des conversations non linéaires tout en conservant un comportement déterministe, maintenable et facilement extensible.
Stratégies de clarification et de reformulation
Les demandes des utilisateurs sont rarement parfaites. Elles peuvent être incomplètes, ambiguës ou réparties sur plusieurs messages successifs. Pour gérer ces situations sans multiplier les hypothèses, deux mécanismes complémentaires peuvent être utilisés : la clarification et la reformulation.
La clarification intervient lorsqu'une information indispensable manque à l'exécution de la demande. Dans ce cas, l'orchestrateur place le fil dans un état AWAITING_CLARIFICATION et demande explicitement l'information à l'utilisateur.
Ce fonctionnement présente un avantage important : la logique de conversation reste explicite. L'orchestrateur sait précisément pourquoi un fil est suspendu et dans quelles conditions il pourra reprendre son exécution. Selon les besoins, d'autres états peuvent être introduits, comme AWAITING_CONFIRMATION, afin de réduire les inférences confiées au LLM et de rendre les décisions de pilotage plus déterministes.
La reformulation répond à un besoin différent. Ici, toutes les informations nécessaires sont disponibles, mais la demande reste ambiguë ou dispersée dans plusieurs messages. L'objectif consiste alors à reconstruire une requête explicite représentant l'intention réellement comprise.
Par exemple, après plusieurs échanges concernant une commande, un utilisateur peut écrire :
« Peux-tu la changer ? »
L'orchestrateur peut produire la reformulation suivante :
« Modifier l'adresse de livraison de la commande n°123. »
Cette reformulation peut être utilisée directement pour appeler un outil ou un sous-agent. Lorsque le niveau de confiance est insuffisant, elle peut être présentée à l'utilisateur afin d'obtenir une confirmation avant de poursuivre.
Le traitement d'un message suit alors une séquence relativement simple :
- l'orchestrateur identifie le fil concerné ;
- il récupère le contexte associé ;
- il vérifie si des informations sont manquantes ;
- si nécessaire, il déclenche une clarification ;
- sinon, il génère éventuellement une reformulation ;
- il décide d'exécuter immédiatement la requête ou de demander une confirmation avant de poursuivre.
Cette approche permet d'obtenir des conversations plus naturelles tout en limitant les hypothèses dangereuses. L'orchestrateur conserve la maîtrise du déroulement de la conversation tandis que le LLM est utilisé là où il apporte le plus de valeur : comprendre les intentions et produire du langage naturel.
Et si l'on se passait de taxonomie ?
Il serait malhonnête de présenter cette architecture sans évoquer l'approche qui la conteste aujourd'hui : supprimer la taxonomie d'intentions et confier au modèle le routage direct vers les outils disponibles. Chaque capacité devient un tool, le modèle choisit lequel appeler, et l'orchestrateur se réduit à une boucle d'exécution.
Les arguments en sa faveur sont solides. La couche de conception disparaît, l'ajout d'une capacité se limite à la description d'un nouvel outil, et le système bénéficie de chaque progrès des modèles sans effort d'ingénierie. Sur un périmètre restreint, avec peu d'outils et des actions réversibles, c'est difficile à battre en vitesse de mise en œuvre. Nous considérons que c'est le bon choix par défaut pour un prototype ou un domaine étroit.
Le passage à l'échelle fait apparaître deux propriétés qui tiennent moins à l'implémentation qu'à la nature de l'approche.
L'évaluation perd son référentiel. Évaluer un système suppose de comparer une exécution à une attente. Lorsque la trajectoire de résolution n'est pas contrainte, il n'existe plus de séquence attendue : le modèle peut atteindre le même résultat par des chemins différents, et deux exécutions correctes n'ont pas la même forme. On peut encore juger la réponse finale, mais plus localiser l'étape où une conversation a dérapé, ni construire un jeu de référence sans figer précisément ce que l'approche a fait le choix de ne pas figer. En pratique, cela déplace l'évaluation vers une revue manuelle par échantillonnage, avec la difficulté qui en découle : détecter une régression avant qu'un utilisateur ne la signale.
Le coût par tour croît avec la conversation. Sans état persistant, une part du raisonnement doit être reconstruite à chaque message : relire l'historique, re-inférer l'objectif en cours, re-sélectionner l'outil. Ce coût augmente avec la longueur de l'échange et le nombre d'outils exposés, là où un état explicite le maintient constant. Un facteur de trois à quatre sur le temps de réponse moyen n'a rien d'inhabituel, avec un effet secondaire souvent sous-estimé : les systèmes appelants doivent élargir leurs délais d'expiration, et la contrainte se propage à l'ensemble de la chaîne.
Notre critère n'est donc pas une préférence d'école mais un seuil. Tant que le périmètre reste étroit et les actions réversibles, le routage direct est un excellent choix. Dès lors que le nombre d'intentions augmente, que certaines actions sont irréversibles — annuler une commande, modifier une adresse de livraison — et qu'il faut pouvoir mesurer la qualité du système avant chaque mise en production, l'état explicite cesse d'être un surcoût pour devenir la condition de l'exploitabilité.
Conclusion
La conception d'un agent conversationnel ne se résume pas au choix d'un modèle de langage performant. Elle tient d'abord à une décision d'architecture : quelle part du pilotage de la conversation confie-t-on au modèle, et quelle part maintient-on explicite dans le système.
Sur un périmètre restreint, avec peu d'outils et des actions réversibles, le laisser du côté du modèle permet d'avancer vite et reste le choix le plus raisonnable. L'architecture décrite dans cet article répond à un autre contexte : un nombre d'intentions qui augmente, des actions dont certaines sont irréversibles, et l'exigence de pouvoir mesurer la qualité du système avant chaque mise en production.
Dans ce contexte, taxonomie d'intentions, fils de conversation explicites et mécanismes de clarification ne sont pas une complexité ajoutée : ils sont ce qui rend le comportement de l'agent observable, testable et reproductible.
Cette remarque appelle sa propre vérification : une architecture ne vaut que ce que valent les mesures qui l'accompagnent. Dans un prochain article, nous nous intéresserons aux mécanismes d'évaluation, d'observabilité et d'amélioration continue qui permettent de mesurer la qualité de ces architectures et de les faire progresser au fil du temps.
Charlotte Ryssen (Coumont)
