Comment Fonctionne un Agent IA Conversationnel de l'Intérieur

Comment Fonctionne un Agent IA Conversationnel de l'Intérieur (Architecture OpenClaw)

Comment fonctionne un agent IA conversationnel en pratique, tour par tour ? Cet article ouvre la boîte noire d'OpenClaw : du moment où le message du client arrive sur WhatsApp jusqu'au texte que l'agent écrit en retour. Ce sera technique. Ça vaut le coup si vous décidez de l'architecture produit, si vous allez acheter une solution et voulez évaluer le fond, ou si vous aimez savoir ce qui se passe derrière la conversation.

TL;DR : chaque tour passe par 6 étapes — ingest, résolution de contexte, sélection de skills, décision de la prochaine action, exécution avec guard-rails, persistance de la mémoire. Tout le cycle tourne en <2 secondes sur l'edge de Cloudflare, sans serveur fixe.

---

Pourquoi l'architecture compte

Un agent conversationnel qui semble fonctionner dans une démo mais casse en production a généralement l'un de ces 4 problèmes :

1. Latence élevée — le client attend 8 secondes pour la réponse, la conversation meurt.
2. Hallucination non contrôlée — l'agent invente un prix, un horaire, une politique.
3. Contexte perdu — le client revient après 2 jours et l'agent "oublie" tout.
4. Coût incontrôlé — chaque longue conversation remplit le prompt et vous payez une fortune en tokens.

Les 4 sont des choix d'architecture, pas des limitations du modèle. OpenClaw a été construit pour éviter les 4 — et le chemin pour comprendre est de regarder le cycle d'un tour.

---

Le cycle d'un tour (6 étapes)

Imaginez que le client vient d'envoyer le message "quero marcar pra sábado de manhã". Que se passe-t-il entre le "received" et la réponse de l'agent ?

Étape 1 — Ingest (edge worker, <50ms)

Le message WhatsApp arrive via webhook de Meta directement dans un Cloudflare Worker au point de présence (PoP) le plus proche géographiquement. Au Brésil, cela signifie São Paulo ou Rio, latence réseau < 20ms.

Le worker fait trois choses :

1. Valide la signature du webhook (HMAC contre le secret de la WABA).
2. Identifie le tenant par le numéro de téléphone du récepteur (multi-tenant par to_number).
3. Normalise le payload — l'audio devient transcription, l'image devient description, la localisation devient {lat,lng}, le texte reste tel quel.

À la fin de l'étape 1, vous avez un objet {tenant_id, conversation_id, user_message} prêt pour l'étape suivante.

Étape 2 — Résolution de contexte (D1 + KV, ~80ms)

L'agent a besoin de 3 éléments de contexte avant de décider :

