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 ? Ce billet 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 la peine si vous décidez de l'architecture de 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 — ingestion, résolution du contexte, sélection des compétences, décision de la prochaine action, exécution avec garde-fous, 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 importe

Un agent conversationnel qui semble fonctionner dans une démo mais plante en production a généralement 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 conversation longue remplit le prompt et vous payez une fortune en jetons.

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 "je veux réserver pour samedi matin". Que se passe-t-il entre le « reçu » et la réponse de l'agent ?

Étape 1 — Ingestion (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 WABA).
2. Identifie le tenant par le numéro de téléphone du récepteur (multi-tenant par to_number).
3. Normalise la charge utile — 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 la prochaine étape.

É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, compétences activées, règles).

Tous proviennent de D1 (SQLite distribué de Cloudflare). D1 remplace Postgres/Mongo traditionnel — aucun serveur de base de données à maintenir, accès en quelques ms à partir du 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 seulement les tours pertinents pour le tour actuel (derniers N + N de haute pertinence sémantique). Cela maintient le coût de jeton prévisible même dans des conversations de 100+ tours.

Étape 3 — Sélection de compétences (policy engine, ~20ms)

Chaque agent a un ensemble de compétences disponibles — fonctions qu'il peut invoquer. Exemples : consulter_calendrier, creer_evenement, generer_lien_paiement, consulter_commande, appeler_humain.

Étant donné le message "je veux réserver pour samedi matin", le policy engine filtre :

• Compétences compatibles avec l'intention détectée (planification).
• Compétences permises pour cette phase de la conversation (toutes les compétences ne sont pas disponibles tout le temps).
• Compétences que ce tenant a activées (calendrier n'apparaît que si le tenant l'a intégré).

Au final, vous avez un petit sous-ensemble de compétences 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 compétence.

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

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

• System prompt = persona de l'agent + règles + compétences 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écuter une compétence spécifique avec des paramètres).

Dans l'exemple "je veux réserver pour samedi matin", le modèle retourne typiquement :

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

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

La compétence 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-t-il le bon format? est-il conforme aux règles du locataire?).
2. Vérifie la permission (cet agent a-t-il le droit de consulter ce calendrier?).
3. Exécute l'appel (API Google Calendar 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 sera transmis au prochain appel. Si la compétence échoue, le modèle sait qu'elle a échoué. Zéro risque que l'agent « invente » qu'il y a un créneau à 9h quand il n'y en a pas.

Pour les cas impliquant des informations sensibles (prix, délai, nom du client), le pipeline force 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 compétence en main, le modèle effectue le deuxième appel — maintenant pour former 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 nouveau fait (ex: "le client préfère 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 rapidement la confiance. OpenClaw a 4 lignes de défense:

1. Source de vérité forcée. Les données factuelles (prix, horaire, nom) proviennent toujours d'une compétence, jamais du modèle seul.
2. Vérification double pour les données sensibles. La réservation 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'invente jamais X, Y, Z" — le modèle obéit.
4. Repli vers l'humain. Lorsqu'aucune compétence ne couvre la question, l'agent dit "laisse-moi vérifier avec l'équipe" et ouvre un ticket — il ne devine pas.

Dans les audits que nous avons effectués au cours des 6 derniers mois (conversations réelles révisées 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 locataire a oublié d'activer une compétence 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 + recherches dans D1, le coût typique par conversation complète (10-15 tours) se situe à :