WhatsApp vers commande.WhatsApp vers commande, sous contrôle.
Extraction IA, règles métier et validation humaine dans un benchmark reproductible.
Classification
Benchmark d’ingénierie
État des preuves
Protocole publié, mesures en attente
Secteur
Distribution wholesale et prise de commande B2B
Capacités mobilisées
IA appliquée, Atlas B2B, Validation humaine, Intégration ERP
Périmètre de preuve
Atlas ne présente ici ni déploiement client ni résultat de production. Les chiffres seront ajoutés uniquement après exécution du protocole sur un corpus versionné.
Synthèse exécutive
Ce que ce cas démontre
Ce benchmark ne cherche pas à prouver qu’un modèle comprend parfaitement les commandes. Il vérifie dans quelles conditions une extraction probabiliste peut préparer un brouillon sûr, traçable et moins coûteux à contrôler qu’une saisie entièrement manuelle.
Le système métier dans lequel la solution s’inscrit
- 01Les commandes arrivent par WhatsApp, appel ou texte libre, souvent avec des abréviations, des habitudes client et des unités implicites.
- 02Le produit demandé doit être rapproché d’un SKU réel, d’un conditionnement autorisé et d’une règle tarifaire applicable au client.
- 03Une quantité valide au niveau linguistique peut rester impossible au niveau stock, crédit, territoire ou minimum de commande.
- 04La conséquence métier n’est pas la réponse du modèle, mais l’écriture finale dans le système de commande.
Le problème opérationnel à résoudre
Le langage commercial est tolérant aux ambiguïtés alors que le système transactionnel ne l’est pas. Une erreur sur un produit, une unité ou une quantité peut déplacer du stock, modifier une facture ou créer un litige.
- Résoudre les synonymes, marques, formats et références proches sans inventer un SKU.
- Distinguer pièce, pack, carton et palette quand le message ne précise pas toujours l’unité.
- Récupérer uniquement l’historique et les conditions du client authentifié.
- Refuser ou escalader lorsque le niveau de confiance ou les règles métier ne permettent pas une commande sûre.
Pourquoi les outils existants ne suffisaient pas
Un simple chatbot peut reformuler le message, mais il ne garantit ni le mapping catalogue, ni le prix, ni la disponibilité. Le workflow doit combiner extraction IA, services métier déterministes et validation humaine.
L’hypothèse testée et la chaîne de contrôle
Pour les commandes répétitives, une extraction IA suivie de contrôles déterministes et d’une validation ciblée peut réduire le temps opérateur sans augmenter le taux d’erreur critique.
- 01
Message client
- 02
Extraction structurée
- 03
Résolution catalogue
- 04
Prix et stock
- 05
Validation humaine
- 06
Brouillon ERP
L’approche construite par Atlas
Le modèle propose une structure de commande. Les services Atlas résolvent ensuite les identifiants, appliquent les règles de prix et vérifient le stock avant de présenter un brouillon à un opérateur.
- 01Normaliser le message et conserver le texte original comme preuve.
- 02Extraire client, produits, quantités, unités, dates et instructions sans écrire en base.
- 03Résoudre chaque ligne contre un catalogue limité au tenant et classer les correspondances possibles.
- 04Calculer prix, conditionnement, stock et crédit avec des services déterministes.
- 05Bloquer toute ligne ambiguë et expliquer la raison de l’escalade.
- 06Créer un brouillon uniquement après validation humaine, avec journal des valeurs proposées et corrigées.
Les décisions qui structurent la solution
Séparer compréhension et transaction
Le modèle n’obtient pas le droit de confirmer la commande. Il produit une proposition structurée que le domaine métier doit valider.
Mesurer par ligne et par commande
Une commande peut sembler correcte tout en contenant une ligne critique erronée. Le protocole suit donc les champs, les lignes et le document complet.
Inclure les cas ambigus dans le corpus
Les abréviations, fautes, mélanges arabe-français, demandes “comme la dernière fois” et substitutions font partie du test principal.
Rendre l’abstention mesurable
Un système mature doit savoir demander une clarification. Le taux d’escalade est évalué avec la précision, pas traité comme un échec automatique.
Impact métier
Ce que la solution doit changer
Aucun gain chiffré n’est publié à ce stade. Le benchmark est conçu pour comparer le processus manuel au processus assisté sur le même corpus et avec les mêmes règles.
- Réduire le temps de préparation des commandes simples et répétitives.
- Concentrer l’intervention humaine sur les lignes ambiguës ou à conséquence élevée.
- Mesurer le coût complet par commande acceptée, pas seulement le coût des tokens.
- Créer une trace exploitable des suggestions, corrections et validations.
Comment la solution est validée
Le protocole utilise un jeu de commandes anonymisées et annotées, rejoué dans un parcours manuel puis dans le workflow assisté.
- Double annotation du résultat attendu pour chaque ligne de commande.
- Répartition du corpus par langue, qualité de texte, client, produit, unité et niveau d’ambiguïté.
- Comparaison aveugle du temps, des erreurs et des corrections sur les deux parcours.
- Tests de non-régression à chaque changement de modèle, prompt, catalogue ou règle métier.
- Journalisation séparée des erreurs IA, erreurs de résolution catalogue et refus métier légitimes.
Le protocole publié avant la mesure
Périmètre
100 à 500 commandes anonymisées, couvrant les langues, abréviations, unités et niveaux d’ambiguïté observés.
Corpus
Messages historiques autorisés ou données synthétiques validées par un opérateur, avec vérité terrain figée et versionnée.
Baseline
Saisie manuelle par un opérateur à partir du même message et avec le même catalogue.
Méthode
Rejeu chronométré, ordre randomisé, correction enregistrée champ par champ et calcul séparé des coûts techniques et humains.
Conditions d’acceptation
- Aucune commande critique ne peut être confirmée sans validation humaine.
- Toute référence absente du catalogue doit produire une abstention, jamais une invention.
- La borne d’erreur critique doit être définie avant le test et validée par le métier.
- Le temps total inclut la revue, la correction et les appels aux services métier.
Les métriques à suivre
Ces indicateurs définissent le protocole de mesure. Ils ne constituent pas des résultats publiés tant qu’un pilote ou le client n’a pas validé les données.
| Indicateur | Ce qu’il vérifie | Mode de mesure |
|---|---|---|
| Exactitude par ligne | Vérifier produit, quantité et unité | Lignes totalement conformes divisées par les lignes annotées |
| Exactitude commande | Mesurer le résultat utilisable sans correction | Commandes entièrement conformes divisées par le corpus |
| Taux d’intervention | Quantifier la charge humaine restante | Commandes corrigées ou clarifiées sur commandes traitées |
| Temps opérateur | Comparer la charge réelle | Temps actif médian et p95 par commande pour chaque parcours |
| Coût par commande conforme | Relier coût technique et valeur | Coûts modèle, infrastructure et revue divisés par les commandes conformes |
| Erreur critique | Protéger stock et facturation | Mauvais SKU, mauvaise unité ou quantité acceptée malgré les contrôles |
Résultats publiés et points de rupture
Résultats non publiés
Le benchmark est prêt à être exécuté. Cette page sera mise à jour avec le corpus, la version du système, les distributions et les intervalles de mesure dès validation.
Ce qui doit faire échouer ou limiter le système
- Confusion entre deux formats proches ou entre pack et carton.
- Résolution abusive d’un produit absent vers le SKU le plus proche.
- Référence à une commande précédente sans historique autorisé suffisant.
- Confiance élevée alors qu’une règle de crédit ou de stock bloque la ligne.
Sécurité, données et contrôle humain
- 01Limiter le contexte au tenant, au client et au catalogue nécessaires à la demande.
- 02Traiter le message comme une entrée non fiable et valider toute sortie avant usage transactionnel.
- 03Masquer les données sensibles dans les traces d’évaluation et séparer les rôles de lecture et d’approbation.
- 04Conserver un journal d’audit des suggestions, corrections, validations et écritures.
Les enseignements à retenir
- 01La performance d’extraction ne remplace jamais la validation du catalogue et des règles commerciales.
- 02Le coût utile se calcule sur une commande conforme, pas sur un appel API réussi.
- 03Les demandes ambiguës doivent être une catégorie de test explicite.
- 04La correction humaine constitue une donnée d’évaluation et de maintenance, pas une simple exception UI.
Recommandation de mise en production
Commencer par les commandes fréquentes d’un catalogue stable. Garder la création en brouillon, instrumenter les corrections, puis élargir le périmètre seulement lorsque les seuils par segment restent stables.
Références méthodologiques officielles
Pour aller plus loin
Capacités et services liés
Votre contexte mérite une solution mesurable.
Nous cadrons le problème, les contraintes, les décisions et les preuves attendues avant de proposer une trajectoire de livraison.
Évaluer votre contexte