L'ERP à l'ère des agents IA : pourquoi le protocole MCP change la donne

Des API à la conversation : un nouveau mode d'accès à l'ERP

Pendant vingt ans, intégrer un logiciel de gestion à un autre outil supposait d'écrire du code : appeler une API REST, gérer l'authentification, parser les réponses, maintenir le tout à chaque évolution. Cette approche reste solide, mais elle exclut de fait tous les utilisateurs qui ne sont pas développeurs.

L'arrivée des agents IA — ChatGPT, Claude, Cursor et leurs équivalents — change la donne. Ces assistants ne se contentent plus de répondre à des questions : ils peuvent agir, c'est-à-dire déclencher des opérations dans un système tiers. Pour qu'un agent crée un devis, lise un stock ou planifie une intervention dans un ERP, il lui faut un langage commun avec ce logiciel. C'est précisément le rôle du protocole MCP.

Le protocole MCP, en clair

Le MCP (Model Context Protocol) est un protocole ouvert qui standardise la connexion entre un modèle de langage et des sources de données ou des outils externes. On le compare souvent à un « port universel » : plutôt que de réinventer une intégration sur mesure pour chaque assistant, un éditeur expose une seule fois ses capacités via un serveur MCP, et n'importe quel agent compatible peut s'y connecter.

Concrètement, un serveur MCP publie une liste d'outils (tools). Chaque outil décrit une action possible — « créer un client », « lister les factures impayées », « consulter le tableau de bord » — avec ses paramètres attendus. L'agent IA découvre cette liste, choisit l'outil pertinent en fonction de la demande de l'utilisateur, le remplit et reçoit le résultat structuré.

Comment ça marche concrètement

Un utilisateur écrit dans son assistant : « Crée un devis de 1 500 € pour le client Durand et envoie-le. » L'agent :

1. Découvre les outils exposés par le serveur MCP de l'ERP.
2. Sélectionne l'outil de création de devis et déduit les paramètres du message.
3. Appelle l'outil via le serveur, qui exécute l'opération comme le ferait l'interface web.
4. Restitue une confirmation lisible et, le cas échéant, le lien vers le document.

L'atout majeur : ces outils peuvent être générés automatiquement à partir de la spécification OpenAPI de l'ERP. Chaque route documentée devient un outil exploitable par l'agent, sans réécriture manuelle. eyeot adopte cette logique : son serveur MCP dérive ses outils de l'API existante et achemine chaque appel à travers la même pile que l'interface — préservant authentification, périmètre de données et journal d'audit.

Authentification : ouvrir l'ERP aux agents sans baisser la garde

Donner à une IA les clés d'un système de gestion soulève immédiatement une question de sécurité. Un ERP contient des données financières, RH et clients : l'accès agentique ne peut pas s'appuyer sur un simple mot de passe partagé.

Le standard qui s'impose est [OAuth](/glossaire/oauth) 2.1, avec plusieurs modes adaptés au contexte :

• Authorization Code + PKCE : l'utilisateur s'authentifie dans son navigateur et autorise explicitement l'agent. Le jeton délivré est de courte durée et renouvelable.
• Device Grant : pensé pour les agents en ligne de commande ou les applications sans navigateur intégré (un assistant de bureau, par exemple). L'utilisateur valide l'accès sur un autre écran.
• Clés d'API émises par l'organisation, au périmètre maîtrisé, pour les intégrations de service.

Dans tous les cas, le principe reste le même : l'agent hérite des permissions de l'utilisateur qui l'a autorisé, jamais davantage. Un assistant connecté au compte d'un commercial ne pourra pas consulter la paie. Cette cohérence repose sur un contrôle d'accès fin, appliqué à chaque requête, et sur la multi-location stricte des données.

Les garde-fous indispensables d'un ERP agentique

Un agent IA est puissant mais faillible : il peut mal interpréter une consigne, répéter une action, ou agir trop vite. Un ERP prêt pour l'IA doit donc intégrer des mécanismes de sécurité conçus pour ce nouveau mode d'usage.

Idempotency : ne pas créer deux fois la même facture

Si un agent renvoie une requête après un délai réseau, il risque de dupliquer une opération — deux factures, deux commandes. La parade est l'idempotency : l'agent joint un identifiant unique (Idempotency-Key) à chaque requête sensible. Si le serveur reçoit deux fois la même clé, il renvoie le résultat initial sans réexécuter l'action. Une seule facture est créée, quoi qu'il arrive.

Dry-run : simuler avant d'écrire

Avant de valider une opération à fort impact, il est précieux de pouvoir prévisualiser ses effets sans rien modifier. Le mode dry-run (souvent un en-tête X-Dry-Run) exécute la logique métier, capture ce qui aurait changé — mutations, notifications, déclenchements — puis annule tout. L'agent peut ainsi annoncer « voici ce que cette action va produire » avant de demander une confirmation finale.

Audit et RBAC : traçabilité et permissions

Chaque action déclenchée par un agent doit être tracée comme n'importe quelle action humaine : qui, quoi, quand, depuis quel jeton. Un journal d'audit horodaté — idéalement chaîné cryptographiquement — garantit qu'aucune opération automatisée n'échappe au contrôle. Côté droits, le [RBAC](/glossaire/multi-tenant) filtre en amont ce que l'agent peut faire. Pour les décisions automatisées touchant des personnes, le cadre du RGPD (notamment l'article 22) impose par ailleurs de garder un humain dans la boucle.

À ces garde-fous s'ajoute une logique de lecture seule par défaut : un agent peut consulter et informer librement, tandis que les opérations d'écriture restent conditionnées à une autorisation active. Une frontière nette entre « lire » et « agir ».

Cas d'usage concrets

Une fois l'ERP rendu pilotable par IA, les usages se multiplient :

• Reporting conversationnel : « Quel est mon chiffre d'affaires du mois et mes impayés ? » sans ouvrir le moindre tableau de bord.
• Saisie assistée : dicter une opportunité, un client ou un ticket à l'oral, l'agent structurant l'information.
• Orchestration cross-module : relier devis, stock et facturation en une seule consigne, en s'appuyant sur l'intelligence cross-module de l'ERP.
• Connexion à l'écosystème : combiner l'ERP à d'autres outils via des intégrations déclenchées par l'agent.

L'objectif n'est pas de remplacer l'interface, mais d'offrir un canal supplémentaire, plus rapide pour certaines tâches répétitives ou exploratoires.

Découvrir eyeot

eyeot est un ERP français pensé pour cette nouvelle génération d'usages : son serveur MCP expose les opérations métier aux agents compatibles, avec authentification OAuth, idempotency, mode dry-run et journal d'audit intégrés. L'accès agentique respecte les mêmes permissions et la même isolation que l'interface web.

Si vous souhaitez expérimenter le pilotage d'un ERP depuis votre assistant favori, le compte particulier gratuit ouvre l'accès à tous les modules pour un utilisateur, sans carte bancaire, pour éprouver l'outil en conditions réelles.