De WhatsApp à Salesforce : la capture conversationnelle au service de la saisie CRM

Un pipeline qui transforme messages WhatsApp et notes vocales en fiches CRM structurées

Transformer un message WhatsApp en mise à jour CRM marche à merveille en démo et casse en silence une fois envoyé en production. La démo lit un message propre et écrit une fiche propre. La production reçoit des notes vocales avec du bruit de fond, des phrases à moitié finies, des noms d'entreprise mal orthographiés et des changements de sujet décousus, ce qu'elle écrit ensuite dans le CRM censé être la source de vérité. Une seule mauvaise interprétation et on le pollue de manière silencieuse et sournoise.

Voici l'architecture de référence que nous exploitons pour la capture conversationnelle : le chemin d'un message entrant jusqu'à une écriture propre dans le CRM, ainsi que les points d'attention qui séparent une démo d'un système fiable.

Le pipeline en un coup d'œil

WhatsApp / Telegram
      │  webhook entrant
      ▼
Normalisation du message      → une forme interne unique, quelle que soit la plateforme
      │
      ▼
Pretraitement media           → note vocale : ffmpeg → transcription Whisper
      │
      ▼
Classifieur (raisonne+extrait)→ remplit un schema type : contact, deal, etape, relance
      │
      ▼
Appel outil MCP (dry-run)     → "qu'est-ce qui changerait ?", jamais d'ecriture directe
      │
      ▼
Validation humaine (un appui) → la validation avant envoi
      │
      ▼
Ecriture CRM via MCP          → Salesforce / HubSpot / Pipedrive / le votre

Chaque étape a une seule responsabilité, et c'est dans le passage de l'une à l'autre que la fiabilité se gagne ou se perd.

Que se passe-t-il à chaque étape ?

Webhook entrant. WhatsApp (via la Meta Cloud API) et Telegram envoient les messages à un webhook. Chaque plateforme a son propre format de requête.
Normalisation. Le payload de chaque plateforme est converti en une forme interne unique, pour que rien en aval n'ait à savoir si un message vient de WhatsApp ou de Telegram.
Prétraitement média. Le texte passe directement. Une note vocale est convertie avec ffmpeg et transcrite par un service Whisper avant toute tentative d'interprétation. Whisper est configuré pour gérer les blancs, le bruit environnant ou les différents types d'entrée (enregistrement RDV versus CR post rendez-vous).
Classifieur. Notre système s'appuie sur différents agents LLM pour lire le texte et remplir un schéma typé aligné sur les vrais objets de votre CRM (quel contact, quel deal, quelle étape, quelle relance). Des boucles internes de QA détectent les incohérences et proposent le bon correctif, et l'identité de l'expéditeur est validée d'abord pour ne voir que les comptes auxquels il a droit.
Appel outil MCP, dry-run. L'écriture est proposée via un outil MCP typé, en mode dry-run, qui renvoie exactement ce qui changerait.
Validation humaine. Le commercial voit un aperçu en langage naturel et appuie sur Confirmer. Cette confirmation est la seule chose qui enregistre.
Écriture CRM. Ce n'est qu'après confirmation que la couche MCP réalise l'écriture réelle.

Où ça casse, et qu'est-ce qu'on y fait ?

Le plus difficile n'est pas le chemin nominal, ce sont les faiblesses de chaque maillon.

Erreurs de transcription. Whisper se trompe sur les noms et les chiffres, surtout dans le bruit ou quand l'entrée est faite en plusieurs langues. La solution n'est pas une transcription parfaite, c'est l'étape de validation : le commercial relit la valeur transcrite et rattrape une erreur d'écoute d'un coup d'œil, avant qu'elle n'entre dans le CRM.
Intention ambiguë. "Fais avancer le deal" : lequel, à quelle étape ? Le classifieur n'a pas le contexte : il peut chercher et proposer, mais il se retrouve vite limité. Il propose différentes solutions avant d'écrire quoi que ce soit. Au pire, il s'agira d'un brouillon à corriger sans aucune corruption de données dans le CRM.
Ordre et corrections. "Quarante mille, en fait quarante-cinq" doit arriver dans l'ordre. Les messages d'une même conversation sont enregistrés séquentiellement, donc une correction arrive toujours après ce qu'elle corrige. Ça parait évident mais du fait que les messages correctifs sont souvent plus courts que les messages initiaux, c'est un mécanisme qu'il faut forcer pour éviter que le message le plus court transcrit le plus rapidement ne soit interprété avant le message d'origine.
Doublons. Un double appui, une reprise réseau, un webhook renvoyé : des clés d'idempotence garantissent qu'une même mise à jour ne peut pas créer deux fiches.

Rien de tout cela n'est spectaculaire. Ça contribue cependant à faire la différence entre une démo et un outil sur lequel une force de vente fait passer son pipeline.

Pourquoi MCP est-il le chemin d'écriture ?

Parce qu'un système de référence mérite une porte typée, cadrée et auditable, pas un LLM avec un accès à la base. Faire passer chaque écriture par des outils MCP veut dire qu'une écriture ne peut prendre qu'une forme que le CRM accepte et valide, que chaque appel est limité à l'organisation de l'expéditeur, et que le dry-run-puis-confirmation est intégré. Le modèle propose, MCP est la seule chose qui écrit, l'humain autorise. C'est ce qui fait qu'on peut passer sereinement du bac à sable à la donnée réelle sur Salesforce.

C'est le même moteur que derrière le remplissage d'un CRM depuis le terrain, l'architecture rend juste explicite pourquoi chaque étape est là.

L'essentiel

La capture conversationnelle n'est pas un problème d'IA, c'est un problème de fiabilité avec une étape d'IA au milieu. Maitrisez la normalisation, la transcription, l'extraction scopée, la validation et les écritures idempotentes, et la partie IA devient la plus simple.

Cette architecture est au coeur de Voice to CRM, notre version produit.

Nous construisons des pipelines de capture conversationnelle sur les CRM et ERP que les équipes utilisent déjà, et nous exploitons des serveurs MCP en tant que service comme couche d'écriture. Si vous voulez cela sur votre stack, parlons-en.