Module 1 — Fondamentaux du MCP

Avant d’installer quoi que ce soit, il faut comprendre ce que MCP résout et où se situe le paquet mcp-server-odoo dans cette architecture — sans cela, les choix de configuration du module suivant (notamment le fameux mode YOLO) n’auront aucun sens.

Le problème : l’intégration M×N

Un assistant IA (Claude, un agent, un chatbot d’entreprise) devient réellement utile quand il peut agir sur des données réelles : lire une facture Odoo, créer un contact, chercher un produit. Sans standard commun, chaque paire (assistant, système) nécessite une intégration sur mesure :

Claude Desktop <-> connecteur maison -> Odoo
Cursor          <-> connecteur maison -> Odoo
Agent interne   <-> connecteur maison -> Odoo
Claude Desktop  <-> connecteur maison -> Salesforce
...

Avec N systèmes (Odoo, Salesforce, GitHub, une base SQL…) et M assistants (Claude Desktop, Cursor, un agent applicatif…), on obtient potentiellement M × N intégrations à écrire et maintenir, chacune avec ses propres conventions d’authentification, de format de données et de gestion d’erreurs.

Le Model Context Protocol (MCP), créé par Anthropic et publié comme standard ouvert, remplace ce problème M×N par un problème M + N : chaque système expose une seule fois ses capacités via un serveur MCP, et chaque assistant n’a besoin d’implémenter le protocole qu’une seule fois pour parler à n’importe quel serveur MCP.

Claude Desktop  \                    / Serveur MCP Odoo    -> Odoo
Cursor           >--- protocole MCP -
Agent interne   /                    \ Serveur MCP GitHub  -> GitHub

Vocabulaire MCP

MCP définit trois rôles :

Host : l’application avec laquelle l’utilisateur interagit (Claude Desktop, Claude Code, LibreChat…). C’est elle qui héberge le modèle de langage et décide, tour après tour, quels outils appeler.
Client MCP : le composant, intégré à l’host, qui maintient une connexion 1:1 avec un serveur MCP et parle le protocole (JSON-RPC 2.0 sur la connexion choisie).
Serveur MCP : le programme qui expose les capacités d’un système donné — dans notre cas, mcp-server-odoo expose les capacités d’une instance Odoo.

Un serveur MCP peut exposer deux grandes catégories de capacités :

Tools : des fonctions appelables par le modèle, avec des paramètres et un effet (lire, chercher, créer, modifier, supprimer un enregistrement…). Ce sont les “verbes” du protocole.
Resources : des données adressables par une URI, que l’host peut aller lire à la demande (l’équivalent de “noms” plutôt que de “verbes”) — par exemple odoo://res.partner/record/42.

Les deux transports

Le protocole MCP peut circuler sur deux types de canaux, selon où tourne le serveur par rapport à l’host :

Transport	Usage typique	Fonctionnement
`stdio`	Serveur lancé localement, en sous-processus de l’host (ex. Claude Desktop qui lance `uvx mcp-server-odoo` sur la machine de l’utilisateur)	Les messages JSON-RPC transitent sur l’entrée/sortie standard du processus
`streamable-http`	Serveur qui tourne à distance ou dans un conteneur séparé, joignable par une URL réseau (ex. `http://mcp_odoo_server:8000/mcp` dans une stack Docker)	Les messages JSON-RPC transitent sur des requêtes HTTP, avec un flux de réponse (streaming)

C’est un choix important dès la mise en place : un usage individuel avec Claude Desktop sur son propre poste utilisera plutôt stdio, tandis qu’une architecture Docker Compose partagée (comme celle de ce cours) utilisera streamable-http, seul transport qui traverse un réseau de conteneurs.

Où se situe `mcp-server-odoo` ?

mcp-server-odoo est un serveur MCP écrit en Python (par ivnvxd) : c’est un pont entre le protocole MCP et une instance Odoo existante, qu’il interroge via son API standard (XML-RPC). Il expose des tools comme search_records, get_record, create_record, update_record, delete_record, ou encore call_model_method, ainsi que des resources adressables comme odoo://{model}/record/{id} ou odoo://{model}/search.

Un point d’architecture essentiel, qui structure tout le reste de ce cours : ce serveur peut fonctionner avec ou sans un module Odoo dédié installé côté serveur :

Sans module Odoo (mode dit YOLO) : le serveur parle directement à Odoo en XML-RPC avec un couple utilisateur/mot de passe classique. Rapide à mettre en place, mais sans aucun contrôle d’accès par modèle — l’assistant IA a accès à tout ce que l’utilisateur Odoo authentifié peut voir.
Avec le module mcp_server installé dans Odoo : ce module ajoute une couche de sécurité côté Odoo — liste blanche de modèles autorisés, clés d’API dédiées, journal d’audit, limitation de débit. C’est le mode recommandé pour un usage au-delà de la démonstration personnelle.

Cette distinction (détaillée au Module 4) explique pourquoi la configuration ODOO_YOLO n’est pas un simple raccourci technique, mais un vrai choix de posture de sécurité.

Ce que ce cours va construire

Ce cours accompagne un projet complet, disponible sur GitHub, dans lequel nous allons :

Démarrer une stack Docker (Odoo 16 + PostgreSQL + serveur MCP) en mode YOLO pour aller vite (Module 2).
Écrire un client Python qui dialogue avec ce serveur via le SDK officiel MCP et exercer ses tools sur des données réelles (Module 3).
Comprendre en détail le module Odoo mcp_server et sa couche de sécurité (Module 4).
Basculer la même stack vers ce mode sécurisé (Module 5).
Brancher une interface de chat (LibreChat) sur ce serveur MCP (Module 6).
Conclure sur les bonnes pratiques de sécurité pour un déploiement réel (Module 7).

Prochaine étape

👉 Module 2 : Démarrage rapide en mode YOLO