FR 
EnglishPar défaut
Українська
Polski🏢 Gestionnaire de Dialogue de Chatbot Gouvernemental
Simulateur interactif de machine à états de dialogue : observez un chatbot de service aux citoyens classifier l'intention, remplir les créneaux (slots) et acheminer une vraie conversation de service public étape par étape.
À propos du Gestionnaire de Dialogue de Chatbot Gouvernemental
La plupart des chatbots gouvernementaux destinés aux citoyens ne sont pas propulsés par un unique modèle boîte noire devinant la prochaine réplique — sous la fenêtre de chat conviviale se trouve une machine à états de dialogue : un graphe d'états nommés (« en attente de l'identifiant de la propriété », « confirmation du type de permis », « transféré à un humain ») reliés par des transitions qui ne se déclenchent que lorsque la compréhension du message courant par le système correspond à ce qu'attend cet état. Cela rend la conversation prévisible et auditable, ce qui compte lorsqu'un bot annonce un montant de frais, confirme une échéance de dépôt, ou enregistre un signalement qu'une municipalité doit traiter.
Cette simulation restitue ce graphe directement : un état initial se ramifie en trois intentions de service — Taxe foncière, Demande de permis et Signaler un problème — plus une sortie directe « Parler à un humain », et chaque branche traverse ses propres états de remplissage de créneaux avant de fusionner à nouveau au niveau de « Autre chose ? ». Cliquez sur les messages d'exemple intégrés (ou saisissez les vôtres) et une petite couche NLU basée sur des règles décide, à partir de l'état courant et du texte envoyé, vers quel état passer ensuite — y compris en revenant en boucle sur lui-même si un créneau requis n'a pas été trouvé, exactement comme le ferait un gestionnaire de dialogue en production.
Questions Fréquentes
Qu'est-ce qu'une machine à états de dialogue et en quoi diffère-t-elle d'un simple classificateur d'intention ?
Un simple classificateur d'intention examine un message isolément et produit une étiquette — « taxe foncière », « permis », « plainte » — sans aucune mémoire de ce qui a précédé. Une machine à états de dialogue, elle, suit un état courant (par exemple « en attente de l'identifiant de la propriété ») et n'accepte que les transitions qui ont du sens depuis cet état, en utilisant le message reçu pour décider quelle arête suivre. Cela permet au même mot de signifier des choses différentes selon l'état — « 123 rue du Chêne » est une adresse lorsque le bot en demande une, et un bruit dénué de sens autrement — et permet au système de se souvenir de ce qui a déjà été demandé et répondu sur de nombreux échanges, pas seulement le dernier message.
Que signifie « remplissage de créneaux » dans un système d'IA conversationnelle ?
Une fois l'intention connue (disons, « Demande de permis »), le système a généralement encore besoin de plusieurs éléments d'information structurée — appelés créneaux — avant de pouvoir agir : une adresse, un type de permis, parfois une date. Le remplissage de créneaux est le processus qui consiste à extraire chacune de ces valeurs des réponses en texte libre de l'utilisateur et à les inscrire dans un petit enregistrement structuré. Une demande de permis n'est pas exploitable tant que chaque créneau requis (adresse, type_de_permis) n'a pas de valeur ; le rôle du gestionnaire de dialogue est de continuer à demander ce qui reste vide.
Pourquoi le bot revient-il en boucle lorsqu'un créneau est manquant, au lieu de simplement demander une seule fois ?
Les utilisateurs réels répondent souvent à une autre question que celle posée, s'écartent du sujet, ou donnent une réponse que l'extracteur ne peut pas analyser (« le grand, près de l'école » n'est pas une adresse analysable). Si la machine à états avançait simplement malgré tout, elle tenterait de rechercher un permis avec une adresse manquante et échouerait silencieusement ou provoquerait une erreur en aval. À la place, l'état « demande » possède une boucle sur lui-même : si le motif de créneau attendu n'est pas détecté dans la réponse, la machine reste dans le même état et repose la question. Cette boucle est exactement ce que cette simulation comptabilise comme une « boucle de remplissage de créneau » — un signal réel et mesurable de la friction causée par un échange.
Quand et pourquoi les vrais chatbots gouvernementaux transfèrent-ils la conversation à un humain ?
Le transfert se déclenche soit explicitement — le citoyen dit « parler à une personne » — soit implicitement, lorsque la même boucle de remplissage de créneau se déclenche plus de deux fois, lorsque la confiance du classificateur d'intention reste faible sur plusieurs échanges, ou lorsque la requête touche à quelque chose que le bot n'est pas autorisé à résoudre. Orienter tôt vers un humain, avant que le citoyen ne se frustre, est considéré, dans les systèmes bien conçus, comme un indicateur de réussite et non un échec — un transfert efficace vaut bien mieux qu'une longue boucle sans issue.
En quoi cela diffère-t-il d'un agent conversationnel moderne basé sur un LLM ?
Un grand modèle de langage (LLM) peut traiter des formulations ouvertes, des intentions mélangées dans une seule phrase et des questions de suivi sans graphe rédigé à la main, car il génère la réponse suivante à partir d'une distribution apprise sur le langage plutôt qu'en faisant correspondre des mots-clés. Cette flexibilité a un coût en termes de prévisibilité : un LLM peut s'écarter du scénario, inventer une politique, ou accepter une adresse qu'il n'a en réalité jamais validée. Une machine à états basée sur des règles comme celle-ci est bien moins flexible quant à la formulation, mais chaque chemin qui la traverse est énumérable, testable et auditable — c'est pourquoi de nombreux systèmes gouvernementaux et réglementés associent encore une interface LLM à une machine à états déterministe ou à une couche de validation de créneaux sous-jacente pour tout ce qui a des conséquences juridiques ou financières.
Quelle est la différence entre la détection d'intention et l'extraction d'entités ou de créneaux ?
La détection d'intention répond à « que veut faire l'utilisateur » — payer une facture, demander un permis, signaler un nid-de-poule — et se décide généralement une seule fois, au début de la conversation. L'extraction d'entités ou de créneaux répond à « quelles valeurs précises m'a-t-il données » — une adresse, un type de permis, une date — et peut se produire à presque chaque échange, à mesure que la conversation renseigne les détails nécessaires pour agir sur l'intention. Un message peut porter les deux à la fois : « il y a un nid-de-poule sur la rue principale » définit l'intention (signaler_probleme) et peut remplir un créneau (localisation) en un seul énoncé, ce que le NLU de cette simulation gère en vérifiant les deux types de motifs sur chaque message entrant.
Pourquoi les chatbots gouvernementaux utilisent-ils souvent des machines à états plutôt que des LLM entièrement libres ?
Les services publics sont soumis à des règles qui doivent être appliquées de façon cohérente et justifiable — un mauvais montant de frais de permis annoncé, ou une échéance fiscale mal communiquée, a de réelles conséquences et peut faire l'objet de demandes d'accès à l'information ou d'audits. Une machine à états finis garantit que certaines étapes se déroulent toujours dans le même ordre et ne peuvent jamais être sautées, et que chaque chemin possible dans la conversation peut être répertorié et testé à l'avance. Cette auditabilité et cette prévisibilité valent généralement plus, pour un organisme public, que la conversation plus naturelle qu'un LLM pur pourrait offrir.
Observez la machine à états de dialogue d'un chatbot de service aux citoyens s'animer au fil d'une conversation — intention, créneaux et transitions en direct.
3D · Moteur Three.js / WebGL · Cible 60 FPS · fonctionne entièrement côté client, sans installation