Quand chaque e-mail de commande est saisi manuellement dans l’ERP

5 min de lecture

Chaque matin, la boîte de réception déborde de commandes : sous forme d’e-mails textuels, de PDF ou de formulaires numérisés. Au service client, quelqu’un les saisit manuellement dans l’ERP, ligne par ligne. Cela prend des heures, génère des erreurs de frappe et mobilise du personnel qui devrait conseiller plutôt que saisir. Ces e-mails de commande constituent des Dark Data : non mesurées, non structurées, coûteuses. Un modèle de langage peut en extraire les données de commande. Mais cette approche n’est viable que si un format de données strict discipline la sortie et qu’une validation humaine intervient à la fin.

À lire aussi :Quand l’agent comptabilise lui-même la facture fournisseur  /  L’optimisation des processus échoue au moment de la transmission

Les commandes que personne ne compte

Dans de nombreuses PME, la prise de commande passe par une boîte de réception commune. Le client écrit ce dont il a besoin, tantôt sous forme de tableau propre, tantôt en texte continu, et souvent sous la forme d’une photo d’un bon de livraison manuscrit. Le service sédentaire lit, classe et saisit. Le lundi matin, le travail s’accumule car les demandes du week-end s’y ajoutent.

Trois types d’erreurs reviennent systématiquement. Une ligne est mal attribuée car la référence article du client ne correspond pas à la nôtre. Une quantité est faussée car l’unité d’emballage et le nombre de pièces sont confondus. Un prix diffère car le client se base sur une ancienne offre. Chacune de ces erreurs coûtera ensuite bien plus que la minute qu’a duré la saisie. Quiconque connaît ses coûts de processus voit ici un poste caché, comparable au piège de la maintenance ERP dans les PME.

Comment l’IA lit et comment le format la discipline

Le schéma sous-jacent n’est pas lié à un éditeur spécifique. Il se déroule en quatre étapes. Tout d’abord, l’ERP se synchronise avec la boîte de réception via une interface de messagerie comme Microsoft Graph ou IMAP et importe les nouveaux e-mails avec leurs pièces jointes. Ensuite, un modèle de langage analyse le contenu à l’aide d’instructions prédéfinies. Puis, le modèle ne renvoie pas les données extraites sous forme de texte libre, mais dans un format JSON strict. Enfin, une validation vérifie le résultat, l’inscrit dans une table intermédiaire et crée la commande automatiquement ou après approbation manuelle.

L’astuce décisive réside dans le schéma imposé. Un modèle de langage a tendance à formuler ses réponses librement. Un schéma JSON prédéfinit chaque champ à remplir. Le discours se transforme ainsi en une structure lisible par la machine. Cela discipline la forme, mais pas l’exactitude. Le schéma empêche les réponses libres et réduit les erreurs de format. Il ne remplace toutefois pas une vérification métier. C’est exactement ainsi que l’on peut traiter des cas complexes : un premier prompt classe l’e-mail comme commande, ticket ou document et le route en conséquence. Ceux qui poussent la réflexion de la boîte de réception jusqu’à la comptabilisation arrivent rapidement à la question de savoir quand un agent comptabilise lui-même la facture d’achat.

Cette classification indique des tendances. Pour un nombre réduit de formats de commande stables, un modèle OCR reste souvent l’option la plus économique.

Comment les fournisseurs mettent en œuvre ce modèle aujourd’hui

Plusieurs types de prestataires empruntent cette voie. Les spécialistes du traitement documentaire, tels qu’ABBYY ou Konfuzio, extraient les données des pièces justificatives pour les transmettre. Les plateformes d’automatisation comme UiPath ou Microsoft Power Automate enchaînent les étapes d’un système à l’autre. Les grands éditeurs d’ERP développent leurs propres modules, notamment autour de SAP ou de Microsoft Dynamics. Les fabricants d’ERP, quant à eux, intègrent directement ce schéma au cœur de leur plateforme, où il alimente le traitement des commandes sans couche intermédiaire. Le choix de la bonne approche dépend du degré d’intégration à l’ERP existant, de la maîtrise des données et de la maturité des processus de validation humaine, et non des promesses les plus tapageuses. Le fait que l’outil soit rarement le problème devient évident lorsque l’optimisation des processus achoppe sur les transferts de données.

