Comment fonctionne un agent de IA conversational par dedans

Comment fonctionne un Agent IA Conversational par Intérieur (Architecture OpenClaw)

Comment fonctionne un agent de IA conversational en pratique, tour par tour ? Ce post ouvre la boîte noire du OpenClaw : du moment où le message du client arrive sur WhatsApp jusqu'au texte que l'agent écrit de retour. Cela sera technique. C'est la peine si vous décidez d'architecture de produit, si vous allez acheter une solution et que vous 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 de contexte, sélection de compétences, décision de prochaine action, exécution avec garde-fou, persistance de mémoire. Tout le cycle tourne en <secondes sur l'edge de Cloudflare, sans serveur fixe.

---

Pourquoi l'architecture compte

Agent conversational qui semble fonctionner dans un démo mais qui casse en production générale a l'un de ces 4 problèmes :

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

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

---

Le cycle d'un tour (6 étapes)

Imaginez que le client a tout récemment envoyé le message "je veux réserver pour samedi matin". Qu'est-ce qui se passe entre le "reçu" et la réponse de l'agent ?

Étape 1 — Ingestion (edge worker, <ms)

Le message de 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 de réseau <0ms.

Le worker fait trois choses :

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

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

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

L'agent a besoin de 3 pièces de contexte avant de décider :

1. Conversation précédente : l'agent doit savoir ce qui s'est passé précédemment dans la conversation.
2. Informations du client : l'agent doit savoir qui est le client et quels sont ses préférences.
3. Informations de l'entreprise : l'agent doit savoir les informations de l'entreprise, telles que les heures d'ouverture et les prix.

L'agent utilise des données de conversation précédente (D1) et des données de clés-valeurs (KV) pour résoudre le contexte.

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

L'agent sélectionne les compétences nécessaires pour traiter le message du client. Les compétences sont des modèles de langage qui ont été entraînés pour traiter des types spécifiques de messages.

Étape 4 — Décision de prochaine action (D3, ~20ms)

L'agent utilise les compétences sélectionnées pour décider de la prochaine action à prendre. La prochaine action peut être de répondre au client, de demander des informations supplémentaires ou de prendre une décision.

Étape 5 — Exécution avec garde-fou (D4, ~20ms)

L'agent exécute la prochaine action avec des garde-fous pour s'assurer que l'action est sécurisée et respecte les règles de l'entreprise.

Étape 6 — Persistance de mémoire (D5, ~20ms)

L'agent persiste les informations de la conversation dans la mémoire pour que les informations soient disponibles pour les futures conversations.

Tout le cycle tourne en <secondes sur l'edge de Cloudflare, sans serveur fixe.

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

Tous proviennent du D1 (SQLite distribué de Cloudflare). D1 remplace Postgres/Mongo traditionnel — sans serveur de base de données pour maintenir, accès en quelques millisecondes à partir du worker, multi-locataire par tenant_id.

Point clé : on n'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 de jeton prévisible même pour 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 : consultar_calendario, crier_evento, gerer_link_pagement, consultar_pedido, chamer_humano.

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

• Compétences compatibles avec l' intention détectée (agendement).
• Compétences autorisées pour cette phase de la conversation (pas toute compétence est disponible à tout moment).
• Compétences que ce locataire a activées (calendar ne s'affiche que si le locataire a intégré).

Au final, vous avez un sous-ensemble petit de compétences passé au modèle — pas les 50 possibles, mais les 4 qui ont du sens ici. Cela réduit drastiquement la chance que le modèle invoque une compétence erronée.

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

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

• Prompt système = personne de l'agent + règles + compétences disponibles.
• Histoire = tours sélectionnés à l'étape 2.
• Message utilisateur = message du tour actuel.

Le modèle répond une des deux choses :

• Réponse finale (texte direct pour le client).
• Appel d'outil (demande pour exécuter une compétence spécifique avec des paramètres).

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

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

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

La compétence ne s'exécute pas dans le modèle. Elle s'exécute dans un code notre, qui :

...

1. Valide les paramètres (la plage de dates a un format correct ? est-elle conforme aux règles du locataire ?).
2. Vérifiez la permission (cet agent a-t-il le droit de consulter ce calendrier ?).
3. Exécutez l'appel (API Google Calendar dans ce cas).
4. Retournez le résultat structuré au modèle.

Pourquoi cela est-il important ? Parce que le modèle ne fabrique jamais le résultat. Si le calendrier retourne [10h, 11h], c'est exactement cela qui va à la prochaine appelle. Si la skill échoue, le modèle sait qu'elle a échoué. Aucun risque de l'agent "inventer" qu'il a un horaire à 9h quand il n'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 du "connaissances" propre. Cela élimine la classe d'alucination la plus courante dans les agents commerciaux.

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

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

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

Parallèlement, le worker :

1. Envoie la message de retour par l'API de WhatsApp.
2. Persiste le tour complet (utilisateur + assistant + appels de tool + 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'échelle).

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

---

Où est la défense contre l'alucination

Agent qui alucine en production perd confiance rapidement. OpenClaw a 4 lignes de défense :

1. Source-of-truth forçée. Données factuelles (prix, horaire, nom) sont toujours venues de skill, jamais du modèle seul.
2. Vérification double en données sensibles. Agendement est confirmé avec le client avant de persister. Paiement est confirmé avant de libérer l'accès.
3. Règles négatives explicites. Persona de chaque agent inclut "n'oublie jamais X, Y, Z" — le modèle obéit.
4. Fallback pour l'humain. Lorsque aucune skill ne couvre la question, l'agent dit "laissez-moi vérifier avec l'équipe" et ouvre un ticket — il ne chute pas.

Dans les audits que nous avons effectués ces derniers 6 mois (conversations réelles revues manuellement), le taux d'alucination factuelle est inférieur à 0,3% des tours — et la plupart des cas ont été dus à une configuration (locataire 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 LLM + recherches dans D1, le coût typique par conversation complète (10-15 tours) se situe en:

(Note : D1 est probablement une référence à une base de données, mais je l'ai laissée telle quelle car elle n'est pas traduisible sans plus de contexte)