Connecter un agent IA à un ERP consiste à lui donner, par API, un accès contrôlé aux données de gestion (clients, articles, stocks, commandes, factures) et à un nombre limité d'actions d'écriture, chacune validée selon une règle. Le travail se joue à 20 % dans le modèle et à 80 % dans la couche d'intégration : droits, formats, journalisation, gestion des erreurs. Reste à décrire cette couche : les trois façons de la construire, et ce qui a été fait sur des projets JUWA.
Ce que l'agent demande à l'ERP, et comment
Un agent moderne ne « lit » pas l'ERP comme un humain. Le modèle de langage reçoit une liste d'outils, des fonctions décrites en langage naturel avec leurs paramètres, et décide d'en appeler une quand la tâche l'exige. C'est le mécanisme d'appel de fonctions documenté par OpenAI et par Anthropic. L'agent ne voit jamais la base : il voit rechercher_commande(numero), lister_factures_impayees(client, depuis), creer_bon_de_livraison(commande). Chaque outil est un point d'entrée que vous avez écrit, avec les contrôles que vous avez décidés.
La conséquence est rassurante pour une direction : le périmètre de l'agent est exactement la liste des outils exposés. Un agent sans outil d'écriture ne peut rien modifier, quoi qu'on lui demande. Ce point distingue l'agent du copilote et du chatbot ; l'article sur les exemples d'agents IA en PME montre sept périmètres réels.
Résumé de la vidéo (en anglais) : Barry Zhang, de l'équipe Applied AI d'Anthropic, décrit comment cadrer les outils exposés à un agent, pourquoi rester simple, et comment penser du point de vue de l'agent pour anticiper ses erreurs.
Trois façons de construire la couche d'intégration
| Approche | Comment ça marche | Quand la retenir | Limite |
|---|---|---|---|
| Connecteur direct par API de l'ERP | Des fonctions écrites sur l'API native (REST, XML-RPC, GraphQL) de l'ERP | ERP avec API documentée (Odoo, Sage, Dynamics, SAP), équipe capable de maintenir du code | Une fonction par action, à maintenir à chaque montée de version |
| Plateforme d'automatisation (n8n, Make) | Des scénarios qui exposent les actions de l'ERP à l'agent via des webhooks | Premier projet, volumes modestes, peu de développeurs | Dépendance à la plateforme, latence, débogage difficile au-delà de quelques dizaines de scénarios |
| Serveur MCP | Un serveur qui décrit les outils dans un protocole standard, consommable par plusieurs agents et plusieurs modèles | Plusieurs agents ou plusieurs modèles doivent partager les mêmes accès | Standard récent, à encadrer par les mêmes règles de droits que les autres approches |
Le Model Context Protocol normalise la description des outils et leur appel, ce qui évite de réécrire les connecteurs pour chaque modèle. Sur un ERP open source comme Odoo, l'API externe XML-RPC documentée par l'éditeur suffit pour la première approche ; la troisième devient intéressante quand le deuxième agent arrive. Le choix entre n8n et Make est traité dans le comparatif Make et n8n.
Les droits : un compte technique par agent, pas le compte de l'administrateur
La première erreur rencontrée sur le terrain est de faire tourner l'agent avec les identifiants d'un administrateur, « pour aller vite ». L'agent hérite alors de tous les droits, y compris ceux qu'il n'utilisera jamais, et une instruction mal formée peut produire une écriture que personne n'avait prévue. La règle est simple : un compte technique dédié par agent, avec les seuls droits nécessaires aux outils exposés, en lecture sur ce qu'il consulte, en écriture sur ce qu'il modifie, rien d'autre. Ce principe de moindre privilège figure en tête du Top 10 OWASP des risques de sécurité des API, dont les deux premières entrées portent sur des autorisations mal contrôlées au niveau des objets et des fonctions.
Concrètement, chaque outil d'écriture porte une règle de validation : montant plafond, liste de champs modifiables, obligation d'un accord humain au-delà d'un seuil. L'agent qui prépare un bon de livraison le crée en statut brouillon ; la validation reste à l'humain tant que l'équipe n'a pas constaté, sur des dizaines de cas, que l'agent ne se trompe pas.
Les données : ce que l'ERP contient et ce qu'il ne contient pas
Un ERP contient des données structurées, propres en apparence, et pourtant l'agent bute souvent sur trois choses. Les doublons (deux fiches pour le même client), les champs libres utilisés comme fourre-tout, et les codes internes que personne n'a documentés. Avant d'exposer un outil de recherche client, il faut décider comment l'agent tranche entre deux fiches proches, et lui donner un référentiel des codes. Sans ce travail, il choisit au hasard avec assurance.
À l'inverse, beaucoup d'informations utiles ne sont pas dans l'ERP : conditions négociées par email, notices produits, historique des litiges. Un agent qui doit répondre à un client sur un délai a besoin de l'ERP pour la commande et d'une base documentaire pour les conditions. C'est la combinaison décrite dans le guide connecter vos outils métier à l'IA par API, et la raison pour laquelle un projet ERP finit souvent par inclure un RAG.
Journalisation, erreurs et reprise
Chaque appel d'outil est journalisé avec la demande d'origine, les paramètres, la réponse de l'ERP et la décision prise. Ce journal sert à trois choses : auditer ce que l'agent a fait, mesurer où il se trompe, et prouver la conformité au regard du RGPD quand des données personnelles sont manipulées, selon les fiches pratiques IA de la CNIL. Sans journal, un agent qui a créé cinquante commandes erronées un dimanche n'est découvert que le lundi, sans moyen de savoir lesquelles.
Les erreurs de l'ERP (API indisponible, champ obligatoire manquant, verrou sur une fiche) doivent être renvoyées à l'agent sous une forme qu'il comprend, avec une consigne : réessayer, demander à un humain, abandonner. Un agent qui reçoit une erreur brute la réinterprète et invente parfois une solution. L'écriture de ces consignes fait partie de la couche d'intégration au même titre que les outils.
Ce que ça donne sur des projets JUWA
Chez une PME industrielle aéronautique, l'agent de vérification des bons de commande lit les documents entrants, interroge l'ERP achats sur la commande correspondante et compare ligne à ligne. Il n'écrit rien : il produit une liste d'écarts que l'acheteur traite. Cette architecture en lecture seule a suffi pour récupérer 317 heures par mois sur 1 900 paires de documents mensuelles, et c'est souvent le bon premier périmètre.
Chez un éditeur SaaS, les quatre agents livrés en 12 jours sont orchestrés par un composant écrit en Laravel, la stack backend du client, et branchés à ses données par des outils dédiés. Le choix d'écrire l'orchestrateur dans le langage déjà maîtrisé par l'équipe interne a évité toute dépendance à une plateforme tierce et rendu le handover immédiat.
Dans les deux cas, le cadrage a d'abord listé les outils à exposer, avec pour chacun le droit nécessaire et la règle de validation, avant d'écrire une ligne de code. C'est ce que JUWA livre en premier sur un projet d'intégration de l'IA au système d'information : la carte des connecteurs, les comptes techniques, le journal, puis l'agent.
La check-list avant de brancher un agent sur l'ERP
- Liste des outils exposés, avec pour chacun lecture ou écriture, paramètres et règle de validation.
- Un compte technique par agent, droits limités aux outils listés, rotation des clés.
- Référentiel des codes internes et règle de désambiguïsation des doublons.
- Journal de chaque appel, consultable par le métier, conservé selon la durée légale des données concernées.
- Consignes de gestion d'erreur écrites pour l'agent : réessayer, escalader, abandonner.
- Environnement de test isolé de la production, avec un jeu de cas réels anonymisés.
- Premier périmètre en lecture seule ou en écriture brouillon, passage en écriture validée après mesure.
