Développer son propre outil d’automatisation des commandes ou choisir une solution existante ?

Développer en interne se défend quand le flux de commandes est petit et homogène, ou quand une équipe technique solide peut s’en occuper durablement. Dans les autres cas, ce qui coûte n’est pas le prototype, qui se monte vite avec les modèles d’IA actuels, mais tout ce qui vient après : la correspondance avec le catalogue, les cas particuliers, l’écriture dans l’ERP, l’interface de contrôle et le suivi des modèles. Pour trancher, comparez les deux options sur vos commandes les plus difficiles, pas sur les plus simples.

Pourquoi la question se pose maintenant

Il y a quelques années, automatiser la lecture des bons de commande demandait un projet lourd. Aujourd’hui, un développeur peut envoyer un PDF à un modèle de langage et récupérer en une après-midi un fichier structuré avec le client, les références et les quantités. Sur dix commandes choisies, le résultat est souvent bluffant.

C’est une vraie avancée, et il est normal qu’une direction informatique se demande pourquoi payer un abonnement pour quelque chose qui semble tenir en quelques centaines de lignes de code. La réponse honnête est que, parfois, elle a raison.

Les cas où développer en interne se défend

Un flux petit et très homogène. Si l’essentiel de vos commandes vient de trois ou quatre gros clients qui envoient toujours le même fichier Excel, avec vos propres références, vous n’avez pas besoin d’IA. Un script d’import, voire la fonction d’import de votre ERP, fera très bien l’affaire.

Une équipe qui connaît déjà vos données et restera en place. Si vous avez des développeurs qui maintiennent depuis des années vos intégrations ERP, qui connaissent votre catalogue et vos règles, et qui auront du temps pour ce sujet dans la durée, le projet est envisageable.

Une prise de commande qui fait partie de votre avantage concurrentiel. C’est le cas de certains fabricants dont la commande est en réalité une configuration technique sur mesure. L’outil devient alors un morceau de votre métier, et le garder en interne a du sens.

Un prototype pour apprendre. Même si vous finissez par choisir une solution existante, quelques semaines de prototype aident à comprendre vos propres flux et à formuler vos exigences. Ce n’est pas du temps perdu, tant qu’on ne confond pas le prototype avec un outil de production.

Ce que coûte vraiment un outil maison

Lire une commande n’est que la première étape. Voici ce qu’on découvre quand on passe des dix commandes de la démo aux centaines du mois suivant.

Le catalogue. Extraire « ref 4020 × 10 » est facile. Savoir de quel article il s’agit l’est beaucoup moins : le client utilise ses propres codes, une ancienne référence, celle du fabricant, ou une simple désignation comme « gaine ICTA 20 grise, couronne de 100 m ». Il faut des tables de correspondance, et quelqu’un pour les tenir à jour à chaque article créé, remplacé ou arrêté. Nous détaillons ce problème dans notre article sur la façon de retrouver le bon article à partir des références client.

Les cas particuliers. Ils ne s’arrêtent jamais. Un client commande au carton quand vous vendez à l’unité (voir la conversion des conditionnements). Un autre envoie un « annule et remplace » sans dire ce qui change. Un troisième répartit sa commande sur deux e-mails, ou renvoie la même deux fois. Il y a les prix négociés qui ne correspondent pas au tarif, les adresses de chantier, les dates de livraison souhaitées écrites en bas de page, les scans de travers, les commandes tapées dans le corps du mail entre deux lignes de signature. Chaque cas devient une règle, puis un test. Et celle qui connaît ces cas, c’est la personne de l’ADV, pas le développeur : le projet vit d’allers-retours permanents entre les deux.

Le connecteur ERP. Créer une commande proprement ne consiste pas à insérer des lignes dans une table. Il faut le bon code client, la bonne adresse de livraison, les conditions tarifaires, le bon type de document, parfois la réservation du stock et l’envoi de l’accusé de réception. Les possibilités d’intégration varient selon l’ERP et sa version, une mise à jour peut casser ce qui marchait, et il faut décider de ce qui se passe quand l’ERP refuse une commande.

L’interface de contrôle. Pour que l’équipe fasse confiance à l’outil, elle doit voir ce qui a été lu, ce qui pose question et pourquoi, corriger une ligne et valider. Il faut aussi savoir qui a validé quoi. C’est une application à part entière, souvent oubliée dans le chiffrage initial.