• Historique récent de la conversation (derniers N tours pertinents).
• Mémoire à long terme du client (préférences, historique d'achat, annotations).
• État de l'agent (persona, skills activées, règles).

Tous proviennent du D1 (SQLite distribué de Cloudflare). D1 remplace Postgres/Mongo traditionnel — pas de serveur de base de données à maintenir, accès en quelques ms depuis le worker, multi-tenant par tenant_id.

Point clé : on ne charge pas la conversation entière dans le prompt. Le Memory Manager v2 d'OpenClaw (décrit dans notre documentation interne) sélectionne uniquement les tours pertinents pour le tour actuel (derniers N + N de haute pertinence sémantique). Cela maintient le coût en tokens prévisible même dans des conversations de 100+ tours.

Étape 3 — Sélection des skills (policy engine, ~20ms)

Chaque agent dispose d'un ensemble de skills disponibles — des fonctions qu'il peut invoquer. Exemples : consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Étant donné le message "quero marcar pra sábado de manhã", le policy engine filtre :

• Skills compatibles avec l'intention détectée (prise de rendez-vous).
• Skills autorisées pour cette phase de la conversation (toutes les skills ne sont pas disponibles en permanence).
• Skills que ce tenant a activées (calendar n'apparaît que si le tenant l'a intégré).

Au final, vous avez un petit sous-ensemble de skills transmis au modèle — pas les 50 possibles, seulement les 4 qui ont du sens ici. Cela réduit drastiquement la chance que le modèle invoque la mauvaise skill.

Étape 4 — Décision (LLM call, 400-1200ms)

Maintenant le modèle entre en jeu. OpenClaw effectue un appel unique à un LLM de frontière (Anthropic Claude, OpenAI GPT, Google Gemini — configurable par tenant) avec :

• System prompt = persona de l'agent + règles + skills disponibles.
• History = tours sélectionnés à l'étape 2.
• User message = message du tour actuel.

Le modèle répond l'une de deux choses :

• Réponse finale (texte direct pour le client).
• Tool call (demande d'exécution d'une skill spécifique avec des paramètres).

Dans l'exemple "quero marcar pra sábado de manhã", le modèle retourne typiquement :

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Étape 5 — Exécution avec garde-fous (variable, ~100-500ms)

La skill ne tourne pas dans le modèle. Elle tourne dans notre code, qui :

1. Valide les paramètres (date_range a le bon format ? est dans les règles du tenant ?).
2. Vérifie la permission (cet agent a-t-il le droit de consulter ce calendrier ?).
3. Exécute l'appel (Google Calendar API dans ce cas).
4. Retourne un résultat structuré au modèle.

Pourquoi c'est important ? Parce que le modèle ne fabrique jamais le résultat. Si le calendrier retourne [10h, 11h], c'est exactement ça qui va au prochain appel. Si la skill échoue, le modèle sait qu'elle a échoué. Zéro risque que l'agent « invente » qu'il y a un créneau à 9h alors qu'il n'y en a pas.

Pour les cas qui impliquent des informations sensibles (prix, délai, nom du client), le pipeline force le tool call — il ne laisse pas le modèle répondre de sa propre « connaissance ». Cela élimine la classe d'hallucination la plus courante chez les agents commerciaux.

Étape 6 — Réponse et persistance (~50ms)

Avec le résultat de la skill en main, le modèle fait le deuxième appel — cette fois pour former la réponse finale au client. Ex :

"J'ai samedi à 10h et 11h. Lequel vous préférez ?"

En parallèle, le worker :

1. Envoie le message en retour via l'API WhatsApp.
2. Persiste le tour complet (user + assistant + tool calls + durée) dans D1.
3. Met à jour la mémoire à long terme si le tour a produit un fait nouveau (ex : "le client préfère samedi").
4. Émet un événement d'observabilité (métrique de latence, coût de token, taux d'escalade).

Tout cela tourne en parallèle. La persistance ne bloque pas l'envoi du message — le client n'attend pas le D1.

---

Où se trouve la défense contre l'hallucination

Un agent qui hallucine en production perd la confiance rapidement. OpenClaw a 4 lignes de défense :

1. Source de vérité forcée. Les données factuelles (prix, horaire, nom) viennent toujours d'une skill, jamais du modèle seul.
2. Vérification double sur les données sensibles. La prise de rendez-vous est confirmée avec le client avant d'être persistée. Le paiement est confirmé avant de libérer l'accès.
3. Règles négatives explicites. Le persona de chaque agent inclut "n'inventez jamais X, Y, Z" — le modèle obéit.
4. Fallback vers un humain. Quand aucune skill ne couvre la question, l'agent dit "laissez-moi vérifier avec l'équipe" et ouvre un ticket — il ne devine pas.

Lors des audits que nous avons réalisés ces 6 derniers mois (conversations réelles revues manuellement), le taux d'hallucination factuelle est resté en dessous de 0,3% des tours — et presque tous les cas étaient dus à la config (le tenant a oublié d'activer la skill pertinente), pas à une erreur du modèle.

---

Le coût par conversation

Une bonne architecture est invisible jusqu'à ce que vous regardiez la facture. Étant donné que chaque tour effectue 1-2 appels de LLM + des lookups en D1, le coût typique par conversation complète (10-15 tours) se situe à :