Construire avec l'IA en interne est une nécessité, mais la saisie des commandes est un premier chantier difficile. Quand un seul client vous envoie toujours le même fichier, un flux maison suffit. Quand des dizaines de clients commandent chacun à leur façon et qu'une erreur part en livraison, achetez le moteur de lecture et gardez vos règles métier. Le coût n'est pas le prototype, c'est son exploitation.
Peut-on développer soi-même un agent de saisie de commandes ?
Oui, et des entreprises l'ont fait. Lire un PDF, en sortir des lignes et les pousser dans l'ERP est à la portée d'une équipe IT ou d'un prestataire, en quelques semaines. La question n'est pas de savoir si c'est possible, ni même s'il faut construire avec l'IA : il le faut. C'est de savoir si ce chantier-là est le bon pour commencer.
Le sujet revient de plus en plus souvent en premier rendez-vous, et il vient du prospect : il a construit, est en train de construire ou envisage de construire son propre outil. Depuis le printemps 2026, c'est l'une des premières objections. Le marché mûrit, et la question n'est plus « est-ce que ça marche ? » mais « est-ce qu'on ne peut pas le faire nous-mêmes ? ».
Ce qu'ils ont construit tient debout. Un fabricant qui développe tous ses outils internes a branché un modèle Microsoft sur sa boîte mail commune : il repère les PDF de commande et les fait entrer dans l'outil métier. Un fabricant de quincaillerie fait tourner plusieurs agents sur ses propres serveurs. Un distributeur traite les commandes de sa filiale étrangère avec Power Automate, et il le dit sans détour : c'est un seul émetteur, au format qu'il impose.
Tous ces cas ont un point commun : un flux connu à l'avance. Un format, un expéditeur, une structure stable. C'est précisément ce que l'on sait automatiser en interne. Et c'est précisément ce que la commande par mail n'est pas, dès que le flux vient de dizaines de clients différents.
Par quoi commencer en interne ?
Par ce qui tolère l'erreur et le changement. Une IA ne répond pas deux fois la même chose : un premier chantier interne doit pouvoir se tromper sans conséquence physique, se corriger à la main et s'arrêter sans casser un processus. Rédaction, tri, résumé, recherche dans vos documents : oui. Une ligne de commande écrite dans l'ERP : pas en premier.
Essayer l'IA sur vos propres flux, former vos équipes dessus, construire de petites choses : c'est devenu indispensable, et aucune entreprise ne devrait attendre. Mais le choix du premier chantier compte plus que l'outil.
Trois critères pour le choisir :
- La tolérance à l'erreur. Un brouillon de mail faux se relit. Une référence fausse poussée dans l'ERP part dans un camion. Commencez là où une erreur coûte une relecture, pas une livraison.
- Le besoin de stabilité. Un modèle de langage ne répond pas deux fois exactement la même chose. Un processus qui doit donner le même résultat chaque matin demande des garde-fous, des tests et un suivi quotidien que l'on ne met pas en place sur un premier projet.
- La réversibilité. Si l'outil s'arrête un vendredi soir, l'équipe doit pouvoir reprendre à la main sans que rien ne soit perdu.
De bons premiers chantiers : aider à rédiger les réponses clients, trier et étiqueter la boîte mail, résumer des comptes-rendus, chercher dans vos documents internes. Ils apprennent beaucoup, ils coûtent peu, et ils se corrigent à la main.
La saisie de commandes vers l'ERP coche les trois mauvaises cases : une erreur est physique, le résultat doit être stable, et l'arrêt bloque les expéditions. Elle se construit en interne dans un seul cas : un ou deux émetteurs, un format que vous imposez ou qui ne bouge pas, une équipe IT qui restera là, un volume stable. Le distributeur qui automatise sa filiale étrangère avec Power Automate est exactement dans ce cas, et il le dit sans détour : facile d'imposer un format à ses collègues, impossible de l'imposer à un grand compte qui a ses propres habitudes.
Où est le vrai coût : le prototype ou l'exploitation ?
L'exploitation. Le prototype lit un PDF propre en trois semaines. La production, c'est le client qui écrit « le bleu, comme la dernière fois », le modèle qui change de version, la réponse qui n'est pas la même deux fois. Chaque cas demande une règle, un garde-fou ou une mise à jour. Et quelqu'un pour s'en occuper, chaque jour.
Le travail qui coûte n'est pas la lecture, c'est l'association. Sur un document propre, extraire le texte est résolu depuis longtemps. Ce qui prend du temps, c'est de rapprocher ce que le client a écrit de la bonne référence dans votre ERP : une désignation commerciale, une dimension dans le mauvais ordre, un code client interne que vous n'utilisez pas. Nous observons sur les flux que nous traitons que la part de lignes associées sans intervention varie de 60 à 90 % selon que le client écrit votre référence ou sa propre désignation. Ces 10 à 40 % restants, c'est là que vit la maintenance.
Un outil maison traite ces cas par des règles : une table de correspondance par client, une exception pour tel format, un correctif pour telle colonne qui a bougé. Chaque nouveau client ajoute les siennes. Chaque changement d'ERP chez un client en casse quelques-unes. Et le jour où la personne qui a écrit ces règles change de poste, personne ne sait plus pourquoi la ligne 212 existe.
Un groupe de distribution rencontré au printemps 2026 avait mis en place un flux de ce type avec les outils Microsoft. Son responsable le dit lui-même : ils en étaient « un peu revenus ». Ce n'est pas que ça ne marchait pas. C'est que ça demandait de l'attention tous les jours, pour un sujet qui n'était pas le cœur de son métier.
Le deuxième coût est la stabilité. Un modèle de langage ne répond pas deux fois exactement la même chose, et un processus de commande doit, lui, donner le même résultat chaque matin. Il faut donc un mode brouillon, un score de confiance par ligne, une file de validation pour l'équipe, des tests qui rejouent les commandes d'hier à chaque changement, et une trace de qui a corrigé quoi. Sans cela, une ligne poussée dans l'ERP sans certitude met le mauvais produit dans le camion.
Le troisième est l'apprentissage. Un outil qui ne voit que vos commandes n'apprend que vos cas. Un outil qui en voit passer des milliers, de dizaines d'entreprises, rencontre chaque semaine des formats, des abréviations et des erreurs que vous ne verrez qu'une fois par an. C'est cette variété qui fait progresser la lecture et l'association, et aucune équipe interne ne l'a.
Le quatrième est le rythme. Les modèles changent de version tous les mois, leurs réponses bougent avec, et les nouveautés utiles arrivent toutes les semaines. Tenir un agent à jour n'est pas une tâche mensuelle, c'est une tâche quotidienne, avec quelqu'un qui lit ce qui sort et le mesure. C'est un métier, et il est rarement celui de votre équipe IT.
Power Automate, Copilot Studio, prestataire IA : que fait chacun, et que vous laisse-t-il ?
Power Automate enchaîne des étapes sur un format connu. Copilot Studio ajoute un modèle de langage pour lire du texte libre. Un prestataire IA vous livre un agent sur mesure. Les trois lisent la commande. Aucun des trois ne porte, à votre place, l'association aux références de votre ERP ni les exceptions des mois suivants.
Le point commun des trois premières options : vous achetez une capacité de lecture, pas une capacité d'exploitation. Et c'est l'exploitation qui coûte. Un agent de traitement des commandes sur étagère ne fait pas mieux la lecture, il porte ce qu'il y a après : la base articles rapprochée, le client qui écrit autrement, la ligne qui attend une validation, la correction qui sert à la commande suivante.
| Ce qu'il fait bien | Ce qui reste à votre charge | |
| Power Automate | Déclencher une suite d'actions sur un mail ou un fichier au format connu. Idéal pour un émetteur unique. | Toute variation de format. L'association aux références. La validation humaine. |
| Copilot Studio | Lire un texte libre et en extraire des champs, sans modèle de zones. | Le rapprochement avec votre base articles. Les règles par client. L'exploitation au quotidien. |
| Prestataire IA | Livrer un agent adapté à vos flux, avec votre vocabulaire. | La maintenance après livraison, facturée ou non. Le départ du prestataire. L'évolution du modèle. |
| Agent IA | Lecture, association aux références, mode brouillon, validation, déjà en production chez d'autres. | Vos règles métier spécifiques, à paramétrer. Coût à l'usage. |
Vous avez déjà commencé à construire : que garder ?
Tout ce que vous avez appris, et rien de ce qui vous coûte. Votre prototype a produit une chose précieuse : la liste exacte de vos cas particuliers, vos formats, vos clients difficiles. C'est une spécification. Elle vaut des semaines de cadrage. Ce qu'il faut lâcher, c'est l'obligation de maintenir le moteur vous-mêmes.
Plusieurs des entreprises citées plus haut étaient dans ce cas : un flux en place, qui marche sur une partie des commandes, et qui demande plus qu'il ne rend. Le réflexe est de défendre l'investissement. Le bon calcul est ailleurs.
Faites l'inventaire de ce que le prototype a révélé : les clients dont les commandes passent sans retouche, ceux qui cassent tout, les formats rencontrés, les règles ajoutées et pourquoi. Cette liste est votre cahier des charges. Un agent sur étagère se paramètre dessus en jours, pas en semaines, parce que le travail de découverte est fait.
Gardez aussi ce qui tourne bien. Si votre flux Power Automate traite la filiale sans erreur, il n'y a aucune raison de le débrancher. Un agent de traitement des commandes peut prendre le reste : les clients hors format, les PDF scannés, les commandes dans le corps du mail. Les deux cohabitent, chacun sur le flux où il est le plus fort.
Comment décider : la grille en sept questions
Répondez à ces sept questions sur votre propre flux, pas sur un cas général. Six réponses sur sept dans la colonne de gauche : construisez, vous avez un flux standard et une équipe pour le tenir. Six sur sept à droite : achetez le moteur, et consacrez votre équipe à vos règles métier.
- Combien d'émetteurs différents envoient des commandes ? Moins de cinq, au format que vous choisissez : construire tient. Des dizaines, chacun avec ses habitudes : acheter.
- Vos clients écrivent-ils vos références ou leurs désignations ? Vos références, dans un fichier structuré : construire tient. Leurs mots, dans un PDF ou un mail : acheter, c'est l'association qui coûte.
- Qui maintiendra les règles dans dix-huit mois ? Une équipe IT en place, avec le temps prévu pour ça : construire tient. Un prestataire, un alternant ou personne : acheter.
- Combien de nouveaux clients par mois ? Aucun ou presque : construire tient. Plusieurs, avec leurs formats : acheter, chaque client est une règle de plus.
- Un changement d'ERP est-il prévu chez vous ou chez vos clients ? Non : construire tient. Oui, ou vous ne savez pas : acheter, un agent qui rapproche par le sens survit au changement de format.
- Combien de commandes arrivent hors format chaque mois ? Moins de deux cents : aucune des deux approches ne se rembourse vite, mesurez d'abord. Au-delà de quatre cents, chaque commande saisie à la main coûte dix minutes, l'agent en rend sept : c'est près de soixante-dix heures de saisie par mois, dont plus de quarante rendues à l'équipe. La question n'est plus s'il faut automatiser, mais comment.
- Que se passe-t-il quand le résultat est faux ? Une relecture et une correction : construire tient. Un mauvais produit expédié, une facture fausse, un client livré en retard : acheter, et exiger un mode brouillon, un score de confiance et des tests à chaque changement de modèle.
Cette grille peut conclure « construisez ». Un flux mono-client, stable, tenu par une équipe qui reste, n'a pas besoin d'un agent. Elle conclut « achetez » dès que la variété des clients devient le problème, parce qu'aucune équipe interne n'a vocation à écrire une règle par client, tous les mois, pour un sujet qui n'est pas son métier.
Et l'hybride : acheter le moteur, garder ses règles
C'est la réponse de la plupart des entreprises que nous rencontrons. Le moteur de lecture, l'association aux références et le mode brouillon viennent de l'agent. Les règles métier restent à vous : quel client valider à la main, quel seuil de confiance, quelle exception pour tel grand compte. Vous gardez la main, sans porter le moteur.
Un agent de traitement des commandes se branche sur la boîte mail et sur l'ERP, par API ou par fichier plat, sans chantier IT. Il lit, rapproche, propose. L'équipe ADV valide ce qui doit l'être et corrige ce qui doit l'être, et chaque correction sert aux commandes suivantes.
Ce partage a une vertu que le choix binaire n'a pas : il est réversible. Les règles que vous écrivez sont à vous. La liste de vos cas particuliers est à vous. Si un jour votre équipe veut reprendre le moteur, elle part d'un flux documenté, mesuré, et de deux ans de corrections consignées. C'est rarement le cas d'un prototype maison.
Si vous hésitez encore, commencez par mesurer. Un export de votre boîte mail commandes sur deux mois dit, en quelques jours, combien de commandes arrivent hors format, combien de clients écrivent leurs propres désignations, et combien de temps l'équipe passe dessus. La grille se remplit d'elle-même. Votre équipe IT, si vous en avez une, garde ce qui compte pour elle : les règles de gestion, les contrôles avant écriture dans l'ERP, les tableaux de bord.