L’évolution des modèles d’IA. Les fournisseurs de modèles sortent de nouvelles versions et retirent les anciennes selon leur propre calendrier. Une nouvelle version peut lire différemment une colonne de quantités ou une date. Il faut donc constituer une base de commandes réelles avec les résultats attendus, la relancer à chaque changement, comparer, corriger. Le coût par document évolue lui aussi. Ce suivi ne s’arrête pas après la mise en production.

La surveillance et la dépendance à une personne. Une commande qui n’est pas traitée, c’est un client qui n’est pas livré. Il faut être prévenu quand quelque chose ne passe pas, même en silence. Et si le développeur qui a construit l’outil quitte l’entreprise, il ne reste souvent qu’une boîte noire que personne n’ose toucher.

Le temps. Pendant les mois de développement, l’équipe ADV continue de tout saisir à la main, et l’équipe informatique ne travaille pas sur autre chose.

Une méthode simple pour trancher

Plutôt que de comparer des devis, faites un test concret.

1. Rassemblez une cinquantaine de commandes réelles, en choisissant volontairement les pénibles : scans, Excel mal formés, références client, commandes dans le corps du mail.
2. Pour chaque option, regardez combien sont traitées correctement de bout en bout, jusqu’à la commande créée dans l’ERP, et pas seulement lues.
3. Posez ensuite les questions de la durée. Qui met à jour les correspondances quand le catalogue change ? Qui est prévenu quand une commande n’est pas traitée ? Qui reteste quand le modèle change ? Que se passe-t-il si la personne clé s’en va ?

Si les réponses tiennent en interne, avec des noms et du temps réservé, développer peut être le bon choix. Sinon, la solution existante l’emporte presque toujours. Pour faire ce test avec Eledone, vous pouvez commencer par l’essai en ligne sur une de vos commandes.

Choisir une solution n’empêche pas de construire autour

Les deux options ne s’excluent pas. Avec Eledone, les règles de saisie et de contrôle sont définies avec vous à la mise en place, et peuvent être précisées pour chacun de vos clients ou de vos produits. Eledone dispose de connecteurs natifs pour Sage 100, Sage X3, Microsoft Dynamics 365 et Odoo, et s’intègre aussi à Cegid, Divalto, NetSuite, Sylob, Proginov, SAP, Infor M3, Exact Online et Oracle par une intégration sur mesure. L’équipe informatique garde un rôle clé : accès à l’ERP, règles propres à l’entreprise, tableaux de bord internes.

La question des données, souvent avancée pour justifier le développement interne, mérite aussi d’être posée concrètement. Chez Eledone, l’espace de chaque client est indépendant et hébergé dans l’Union européenne, vous pouvez choisir le modèle d’IA utilisé, et le système de connaissances construit à partir de vos données peut être hébergé sur vos serveurs.

Questions fréquentes

Nos règles métier sont très spécifiques : un outil existant peut-il les suivre ?

C’est la question à vérifier sur vos propres commandes. Chez Eledone, chaque projet commence par une phase d’observation de vos équipes, de votre ERP et de vos boîtes mail, pour en déduire les règles. Des règles particulières peuvent ensuite être ajoutées par client ou par produit.

Peut-on commencer par un prototype interne et changer d’approche ensuite ?

Oui, et le prototype n’est pas perdu. Il vous aura appris où se trouvent vos vraies difficultés. Gardez les commandes de test que vous avez rassemblées : elles serviront à évaluer n’importe quelle solution.

Combien de temps prend la mise en place d’une solution existante ?

Cela dépend de l’ERP et de la variété de vos commandes. À titre d’exemple, MP Hygiène a intégré Eledone en deux semaines, et l’outil a pu traiter l’ensemble des commandes que ses clients envoyaient par e-mail.

Que devient notre équipe informatique ?

Elle n’a plus à maintenir l’extraction, les correspondances ni le suivi des modèles d’IA. Elle reste en revanche indispensable pour l’accès à l’ERP, la sécurité et les règles propres à l’entreprise.

Vous voulez comparer sur vos propres commandes, y compris les plus difficiles ?
Demandez une démo