Automatiser les bons de commande B2B : le cas d'un e-commerçant sur Make

Récemment, j’ai eu un appel avec un e-commerçant. Il vend des compléments alimentaires, en direct sur sa boutique Shopify , mais aussi en B2B : des pharmacies et des salles de sport qui lui passent des grosses commandes. Et c’est là que ça coince. Ces commandes B2B n’arrivent pas via le site. Elles tombent par email, sous forme de bon de commande : un PDF pour les pharmacies, un fichier Excel pour les salles de sport.

Avant, quelqu’un dans sa boîte ouvrait chaque email, lisait le bon de commande, recopiait chaque ligne dans Shopify pour créer la commande, puis créait la facture dans son outil de compta. Comptez vingt minutes par commande. Avec quinze à vingt commandes par jour et un objectif à cinq cents par mois, le calcul est vite fait : c’est un mi-temps de saisie pure.

Et il n’arrivait pas les mains vides. Il avait déjà une automatisation Make , montée par un ancien collaborateur qui avait suivi une formation. Elle marchait. Mais elle n’était pas fiable au point de tourner toute seule, et lui passait encore ses journées à la surveiller. Notre call a donc porté sur quelque chose de plus subtil et de bien plus fréquent qu’on ne croit : comment on fait passer une automatisation du stade “ça marche quand je regarde” au stade “ça tourne sans moi”.

Le squelette : un bon de commande email devient une commande Shopify

Avant de parler de fiabilité, le principe de base. L’automatisation qu’il avait suit une logique simple, et c’est la bonne :

Le trigger : Make surveille une boîte mail dédiée aux bons de commande. Dès qu’un email arrive avec sa pièce jointe, le scénario se déclenche.
L’extraction : une IA lit le PDF (ou l’Excel) et en sort les données structurées. Quel client, quels produits, quelles quantités.
La commande : Make crée la commande correspondante dans Shopify.
La facture : dans la foulée, il génère la facture dans l’outil de compta, en appliquant les bonnes conditions tarifaires du client.

Sur le papier, c’est limpide. Le diable est dans les détails, et c’est précisément ces détails qui empêchaient mon e-commerçant de lâcher prise.

Pourquoi il faut une IA pour lire un bon de commande

On pourrait croire qu’un bon de commande, ça se lit avec une simple extraction de texte. Sauf qu’un bon de commande de pharmacie ne ressemble pas à un bon de commande de salle de sport, et même entre deux pharmacies, la mise en page change.

Surtout, il y a un piège que seul un modèle de langage gère bien : la traduction des unités. Les pharmacies commandent en unités de vente à elles, par exemple « 40 collagènes ». Mais dans Shopify, ce produit existe en packs de 24. L’IA doit comprendre que « 40 collagènes » ne veut pas dire « 40 lignes », mais qu’il faut raisonner en packs et créer la bonne quantité. Une extraction bête se serait plantée. Un agent qui « comprend » le document, non.

Et c’est là aussi que les erreurs apparaissent. Sur un produit ajouté récemment, le scénario allait parfois chercher le mauvais nombre : il attrapait le taux de TVA au lieu de la quantité, et créait 20 unités au lieu de 1. Rien de dramatique, c’est corrigeable. Mais tant que ce genre de bavure peut passer en silence, tu ne peux pas quitter la pièce. Et c’est tout le problème.

Ce que l’IA doit gérer	Pourquoi une extraction simple échoue
Deux formats (PDF pharmacie, Excel salle de sport)	Mises en page différentes, pas de structure fixe
Unités de vente ≠ unités Shopify (« 40 » = 2 packs de 24… ou pas)	Il faut raisonner sur le conditionnement, pas recopier
Conditions tarifaires propres à chaque client	Le prix du bon de commande prime sur le prix catalogue
Lignes ajoutées ou fusionnées à la main par le client	Le document n’est jamais parfaitement régulier

Le vrai problème : un email à la fois

Voilà le nœud. Son automatisation ne savait traiter qu’un seul email à la fois. Concrètement, son rituel ressemblait à ça : il transférait un bon de commande sur l’adresse trigger, lançait le scénario, attendait une minute que la commande se crée, vérifiait que tout était bon, puis envoyait le suivant. Une heure pour trente commandes. Son assistante, elle, attendait bêtement que ça se fasse pour enchaîner. Deux personnes en otage d’un workflow censé les libérer.

Son rêve était simple à formuler : pouvoir balancer cinquante emails dans l’heure et que ça se traite tout seul, en file, sans qu’il ait à cliquer entre chaque. Techniquement, ce n’est pas le plus dur. Make sait très bien encaisser une rafale d’événements et les traiter les uns après les autres. Le blocage venait d’ailleurs : la confiance. Tant qu’il n’était pas sûr que chaque commande passe sans erreur, il préférait regarder. Le vrai chantier, c’était donc de rendre le truc assez fiable pour qu’il ose ne plus regarder.

Fiabiliser sans demander un acte de foi

