IA générative dans Dialogflow CX : generators, fallback et playbooks

Un agent conversationnel perd la conversation au même endroit que d'habitude : quand l'utilisateur sort du script et que le bot répond « désolé, je ne sais pas comment vous aider ». Dialogflow CX, le constructeur d'agents virtuels de Google Cloud, résout le trafic normal avec une machine à états ; ce que le cours « Conversational AI on Vertex AI and Dialogflow CX » de Google Skills enseigne, c'est quoi faire de tout ce qui reste dehors, en incorporant l'IA générative sans lâcher les rênes. Ce post parcourt les quatre nouveaux composants (generative AI agents, data stores, generators et generative fallback) et les Generative Playbooks.

Le terrain : flows, pages et routes

Il vaut fixer le vocabulaire, car tout le reste s'appuie ici. Dialogflow CX modélise la conversation comme une machine à états : les flows sont le bloc général d'instructions, les pages représentent les états possibles de la conversation, avec une seule active à la fois, et c'est là que se configurent paramètres, prompts et fulfillment ; les routes indiquent où aller quand l'état change, par intent apparié ou par condition vraie.

Les state handlers routent le comportement attendu, le chemin prévu par le design. Les event handlers couvrent l'autre : les no-input et no-match, quand l'utilisateur ne donne pas l'information pour avancer, pour qu'il ne reste pas abandonné. Les intents s'entraînent avec 5 à 10 training phrases représentatives, les entities portent des valeurs et des synonymes pour que l'utilisateur n'ait pas besoin du terme interne, et les entités mises en avant dans les phrases sont le slot filling. Un détail de sécurité dans la même pièce : « Redact in log » évite de stocker en clair des valeurs sensibles comme un PIN.

Les deux voies pour ajouter de la générative

Il y a deux façons d'ajouter des capacités d'IA générative à un agent. La première, créer un nouvel agent génératif avec Vertex AI Conversation, la plateforme unifiée pour les solutions conversationnelles avec IA générative, en créant un data store avec le contenu que l'agent cherchera. La seconde, faire monter l'agent existant en ajoutant des data stores de Vertex AI Search and Conversation, en ajoutant une autre couche de couverture de questions au-dessus du routage par intents.

Ce qui soutient les deux, c'est une position : le développeur contrôle l'expérience. La conversation reste sur un chemin connu et le contenu généré est restreint à l'usage prévu, avec des réponses ancrées (grounded) dans le contenu et de la logique métier dans les flows pour réduire le risque. C'est là la différence face à une approche LLM pure. S'y ajoutent la scalabilité élastique, la sécurité gérée avec des standards de sécurité et résidence des données, et des SLA. Les agents virtuels se classent en informationnels, transactionnels et companions, et opèrent par canaux texte, rich text, voix ou multimodal.

Generators : un LLM dans le fulfillment

Un generator est un LLM avec un prompt personnalisé qui génère des réponses de l'agent en runtime, dans le fulfillment d'une page. Il se configure dans Manage → Generators avec display name, prompt, modèle et paramètres (Temperature, Top P, Top K). Le prompt accepte des placeholders avec $, associés à des session parameters, et en apporte deux intégrés : $conversation, la conversation moins le dernier message de l'utilisateur, et $last-user-utterance, le dernier texte de l'utilisateur.

Les capacités citées sont du quotidien : résumer des articles ou la conversation elle-même, analyse de sentiment en temps réel, mise à jour de formats structurés JSON et décisions informées par le contexte. Plusieurs generators dans un fulfillment s'exécutent séquentiellement, en prenant la sortie du précédent comme entrée du suivant, avec des sorties nommées utilisables comme réponse de l'agent, dans des webhooks ou des presets de paramètres.

Le même mécanisme génère du code avec code-bison depuis des descriptions en langage naturel, avec support de Go, Java, JavaScript, Python et TypeScript, entre autres. Les avertissements du matériel sont directs : cela ne remplace pas l'intervention humaine, le code généré doit être testé exhaustivement avant la production, ce n'est pas conçu comme remplacement du développement de code, et il ne doit pas servir pour des industries sensibles comme la cybersécurité et la prévention du hacking.

Generative Fallback : quoi répondre quand on ne sait pas

Le generative fallback attaque le no-match, le point où la conversation dérive du flux prévu sans déclencher une autre action ou un autre flow. Il améliore les réponses génériques comme « désolé, je ne sais pas comment vous aider » et s'appuie sur le Principe de coopération de Grice : la communication efficace dépend de la coopération entre participants, et les gens traitent la machine avec leur modèle mental de conversation humain-humain. De là viennent les quatre maximes qui guident le prompt : qualité (vérité de ce qu'on dit), quantité (information fournie), relation (pertinence) et manière (communication claire).

Il s'active sur les no-match event handlers à trois niveaux. Au niveau flow, depuis la Start Page, avec $flow-description pour que le prompt tire parti de la description du flow. Au niveau page, si l'entrée n'apparie pas les intents actifs, avec $route-descriptions qui utilise les descriptions de ces intents. Au niveau parameter, quand l'entrée viole le entity type du paramètre, en invitant à re-demander une valeur valide dans la plage. Si la génération échoue ou que l'entrée contient des banned phrases, safety checks configurables, Dialogflow émet la réponse régulière prescrite du fulfillment.

Et le contexte n'est pas un extra : sans $conversation, une question avec un pronom comme « quand vient-il en ville ? » fait dérailler la conversation. L'ASR sait presque toujours ce qui a été dit ; ce que l'utilisateur voulait dire se résout avec le contexte.

Agents hybrides et ordre d'évaluation

