Les chatbots traditionnels, souvent rigides et limités à des scénarios prédéfinis, cèdent la place à une nouvelle génération d'assistants intelligents, plus flexibles et naturels grâce à l'IA générative*. Pour répondre à cette évolution, Google Cloud a lancé Conversational Agent, un service qui complète et enrichit son offre existante, Dialogflow CX.
Au fil de cet article, nous décortiquerons cette nouvelle approche. Vous découvrirez :
- La différence fondamentale entre un agent génératif et un agent déterministe.
- Le fonctionnement des Playbooks, la pierre angulaire de Conversational Agent pour piloter les LLM*.
- La complémentarité avec les Flows de Dialogflow CX, essentiels pour les parcours structurés.
Les termes techniques en gras avec une étoile sont expliqués dans le glossaire à la fin.
1.1°) Définition d’un chatbot (agent conversationnel)
Un chatbot (agent conversationnel) est une application capable d’interagir avec des utilisateurs à l’oral ou à l’écrit. Il peut répondre à des questions, fournir des informations ou encore exécuter des actions via des systèmes tiers.
On distingue généralement deux grandes catégories d’interactions :
Depuis 2020, Google propose Dialogflow CX, une plateforme permettant de créer des chatbots adaptés à ces usages.
En 2025, cette approche évolue avec le lancement de Conversational Agent, un service enrichi par l’intégration de modèles de langage de grande taille (LLM).
Dans la section suivante, nous explorerons les principales différences entre ces deux outils.
1.2°) Différence DialogFlow et Conversational Agent
Ces deux services partagent un même objectif, mais se distinguent par la technologie sous-jacente et le mode de conception.
Les agents dits déterministes suivent des scénarios prédéfinis, chaque réponse étant explicitement codée.
À l’inverse, les agents génératifs s’appuient sur l’IA générative et les LLM pour fournir des réponses adaptées, même dans des situations imprévues.
Conversational Agent permet d’orchestrer ces deux approches dans un modèle hybride.
Voyons maintenant comment cela fonctionne techniquement.
2.1°) Conversational Agent : Playbook
Le Playbook est l’élément central de cette nouvelle génération d’agents conversationnels hybrides. Il permet de paramétrer un LLM comme Gemini avec précision, en définissant son comportement, ses objectifs et sa manière d’interagir avec l’utilisateur.
Agissant comme une surcouche intelligente, il orchestre le raisonnement du modèle, encadre ses réponses et les enrichit à l’aide de ressources externes.
Pour cela, il repose sur plusieurs paramètres essentiels, que nous allons détailler dans la section suivante.
2.2°) Comment configurer un Playbook ?
Un Playbook s’organise autour de quatre composantes essentielles, qui déterminent la manière dont l’agent construit ses réponses et interagit avec l’utilisateur :
2.2.1°) Goal
Le Goal définit la finalité de la conversation. C’est l’objectif que l’agent doit atteindre.
Par exemple :
• Réserver un rendez-vous médical
• Résumer un contrat juridique en langage courant
2.2.2°) Instructions
Les Instructions définissent les étapes que doit suivre l’agent pour atteindre l’objectif.
Exemple :
- Demander à l’utilisateur s’il a une date de préférence.
- Si oui, proposer un créneau disponible.
- Sinon, en proposer trois au hasard.
2.2.3°) Guider avec des exemples
Les exemples sont indispensables. Ils montrent au LLM comment réagir dans des situations concrètes.
- ✅ Réussite : la réponse idéale attendue
- ❌ Échec : que dire quand l’IA ne sait pas répondre
- 🚫 Hors périmètre : comment refuser poliment une question hors sujet
Ces scénarios permettent d’ancrer le comportement de l'agent dans des cas concrets et d'assurer la cohérence des réponses.
2.2.4°) Tools
Plusieurs tools peuvent être intégrés pour augmenter les capacités de l’agent comme par exemple :
- Datastore : base de données vectorielles gérée automatiquement, permettant d’ajouter des connaissances métiers et d’effectuer des recherches contextuelles via la technologie RAG* (Retrieval-Augmented Generation).
- OpenAPI Tools : connectent l’agent à des API tierces pour exécuter des actions ou récupérer des données externes (ex. : créer un ticket, consulter un stock, réserver un créneau).
2.3°) Diviser pour mieux régner
L’un des atouts majeurs des agents conversationnels modernes réside dans leur capacité à orchestrer plusieurs modèles spécialisés, chacun dédié à un domaine ou une tâche précise.
Prenons l’exemple d’un assistant conversationnel dédié au cinéma:
- Le premier Playbook est une encyclopédie du cinéma. Il s’appuie sur une base de données complète de films pour répondre à des questions factuelles comme :
“Quels films avec Audrey Hepburn entre 1960 et 1970 ?”, “Qui a réalisé Le Parrain ?” - Le second Playbook est dédié aux films actuellement à l’affiche. Il commence par interroger l’utilisateur sur ses envies du moment (humeur, genre, durée, lieu, horaire), puis lui propose des séances en fonction des cinémas proches, via des données mises à jour en temps réel.
🎯 Il est plus judicieux de séparer ces logiques en deux Playbooks, aux objectifs bien distincts (informer vs recommander) et aux sources de données différentes (base statique vs API dynamique).
Cette séparation permet d’éviter les confusions, par exemple :
- que l’agent réponde à “Quels films avec Brad Pitt ?” par une liste de séances à l’affiche,
- ou à l’inverse, qu’il propose un film de 1985 à quelqu’un qui cherche une séance ce soir.
En plus de garantir la cohérence des réponses, cette approche simplifie la maintenance, et réduit les risques de réponses hors sujet.
Enfin, lorsque les interactions nécessitent un enchaînement précis et sans ambiguïté, il reste possible d’utiliser l’approche déterministe de Dialogflow CX.
L’agent peut alors basculer vers un Flow pour guider l’utilisateur étape par étape, avant de revenir vers un Playbook plus flexible une fois le parcours terminé.
Nous n’entrerons pas dans le détail de la création technique d’un flow mais voici la definition d'un agent avec des flows pour avoir une compréhension de la différence entre agent déterministe et génératif.
3°) DialogFlow
Un agent basé sur Dialogflow CX repose sur une architecture en flow, représentée sous forme de graphe. Chaque nœud de ce graphe est appelé un Driver.
Son objectif est de déterminer l’intention de l’utilisateur lorsqu'il sollicite l’agent, et potentiellement l’orienter vers le Driver approprié.
Dans un driver on pourra définir plusieurs interactions possibles.
Voici un exemple d’interaction typique dans un agent basé sur Dialogflow CX, imagé étape par étape :
- (1) Message de l’utilisateur
Exemple : « Je veux acheter un produit » - (2) Détection d’intention
Le système utilise du NLP* pour identifier l’intention exprimée. Ici une intention d’achat. Cette détection s’appuie sur un calcul de similarité avec un ensemble de training phrases prédéfini pour cette intention - (3) Réponse configurée
Une réponse correspondante est automatiquement déclenchée, par exemple :
« Très bien, quels produits souhaitez-vous acheter ? » - (4) Transition
En fonction de l’intention détectée, l’utilisateur peut être redirigé vers un autre Driver, ou vers une page spécifique dédiée à l’achat
Pour chaque type de demande que l’on souhaite que l’agent couvre, comme par exemple : “Quels sont les allergènes sur tel produit ?” ou “Quel est le prix de ce produit?”, un scénario distinct doit être défini manuellement.
Bien que depuis 2023 il soit possible d’intégrer de l’IA générative dans Dialogflow CX, l’outil reste avant tout conçu pour la modélisation d’agents déterministes, structurés autour d’une logique explicite et encadrée.
En cela, il se distingue clairement de Conversational Agent, qui repose sur des Playbooks exploitant la puissance des LLM pour couvrir des scénarios beaucoup plus ouverts, sans avoir à les définir un par un.
Pour approfondir techniquement le sujet, voici quelques ressources utiles :
- Concepts de base de Dialogflow – SoftFluent
- Créer un chatbot performant avec Dialogflow – Ideta
- Améliorer les dialogues avec Bubblescript – Botsquad
Conclusion
Conversational Agent permet de tirer parti de la souplesse des LLM pour concevoir des agents no-code, capables de générer des réponses plus ouvertes et contextuelles. L'outil offre une approche hybride puissante en combinant la flexibilité des Playbooks et la rigueur des Flows, s'adaptant ainsi à une multitude de cas d'usage, des procédures rigides aux échanges les plus libres.
Toutefois, cette approche low-code/no-code, bien qu’accessible, n’est qu’une facette de la création d’agents intelligents. En parallèle, un écosystème florissant de frameworks de développement permet aux ingénieurs de construire des agents sur-mesure avec un contrôle total sur leur logique et leur intégration. Des outils comme LangChain se sont imposés comme des standards pour l'orchestration d'agents, en permettant de chaîner des appels aux LLM, des outils (tools) et des sources de données. De même, des kits de développement logiciel spécifiques, tels que l'OpenAI Agents SDK et Agent Development Kit (ADK) de Google, fournissent les briques essentielles pour bâtir des agents exploitant les capacités de modèles particuliers.
En définitive, que ce soit via des plateformes intégrées comme Google Conversational Agent ou via des frameworks de code, la tendance est claire : l’avenir des interfaces est conversationnel, piloté par des agents intelligents. Le choix de la technologie dépendra de l'équilibre recherché entre la rapidité de mise en œuvre et la profondeur de la personnalisation. Ces deux mondes, loin de s'opposer, façonnent ensemble la nouvelle génération d’applications intelligentes.
Glossaire
- IA générative : Type d’intelligence artificielle capable de créer du contenu nouveau (texte, code, image) à partir de données d’apprentissage.
- LLM (Large Language Model) : Modèle d’intelligence artificielle générative de grande taille, entraîné sur des milliards de textes. Des exemples connus de LLMs sont ChatGPT et Gemini.
- NLP (Natural Language Processing) : Traitement automatique du langage naturel. Ensemble de techniques utilisées pour analyser, comprendre et générer du texte ou de la parole.
- RAG (Retrieval-Augmented Generation) : Méthode qui combine la recherche d’informations pertinentes dans une base de données avec un message entrant, puis enrichit la requête envoyée au LLM avec ces informations.
