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 après 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. Cela 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 du contexte, sélection des skills, décision de la prochaine action, exécution avec guard-rails, persistance de la mémoire. Tout le cycle s'exécute 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 une 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 d'observer 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 le 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 du 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é : nous ne chargeons 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 :

• Les skills compatibles avec l'intention détectée (prise de rendez-vous).
• Les skills autorisées pour cette phase de la conversation (toutes les skills ne sont pas disponibles en permanence).
• Les 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 le risque 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 ces deux choses :

• Réponse finale (texte envoyé directement au 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 s'exécute pas dans le modèle. Elle s'exécute dans notre code, qui :

1. Valide les paramètres (date_range a le bon format ? est-il conforme aux 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 est-ce important ? Parce que le modèle ne fabrique jamais le résultat. Si le calendrier retourne [10h, 11h], c'est exactement ce qui est transmis à l'appel suivant. 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 impliquant des informations sensibles (prix, délai, nom du client), le pipeline force un tool call — il ne laisse pas le modèle répondre à partir de ses propres « connaissances ». 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 effectue le second appel — cette fois pour formuler la réponse finale au client. Ex :

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

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 le samedi").
4. Émet un événement d'observabilité (métrique de latence, coût en tokens, taux d'escalade).

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

---

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

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

1. Source de vérité imposée. Les données factuelles (prix, horaire, nom) proviennent toujours d'une skill, jamais du modèle seul.
2. Double vérification 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. La 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 au cours des 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 configuration (le tenant avait 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 à :