Connecter une IA aux outils métier de l’entreprise

Le POC réellement développé

Kodeva a construit un serveur MCP en .NET et ASP.NET Core, relié à l’API REST de Dolibarr. Le Model Context Protocol expose à un assistant compatible un catalogue d’outils clairement définis, au lieu de lui ouvrir un accès général à l’application.

Le connecteur opérationnel permet actuellement, en lecture seule, de :

• rechercher des entreprises et consulter la fiche d’un tiers ;

• rechercher des contacts ;

• rechercher des projets ;

• rechercher des propositions commerciales ;

• rechercher des factures.

Un scénario concret

Un utilisateur peut demander à son assistant de retrouver une entreprise, puis de rechercher les propositions commerciales ou les factures qui la concernent. L’assistant choisit l’outil MCP adapté, le serveur interroge Dolibarr et renvoie un résultat structuré que l’assistant peut reformuler. Ce scénario reste volontairement en lecture : le POC ne crée et ne modifie encore aucune donnée.

Une architecture découplée

Utilisateur → assistant IA compatible MCP → outils métier autorisés → serveur MCP Kodeva → API REST Dolibarr.

Cette séparation évite de lier le connecteur à un modèle précis. Elle facilite aussi la réutilisation des outils et l’ajout futur d’autres sources métier.

Pourquoi MCP dans ce contexte ?

MCP sert ici de contrat entre l’assistant et les applications. Chaque outil possède un rôle limité et des paramètres définis. L’assistant ne reçoit ni identifiant de tenant ni clé Dolibarr : le serveur détermine l’organisation à partir de l’identité authentifiée et charge la configuration correspondante côté serveur.

MCP ne garantit toutefois pas, à lui seul, la sécurité. Le POC complète ce cadre par une authentification JWT compatible Keycloak, un endpoint MCP protégé, une isolation par organisation et des outils limités à la lecture. Les autorisations fines par outil, la validation humaine des écritures et la journalisation d’audit font partie des évolutions à construire avant d’ouvrir des actions sensibles.

LLM local et confidentialité

Le serveur MCP est indépendant du LLM : il peut être relié à différents assistants compatibles. Cette séparation permet d’étudier un déploiement avec un LLM local lorsque l’entreprise souhaite mieux maîtriser l’hébergement et les flux de données, ou conserver certains traitements dans son infrastructure.

À ce stade, aucun LLM local n’est intégré ni validé dans le dépôt audité. Il s’agit d’une perspective de sécurité et d’architecture, qui devra être testée selon les modèles retenus, les données manipulées et les contraintes d’hébergement.

Des bénéfices métier à mesurer

Cette approche peut permettre d’interroger des données métier en langage naturel, de réduire certaines recherches manuelles et de créer des assistants spécialisés sans remplacer les logiciels existants. Le POC valide le socle technique ; il ne revendique pas encore de gain de temps ou de retour sur investissement mesuré.

L’objectif n’est pas de remplacer le logiciel métier, mais de permettre à l’IA de travailler avec lui. Le projet mobilise les savoir-faire Kodeva en développement .NET, API, intégration ERP/CRM, sécurité applicative, automatisation et IA.