Comment connecter ChatGPT à son ERP en 2026 ?
L'ERP est le seul système qui sait vraiment ce qui se passe dans l'entreprise : ce qui est commandé, produit, facturé, payé. C'est aussi, dans la plupart des PME, le système le moins agréable à interroger — écrans denses, requêtes qui passent par le contrôle de gestion, rapports qui arrivent le 10 du mois. L'idée de poser une question en français et d'obtenir la réponse a donc quelque chose d'évident. Techniquement, c'est désormais faisable. La difficulté n'est plus de faire fonctionner la démo, mais de construire quelque chose qui tienne en production, sans ouvrir une brèche dans le système le plus sensible de l'entreprise.
Pourquoi vouloir connecter l'IA à son ERP
Interroger les données en langage naturel. « Combien de commandes en retard chez Dupont ? », « Quelles références sont sous le seuil de réappro ? », « Quel est le délai moyen de règlement sur les six derniers mois ? ». Ces questions ont toutes une réponse dans l'ERP et demandent aujourd'hui soit une navigation experte, soit une demande à quelqu'un d'autre. C'est le cas d'usage le plus simple à mettre en œuvre et celui qui produit l'adhésion la plus rapide, parce qu'il supprime une friction que tout le monde ressent.
Automatiser des tâches multi-écrans. Créer un devis suppose de vérifier un client, retrouver une grille tarifaire, contrôler une disponibilité, générer un document. Relancer un impayé suppose de croiser facturation, historique client et échéancier. Ces enchaînements sont coûteux non par leur difficulté mais par leur dispersion. Un assistant qui les orchestre fait gagner des minutes plusieurs fois par jour — mais on entre ici dans l'écriture, avec les exigences de contrôle que ça implique.
Accélérer le reporting ad hoc. Le rapport mensuel standard existe. C'est la question hors format qui coûte cher : un croisement inhabituel, une segmentation nouvelle, une hypothèse à vérifier avant un comité. Ces demandes finissent souvent en exports Excel retravaillés à la main, ou ne sont jamais posées.
Assister le support ERP interne. Dans beaucoup de PME, une ou deux personnes concentrent la connaissance fonctionnelle de l'outil et passent une part réelle de leur temps à répondre aux mêmes questions de paramétrage. Un assistant nourri de la documentation et des procédures internes absorbe le premier niveau — cas d'usage souvent négligé, alors qu'il est le moins risqué de tous : ni écriture, ni données clients.
Les trois architectures possibles
1. Le plugin du fournisseur ERP
Les éditeurs proposent tous leur assistant intégré — SAP avec Joule, Sage, Cegid, Odoo et les autres à des degrés divers de maturité. L'IA est activée depuis la console d'administration, elle connaît nativement le modèle de données et hérite du système de droits existant.
Le bénéfice est la vitesse : quelques jours de paramétrage plutôt qu'un projet. L'intégration est cohérente, supportée, et la responsabilité en cas de problème est claire.
Les limites sont l'envers exact de ces avantages. Vous êtes lié au modèle choisi par l'éditeur, à son rythme de mise à jour, à sa feuille de route fonctionnelle et à sa politique tarifaire — souvent un module additionnel facturé par utilisateur. Les cas d'usage couverts sont ceux que l'éditeur a jugés prioritaires pour l'ensemble de sa base clients, rarement les vôtres en particulier. Et si vous exploitez plusieurs systèmes, chaque éditeur pousse son assistant : vous vous retrouvez avec trois assistants qui ne se parlent pas.
2. Le connecteur via MCP ou API custom
Un serveur intermédiaire, que vous hébergez, expose au modèle un ensemble restreint de fonctions ERP : get_commandes_client, get_stock_reference, creer_devis. Le modèle appelle ces fonctions, le serveur vérifie les droits, interroge l'ERP et renvoie un résultat cadré.
C'est l'architecture la plus flexible. Vous choisissez le modèle et pouvez en changer. Vous décidez exactement ce qui est exposé et à qui. Vous couvrez vos cas d'usage réels plutôt que ceux du catalogue. Vous pouvez brancher plusieurs systèmes derrière la même interface. Et en passant par MCP plutôt qu'une API propriétaire, le travail reste portable.
Le coût est réel : il faut construire ce serveur, ou en acheter un et l'adapter. Comptez quelques semaines pour un périmètre de lecture bien défini, davantage dès qu'il y a écriture. Il faut aussi l'exploiter — supervision, mises à jour, suivi des évolutions de l'API ERP. C'est un composant de production, pas un script.
3. Le RAG sur les exports ERP
Approche la plus légère : vous exportez périodiquement des extractions de l'ERP — quotidiennement, par exemple — vous les indexez dans une base vectorielle, et le modèle interroge cet index. Aucune connexion directe au système de production.
Simple, peu coûteux, sans aucun risque d'écriture accidentelle, et implémentable en quelques jours avec des briques existantes. Pour de l'analyse, de la recherche documentaire ou des questions sur des données qui ne bougent pas d'heure en heure, c'est largement suffisant.
Le prix à payer est la fraîcheur. Vos réponses ont l'âge du dernier export, ce qui disqualifie l'approche pour tout ce qui touche au stock temps réel ou à un statut de commande en cours. La modélisation relationnelle se perd aussi partiellement dans la vectorisation : les questions impliquant des jointures complexes ou des agrégats précis donnent des résultats moins fiables qu'une requête. Un chiffre approximativement juste est parfois pire que pas de chiffre du tout.
En pratique, ces trois options ne s'excluent pas. Une trajectoire fréquente et saine : démarrer en RAG sur les exports pour valider les usages et la demande réelle des équipes, puis basculer les cas d'usage qui ont fait leurs preuves vers un connecteur temps réel. On investit là où la valeur est démontrée plutôt que sur une intuition.
Les questions de sécurité
Authentification : au nom de qui ? C'est la première question à trancher et elle est structurante. Deux modèles. Un compte de service unique : simple à mettre en place, mais toutes les actions apparaissent sous la même identité, ce qui ruine la traçabilité et impose que ce compte cumule tous les droits nécessaires — un point de compromission majeur. Ou une délégation d'identité : le connecteur agit au nom de l'utilisateur connecté, via OAuth ou équivalent. Plus complexe, nettement plus sain. Sur un périmètre de lecture non sensible, le compte de service peut se défendre. Dès qu'il y a écriture ou données personnelles, la délégation n'est pas négociable.
Permissions : l'IA hérite ou décide ? La règle : l'assistant ne doit jamais pouvoir donner accès à ce que l'utilisateur ne pourrait pas atteindre lui-même dans l'interface. Ça paraît évident et c'est régulièrement raté — un connecteur configuré avec un compte administrateur laisse un commercial obtenir la marge sur un dossier ou une donnée RH, simplement en posant la question autrement. Le contrôle appartient au connecteur, pas au prompt : une consigne système demandant au modèle de ne pas divulguer certaines informations n'est pas un mécanisme de sécurité.
Journalisation. Chaque appel doit laisser une trace exploitable : qui, quand, quelle fonction, quels paramètres, quel résultat. En lecture, c'est votre capacité à répondre à une question de conformité. En écriture, c'est la condition pour reconstituer ce qui s'est passé le jour où un devis part avec un tarif aberrant. La journalisation applicative de l'ERP ne suffit pas : elle enregistre l'action, pas l'intention ni la formulation qui l'a produite.
Données sensibles dans les prompts. Tout ce qui remonte au modèle sort de votre périmètre si le modèle est hébergé chez un tiers. La parade est en amont : le connecteur ne renvoie que les champs strictement nécessaires à la question, filtre ou masque les identifiants personnels quand ils ne servent pas au raisonnement, et plafonne le volume retourné. « Renvoie la fiche client complète » est un anti-pattern ; « renvoie le nom, le montant et l'échéance » est une décision d'architecture. Pour les périmètres les plus sensibles, un modèle auto-hébergé supprime la question — au prix d'une infrastructure à opérer.
Coûts à prévoir
Ordres de grandeur, à recaler selon votre contexte et le périmètre réellement couvert.
PME, 30 à 50 utilisateurs, périmètre lecture. Consommation modèle par API : quelques dizaines à quelques centaines d'euros par mois selon l'intensité d'usage — bien en dessous d'un abonnement par siège pour un usage occasionnel, potentiellement au-dessus pour des utilisateurs très actifs. Infrastructure du connecteur : un serveur modeste, de l'ordre de 50 à 150 € mensuels. Intégration initiale : entre 15 et 40 k€ selon le nombre de fonctions exposées et l'accessibilité de l'API ERP. Run annuel — maintenance, évolutions, supervision : compter 15 à 25 % de l'investissement initial.
ETI, plusieurs centaines d'utilisateurs, lecture et écriture. L'intégration initiale se situe plutôt entre 60 et 150 k€, avec les postes qui pèsent réellement : gestion fine des permissions, intégration à l'IAM existant, recette fonctionnelle sérieuse sur les cas d'écriture. La consommation modèle devient significative et mérite un suivi par cas d'usage. Le run annuel se professionnalise : supervision, astreinte, gestion des évolutions ERP.
Deux postes systématiquement sous-estimés. La qualité des données d'abord : si les référentiels sont sales, l'assistant restituera fidèlement ce désordre, et le travail de remise en ordre n'était pas dans le budget. L'accompagnement ensuite : formation, documentation des usages, définition de ce qu'on peut et ne peut pas demander. Un connecteur techniquement irréprochable que personne n'utilise a un ROI nul.
Le piège classique : confondre pilote et production
Le scénario se répète avec une régularité déprimante. Un développeur motivé branche un modèle sur une base de test, produit en deux jours une démo qui répond correctement à cinq questions métier. La démonstration au comité de direction est un succès, un déploiement est annoncé. Six mois plus tard, rien n'est en production.
Ce qui s'est passé : la démo tournait sur un jeu de données propre et restreint, sans gestion des droits, sans authentification nominative, sans journalisation, sans traitement des cas limites, sans supervision, sans reprise sur erreur, sans documentation. Elle ne validait qu'une chose — que le modèle sait formuler une requête et présenter un résultat. Ce n'est pas rien, mais c'est peut-être 10 % du travail. Les 90 % restants sont exactement ce qui différencie un prototype d'un système sur lequel on prend des décisions.
Trois pratiques évitent ce cycle. Nommer le pilote pour ce qu'il est : un test d'appétence et de faisabilité, pas un produit à 90 %. Le dire explicitement au moment de la démo évite de créer une attente qu'on ne pourra pas tenir. Choisir un premier périmètre restreint et complet plutôt que large et bancal : une seule famille de questions, exposée à un vrai groupe d'utilisateurs, avec authentification, droits et logs en place. Un usage en production vaut mieux que dix en démonstration. Mesurer l'usage réel dès le premier jour — nombre de requêtes, utilisateurs actifs, taux de réponses jugées utiles. C'est le seul argument qui tienne pour arbitrer la suite, dans un sens comme dans l'autre.
Aller plus loin
Pour cadrer le bon scénario d'intégration pour votre ERP, voyez la page Connecteurs IA. Un audit IA permet d'identifier les cas d'usage qui valent l'effort.