Chapitre 31 / 39

Bot d'accusé de réception WhatsApp

Statut : Planifié — programmé plus tard dans la mission après que la pile mail et le CRM sont en ligne. C’est un canal expérimental, délibérément secondaire à l’e-mail et au téléphone. Une surface petite et contrôlée : un cas d’usage, une liste blanche restreinte de clients, une file de revue humaine avant que quoi que ce soit parte.


Ce que ça fait en une phrase.

Quand un client sur la liste blanche envoie un message ayant la forme d’une commande au numéro WhatsApp Business de Sodimo, le bot rédige une réponse d’accusé de réception. La réponse n’est pas envoyée tant qu’un humain ne l’a pas approuvée.


Ce que ça ne fait explicitement pas.

  • Pas de conversation bidirectionnelle en direct. Le bot ne tient pas un fil ni ne répond aux questions de suivi.
  • Pas de transcription vocale, pas de voix-vers-commande, pas d’intégration Whisper. La voix est hors périmètre pour cette mission.
  • Pas de chemin d’écriture vers Sodiwin. Le bot ne crée jamais une commande. Une commande passée via WhatsApp atterrit toujours dans une boîte mail ou sur un téléphone — le bot accuse seulement réception.
  • Pas d’envoi sortant non sollicité. Le bot répond ; il n’initie pas.

Le périmètre est délibérément mince parce que WhatsApp est un canal secondaire chez Sodimo et qu’un agent conversationnel en direct nécessite un seuil de confiance plus élevé que ce que cette mission peut établir.


Le câblage

Rani / Paulreview_queueD1 (CRM + run_ledger)sodimo-core Worker(webhook endpoint)Meta Cloud APICustomer (WhatsApp)Rani / Paulreview_queueD1 (CRM + run_ledger)sodimo-core Worker(webhook endpoint)Meta Cloud APICustomer (WhatsApp)alt[approved][rejected / edited]sends messagewebhook POSTverify signature + allowlist checklook up customer, recent ordersLLM drafts ack replywrite run_ledger rowenqueue draft for reviewreview draft (CRM UI)approvesend replydeliver replyreject or edit-and-sendsend edited text (if edited)

Le webhook atterrit sur un Cloudflare Worker — le même Worker sodimo-core qui héberge la surface MCP unique (chapitre 42). Le Worker est le seul endpoint auquel les serveurs de Meta parlent. Le harness Fedora n’est pas impliqué dans le chemin entrant ; le bot ne touche pas aux services locaux.


Garde-fous

Chacun de ces éléments est une exigence stricte avant que le bot puisse être activé, pas une aspiration.

Clients sur liste blanche uniquement. Le webhook rejette tout message dont l’expéditeur n’est pas sur une liste blanche explicite de numéros de téléphone dans D1. La liste blanche commence vide ; Rani ajoute les clients un par un après un opt-in explicite. Il n’existe pas d’interrupteur « ouvert à tous les clients ».

Limite de débit. Le Worker plafonne le débit par expéditeur et par heure. Une boucle hors de contrôle côté envoi ne peut pas inonder la file ni faire exploser les dépenses de modèle.

File de revue humaine. Aucun brouillon ne quitte le système sans qu’un humain appuie sur approuver. Le brouillon atterrit dans le CRM (chapitre 53) comme une carte de revue ; Rani ou Paul approuve, modifie ou rejette. « Auto-approuver après N secondes » n’est pas une fonctionnalité.

Portail de forme de message. Avant que le Worker demande à un modèle de rédiger quoi que ce soit, une vérification déterministe confirme que le message ressemble à une commande — mots-clés, numériques, références de produits connus. Les messages hors sujet sont routés vers un compartiment humain uniquement sans brouillon généré.

Émission dans le registre d’exécution. Chaque invocation — message entrant analysé, brouillon généré, approuvé, rejeté — est une ligne dans run_ledger (chapitre 15, Principe 2). Si une revue future demande « à quelle fréquence le bot a-t-il aidé ? à quelle fréquence a-t-il induit en erreur ? », la réponse est une requête SQL.

Vérification de signature. Le Worker vérifie la signature webhook de Meta à chaque requête. Les requêtes non signées ou mal signées sont rejetées silencieusement.


Pourquoi c’est dans le manuel

WhatsApp est l’endroit où plusieurs clients Sodimo contactent déjà l’équipe — le téléphone d’un commercial, principalement. Deux modes d’échec existent aujourd’hui : un message est complètement raté, ou un message reçoit une réponse des heures plus tard. Le bot cible uniquement le second, et uniquement pour la réponse « nous avons bien reçu votre commande », qui est le message à moindre risque du fil.

Si le bot fonctionne dans cette forme étroite sur un mois ou deux, un futur ingénieur peut élargir le périmètre — plus de modèles, plus de clients, et finalement une boucle plus serrée avec le système de commandes. S’il ne fonctionne pas, la surface est assez petite pour être éteinte sans que personne ne s’en aperçoive.


Traçabilité des décisions. D-119 (annotation du mardi) : « drop the voice ecosystem completely. whatsapp gets a bot that is well scoped, that we set up with strong guardrails. use as experimental, this is quite secondary. » D-018 (annotation du lundi) : séquençage des dépôts — changelog, puis brand, puis whatsapp-webhook la semaine suivante, puis les piliers quand débloqués. Le chapitre 55 contient les annotations complètes.

Références croisées. Chapitre 15 (Principe 3 — surface MCP unique, registre d’exécution), chapitre 42 (Worker sodimo-core et l’inventaire des outils MCP), chapitre 53 (le CRM, qui héberge la file de revue humaine).