Comment fonctionne un agent IA conversationnel de l'intérieur

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

Comment fonctionne un agent d'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. Ça va être technique. Ça vaut la peine 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 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 est importante

Un agent conversationnel qui semble fonctionner dans une démo mais qui 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 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 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 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, 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 à 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 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 de 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 permises pour cette phase de la conversation (toutes les skills ne sont pas disponibles en tout temps).
• 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 font 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 fait 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écuter 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 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 de l'information sensible (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 fait le deuxième 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 roule 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) proviennent 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. Repli 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 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 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 recherches dans D1, le coût typique par conversation complète (10-15 tours) se situe à :