État de l'art sur l'Intelligence Artificielle (IA) : concepts, enjeux, technologies et stratégies pour les entreprises
- Durée
- Durée :2 jours
- Niveau
- Niveau :Fondamental
- Certification
- Certification :Non
1990€ HT
Prochaine session :
Développer un assistant conversationnel avec Rasa et LlamaIndex
Concevoir, enrichir et déployer un assistant conversationnel hybride combinant Rasa, NLP et architecture RAG avec LlamaIndexDescription de la formation Rasa LlamaIndex
Qu'est-ce qu'un assistant conversationnel avec Rasa et LlamaIndex ?
Les assistants conversationnels sont devenus des interfaces privilégiées dans les secteurs de la banque et de l’assurance : qualification de leads, assistance client, collecte d’informations structurées, orientation vers les bons services. Deux approches dominent : les chatbots ML avec Rasa, robustes et maîtrisables, et les architectures RAG avec LlamaIndex qui connectent un LLM à une base de connaissances interne.
Pourquoi suivre une formation Développer un assistant conversationnel avec Rasa et LlamaIndex ?
Cette formation s’appuie sur le projet fil rouge DataInsure : les participants construisent le chatbot d’accueil et d’orientation client de la plateforme. Ce chatbot s’intègre avec les modèles précédemment construits : il appelle le classifieur documentaire PyTorch pour router les documents entrants et le modèle de churn TensorFlow pour alerter les conseillers sur les clients à risque de résiliation. LlamaIndex enrichit l’assistant d’une base de connaissances sur les CGU et contrats DataInsure.
Programme de la formation
Objectif opérationnel :
Savoir créer et déployer un assistant conversationnel.
Objectif pédagogiques :
À l'issue de cette formation Développer un assistant conversationnel avec Rasa et LlamaIndex, vous aurez acquis les connaissances nécessaires pour :
- Concevoir un chatbot intelligent.
- Gérer le traitement du langage naturel.
- Intégrer et déployer le chatbot.
- Optimiser la compréhension et les réponses.
Jour 1
Architecture d’un assistant : NLU, dialogue management, actions, canaux
Cas d’usage DataInsure : accueil, qualification, orientation, FAQ
Positionnement de Rasa : open source, maîtrise des données, déploiement on-premise
Architecture de la plateforme DataInsure et place du chatbot dans l’écosystème IA
Installation et démarrage : rasa init, structure des fichiers, rasa train
Composants du pipeline NLU : WhitespaceTokenizer, DIETClassifier
L’interface Rasa Shell pour tester en ligne de commande
Rasa X / Rasa Pro : l’interface d’annotation et d’amélioration continueTravaux pratiquesObjectif : Créer le premier assistant DataInsure capable d’accueillir un client, d’identifier son besoin et de lui indiquer le bon service.
Description : Initialisation du projet Rasa DataInsure. Les participants définissent d’abord les cinq scénarios clients les plus fréquents (signaler un sinistre, demander un devis, résilier un contrat, poser une question sur sa garantie, être mis en relation avec un conseiller). Cette étape de conception en amont est intentionnelle : un chatbot mal conçu dès le départ ne sera jamais bon, quel que soit le raffinement NLU. Le domain.yml est créé avec les intents, les réponses et les actions nécessaires. Les premières stories sont rédigées, le modèle est entraîné et testé en shell. Le groupe confronte les formulations inattendues d’un client réel : « je veux changer ma formule », « y a eu un dégât des eaux » et obsèrve les premières limites.
Entités : extraction par regex, lookup tables et DIETClassifier
Qualité des données NLU : équilibre des classes, variations linguistiques
Évaluation NLU : rasa test nlu, matrice de confusion des intents
Augmentation des données : paraphrases, gestion des fautes d’orthographeTravaux pratiquesObjectif : Améliorer la compréhension du langage naturel du chatbot DataInsure à partir de l’analyse des confusions NLU.
Description : Enrichissement du fichier nlu.yml avec des exemples variés couvrant le vocabulaire assurance (sinistre, dommage, couverture, franchise, cotisation…). Définition des entités métier : type_sinistre, num_contrat, date_incident. Après entraînement, rasa test nlu est exécuté et la matrice de confusion est analysée : quels intents sont confondus ? La paire « demande_resilier / demande_modifier » est intentionnellement ambiguë pour montrer comment les exemples mal choisis créent de la confusion. Les participants corrigent en divisant les intents ou en enrichissant les exemples et mesurènt l’impact sur les métriques NLU. Cette itération « tester / analyser / corriger » est le quotidien du développeur chatbot.
Structure d’une story : user steps, action steps, slots
Politique de dialogue : TEDPolicy, RulePolicy, MemoizationPolicy
Gestion des interruptions et des digressions
Rasa Interactive : annotation interactive de conversations réellesJour 2
Le serveur d’actions : rasa run actions, endpoint.yml
Appeler une API externe depuis une action : requêtes HTTP, gestion des erreurs
Modifier les slots et le suivi de dialogue depuis une action
Tests unitaires des actions avec pytestTravaux pratiquesObjectif : Intégrer le classifieur documentaire PyTorch dans une action Rasa pour router automatiquement les documents reçus par DataInsure.
Description : Les participants implémentent une action Rasa « action_classifier_document » qui envoie une image de document reçue par le chatbot à l’endpoint TorchServe et récupère la catégorie prédite (sinistre / devis / résiliation). Selon la classification, l’assistant oriente le client vers le bon service et déclenche la story correspondante. Trois cas d’erreur sont implémentés : service indisponible, confiance NLU trop faible, catégorie inconnue. Cette intégration réelle d’un modèle ML dans un chatbot illustre comment les briques de la plateforme DataInsure fonctionnent ensemble.
Formulaires : l’action FormAction, required_slots, slot_mappings
Validation des slots : FormValidationAction
Gestion des interruptions dans un formulaire : unhappy paths
Cas d’usage : collecte d’un dossier de déclaration de sinistreTravaux pratiquesObjectif : Construire le formulaire de déclaration de sinistre DataInsure avec validation métier et gestion des cas d’erreur.
Description : Implémentation d’un formulaire Rasa pour la déclaration de sinistre DataInsure : collecte du numéro de contrat, type de sinistre, date d’incident, description. La FormValidationAction vérifie que le numéro de contrat est au bon format (regex), que la date est dans le passé et que le type de sinistre correspond à une garantie active (vérification dans une API simulant le système de gestion DataInsure). Trois scénarios d’unhappy path sont implémentés : le client interrompt pour poser une question, fournit un numéro de contrat invalide, change d’avis sur le type de sinistre. La robustesse du formulaire est testée par tout le groupe avec des scénarios improbables pour révéler les cas non couverts.
Analyse des conversations réelles : patterns d’échec, intents manquants
Amélioration continue : cycle annotation → entraînement → évaluation
Métriques clés : intent accuracy, entity F1, dialogue success rate
Gestion du versionnement des modèlesTravaux pratiquesObjectif : Simuler le processus d’amélioration continue du chatbot DataInsure à partir de conversations réelles échouées.
Description : Un jeu de 30 conversations DataInsure échouées est fourni : clients ayant été mal orientés, formulaires abandonnés, intents non reconnus. Les participants analysent ces échecs, les catégorisent (problème NLU, problème de flow, manque d’intent, validation trop stricte) et définissent les corrections prioritaires. Les corrections sont implémentées, le modèle est réentraîné et les mêmes 30 conversations sont rejouées pour mesurer l’amélioration. Cette simulation d’un cycle d’amélioration continue est représentative du travail quotidien sur un chatbot en production.Jour 3
Le paradigme RAG : retrieval + génération
Architecture LlamaIndex : Data Connectors, Index, Query Engine
Comparaison des approches : Rasa (déterministe) vs RAG (génératif) vs hybride
Cas d’usage RAG DataInsure : FAQ sur les CGU, conditions de garanties, procédures
Chunking et Node Parsing : stratégies de découpage
Modèles d’embedding : OpenAI, HuggingFace, Ollama pour les embeddings locaux
Vector stores : FAISS, Chroma, Qdrant — critères de choix
Évaluation de la qualité du retrieval : hit rate, MRR, precision@kTravaux pratiquesObjectif : Indexer la base documentaire DataInsure (CGU, conditions de garanties) avec LlamaIndex et valider la pertinence des résultats de recherche.
Description : Chargement et indexation du corpus documentaire DataInsure (5 CGU produits, 3 guides de procédure, la grille tarifaire) avec LlamaIndex. Comparaison de deux stratégies de chunking : par taille fixe (512 tokens) et par section sémantique (découpage aux titres et sous-titres). Pour chaque stratégie, un jeu de 10 questions métier est testé (ex. : « quelle est la franchise pour un dégât des eaux ? ») et les passages récupérés sont évalués manuellement. Le VectorStore Chroma est persisté sur disque.
Décider quand router vers le RAG et quand utiliser le dialogue structuré
Construire un fallback intelligent : NLU confidence + RAG
Chaîner retrieval et LLM : prompt engineering pour des réponses factuelles
Gérer la citation des sources dans les réponsesTravaux pratiquesObjectif : Enrichir le chatbot DataInsure avec la base documentaire RAG pour répondre aux questions sur les garanties sans programmer chaque cas manuellement.
Description : Implémentation d’une action Rasa « action_ask_knowledge_base » qui interroge le VectorStoreIndex LlamaIndex construit dans le TP précédent. Le routage est implémenté : si la confiance NLU de l’intent est inférieure à 0.7 ou si l’intent est « ask_contract_details », l’action RAG est déclenchée. Test de l’assistant hybride sur 15 questions : 5 structurées (formulaire sinistre), 5 documentaires (garanties), 5 limites (questions hors-scope pour tester le fallback gracieux). Les participants observent que l’assistant n’a pas besoin de stories pour chaque question documentaire — le RAG l’en dispense — mais que le dialogue structuré reste indispensable pour les processus critiquest (déclaration, souscription). Ce modèle hybride est le pattern architectural de référence pour les assistants en production.
Docker Compose : orchestrer Rasa, actions, vector store et APIs externes
Canaux de déploiement : web socket, REST, Teams, WhatsApp
Monitoring en production : logs de conversation, métriques de performance
Sécurité et confidentialité : données PII, chiffrement, conformité RGPD
Introduction aux chatbots et à l’architecture conversationnelle
Panorama des approches : chatbots à règles, ML (Rasa), LLM natifs, LLM augmentés (RAG)Architecture d’un assistant : NLU, dialogue management, actions, canaux
Cas d’usage DataInsure : accueil, qualification, orientation, FAQ
Positionnement de Rasa : open source, maîtrise des données, déploiement on-premise
Architecture de la plateforme DataInsure et place du chatbot dans l’écosystème IA
Structure d’un projet Rasa et prise en main
Architecture d’un projet Rasa : domain.yml, nlu.yml, stories.yml, rules.yml, config.ymlInstallation et démarrage : rasa init, structure des fichiers, rasa train
Composants du pipeline NLU : WhitespaceTokenizer, DIETClassifier
L’interface Rasa Shell pour tester en ligne de commande
Rasa X / Rasa Pro : l’interface d’annotation et d’amélioration continueTravaux pratiquesObjectif : Créer le premier assistant DataInsure capable d’accueillir un client, d’identifier son besoin et de lui indiquer le bon service.
Description : Initialisation du projet Rasa DataInsure. Les participants définissent d’abord les cinq scénarios clients les plus fréquents (signaler un sinistre, demander un devis, résilier un contrat, poser une question sur sa garantie, être mis en relation avec un conseiller). Cette étape de conception en amont est intentionnelle : un chatbot mal conçu dès le départ ne sera jamais bon, quel que soit le raffinement NLU. Le domain.yml est créé avec les intents, les réponses et les actions nécessaires. Les premières stories sont rédigées, le modèle est entraîné et testé en shell. Le groupe confronte les formulations inattendues d’un client réel : « je veux changer ma formule », « y a eu un dégât des eaux » et obsèrve les premières limites.
NLU : intents, entités et données d’entraînement
Conception des intents : granularité, couverture, exemples diversifiésEntités : extraction par regex, lookup tables et DIETClassifier
Qualité des données NLU : équilibre des classes, variations linguistiques
Évaluation NLU : rasa test nlu, matrice de confusion des intents
Augmentation des données : paraphrases, gestion des fautes d’orthographeTravaux pratiquesObjectif : Améliorer la compréhension du langage naturel du chatbot DataInsure à partir de l’analyse des confusions NLU.
Description : Enrichissement du fichier nlu.yml avec des exemples variés couvrant le vocabulaire assurance (sinistre, dommage, couverture, franchise, cotisation…). Définition des entités métier : type_sinistre, num_contrat, date_incident. Après entraînement, rasa test nlu est exécuté et la matrice de confusion est analysée : quels intents sont confondus ? La paire « demande_resilier / demande_modifier » est intentionnellement ambiguë pour montrer comment les exemples mal choisis créent de la confusion. Les participants corrigent en divisant les intents ou en enrichissant les exemples et mesurènt l’impact sur les métriques NLU. Cette itération « tester / analyser / corriger » est le quotidien du développeur chatbot.
Gestion du dialogue : stories et règles
Stories vs règles : quand utiliser l’une ou l’autreStructure d’une story : user steps, action steps, slots
Politique de dialogue : TEDPolicy, RulePolicy, MemoizationPolicy
Gestion des interruptions et des digressions
Rasa Interactive : annotation interactive de conversations réellesJour 2
Actions personnalisées et intégration d’APIs externes
Actions personnalisées : la classe Action et la méthode run()Le serveur d’actions : rasa run actions, endpoint.yml
Appeler une API externe depuis une action : requêtes HTTP, gestion des erreurs
Modifier les slots et le suivi de dialogue depuis une action
Tests unitaires des actions avec pytestTravaux pratiquesObjectif : Intégrer le classifieur documentaire PyTorch dans une action Rasa pour router automatiquement les documents reçus par DataInsure.
Description : Les participants implémentent une action Rasa « action_classifier_document » qui envoie une image de document reçue par le chatbot à l’endpoint TorchServe et récupère la catégorie prédite (sinistre / devis / résiliation). Selon la classification, l’assistant oriente le client vers le bon service et déclenche la story correspondante. Trois cas d’erreur sont implémentés : service indisponible, confiance NLU trop faible, catégorie inconnue. Cette intégration réelle d’un modèle ML dans un chatbot illustre comment les briques de la plateforme DataInsure fonctionnent ensemble.
Slots, formulaires et collecte d’informations structurées
Slots : types (text, bool, float, list, categorical), persistance et resetFormulaires : l’action FormAction, required_slots, slot_mappings
Validation des slots : FormValidationAction
Gestion des interruptions dans un formulaire : unhappy paths
Cas d’usage : collecte d’un dossier de déclaration de sinistreTravaux pratiquesObjectif : Construire le formulaire de déclaration de sinistre DataInsure avec validation métier et gestion des cas d’erreur.
Description : Implémentation d’un formulaire Rasa pour la déclaration de sinistre DataInsure : collecte du numéro de contrat, type de sinistre, date d’incident, description. La FormValidationAction vérifie que le numéro de contrat est au bon format (regex), que la date est dans le passé et que le type de sinistre correspond à une garantie active (vérification dans une API simulant le système de gestion DataInsure). Trois scénarios d’unhappy path sont implémentés : le client interrompt pour poser une question, fournit un numéro de contrat invalide, change d’avis sur le type de sinistre. La robustesse du formulaire est testée par tout le groupe avec des scénarios improbables pour révéler les cas non couverts.
Évaluation, tests et amélioration continue
Stratégie de test : tests unitaires des actions, tests end-to-end, tests de régression NLUAnalyse des conversations réelles : patterns d’échec, intents manquants
Amélioration continue : cycle annotation → entraînement → évaluation
Métriques clés : intent accuracy, entity F1, dialogue success rate
Gestion du versionnement des modèlesTravaux pratiquesObjectif : Simuler le processus d’amélioration continue du chatbot DataInsure à partir de conversations réelles échouées.
Description : Un jeu de 30 conversations DataInsure échouées est fourni : clients ayant été mal orientés, formulaires abandonnés, intents non reconnus. Les participants analysent ces échecs, les catégorisent (problème NLU, problème de flow, manque d’intent, validation trop stricte) et définissent les corrections prioritaires. Les corrections sont implémentées, le modèle est réentraîné et les mêmes 30 conversations sont rejouées pour mesurer l’amélioration. Cette simulation d’un cycle d’amélioration continue est représentative du travail quotidien sur un chatbot en production.Jour 3
Introduction à LlamaIndex et aux architectures RAG
Limites des LLM natifs : hallucinations, données privées, kno cutoffLe paradigme RAG : retrieval + génération
Architecture LlamaIndex : Data Connectors, Index, Query Engine
Comparaison des approches : Rasa (déterministe) vs RAG (génératif) vs hybride
Cas d’usage RAG DataInsure : FAQ sur les CGU, conditions de garanties, procédures
Indexation de documents et vector stores avec LlamaIndex
Chargement de documents : SimpleDirectoryReader, connecteurs PDF, Word, CSVChunking et Node Parsing : stratégies de découpage
Modèles d’embedding : OpenAI, HuggingFace, Ollama pour les embeddings locaux
Vector stores : FAISS, Chroma, Qdrant — critères de choix
Évaluation de la qualité du retrieval : hit rate, MRR, precision@kTravaux pratiquesObjectif : Indexer la base documentaire DataInsure (CGU, conditions de garanties) avec LlamaIndex et valider la pertinence des résultats de recherche.
Description : Chargement et indexation du corpus documentaire DataInsure (5 CGU produits, 3 guides de procédure, la grille tarifaire) avec LlamaIndex. Comparaison de deux stratégies de chunking : par taille fixe (512 tokens) et par section sémantique (découpage aux titres et sous-titres). Pour chaque stratégie, un jeu de 10 questions métier est testé (ex. : « quelle est la franchise pour un dégât des eaux ? ») et les passages récupérés sont évalués manuellement. Le VectorStore Chroma est persisté sur disque.
Connecter LlamaIndex à Rasa : architecture hybride
Intégrer LlamaIndex dans une action Rasa personnaliséeDécider quand router vers le RAG et quand utiliser le dialogue structuré
Construire un fallback intelligent : NLU confidence + RAG
Chaîner retrieval et LLM : prompt engineering pour des réponses factuelles
Gérer la citation des sources dans les réponsesTravaux pratiquesObjectif : Enrichir le chatbot DataInsure avec la base documentaire RAG pour répondre aux questions sur les garanties sans programmer chaque cas manuellement.
Description : Implémentation d’une action Rasa « action_ask_knowledge_base » qui interroge le VectorStoreIndex LlamaIndex construit dans le TP précédent. Le routage est implémenté : si la confiance NLU de l’intent est inférieure à 0.7 ou si l’intent est « ask_contract_details », l’action RAG est déclenchée. Test de l’assistant hybride sur 15 questions : 5 structurées (formulaire sinistre), 5 documentaires (garanties), 5 limites (questions hors-scope pour tester le fallback gracieux). Les participants observent que l’assistant n’a pas besoin de stories pour chaque question documentaire — le RAG l’en dispense — mais que le dialogue structuré reste indispensable pour les processus critiquest (déclaration, souscription). Ce modèle hybride est le pattern architectural de référence pour les assistants en production.
Déploiement et bonnes pratiques de production
Conteneurisation avec Docker : Dockerfile pour le modèle Rasa et le serveur d’actionsDocker Compose : orchestrer Rasa, actions, vector store et APIs externes
Canaux de déploiement : web socket, REST, Teams, WhatsApp
Monitoring en production : logs de conversation, métriques de performance
Sécurité et confidentialité : données PII, chiffrement, conformité RGPD
Public cible :
Ce cours s’adresse aux développeurs AI et aux NLP engineers maîtrisant Python, souhaitant concevoir des assistants conversationnels robustes et déployables en production, capables de gérer des dialogues complexes et de s’intégrer aux systèmes métier.
Il intéressera également les data scientists impliqués dans des projets de chatbot ou de voicebot, et les architectes solutions évaluant les approches conversationnelles pour leur organisation.
Prérequis :
Des connaissances solides en Python sont requises. Une familiarité avec les concepts de base du NLP (tokenisation, classification de texte, embeddings) et avec le ML facilitera la compréhension de Rasa NLU.
Des bases en développement web (API REST, JSON) et en Docker seront utiles pour les ateliers de déploiement. Une connaissance des APIs LLM facilitera l’intégration LlamaIndex.
J'évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Date de mise à jour du programme : 29/05/2026
Dates et lieux
Période souhaitée
Lieux
Type d'affichage