L’éditeur de logiciels autrichien Multidata, par exemple, déploie ce modèle sur sa plateforme MD-Premium. Selon l’éditeur, la boîte de réception se synchronise via Microsoft Graph, un modèle européen de Mistral analyse l’e-mail et restitue les données au format JSON strict. En l’absence de référence article interne, le système s’appuie sur des points de données alternatifs tels que l’adresse de livraison, le numéro de client, le numéro de TVA intracommunautaire ou le code EAN. Une étape de validation permet d’éviter les écueils classiques. Si un client commande trois pièces au tarif de 144 unités, le système reconnaît l’unité de conditionnement et corrige automatiquement en trois fois 48. C’est sur ce genre de détails que se joue la réelle efficacité de l’automatisation.

Européen ne signifie pas pour autant conforme

Le recours à un modèle européen comme Mistral représente bien plus qu’un geste symbolique pour les PME. Il réduit la dépendance à l’égard des fournisseurs extra-européens et touche au cœur même du débat sur la souveraineté numérique. Toutefois, le seul label d’origine ne suffit pas à trancher la question juridique. Quatre éléments doivent être clairement distingués : un modèle européen, un hébergement au sein de l’UE, un entraînement sans données clients et une chaîne de sous-traitance excluant tout sous-traitant hors UE. C’est uniquement leur combinaison qui permet d’établir une politique de protection des données robuste, formalisée par un accord de traitement des données. Toute entreprise introduisant l’IA dans son service client se doit de clarifier ces quatre points par écrit avant même que le premier e-mail client réel ne soit traité par le modèle. À défaut, on risque de voir émerger une variante de l’IA fantôme dans les PME, mais cette fois avec une approbation officielle.

Là où l’intervention humaine reste indispensable

L’erreur la plus courante consiste à confondre la structure avec la fiabilité. Un modèle peut générer un JSON formellement valide tout en y insérant le mauvais client. La structure est correcte, mais pas le contenu. C’est pourquoi la table intermédiaire avec validation manuelle n’est pas un simple détail esthétique, mais bien la pièce maîtresse du dispositif.

Fixer un seuil de confiance trop élevé revient à automatiser l’intégration d’erreurs dans le système comptable. Le fixer trop bas conduit à renvoyer chaque e-mail à un opérateur humain, annulant ainsi tout bénéfice. Le calibrage de ce seuil relève d’une décision opérationnelle, et non d’un choix purement technique.

Quatre questions avant de se lancer

Ces quatre questions distinguent le projet rentable de la tentative coûteuse. Celui qui sait y répondre connaît déjà la moitié de la solution.

1. Combien de commandes transitent quotidiennement par la boîte de réception ? Combien de variantes de format cela représente-t-il ?
2. Quels champs le système peut-il saisir automatiquement, et lesquels nécessitent une validation ?
3. Où sont hébergés le modèle et les données ? Le contrat de sous-traitance est-il en place ?
4. Qui mesure le taux de correction, afin que l’automatisation ne se transforme pas en vol à l’aveugle ?

L’e-mail de commande ne disparaît pas. Il est simplement soit saisi manuellement, soit lu par une machine supervisée par un humain. Celui qui met en place ce schéma de manière rigoureuse récupère du temps pour ce qu’aucun modèle ne peut faire : les demandes de précisions, les réclamations et le conseil. Celui qui le déploie sans validation ni mesure ne fait que déplacer l’erreur vers un endroit où plus personne ne la voit.

Foire aux questions

Les recommandations de lecture de la rédaction

Source de l’image : générée par IA (juin 2026)