Commandes B2B par e-mail ou PDF : les saisir dans Sylius
Pour saisir dans Sylius les commandes B2B reçues par e-mail ou en PDF, un agent IA lit le message et le bon de commande joint, identifie le client par son adresse e-mail, fait correspondre chaque ligne à un code de variante, vérifie le stock et recalcule la commande avec vos prix. Il prépare une commande en attente et vous signale tout écart avec le bon. Vous validez. Il ne crée aucune commande définitive et ne modifie aucun prix pour coller au document.
Je suis développeur Sylius et Symfony indépendant, et j'intègre des agents IA dans des boutiques en ligne. Beaucoup de boutiques qui vendent aussi aux professionnels vivent avec une contradiction : un site qui prend les commandes tout seul, et une partie des clients B2B qui continue d'envoyer un PDF par e-mail, parce que c'est le circuit de leur service achats. Quelqu'un ressaisit. Pour la vue d'ensemble des agents sur Sylius, voyez la page agents IA pour Sylius.
Pourquoi la ressaisie des bons de commande pose-t-elle problème ?
Elle prend du temps, mais surtout elle produit des erreurs silencieuses. Une quantité de 100 tapée 10, une référence voisine prise pour une autre, une adresse de livraison de chantier oubliée au profit de l'adresse de facturation. Ces erreurs se découvrent à la livraison, quand le client appelle. Et la ressaisie dépend d'une personne : quand elle est absente, les commandes attendent.
Chaque client a en plus son format : un tableau Excel converti en PDF, un bon de commande généré par un logiciel de gestion, un simple e-mail « comme la dernière fois, mais 50 au lieu de 30 ».
Comment l'agent lit-il un bon de commande ?
Le modèle de langage fait ce qu'il fait bien : comprendre un document dont la forme change à chaque fois. Il en extrait une structure fixe, imposée par le code : numéro de bon de commande du client, date, adresse de livraison, et pour chaque ligne la référence, la désignation, la quantité et le prix indiqué. Pour les documents difficiles (scan, tableau dense), le routeur de modèles envoie la lecture vers un modèle plus capable ; pour un e-mail de trois lignes, un modèle léger suffit.
Ensuite, le code prend le relais pour tout ce qui doit être exact.
| Élément du bon | Contrôle fait par le code | En cas de doute |
|---|---|---|
| Expéditeur | Adresse e-mail exacte rapprochée d'une fiche client | Commande bloquée, signalement |
| Référence de ligne | Correspondance avec un code de variante existant, directe ou par la table du client | Proposition de correspondance à confirmer |
| Quantité | Comparée aux commandes habituelles du client | Écart inhabituel signalé |
| Prix indiqué | Comparé au prix calculé par Sylius et vos règles | Écart affiché ligne par ligne |
| Total du bon | Comparé au total recalculé | Écart affiché en tête |
| Adresse de livraison | Comparée aux adresses connues du client | Nouvelle adresse mise en évidence |
Ce partage des rôles est la clé. Le modèle peut se tromper en lisant ; le contrôle croisé du total et des prix rattrape l'essentiel de ces erreurs. Ce sont les garde-fous.
Et si un agent le faisait pour vous ?
Laissez votre numéro : je vous rappelle sous 24 heures ouvrées et je regarde avec vous ce qu'un agent peut prendre en charge dans votre boutique, dans votre budget.
Comment l'agent travaille-t-il avec Sylius ?
Sur Sylius 2, il lit par l'API d'administration (/api/v2/admin), qui exige un jeton et le rôle ROLE_API_ACCESS, comme le montre la configuration de sécurité de Sylius-Standard 2.3. Il y trouve le client, ses adresses, ses commandes passées, les variantes, leurs prix sur le canal concerné et leur stock. Il dépose ensuite une commande en attente dans une file de l'administration, avec le PDF d'origine à côté et les écarts surlignés. Vous comparez, corrigez si besoin, et validez : c'est seulement à ce moment que la commande entre dans le circuit normal de préparation et d'expédition.
Sylius publie aussi le plugin Admin MCP Server, qui expose l'API d'administration à un assistant IA avec une authentification OAuth. Il est en version 0.2, exige Sylius 2.1 ou plus et impose la télémétrie : c'est une brique à suivre, que j'utilise seulement après avoir réduit les outils exposés au strict nécessaire, comme expliqué dans la couche les outils.
Ce que l'agent ne fait jamais seul
Il ne valide aucune commande, ne déclenche aucune préparation, ne modifie aucun prix, ne crée aucune fiche client et n'écrit pas au client. Si le bon vient d'une adresse inconnue, il ne cherche pas à deviner la société : il signale. Ces interdits sont dans le code, l'agent n'a pas les outils correspondants. Chaque passage est tracé : le document lu, les lignes extraites, les correspondances utilisées, le modèle appelé et qui a validé. Le jour où un client conteste une quantité, vous retrouvez ce qui a été lu et décidé. C'est la couche tests et traces.
Par où commencer ?
Rassemblez une trentaine de bons de commande reçus ces derniers mois, avec la commande que vous avez réellement saisie. C'est le jeu de test : l'agent doit retrouver vos commandes avant de toucher aux nouvelles. Notez au passage quels clients utilisent leurs propres références : leur table de correspondance est souvent le vrai chantier.
Si les bons de commande sont précédés d'un devis, l'agent de saisie peut reprendre le devis accepté, ce que je décris dans l'article sur les devis B2B. La même technique de lecture sert aussi aux documents de vos fournisseurs, dans l'article sur les factures fournisseurs et celui sur l'import de catalogue.
Je propose un diagnostic IA offert : je vous rappelle sous 24 heures ouvrées, je regarde vos bons de commande, vos volumes et votre version de Sylius, et je vous propose la solution qui rentre dans votre budget. Pas d'abonnement de plateforme imposé : le code vous appartient.