Systeme Conversationnel

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.

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

---

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.

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 :

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

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

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 — CLI Ollama, Redis, memoire de session
• N8N en mode Queue — Backend workers

Workflows

• Telegram Orchestrator — Routage des messages et callbacks
• Voice Transcription — Messages vocaux dans les conversations
• Global Error Handler — Gestion des erreurs de workflow

Reference

• Glossaire — MCP, Session, Multi-tours