Module 4 — Le module Odoo mcp_server

Le mode YOLO du Module 2 fonctionne sans rien installer côté Odoo, mais il ne distingue aucun modèle : quiconque atteint le serveur MCP a accès à tout ce que l’utilisateur configuré peut voir. Le module Odoo mcp_server referme cette porte en ajoutant une couche de sécurité côté Odoo, entre le serveur MCP et l’ORM.

Ce que le module ajoute

Une fois installé dans Odoo (16.0), le module ajoute :

Un réglage global (Paramètres > MCP Server) : interrupteur maître, limite de requêtes par minute, délai d’expiration, activation de la journalisation.
Une liste blanche de modèles (mcp.enabled.model) : chaque modèle Odoo doit être explicitement activé, avec quatre permissions indépendantes — lecture, création, écriture, suppression.
Des clés d’API : générées sur un utilisateur Odoo (res.users.apikeys), elles remplacent le couple utilisateur/mot de passe utilisé en mode YOLO.
Un journal d’audit (mcp.log) : chaque authentification, accès à un modèle, opération d’écriture ou erreur est tracée, avec purge automatique après une durée configurable.
Deux groupes de sécurité : MCP User et MCP Admin (ce dernier implicitement accordé aux administrateurs système).

La liste blanche de modèles

Le cœur du contrôle d’accès est le modèle mcp.enabled.model : une ligne par modèle Odoo autorisé, avec ses opérations. Conceptuellement :

mcp.enabled.model
├── model_id  -> res.partner   | allow_read=True  allow_write=False allow_create=False allow_unlink=False
├── model_id  -> product.template | allow_read=True  allow_write=True  allow_create=True  allow_unlink=False
└── model_id  -> res.users     -> (absent de la liste = inaccessible)

Avant chaque opération, le contrôleur XML-RPC du module vérifie que le modèle est activé et que l’opération demandée y est autorisée — sinon la requête est rejetée et l’événement est journalisé comme permission_denied. res.users n’apparaissant pas dans la liste ci-dessus, il resterait inaccessible même à un client authentifié par clé API, contrairement à ce que montrait le mode YOLO au Module 3.

Un assistant d’activation en masse (wizard) permet d’activer plusieurs modèles en une fois, en excluant automatiquement les modèles transitoires et les modèles techniques (ir.*, base_*).

Authentification par clé d’API

En mode sécurisé, le client ne se connecte plus avec un mot de passe Odoo, mais avec une clé d’API générée depuis le profil de l’utilisateur Odoo (Mon profil > Comptes développeur > Clés API). Le module valide cette clé via le mécanisme standard d’Odoo (res.users.apikeys._check_credentials), côté REST (en-tête X-API-Key) comme côté XML-RPC.

Point d’implémentation notable : Odoo 16 ne permet pas nativement l’authentification par clé API sur les appels execute_kw du XML-RPC classique. Le module contourne cette limite avec une valeur sentinelle (un mot de passe spécial reconnu par un correctif ciblé de la fonction de sécurité d’Odoo) qui, une fois validée, autorise l’appel avec les droits de l’utilisateur propriétaire de la clé — sans jamais transmettre de mot de passe réel.

Journalisation et limitation de débit

Chaque type d’événement (auth_success, auth_failure, model_access, write_operation, rate_limit, permission_denied, error) est enregistré dans mcp.log, avec troncature automatique des champs texte volumineux et purge quotidienne (tâche planifiée, rétention configurable — 30 jours par défaut).

La limitation de débit fonctionne par utilisateur, avec un cache en mémoire des horodatages de requêtes récentes ; au-delà de la limite configurée (300 requêtes/minute par défaut, 0 = illimité), les requêtes supplémentaires sont rejetées et journalisées comme rate_limit.

YOLO vs mode sécurisé : le tableau qui compte

	Mode YOLO	Mode sécurisé (module `mcp_server`)
Authentification	Utilisateur + mot de passe Odoo	Clé d’API dédiée
Contrôle par modèle	Aucun — tout ce que l’utilisateur peut voir	Liste blanche explicite (`mcp.enabled.model`)
Granularité des permissions	Aucune	Lecture/création/écriture/suppression indépendantes par modèle
Audit	Aucun	Journal `mcp.log` avec purge automatique
Limitation de débit	Aucune	Configurable par utilisateur
Mise en place	Aucun module à installer	Installation du module + configuration
Usage recommandé	Démonstration, développement local	Tout usage au-delà de la démonstration personnelle

Prochaine étape

Le Module 5 installe réellement ce module (depuis une copie locale, jamais publiée) sur la stack du Module 2, active un modèle précis, génère une clé d’API, et rejoue le client du Module 3 pour observer concrètement la différence de comportement.

👉 Module 5 : Basculer en mode sécurisé