Votre ERP contient des années de données supply chain. Vos stocks, vos commandes fournisseurs, votre historique de ventes, vos délais, vos KPIs : tout est là, quelque part dans la base de données. Mais accéder à cette information de manière rapide et intuitive reste difficile. Les requêtes prennent du temps, les tableaux de bord sont rigides, et les questions improvisées nécessitent souvent l'intervention du service IT.
Connecter un LLM (Large Language Model) à votre ERP ou à votre logiciel supply chain permet de donner une interface conversationnelle à ces données. Mais cette connexion ne se fait pas avec un simple bouton. Comprendre les architectures disponibles et leurs compromis permet de choisir la bonne approche.
Dans cet article, vous apprendrez :
- Les différentes architectures pour connecter un LLM à un ERP ou logiciel supply chain
- Les prérequis côté données et systèmes
- Les avantages et limites de chaque approche
- Comment démarrer avec un budget limité
Pourquoi connecter un LLM à votre système supply chain
La promesse : une interface universelle sur vos données
Un LLM connecté à votre ERP devient une interface en langage naturel sur vos données métier. Au lieu de naviguer dans des menus, de construire des requêtes, ou de demander au service IT de vous créer un rapport, vous posez une question : "Quels fournisseurs ont livré avec plus de 5 jours de retard ce trimestre ?" et vous obtenez une réponse structurée en secondes.
Cette interface universelle bénéficie à tous les profils : le responsable supply chain qui veut des analyses ad hoc, le directeur qui veut un état des stocks sans passer par un tableau de bord, le commercial qui veut savoir si une référence est disponible.
La réalité : ce n'est pas plug-and-play
Connecter un LLM à un ERP n'est pas une intégration triviale. Il faut décider quelle architecture technique adopter, gérer la sécurité des données, et s'assurer que le modèle comprend la sémantique métier (un "délai fournisseur" dans votre ERP peut s'appeler "lead_time_days" dans la base de données).
Les 3 architectures de connexion LLM-ERP
Architecture 1 : LLM + API ERP (la plus directe)
Fonctionnement : Le LLM reçoit la question de l'utilisateur, la transforme en une requête API vers l'ERP, récupère les données, et formule la réponse.
Avantages : Données toujours à jour (temps réel), architecture simple, pas de duplication des données.
Inconvénients : Nécessite un ERP avec une API bien documentée. Les requêtes complexes nécessitent souvent plusieurs appels API successifs, ce qui ralentit les réponses. La qualité des réponses dépend de la qualité de la documentation API.
Adapté à : ERP modernes avec API REST bien documentée (Odoo, Dynamics, certains modules Sage). Cas d'usage simples et structurés.
Architecture 2 : LLM + Data Warehouse (RAG sur données)
Fonctionnement : Les données ERP sont régulièrement exportées vers un entrepôt de données (ou une base vectorielle). Le LLM interroge cet entrepôt plutôt que l'ERP directement.
C'est l'architecture RAG (Retrieval-Augmented Generation) : le modèle récupère les données pertinentes, puis génère sa réponse.
Avantages : Plus flexible (peut consolider plusieurs sources : ERP + WMS + Excel), réponses plus rapides, le LLM peut indexer des documents non structurés (emails fournisseurs, comptes rendus de réunion).
Inconvénients : Les données ne sont pas strictement temps réel (dépend de la fréquence de mise à jour du Data Warehouse). Infrastructure plus complexe.
Adapté à : PME qui veulent une interface unifiée sur plusieurs sources de données, ou dont l'ERP n'a pas d'API directe.
Architecture 3 : LLM + Text-to-SQL
Fonctionnement : Le LLM traduit la question de l'utilisateur en une requête SQL, qui est exécutée directement sur la base de données ERP. Le résultat SQL est renvoyé au LLM qui le présente de manière lisible.
Avantages : Accès direct à toutes les données de la base, sans API. Très puissant pour les requêtes analytiques.
Inconvénients : Nécessite que le LLM comprenne le schéma de données de l'ERP (noms des tables, relations). Risque de sécurité si le modèle peut exécuter des requêtes destructives (DELETE, UPDATE). Requiert un accès en lecture seule bien sécurisé.
Adapté à : Équipes avec des compétences techniques internes ou un prestataire data, ERP avec une base de données SQL accessible.
Quel schéma choisir pour une PME ? Pour une PME sans équipe data interne, l'Architecture 1 (LLM + API ERP) via un outil SaaS clé en main est souvent le meilleur compromis. L'Architecture 2 (Data Warehouse) est pertinente dès que vous avez plusieurs sources à consolider. L'Architecture 3 (Text-to-SQL) convient aux PME avec un DSI ou un prestataire technique disponible.
Les prérequis côté données
Documenter le schéma métier
Le LLM doit comprendre que dans votre ERP, la table "ARTICLE" contient les fiches produits, que le champ "DLV" correspond au délai fournisseur, et que "QTR_STK" est la quantité en stock. Sans cette documentation (appelée "contexte" ou "prompt system"), le modèle répondra à côté.
Préparer un dictionnaire de données métier est une bonne pratique indépendamment de l'IA : il documente votre patrimoine de données et facilite l'intégration.
Gérer la fraîcheur des données
Les données qui servent à répondre aux questions supply chain doivent être à jour. Un stock mis à jour une fois par semaine dans le Data Warehouse donnera des réponses périmées sur les niveaux de stock en temps réel.
Pour les données sensibles au temps (stocks, commandes en cours, alertes), une mise à jour quotidienne est le minimum. Pour les données stables (fiches fournisseurs, nomenclatures), une mise à jour hebdomadaire suffit.
La sécurité et les droits d'accès
Le LLM ne doit pas avoir accès à des données sensibles (marges, salaires, informations stratégiques) accessibles à tous les utilisateurs. La gestion des droits d'accès doit être pensée au niveau du Data Warehouse ou de l'API, pas au niveau du LLM.
Comment démarrer avec un budget limité
L'approche minimale viable
Pour une PME avec peu de ressources techniques, l'approche la plus accessible est d'utiliser un outil SaaS supply chain qui inclut une interface conversationnelle native. Certains logiciels de gestion des stocks intègrent déjà un assistant en langage naturel connecté à leurs données.
Cette approche ne nécessite pas d'intégration technique : l'outil supply chain accède à ses propres données, le LLM est fourni par l'éditeur.
Le développement progressif
Si vous voulez une solution sur mesure, démarrer par un périmètre limité : connecter le LLM uniquement aux données de stock et de commandes en cours, sur les 100 références les plus critiques. Valider la qualité des réponses, ajuster le prompt système, puis élargir progressivement.
Éviter de vouloir tout connecter d'emblée. Un LLM qui répond bien sur un périmètre limité est plus utile qu'un LLM qui répond approximativement sur tout.
Les outils disponibles
Les principaux LLM (GPT-4, Claude, Gemini) sont tous accessibles via API. Les coûts d'API pour un assistant supply chain utilisé quotidiennement par une équipe de 5 personnes sont de l'ordre de quelques dizaines d'euros par mois. Le coût principal est le développement de l'intégration.
Ce qu'il faut retenir
- Connecter un LLM à un ERP permet une interface conversationnelle sur les données métier. Les 3 architectures principales : LLM + API ERP, LLM + Data Warehouse (RAG), LLM + Text-to-SQL.
- Le choix dépend des ressources techniques disponibles et de la complexité souhaitée. Pour une PME sans équipe data, un outil SaaS avec assistant intégré est le meilleur départ.
- Prérequis essentiels : dictionnaire de données métier, fraîcheur des données adaptée au cas d'usage, gestion des droits d'accès.
- Démarrer par un périmètre limité (stock + commandes, 100 références critiques) et élargir progressivement.
- Le coût d'API est marginal (quelques dizaines d'euros/mois). Le coût principal est l'intégration initiale.
Prêt à faire évoluer votre supply chain ?
