Votre ERP contient tout : clients, articles, devis, factures, commandes fournisseurs. Et pourtant, y trouver une information reste souvent lourd et chronophage : des écrans denses, des exports Excel, des allers-retours entre modules. Résultat, vos équipes perdent du temps sur des questions simples (« ce produit est-il disponible ? », « où en est la livraison fournisseur ? ») et vos clients attendent des réponses que vos données contiennent déjà. La promesse d’un assistant IA branché sur l’ERP fait rêver, mais entre la démo spectaculaire et l’outil fiable en production, il y a un chemin que peu d’articles décrivent.
Chez Playmoweb, nous venons de parcourir ce chemin pour un distributeur de matériel informatique et réseau de la région angevine, dont l’ERP EBP (Gestion Commerciale, en SaaS) centralise toute l’activité. Ce retour d’expérience raconte le projet tel qu’il s’est réellement passé : le découpage en étapes, les limites d’API découvertes en route, les choix d’architecture, et ce que nous referions à l’identique.
Sommaire
Notre client est un cas d’école : un distributeur B2B qui gère des milliers de références (baies, switches, câblage fibre, caméras) dans EBP Gestion Commerciale. Chaque devis envoyé à un client devait être accompagné des fiches techniques des produits, et ces fiches vivaient à deux endroits différents : un Google Drive interne et le site web de l’entreprise. Composer un envoi complet prenait de longues minutes de recherche manuelle, plusieurs fois par jour.
Au-delà de ce cas précis, l’équipe passait un temps significatif à répondre à des questions dont la réponse dormait dans l’ERP : historique d’achats d’un client, factures, livraisons fournisseurs en attente, disponibilité d’un produit. C’est le symptôme classique : l’ERP est la source de vérité, mais son interface a été conçue pour la saisie et la gestion, pas pour la consultation rapide au quotidien. C’est exactement l’écart qu’un outil connecté peut combler.
Nous n’avons pas commencé par l’IA. Nous avons commencé par le gain de temps le plus mesurable, puis élargi. Ce découpage en trois étapes est le cœur de la méthode, et la raison pour laquelle le projet a tenu ses promesses.
| Étape | Contenu | Valeur |
|---|---|---|
| 1. Devis et documentation automatiques | À partir d’un numéro de devis, l’outil interroge l’API EBP, récupère les fiches produits associées aux références, laisse l’utilisateur choisir, puis génère l’envoi par email | Des minutes gagnées sur chaque devis, plusieurs fois par jour, dès la mise en service |
| 2. Assistant IA en langage naturel (interne) | L’équipe pose ses questions en texte ou à la voix (« quel est l’historique d’achats de ce client ? », « quelles livraisons fournisseurs sont en attente ? ») et l’IA répond à partir des données EBP | L’ERP devient consultable par tous, sans formation aux écrans EBP |
| 3. Ouverture aux clients professionnels (évolution envisagée) | À terme, l’outil validé en interne pourrait devenir une application web et mobile pour les clients : disponibilité, tarifs, documentation, historique, avec gestion sécurisée des accès | La donnée interne deviendrait un service client différenciant |
L’ordre n’est pas anodin. L’étape 1 apporte un retour sur investissement immédiat et vérifiable, ce qui finance la confiance pour la suite. L’étape 2 introduit l’IA sur un périmètre interne, où une réponse imparfaite se corrige sans risque commercial. L’étape 3, elle, reste à ce stade une évolution envisagée : la donnée ne sera exposée aux clients qu’une fois l’outil durablement éprouvé en interne, et seulement si le besoin se confirme. C’est l’application directe de notre approche MVP : valider chaque palier avec 30 à 50 % du budget de la vision complète avant d’engager le suivant.
Côté calendrier, comptez un rythme réaliste : sur ce projet, environ trois mois de développement, précédés d’une phase de cadrage et de spécifications qui a sécurisé le périmètre (et évité une mauvaise surprise, on y revient juste après). Un projet ERP + IA sérieux ne se livre pas en trois semaines.
C’est la leçon la plus précieuse du projet, et celle que personne ne vous dit avant de signer : le périmètre réel de votre projet est défini par l’API de votre ERP, pas par votre ambition.
EBP en mode SaaS expose une API qui permet de lire les données de gestion : clients, articles, devis, documents. C’est ce qui a rendu les étapes 1 et 2 possibles. Mais lors de la phase de cadrage, en épluchant la documentation développeur d’EBP, nous avons découvert qu’une fonctionnalité envisagée (la création de devis directement via l’API) n’était pas possible. Cette découverte a été faite au bon moment : avant les développements, pendant le cadrage. Le périmètre a été ajusté en conséquence, sans budget perdu ni promesse trahie.
Le réflexe à retenir : avant tout engagement, auditez l’API de votre ERP sur trois questions. Que peut-on lire (et avec quel niveau de détail) ? Que peut-on écrire ? Quelles sont les limites d’usage (quotas, authentification, fraîcheur des données) ? Sur EBP comme sur Sage, Cegid ou un ERP métier, les réponses varient énormément d’une version et d’un mode d’hébergement à l’autre. Cet audit de quelques jours est la meilleure assurance du projet.
L’architecture retenue est volontairement sobre. L’assistant ne remplace pas l’ERP et ne duplique pas ses données dans un système parallèle : il interroge l’API EBP à la demande, transmet le contexte pertinent au moteur d’IA, et restitue une réponse en langage naturel, à l’écrit comme à la voix. Le moteur d’IA apprend en continu des reformulations et corrections de l’équipe, ce qui améliore la pertinence au fil des semaines.
Deux choix méritent d’être soulignés. D’abord le moteur : nous nous appuyons sur des LLM du marché, de type Mistral et Gemini, choisis pour leur rapport pertinence/coût sur ce cas d’usage plutôt que par principe. Le modèle reste d’ailleurs interchangeable dans l’architecture : si les exigences de confidentialité d’un client imposaient demain une chaîne entièrement européenne, la bascule vers une option souveraine (nous avons détaillé ces architectures dans notre article sur l’IA souveraine) se ferait sans refonte. Ensuite la sobriété fonctionnelle : l’assistant répond aux questions dont les réponses existent dans l’ERP. Il ne prétend pas prédire les ventes ni rédiger la stratégie commerciale. Cette modestie est ce qui le rend fiable, donc adopté. Notre guide sur l’intégration de l’IA dans une application détaille les autres architectures possibles selon les cas d’usage.
Le chantier le moins visible du projet n’était ni l’IA ni l’API : c’était la documentation produit. Les fiches techniques vivaient sur un Google Drive et sur le site web, sans référentiel unique. Or un assistant qui joint la mauvaise fiche à un devis fait perdre la confiance en une semaine. Une partie du projet a donc consisté à unifier ce référentiel documentaire et à le relier proprement aux références de l’ERP.
C’est une constante de tous nos projets IA : la qualité des réponses de l’assistant est plafonnée par la qualité des données qu’on lui donne. Avant de brancher une IA sur votre ERP, posez-vous la question honnêtement : vos fiches articles sont-elles à jour, vos référentiels sont-ils uniques, vos documents sont-ils rattachés aux bonnes références ? Si la réponse est non, ce nettoyage fait partie du projet et doit être budgété comme tel, pas découvert en cours de route.
Ces questions structurent la phase de cadrage que nous menons sur ce type de projet, de l’audit d’API aux spécifications, jusqu’au développement de l’outil. Découvrez notre approche du développement IA.
Votre ERP mérite mieux que des exports Excel ? Parlons de votre cas concret lors d’un échange gratuit et sans engagement. 👉 playmoweb.com/nous-contacter