De la conversation aux données structurées : la nouvelle façon d’interagir avec vos outils métiers

Les commandes n’arrivent plus sous forme de formulaires à remplir. Elles déferlent via WhatsApp, au milieu d’un service chargé : « Envoie cinq des habituels à John chez Acme… finalement, fais-en six », ou par un message Telegram avec un nom de produit mal orthographié. C’est la réalité du terrain : les échanges se font là où vos clients et vos équipes passent déjà leur temps, sur les applications que chacun a dans sa poche.

Il fut un temps où le traitement automatique de ces messages relevait de la science-fiction. Les assistants vocaux comme Siri comprenaient à peine nos demandes, et le NLP traditionnel échouait la plupart du temps à transformer ces successions de décisions informelles en actions concrètes. Aujourd’hui, grâce au raisonnement des modèles et au protocole MCP, c’est non seulement possible, mais fiable.

La tentation serait de laisser une IA lire le message et écrire directement la fiche. Ça fonctionne en démo. Puis, discrètement, elle génère la mauvaise facture, pour le mauvais contact, à la mauvaise quantité, avec une confiance absolue. C’est précisément le mode d’échec que nous évoquions récemment : une sortie bien argumentée mais fausse est la plus difficile à détecter.

Nous avons donc adopté une approche différente. En production, le schéma est simple : l’IA propose une extraction structurée, l’utilisateur valide d’un simple clic, et ce n’est qu’alors que l’action est exécutée, uniquement via une couche d’outils typés (MCP), jamais par écriture directe. L’IA raisonne et extrait, l’humain a le dernier mot, MCP écrit. Voici pourquoi cette combinaison change la donne.

Pourquoi ne pas laisser l’IA décider seule ?

Parce qu’une facture erronée coûte bien plus cher qu’une réponse de chatbot imprécise, et qu’à volume réel, l’IA se trompera avec assurance une partie du temps.

Les entrées résistent à toute analyse propre : notes vocales (qui mélangent souvent les langues en cours de phrase), messages incomplets, noms de produits mal orthographiés, corrections en cascade… « En fait, fais-en huit ». Un modèle d’extraction gère bien l’essentiel, mais une partie sera incorrecte, dans les deux cas avec la même certitude.

Pour une lecture (répondre à une question), c’est acceptable. Pour une écriture qui devient une commande, une facture ou une donnée critique dans votre CRM, « globalement juste » n’est pas une option. Comme nous l’avons déjà souligné, même 98 % de précision ne suffisent pas à l’échelle : deux erreurs sur cent deviennent six cents sur trente mille.

La question n’est donc pas « comment extraire parfaitement ? » (c’est impossible), mais comment rendre les erreurs inévitables visibles et sans conséquence avant qu’elles ne s’appliquent. Tout l’enjeu tient dans ce changement de perspective.

Comment rendre le processus prévisible ?

En réduisant drastiquement la marge d’erreur : on contraint le modèle à un schéma connu, on limite le nombre d’outils typés, et on vérifie l’identité avant toute action.

Trois éléments transforment un « comprends ce message » ouvert en un « remplis ce formulaire » vérifiable :

Sortie structurée, jamais du texte libre. Le modèle ne génère pas un paragraphe, mais une action contre un schéma strict : listes déroulantes pour la priorité ou l’étape commerciale, recherche exacte dans un catalogue de produits de référence plutôt que de se fier à la transcription. L’espace des possibles est réduit et totalement validable.
Agent aux capacités limitées. L’extraction fonctionne en boucle raisonnement-action, mais avec une limite stricte : chez nous, cinq appels d’outils maximum par message. Il peut identifier un contact, préparer un brouillon, puis s’arrêter. Il ne peut pas dévier.
Identité vérifiée en amont. Avant même que le modèle n’intervienne, le numéro de l’expéditeur est associé à un utilisateur, une organisation, un compte et un rôle. Le modèle n’a accès qu’aux outils et aux données autorisés pour cette personne : une frontière de sécurité autant que de précision, car il ne peut pas agir sur le mauvais compte, puisqu’il ne le voit même pas.

Recadré ainsi, « transformer une conversation en objet métier » devient « remplir un formulaire contraint à partir d’un vocabulaire limité », et c’est précisément ce que les modèles de langage savent faire de manière fiable.

Où intervient l’humain ?

L’utilisateur valide, et c’est lui qui déclenche l’action. L’IA ne modifie jamais directement les données : elle simule l’opération, présente un aperçu clair, et seul un clic sur Confirmer l’exécute pour de vrai.

C’est le cœur de notre approche. Chaque outil d’écriture dispose d’un mode prévisualisation. Quand le modèle veut créer quelque chose, il appelle l’outil en mode test, récupère exactement ce qui serait écrit, et présente un résumé lisible, pas du JSON brut :

