--- title: Systeme Conversationnel url: https://blog.guigpap.com/fr/workflows/systeme-conversationnel/ url_md: https://blog.guigpap.com/fr/workflows/systeme-conversationnel.md category: tooling date: '2026-03-28' maturite: production techno: - n8n - telegram - claude - odoo application: - ai - knowledge - operations --- # Systeme Conversationnel > Agent IA multi-tours avec plans d'action, outils MCP et memoire persistante dans Telegram ## 1. Quoi ? — Definition et contexte Au-dela des commandes simples (`/docker status`, `/n8n workflows`), il y a des demandes qui necessitent une vraie conversation : "cherche le contact Dupont dans Odoo, puis montre-moi ses factures impayees, et cree un projet de suivi". Ca demande du contexte, de la memoire entre les messages, et la capacite d'executer des actions en plusieurs etapes. Le **Systeme Conversationnel** transforme le bot Telegram en un assistant IA capable de maintenir des conversations multi-tours, d'appeler des outils (Docker, Odoo, N8N, recherche web), d'executer des plans multi-etapes, et de selectionner dynamiquement des outils MCP — le tout avec une memoire persistante via Redis. > **Note - Conversation multi-tours** > > Une **conversation multi-tours** signifie que l'IA se souvient de ce que vous avez dit precedemment. Si vous demandez "cherche Jean", puis "montre ses factures", l'IA sait que "ses" fait reference a Jean grace au contexte de la session. ### Les trois couches du systeme | Couche | Composants | Role | |--------|------------|------| | **Conversations** | Agent (20n), Manager (20n), Command Handlers (35n), Callback Handler (94n), Summarizer (12n) | Cycle de vie des conversations, routage, memoire | | **Outils** | Tool Router (10n), Web Search (6n), Lead Intelligence (11n) | Execution d'actions et enrichissement | | **Plans & MCP** | Plan Engine (55n), MCP Menu, MCP Confirmation (3n) | Actions multi-etapes et outils avances | ### Architecture d'ensemble ```mermaid flowchart TD Msg["Message texte · conversation active"] subgraph Agent["Conversation Agent · 20 nodes"] direction TB Prompt["Build System Prompt"] First["Call Claude · 1er pass"] Detect{"Type de reponse"} Second["Claude 2nd pass · resume"] Send["Envoi Telegram"] end Text["Texte simple"] Tool["bloc tool · Tool Router 10n"] Plan["bloc plan · Plan Engine 55n"] MCP["bloc mcp · cli-ollama"] Msg --> Prompt --> First --> Detect Detect --> Text --> Send Detect --> Tool --> Second Detect --> Plan --> Second Detect --> MCP --> Second Second --> Send ``` --- ## 2. Pourquoi ? — Enjeux et motivations Avant le systeme conversationnel, chaque interaction avec le bot etait atomique. Vous envoyiez une commande, vous receviez une reponse, et le bot oubliait tout. Pour des taches complexes, il fallait enchainer les commandes manuellement en copiant-collant les resultats d'une etape a l'autre. ### Problemes resolus | Probleme | Sans conversations | Avec conversations | |----------|--------------------|--------------------| | **Pas de memoire** | Le bot oublie entre chaque message | Session Redis persistante | | **Actions atomiques** | Une commande = une action | Plans multi-etapes automatiques | | **Pas de contexte** | "montre ses factures" → de qui ? | L'IA garde le fil de la discussion | | **Outils limites** | Commandes fixes /docker, /n8n | Langage naturel + appels d'outils dynamiques | | **Pas de recherche** | Pas d'acces au web | Gemini grounding + lead intelligence | ### Choix d'architecture Pourquoi un flow a 2 passes LLM plutot qu'un appel unique ? | Approche | Avantage | Inconvenient | |----------|----------|--------------| | **1 passe** | Plus rapide | L'IA ne peut que parler, pas agir | | **2 passes** | Detection outil → execution → resume | 2x latence LLM sur les appels outil | La 2eme passe est essentielle : elle permet a Claude de reformuler les resultats techniques (JSON Docker, XML-RPC Odoo) en reponse humaine lisible. > **Tip - Templates de conversation** > > Cinq templates sont disponibles pour specialiser le comportement : `crm` (focus vente), `docker` (focus infra), `code` (focus dev), `content` (focus contenu), `brainstorm` (mode creatif). Chaque template ajuste le prompt systeme et le modele LLM par defaut. --- ## 3. Comment ? — Mise en oeuvre technique ### Gestion du cycle de vie Sept commandes gèrent les conversations : | Commande | Action | |----------|--------| | `/new` | Cree une conversation (archive la precedente si active) | | `/conv` | Liste les conversations avec pagination | | `/endconv` | Archive la conversation active | | `/model` | Change le modele LLM (Codex Max/Standard/Mini, Gemini Pro/Flash) | | `/plan` | Affiche le statut du plan en cours | | `/templates` | Liste les 5 templates disponibles | | `/mcp` | Configure les outils MCP pour cette conversation | Deux Data Tables gerent l'etat : - **conversations** — Titre, modele, template, statut, compteur de tours, config MCP, plan associe - **active_conversations** — Une ligne par utilisateur, pointe vers la conversation en cours Quand un message texte arrive et qu'une conversation est active, l'Orchestrateur court-circuite le routage normal (IA Router, Command Router) et envoie directement le message au Conversation Agent. ### Le parcours d'un message Quand vous ecrivez "quels sont les projets en cours sur Odoo ?" dans une conversation active : **1. Interception** — L'Orchestrateur detecte la conversation active et route vers le Conversation Agent. **2. Verification retry** — Le systeme verifie si un plan est en attente de correction (escalade). Si oui, le message est traite comme une correction, pas comme un nouveau message. **3. Construction du prompt** — Le prompt systeme est construit selon le template actif, avec les descriptions des outils disponibles et les instructions MCP si actives. **4. Premier appel Claude** — Le LLM recoit le message avec tout le contexte de session (via Redis). Il peut repondre en texte simple, ou generer un bloc outil : | Bloc | Routage | |------|---------| | ` ```tool ` | Appel Docker, Odoo, N8N, recherche web | | ` ```plan ` | Création d'un plan multi-étapes | | ` ```mcp ` | Appel direct d'un outil MCP N8N | **5. Execution** — Selon le type detecte, le systeme route vers le Tool Router, le Plan Engine, ou le gateway MCP. **6. Deuxieme appel Claude** — Les resultats bruts sont reinjectes dans le contexte, et Claude genere une reponse lisible. Un prompt restrictif empeche la generation de nouveaux blocs outil a ce stade. **7. Envoi** — La reponse est envoyee sur Telegram (tronquee a 4000 caracteres si necessaire). **8. Compression** — Si le compteur de tours depasse 40, le Conversation Summarizer compresse automatiquement l'historique : les vieux messages sont resumes en un paragraphe, et les 10 derniers messages sont conserves intacts. ### Le Tool Router Quand Claude genere un bloc `tool`, le Conversation Tool Router dispatche vers le bon service : | Service | Handler | Exemples d'actions | |---------|---------|-------------------| | `docker` | Service Handler Docker | status, restart, logs, update | | `odoo` | Service Handler Odoo | search_contact, search_invoice, list_projects | | `n8n` | Service Handler N8N | list_workflows, list_executions, toggle | | `web_search` | Conversation Web Search | Recherche Gemini avec sources | | `lead_intelligence` | Conversation Lead Intelligence | Enrichissement contact (Odoo + web) | La reponse est normalisee avec une detection multi-signal des echecs (champ `error`, `success === false`, status HTTP >= 400, texte vide). ### Le Plan Engine Le Plan Engine gere les demandes qui necessitent plusieurs etapes coordonnees. Quand Claude detecte qu'une tache est trop complexe pour un seul appel outil, il genere un plan : ```text Utilisateur: "Verifie le status de tous les stacks Docker, et redemarre ceux qui sont down" Claude genere un plan : Etape 1: docker status (tous les stacks) Etape 2: analyser les resultats → identifier les down Etape 3: docker restart (stacks down) Le plan est presente avec des boutons : [Executer] [Modifier] [Annuler] ``` Chaque etape peut referencer les resultats des etapes precedentes via des variables (`{{step_0_result}}`). Si une etape echoue, le systeme escalade avec trois options : | Action | Comportement | |--------|--------------| | **[Passer]** | Saute l'etape + cascade transitive (annule les dependances) | | **[Modifier]** | Demande une correction textuelle, puis reprend | | **[Annuler]** | Annule toutes les etapes restantes | > **Caution - Detection de contradictions** > > Si une etape echoue et que des etapes suivantes dependent de son resultat, le Plan Engine detecte la contradiction automatiquement et escalade avant d'executer du code avec des donnees manquantes. ### Le systeme MCP La commande `/mcp` ouvre un menu permettant d'activer ou desactiver des outils MCP (Model Context Protocol) pour la conversation en cours. Vingt outils N8N sont disponibles, repartis en deux categories : | Categorie | Nombre | Comportement | |-----------|--------|--------------| | **Lecture seule** | 12 | Execution directe (list_workflows, get_workflow, search_nodes...) | | **Ecriture** | 8 | Confirmation Telegram obligatoire avant execution | Le menu affiche chaque serveur avec son statut ON/OFF et le nombre d'outils actifs. On peut activer/desactiver a la granularite d'un outil individuel ou en masse par serveur. Quatre couches de securite protegent les operations : 1. **Whitelist utilisateur** — Seuls les outils explicitement actives dans la config MCP sont accessibles 2. **Flag mcp_enabled** — Quand desactive, le CLI tourne sans aucun serveur MCP 3. **Filtre allowed_tools** — Le gateway cli-ollama bloque les appels non autorises (403) 4. **Confirmation Telegram** — Les outils d'ecriture declenchent un workflow de confirmation avec boutons [Approuver] / [Rejeter] et timeout de 90 secondes > **Danger - Timeout de confirmation** > > Si personne ne repond aux boutons de confirmation MCP dans les 90 secondes, l'operation est automatiquement rejetee. C'est un filet de securite contre les appels MCP non surveilles. ### Memoire et compression La memoire de conversation est geree par Redis via le service `memory_service` de CLI Ollama. Chaque conversation a un `session_id` unique qui sert de cle Redis. Quand le nombre de tours depasse 40 (~20 echanges), le Conversation Summarizer intervient : 1. Recupere tous les messages de la session via l'API REST 2. Separe les 10 derniers messages (a conserver intacts) 3. Resume les anciens messages en un paragraphe (Claude, max 200 mots) 4. Vide la session Redis et reinjecte le resume + les messages recents L'utilisateur ne voit rien — la compression est transparente et permet des conversations qui durent des heures sans degradation de qualite. --- ## 4. Et si ? — Perspectives et limites ### Limites actuelles | Limite | Impact | Mitigation | |--------|--------|------------| | **Latence 2 passes** | 5-10s par message avec outil | Acceptable pour usage personnel | | **Pas de streaming** | La reponse arrive d'un bloc | Indicateur "typing..." pendant le traitement | | **Plans lineaires** | Pas d'etapes paralleles | Suffisant pour les cas d'usage actuels | | **Compression a 40 tours** | Perte de details anciens | Resume fidele, 10 derniers messages intacts | ### Scenarios d'evolution **Si besoin de conversations multi-utilisateurs** : - Conversations partagees avec permissions - Historique d'actions visible par l'equipe - Assignation de plans a des membres specifiques **Si besoin de plus d'outils** : - Ajouter un service au Tool Router (un nouveau case dans le Switch) - Ou activer un serveur MCP supplementaire - Le systeme est extensible par design **Si besoin de plans plus complexes** : - Ajouter le support d'etapes paralleles (execution concurrente) - Permettre des sous-plans imbriques - Integrer un systeme d'approbation par etape pour les actions critiques --- ## Pages liees ### Infrastructure - [AI Stack](/fr/infrastructure/ai-stack/) — CLI Ollama, Redis, memoire de session - [N8N en mode Queue](/fr/infrastructure/n8n-queue-mode/) — Backend workers ### Workflows - [Telegram Orchestrator](/fr/workflows/telegram-orchestrator/) — Routage des messages et callbacks - [Voice Transcription](/fr/workflows/voice-transcription/) — Messages vocaux dans les conversations - [Global Error Handler](/fr/workflows/error-handler/) — Gestion des erreurs de workflow ### Reference - [Glossaire](/fr/reference/glossary/) — MCP, Session, Multi-tours ## Metadonnees agent - Cet article est issu du blog GuiGPaP Lab. - Contexte global du blog: https://blog.guigpap.com/llms.txt - Contact auteur: https://odoo.guigpap.com/mon-cv - Licence: CC-BY-SA 4.0