Quand un client te dit « je n’ai pas confiance », tu ne réponds pas « fais-moi confiance ». Tu construis des garde-fous qui rendent la confiance inutile. Sur le call, on a posé trois leviers, du plus léger au plus structurant.

1. Un deuxième agent qui vérifie le premier. L’idée est de séparer les compétences. Le premier agent a un seul job : extraire les données du bon de commande et créer la commande. Le second a un seul job lui aussi : comparer ce qui est sorti avec ce qui était dans le document d’origine, et donner un score de cohérence. « Le bon de commande disait 2 packs, la commande Shopify dit bien 2 packs ? » Un modèle qui n’a qu’une chose à vérifier se trompe beaucoup moins qu’un modèle qui doit tout faire d’un coup.

2. Un human-in-the-loop sur les premières commandes. Avant d’envoyer quoi que ce soit dans Shopify, le scénario poste un message dans Slack avec deux boutons : valider ou refuser. Tant que tu valides, ça continue. Si tu refuses, ça stoppe ou relance. On garde ce filet pour les dix ou vingt premières commandes, le temps de voir le système tourner sur du réel. Une fois la confiance acquise, on retire l’étape et ça passe en autonomie complète.

3. Le bon réflexe sur les notifications. Sa demande était claire : « je veux que ça me sorte de la tête ». Donc surtout pas de récap à chaque commande, ça crée juste un nouveau truc à surveiller. La règle inversée est meilleure : on n’alerte qu’en cas de problème. Tant que tout va bien, silence radio. Le jour où une commande coince, quelqu’un est pingué dans Slack, avec le détail. C’est le seul moment où un humain est utile.

Le filet de sécurité que tout le monde oublie : la réconciliation

Mon levier préféré sur ce call, et celui qui le rassurait le plus, c’est le plus simple. À la fin de chaque journée (ou de chaque lot), le scénario compte deux choses : le nombre de commandes créées dans Shopify, et le nombre de factures générées. Si les deux chiffres sont égaux, tout est passé. S’ils divergent, c’est qu’une commande est restée en route, et là on alerte.

C’est bête comme chou, mais c’est ce contrôle de cohérence qui transforme une automatisation « j’espère que ça marche » en automatisation « je sais que ça marche ». Tu ne vérifies pas chaque commande à la main. Tu vérifies juste que les compteurs s’équilibrent. Le jour où ils ne s’équilibrent pas, tu sais exactement qu’il y a un truc à regarder, et tu sais quoi.

Et le morceau déterministe : Shopify et la création du client

Un dernier détail technique, parce qu’il revient tout le temps. Le point qui plantait le plus chez lui, c’était la création du client : quand un bon de commande arrivait d’une pharmacie pas encore connue de Shopify, le scénario échouait et il devait créer le client à la main avant de relancer.

Ce genre de bloc (« le client existe-t-il ? si non, le créer, récupérer son ID, puis créer la commande ») est très déterministe, et on peut le simplifier. Une option propre, c’est de brancher un serveur Claude MCP de Shopify dans l’agent : au lieu d’enchaîner cinq modules figés, l’agent décide lui-même s’il faut créer le client, va chercher le bon identifiant et appelle les bonnes actions. Ça consomme un peu plus de tokens, mais c’est souvent plus robuste qu’une suite de modules qui se cassent dès qu’un cas n’était pas prévu. Sur une boîte qui ajoute des clients B2B en continu, c’est le genre d’arbitrage qui se justifie.

Ce que ce cas dit de l’automatisation pour de vrai

À la fin du call, on n’avait pas réinventé son automatisation. Elle était déjà là, et plutôt bien faite. Ce qu’on a posé, c’est tout ce qui sépare un prototype d’un système de production : un agent vérificateur, un human-in-the-loop temporaire, des alertes uniquement sur erreur, une réconciliation des compteurs, et un point déterministe simplifié. Rien de spectaculaire. Mais c’est exactement ce qui lui permet de balancer ses cinquante emails dans l’heure et de passer à autre chose.

C’est le piège le plus courant que je vois sur le terrain. Tu penses que le travail, c’est de construire l’automatisation. En réalité, construire le scénario qui marche « quand tu le regardes », c’est la partie facile. Le vrai métier, c’est de le rendre assez solide pour que tu n’aies plus jamais à le regarder. Et ça, ça se joue sur des garde-fous, pas sur de la magie.

Tu veux apprendre à construire ce genre de scénario, de l’extraction IA d’un document jusqu’aux garde-fous qui le rendent fiable en production ? La formation Make complète t’emmène de débutant à autonome : on part des bases, on monte des automatisations métier concrètes, et tu repars avec des systèmes qui tournent sans toi.

Et si tu veux juste tester par toi-même, tu peux ouvrir un compte Make et monter ton premier scénario en quelques minutes.

Sources : Make · Create your first AI agent, Make · Scenarios & error handling, Shopify · Admin API (orders & customers).