Le MCP d’Odoo : ce qu’il voit, ce qu’il ne voit pas

Depuis quelques mois, la question revient à chaque rendez-vous : « Odoo va sortir son connecteur MCP, est-ce que ça ne règle pas le problème ? » La réponse honnête est : en partie, et moins qu’on ne le croit. Ce qui suit explique ce que le MCP d’Odoo expose réellement, ce qu’il ne pourra pas exposer quelle que soit sa qualité, et pourquoi la différence décide de ce que vous devrez construire.

Ce qu’est un MCP, sans jargon

Un modèle de langage ne sait rien de votre entreprise. Pour agir, il lui faut deux choses : la liste de ce qu’il peut faire, et le moyen de le faire. Le Model Context Protocol est une convention qui décrit exactement cela — un logiciel publie ce qu’il sait faire, un modèle le découvre et s’en sert, sans qu’on ait écrit de code de liaison entre les deux.

L’analogie la plus juste est celle d’une prise de courant. Avant, chaque appareil arrivait avec son propre branchement ; il fallait un adaptateur par paire. Une prise normalisée ne rend pas les appareils meilleurs — elle supprime l’adaptateur. C’est le service que rend un MCP, et c’est déjà considérable : un agent peut interroger votre Odoo sans qu’on ait développé un connecteur pour lui.

Ce qu’il expose réellement — et c’est beaucoup

Il faut dire les choses clairement, parce que l’inverse se raconte souvent : l’ORM d’Odoo décrit lui-même sa propre structure, et vos développements spécifiques y figurent dès leur installation. Un module qui ajoute un champ à une ligne de commande inscrit ce champ dans les tables de description du modèle, au même titre que les champs natifs. Rien ne le distingue techniquement.

Un agent branché sur cette introspection obtient donc, pour chaque modèle : le nom technique des champs, leur libellé, leur type, les relations vers d’autres modèles, les valeurs possibles d’une liste de sélection, le caractère obligatoire ou non, et l’éventuel texte d’aide. Il peut lire, filtrer, écrire, dans la limite des droits qu’on lui accorde.

Ne comptez donc pas sur l’argument « le MCP ne verra pas votre spécifique ». Il le verra. Quiconque vous dit le contraire n’a pas regardé, et votre DSI s’en apercevra en dix minutes.

Trois champs de statut, et un seul qui fait foi

Voici la situation que nous rencontrons dans presque tous les Odoo qui ont plus de trois ans. Sur une même ligne de commande coexistent :

• le champ de statut natif, celui d’Odoo, qui suit le cycle standard de la commande ;
• un champ ajouté en 2022 par un développement spécifique, pour suivre un état que le standard ne portait pas à l’époque ;
• un troisième, arrivé avec un module tiers, qui recouvre en partie le deuxième.

Les trois existent, les trois sont renseignés, les trois sont parfaitement visibles dans l’introspection. Aucune information technique ne dit lequel fait foi. Et pourtant vos équipes le savent — sans jamais l’avoir écrit : depuis la montée de version, c’est le natif qui décide, le champ de 2022 n’est plus alimenté que par une automatisation qu’on n’a pas osé couper, et le troisième ne sert qu’à un export mensuel.

C’est cela, la différence entre le schéma et le sens. Le schéma dit : « il y a trois champs de statut ». Le sens dit : « celui-ci fait foi, les deux autres sont des vestiges, et voici ce qui se casse si tu écris dedans ».

Ce qu’un agent fait de faux, et pourquoi c’est pire qu’une erreur

Demandez à un agent bien connecté mais mal renseigné : « quelles commandes sont en attente de livraison ? » Il choisira un champ. Probablement celui dont le nom ressemble le plus à la question — le spécifique de 2022, justement, parce qu’il s’appelle quelque chose comme « statut de livraison ». Il produira une liste. La liste sera cohérente, bien formatée, et fausse.

Le problème n’est pas l’erreur : c’est qu’elle ne se voit pas. Un agent qui échoue franchement se corrige. Un agent qui répond juste neuf fois sur dix, et faux la dixième sans le signaler, détruit la confiance plus vite qu’il ne crée de valeur — et il la détruit pour tous les usages suivants.

Ce qu’il faut construire par-dessus

Entre le schéma et le sens, il manque une couche. Elle n’a rien de mystérieux, et elle ne s’achète pas : elle s’écrit, à partir de ce que vos équipes savent. Elle dit quel champ fait foi pour quelle question, quelles écritures sont permises et lesquelles demandent une relecture humaine, quelles règles métier ne figurent nulle part dans la base, et quels vestiges il faut ignorer.

Cette couche n’est pas une documentation : une documentation se périme en silence. C’est une description exécutable, versionnée avec votre Odoo, testée comme le reste. Et il n’y a que deux façons de l’obtenir : connaître Odoo assez pour lire la base, et connaître votre entreprise assez pour savoir ce qu’elle veut dire.

La conséquence économique, qui est la vraie raison de cet article

Les plateformes d’IA se remplacent vite. Celle que vous choisirez cette année ne sera probablement pas celle que vous utiliserez dans deux ans : les modèles changent, les prix s’effondrent, les protocoles se normalisent. Tout ce que vous aurez investi dans une plateforme se rejouera à chaque changement.

La couche de sens, elle, ne change pas quand la plateforme change. Elle décrit votre entreprise, pas votre fournisseur.

C’est le seul actif durable de cette histoire, et c’est pour cela qu’il vaut mieux qu’il vous appartienne. Le connecteur, lui, finira par être fourni — par Odoo, par un éditeur, par la normalisation. Ce n’est pas là que se joue la valeur.

Ce que nous en faisons

Nous intégrons Odoo et nous construisons des agents autour : c’est la même équipe qui lit la base et qui écrit la couche de sens, ce qui évite le tour de table où l’intégrateur explique au spécialiste de l’IA ce que veut dire un champ. Et nous le disons d’emblée : certaines tâches disparaîtront. Mieux vaut le savoir au démarrage qu’à la livraison.