Un manager planning de production a mis un agent IA en prod dans un grand groupe (sans écrire une ligne de code)

Le contexte

J’étais manager planning de production et BI. Pas développeur. Et pourtant, à mi-temps, en parallèle de mon poste, j’ai mis en place un agent IA qui lit les confirmations de commandes de nos fournisseurs, les compare à l’ERP et prépare le travail des acheteurs.

Deux sites d’un grand groupe industriel international (leader sur un marché de niche, plus de 20 000 personnes) l’utilisent aujourd’hui, et 2 autres sont prévus. Je vous raconte comment ça s’est passé, ce qui a marché, et ce qui m’a fait perdre quelques cheveux.

Le problème : des mails, des mails, et encore des mails

Quand un fournisseur confirme une commande, il le fait par e-mail. Toujours. Et chacun a sa propre idée de ce qu’est un PDF lisible : mise en page différente, scans, Excel, en français, italien, anglais ou allemand.

Et ce n’est pas tout. Une partie de l’info importante n’est même pas dans le PDF. Elle est dans le corps du mail : un « délai OK », un « peut-on avancer la livraison ? », une petite condition glissée entre deux salutations. Un outil qui lit seulement les pièces jointes passe à côté.

Résultat, l’acheteur jongle entre sa boîte mail, le PDF, l’ERP, parfois un tableur, puis il ressaisit tout à la main. Pendant ce temps, les planificateurs travaillent avec des dates qui ne sont plus vraies. Et on découvre les écarts tard, parfois quand la pièce manque sur la ligne.

L’idée : tout à un seul endroit

Je n’ai pas voulu ajouter un énième outil. Je voulais tout centraliser. Pour chaque confirmation, l’acheteur voit au même endroit :

• ce que le fournisseur a écrit, mail compris, et son PDF en un clic ;
• ce qui est ouvert dans l’ERP pour cette commande ;
• les écarts déjà calculés (date demandée contre date confirmée, prix actuel contre prix confirmé, version de la pièce) ;
• trois boutons : accepter, corriger, rejeter.

Tous les leviers de décision à portée de clic. L’IA prépare le dossier, l’acheteur décide. Et je tiens à ce point : chaque confirmation passe par un humain. Confier des commandes à une IA sans regarder, ça ne me tente pas trop.

Comment ça marche (version courte)

1. 1
   Le fournisseur répond

   Par mail, comme d’habitude. Aucun portail, aucun formulaire à lui imposer.

2. 2
   L’IA lit

   Le corps du mail et la pièce jointe, dans n’importe quelle langue.

3. 3
   Elle compare

   Avec les commandes ouvertes de l’ERP : dates, prix, versions.

4. 4
   L’acheteur décide

   Il valide, corrige ou rejette, avec tout sous les yeux.

5. 5
   L’ERP est mis à jour

   Après validation, l’information repart dans l’ERP.

Trois choix qui ont compté

Ce qui a été moins glamour

Un prototype qui lit un PDF, ça se fait vite. La mise en production, c’est une autre histoire :

• Des mails perdus. Quand plusieurs confirmations arrivaient en même temps, une seule était traitée. Les autres disparaissaient, sans bruit. Maintenant elles passent une par une, et un mail en erreur ne bloque pas les suivants.
• Des « OK » sans rien dedans. « Délai OK / Prix OK » dans le corps d’un mail, ça ne dit ni la date ni le prix. Il faut aller les chercher dans la commande. J’ai analysé 9 vrais mails avant de coder pour savoir quels cas traiter en premier.
• Des documents qui ressemblent à des confirmations. Bons de livraison, commandes renvoyées signées, commandes cadre avec plusieurs livraisons. Chacun a sa règle.
• Des données qui ont un jour de retard. L’entrepôt de données se rafraîchit la nuit. Un job quotidien remet les références à jour, sans écraser ce qui a déjà été saisi.
• La sécurité. Accès avec le compte de l’entreprise, rien à installer sur les postes, aucune porte ouverte depuis Internet. Ça a demandé plusieurs échanges avec l’IT. Et c’est normal.

Sans écrire une ligne de code moi-même

Oui, vous avez bien lu. Je n’ai pas écrit de code. J’ai décrit ce que je voulais en langage normal, et Claude Code l’a construit. Mon boulot, c’était plutôt celui d’un chef d’orchestre :

• connaître le métier, pour dire précisément ce dont un acheteur a besoin ;
• choisir et assembler les bons outils ;
• tester sur de vrais mails, corriger, décider de ce qui rentre dans le projet ou pas ;
• accompagner les équipes jusqu’à l’usage au quotidien.

Une fonction de manager aide beaucoup ici. Quand on pilote déjà des priorités, des équipes et des relations avec l’IT, on peut faire avancer un outil en parallèle de sa mission. L’IA produit, le manager cadre et arbitre.

Les résultats

Avant la mise en production, on a fait une phase de tests utilisateurs (UAT) de 15 jours ouvrés, en trois temps de 5 jours :

1. les tests de l’outil, de son utilisation et du parcours de bout en bout ;
2. le traitement de tous les mails de confirmation des fournisseurs, copiés dans la boîte prévue pour l’outil ;
3. un nouveau test, une fois tous les retours et les évolutions demandées traités.

Sur plus de 100 mails fournisseurs réels, pour les 2 sites :

Donc 80 % des extractions sans aucune correction. Sur un échantillon de cette taille, c’est un ordre de grandeur, pas une vérité gravée dans le marbre : les chiffres de production nous en diront plus. Les 20 % corrigés gardent la valeur d’origine de l’IA, ce qui nous permet d’améliorer les règles au fil de l’eau.

• Le délai de traitement : environ 0,5 jour, contre 2 à 5 jours avant.
• Le temps gagné : 3 à 4 jours par mois pour l’équipe d’acheteurs du site pilote, soit 36 à 48 jours par an. Sur 4 sites, ça ferait 144 à 192 jours par an, l’équivalent de 0,65 à 0,9 poste à temps plein, si les volumes sont comparables.

Et maintenant

Les 2 sites pilotes (un par ERP du groupe) ont demandé 6 mois à mi-temps, soit l’équivalent d’environ 3 mois à temps plein. Pour les 2 suivants, le plus dur est fait : les données sont déjà dans Microsoft Fabric, il faut les ouvrir à l’outil, puis former et accompagner les équipes. J’estime ça à environ 2 mois à mi-temps, un site après l’autre. C’est le premier agent IA en production au niveau du groupe, autant prendre le temps de bien accompagner les gens.

Ce que je ferais autrement

• Mesurer la situation de départ dès la première semaine. Je l’ai fait après le lancement, et la comparaison est moins nette.
• Tester sur de vrais mails beaucoup plus tôt. Les 9 cas réels m’ont appris plus que des semaines de tests théoriques.
• Penser à la file d’attente des mails dès le début, pas après en avoir perdu quelques-uns.

À retenir

• Le gain vient de la comparaison avec l’ERP et de la centralisation, pas seulement de la lecture des PDF.
• Chaque confirmation passe par un humain : l’IA prépare, l’acheteur décide.
• « Sans code » ne veut pas dire « sans l’IT » : la sécurité et le réseau se traitent avec les équipes concernées.
• L’approche est indépendante de l’ERP : seul le raccordement change d’un site à l’autre.

Questions