Les Generative AI Agents s'appuient sur des data stores de Vertex AI Search and Conversation : un data store parse et indexe les données de l'entreprise (liens web, documents, FAQs, BigQuery) et l'agent interroge ces données via des data store handlers. Il y a des types d'agents concrets : website agent pour les questions sur le site, FAQ agent et employee-facing agent pour le helpdesk ou les RH internes, plus des intents spéciaux générés automatiquement comme « êtes-vous humain ? » et l'escalade vers un humain.

L'agent existant devient un agent hybride en combinant les contrôles précis (flows, parameters, intents, conditions) avec des data store handlers. Et là l'ordre d'évaluation compte :

flowchart TD
    E[Entrée de l'utilisateur] --> P[1. Parameter input<br/>pendant le form filling]
    P --> I[2. Intent matches<br/>des routes dans le périmètre]
    I --> F[3. Data store handler<br/>contenu FAQ]
    F --> N[4. Data store handler<br/>contenu non structuré]

La précision déterministe des intents et paramètres passe d'abord ; la couverture générative sur le savoir indexé complète ce que les intents ne couvrent pas. Chaque réponse du data store reçoit un score de grounding configurable, et celles hors de la plage permise ne s'affichent pas. La recommandation pratique est de garder ce qui fonctionne et d'étendre progressivement : élargir la couverture avec des questions sans budget d'intents, utiliser le fallback là où les intents n'arrivent pas, et remplacer les intents qui se répondent mieux depuis la base de connaissances. Pour les réponses déterministes, les lookups en base de données et la rédaction de données, le routage par intents reste meilleur.

Sur les data stores, les types sont site web public (tire parti de l'index existant de Google Search), structuré (NDJSON dans Cloud Storage ou tables dans BigQuery) et non structuré (HTML, PDF avec texte, slides, jusqu'à 100 000 fichiers par import). L'import se fait complet ou incrémental, et le cycle de vie inclut refresh, purge (supprime les documents en conservant le schéma et les réglages) et delete.

Sécurité et gouvernance

Les contrôles du périmètre sont ceux de Google Cloud : chiffrement des données client avec des clés gérées par le client quand elles sont fournies, accès de l'équipe d'opérations consigné et traçable avec Access Transparency, et résidence des données et VPC Service Controls respectés. Les LLM sont stateless, avec poids figés et sans stockage de données client, et les données d'un client ne profitent pas à un autre. En gouvernance, par défaut Google Cloud n'utilise pas les données client pour entraîner des LLM et obtient la permission avant de le faire, dans le cadre des termes et du Cloud Data Processing Addendum, avec un engagement déclaré envers le GDPR et le HIPAA. L'accès s'administre avec trois rôles de Discovery Engine : viewer, editor et admin.

Generative Playbooks : raisonner et agir

Les Generative Playbooks sont la mise la plus distincte : ils construisent l'expérience de chat avec des instructions en langage naturel, au lieu de flows, pages, intents et transitions, avec des playbooks qui définissent des workflows de bout en bout et l'accès à des APIs et outils. Ils implémentent le motif ReAct (REasoning + ACTing) : après un prompt, le LLM produit un thought, un raisonnement qui met à jour son état interne, et une action qui appelle un système externe défini avec OpenAPI 3.0 ; la réponse entre comme observation et le cycle se répète jusqu'à la réponse finale.

flowchart LR
    T[Thought<br/>raisonnement du LLM] --> A[Action<br/>outil OpenAPI ou flow]
    A --> O[Observation<br/>réponse externe]
    O --> T2[Thought avec<br/>l'observation]
    T2 -->|Il manque de l'information ?| A
    T2 -->|Cycle complet| R[Réponse finale]

En pratique, un playbook comme Renew_License demande le numéro et l'expiration du permis, les vérifie avec $TOOL : drivers_license (et demande une clarification si l'API répond erreur), demande l'adresse, consulte l'éligibilité au renouvellement en ligne et, selon le résultat, envoie la demande ou prévient qu'elle arrivera par courrier. Les limites sont concrètes : cinq appels par tour de conversation, 15 000 tokens d'entrée et 500 de sortie sommés par tour, et dans les appels HTTP seuls des bodies vides ou du JSON avec tool schemas en application JSON sont acceptés.

La recommandation de qualité est celle de toujours en la matière : des instructions claires sont un prérequis, mais si l'agent ne se comporte pas comme prévu c'est presque toujours par exemples manquants ou déficients ; on recommande quatre ou plus d'exemples few-shot par playbook couvrant tous les happy paths. Et une règle de combinaison à garder claire : les playbooks sont mutuellement exclusifs avec les Generators et le Generative Fallback, car dans un playbook le LLM contrôle tout, y compris l'orchestration de l'état ; ils se combinent en revanche avec les flows traditionnels et avec les data stores.

Quoi choisir et ce qui n'a pas été vérifié

La décision se simplifie si on regarde le problème. Machine à états avec des trous ponctuels : generators pour des tâches bornées dans le fulfillment et generative fallback pour les no-match, avec la couverture des intents intacte. Connaissances de l'entreprise qui grandissent plus vite que les intents : data stores et agent hybride, avec l'ordre d'évaluation qui protège la précision. Processus conversationnels entiers décrits en langage naturel : playbooks. Les trois voies coexistent dans le même produit, mais pas toutes dans le même tour.

Ce qui n'a pas été vérifié : les six contrôles de connaissances n'ont pas été ouverts, et les prix et limites publiés (comme le throughput d'ingestion d'environ 200 lignes par seconde ou les limites de tokens des playbooks) datent d'octobre 2026 sur des modèles PaLM 2, text-bison et code-bison ; ils peuvent changer et il vaut les revalider face à la documentation actuelle avant de les utiliser contractuellement.

*Source : « Conversational AI on Vertex AI and Dialogflow CX », de Google Skills.*