Brouillon de commande, à valider • Client : John Smith (Acme Corp) • 6 × Rouge Maison 2021 • Total : 312 €

[ Confirmer ] [ Modifier ] [ Annuler ]

Ces boutons s’affichent directement dans WhatsApp ou Telegram : pas besoin de changer d’application, pas de tableau de bord à ouvrir. Confirmer exécute l’opération, Modifier permet d’ajuster (« fais-en huit »), Annuler abandonne tout. Les brouillons en attente expirent automatiquement (quelques minutes pour les actions simples, plus longtemps pour les commandes complexes), de sorte qu’aucune information obsolète ne soit validée.

Voilà toute l’astuce de fiabilité : la personne voit exactement ce qui sera créé, là où elle se trouve déjà, et son accord est la seule chose qui déclenche l’action. Une erreur devient un simple coup d’œil au lieu d’un long travail de correction.

C’est aussi la concrétisation de notre principe : on n’obtient pas une IA fiable en lui faisant davantage confiance, mais en plaçant le jugement humain au bon endroit, ici au moment de la validation. Fini le « envoyer et prier pour que ce soit bon » : l’utilisateur a toujours le dernier mot.

Pourquoi MCP est-il indispensable ?

Parce que le modèle ne doit jamais accéder directement à votre base de données. MCP fournit une interface unique, typée et sécurisée : un registre fixe d’outils permissionnés, où chaque lecture et chaque écriture passent par une seule porte auditée et validée.

Le modèle n’appelle pas votre API et n’écrit pas de SQL. Il utilise des outils typés (crm_create_service_ticket, crm_add_order_line_item, crm_log_interaction) issus d’un registre d’environ 195 outils répartis sur nos modules, tous accessibles via un unique point JSON-RPC. Cette architecture apporte quatre garanties :

Validation systématique. Chaque outil a un schéma strict ; les arguments invalides sont rejetés avant même d’atteindre la base.
Permissions et identité gérées centralement, jamais déléguées au modèle.
Prévisualisation et idempotence intégrées : le flux aperçu-puis-validation fonctionne uniformément, et un double clic sur Confirmer ne crée qu’une seule commande.
Surface d’attaque réduite. Le modèle est agnostique de votre API et ne peut littéralement pas inventer un point d’accès : il ne peut utiliser que les outils existants.

Et cette même couche d’outils alimente aussi Claude Desktop, Cursor et nos agents internes. Le flux de messagerie n’est pas une intégration ad-hoc, c’est un client de plus dans un écosystème que nous maintenons déjà.

Ce qui garantit la fiabilité à grande échelle

Ce ne sont pas les algorithmes qui rendent le système robuste, mais l’ingénierie qui les encadre : ordonnancement, idempotence et contexte persistant. Rien de spectaculaire, mais tout est essentiel.

Ordonnancement. Les notes vocales sont transcrites en parallèle (30 à 47 % plus vite) mais traitées séquentiellement par conversation, via une file de tâches. « Cinq des habituels » suivi de « En fait six » ne peuvent jamais entrer en conflit : la correction s’applique toujours après l’action initiale.
Idempotence. Un clic de confirmation, un réseau instable, un double clic : aucun ne peut dupliquer une commande.
Mémoire conversationnelle. Les échanges sont persistés : les modifications multi-tours s’appliquent au brouillon en cours plutôt que de repartir de zéro, et les longues transcriptions sont compressées pour le contexte tout en conservant l’original intact.
Gestion des échecs. Les erreurs transitoires (modèle ou transcription) sont réessayées automatiquement avec temporisation et remontées en supervision, jamais ignorées.

Individuellement, ces mécanismes semblent anodins. Ensemble, ils transforment une belle démo en un système sur lequel une entreprise peut s’appuyer au quotidien.

Ce qu’il faut retenir

L’IA est la partie la plus simple de ce système, et la moins fiable. La robustesse vient uniquement du cadre que nous avons construit autour :

✅ Un schéma contraint, pour des sorties toujours vérifiables
✅ Un clic de l’utilisateur comme seule validation définitive
✅ Une couche d’outils typés, pour des écritures impossibles à corrompre
✅ Une infrastructure qui garantit ordonnancement, idempotence et persistance

Autrement dit : on ne rend pas l’IA infaillible en lui faisant confiance à 100 %. On la rend infaillible en décidant précisément où et comment l’humain intervient, et en faisant de ce moment de validation la seule porte vers vos données.

Message informel en entrée, objet métier structuré en sortie, avec la validation humaine comme garantie.

C’est le moteur des bots WhatsApp et Telegram de Reflekt CRM. Si vos commandes ou vos données arrivent sous forme de messages sans solution fiable pour les capturer, parlons-en.