Réponse courte : privilégiez OAuth 2.1 quand une personne connecte Claude à Odoo pour son propre travail, et une clé API quand vous configurez un agent fixe, sans humain dans la boucle. Les deux sont légitimes. Ils répondent à des besoins différents, et Cledoo MCP prend en charge les deux nativement. Le reste de cet article explique comment chacun fonctionne réellement, pour que vous puissiez choisir en connaissance de cause.
Quelle est la différence, en une phrase ?
Une clé API Odoo est un identifiant de longue durée rattaché à un utilisateur Odoo précis, générée dans l’onglet Sécurité du compte de cet utilisateur et utilisée à la place d’un mot de passe. Une connexion OAuth 2.1 est un flux de connexion-et-consentement : la personne colle l’URL MCP de votre Odoo dans claude.ai, est redirigée vers un écran de connexion Odoo personnalisé, s’authentifie, et approuve cette connexion précise — aucun secret ne change jamais de mains. Dans les deux cas, Claude finit par détenir un jeton qui lui permet d’appeler Odoo en tant que cet utilisateur, sous ses droits d’accès habituels. La différence porte sur comment le justificatif est créé, qui le détient, et comment on s’en débarrasse ensuite.
Comment fonctionne une clé API Odoo
La documentation officielle d’Odoo sur l’API externe est claire : allez dans vos Préférences → onglet Sécurité du compte, cliquez sur Nouvelle clé API, donnez-lui une description et une durée, et Odoo génère la clé une seule fois — elle “ne peut plus être récupérée ni affichée par la suite”. Ensuite, “la façon d’utiliser les clés API dans vos scripts est simplement de remplacer votre mot de passe par la clé, l’identifiant restant inchangé”. Pour des raisons de sécurité, Odoo plafonne la durée de vie des clés : elles ne peuvent pas être créées pour durer plus de trois mois, donc les intégrations durables doivent être renouvelées périodiquement.
Pour l’accès IA, cela signifie : vous générez une clé sur un utilisateur Odoo précis (souvent un compte de service dédié, parfois le compte d’une vraie personne), vous la collez dans les paramètres de connexion de Cledoo MCP, et Claude s’authentifie ensuite en tant que cet utilisateur. Simple. Un seul champ à remplir. Pas de redirection, pas d’écran de consentement dans le navigateur.
Le compromis est celui de tout secret partagé : la clé est une chaîne de caractères qui peut être copiée, collée dans le mauvais canal Slack, poussée dans un dépôt de code, ou oubliée dans un fichier de configuration après le départ de quelqu’un. La révoquer signifie retourner dans le profil Odoo de cet utilisateur et supprimer la clé — ce qui fonctionne, mais il n’existe pas d’inventaire natif de “quels outils IA détiennent actuellement une clé valide pour cet utilisateur” à moins de le construire soi-même.
Comment fonctionne réellement le flux OAuth 2.1 de Cledoo
La spécification du Model Context Protocol définit elle-même comment les clients IA doivent s’authentifier auprès des serveurs MCP, et c’est explicite : les serveurs MCP sur transport HTTP “DEVRAIENT se conformer à cette spécification”, et les serveurs d’autorisation “DOIVENT implémenter OAuth 2.1 avec des mesures de sécurité adaptées, tant pour les clients confidentiels que publics”. La spécification impose aussi PKCE (Proof Key for Code Exchange) sur chaque flux, car la plupart des clients MCP — dont claude.ai — sont des clients publics incapables de conserver un secret confidentiel.
OAuth 2.1 lui-même, selon le draft IETF, consolide OAuth 2.0 (RFC 6749) et ses bonnes pratiques de sécurité en un seul cadre : plus de grant implicite, plus de grant par mot de passe, et les jetons de rafraîchissement pour les clients publics doivent être liés au client (sender-constrained) ou à usage unique. C’est une base plus stricte et plus sûre que l’OAuth 2.0 “classique”.
Cledoo MCP implémente ce flux nativement, à l’intérieur de votre Odoo.
Concrètement : l’utilisateur colle votre URL https://<votre-instance>/mcp
dans claude.ai, Odoo affiche un écran de consentement personnalisé (“Claude
souhaite accéder à votre Odoo — Approuver / Refuser”), l’utilisateur se
connecte avec ses identifiants Odoo habituels, approuve, et claude.ai reçoit un
jeton limité et révocable — jamais le mot de passe de l’utilisateur, jamais une
clé à copier quelque part. Chaque connexion approuvée apparaît alors sous forme
d’entrée nommée dans les paramètres Odoo de l’utilisateur, et peut être révoquée
à tout moment, instantanément, sans toucher aux identifiants de connexion de
l’utilisateur.
Les compromis qui comptent vraiment
Révocabilité. Avec OAuth, couper l’accès d’un agent IA se fait en un clic sur une connexion listée — le mot de passe et les autres jetons de l’utilisateur restent intacts. Avec une clé API, révoquer l’accès signifie supprimer la clé, et si la même clé a été collée dans trois outils différents, les trois cassent en même temps (ce qui est parfois voulu, parfois non).
Prolifération de secrets. Une clé API est un texte. Elle voyage partout où
on la colle — un fichier .env, un message, une capture d’écran. Les jetons
OAuth sont négociés par connexion et par client ; il n’y a pas de chaîne de
caractères qu’une personne puisse mal manipuler au départ.
Identité et audit. Dans les deux cas, les actions de Claude s’exécutent finalement en tant qu’un utilisateur Odoo, donc les ACL, règles d’enregistrement et droits au niveau des champs d’Odoo s’appliquent quel que soit le mécanisme — cela ne change pas. La différence porte sur comment cette identité a été établie. OAuth rattache l’octroi à un événement de connexion-et-consentement vérifiable ; l’origine d’une clé API dépend de ce dont l’équipe se souvient sur qui l’a générée et quand.
Simplicité de mise en place. Les clés API l’emportent ici. On en génère une, on la colle, c’est fait — pas de redirection, pas d’écran de connexion, utile pour scripter rapidement quelque chose ou quand “l’utilisateur” n’est pas du tout une personne.
Adéquation aux comptes de service. Un agent sans interface — une tâche planifiée, une intégration backend sans humain au clavier pour cliquer sur “approuver” — ne peut pas terminer un écran de consentement OAuth interactif. C’est exactement le cas d’usage pour lequel une clé API est conçue.
Utilisez les clés API quand…
- La connexion n’est pas rattachée à une personne précise — c’est un compte de service ou d’automatisation.
- Personne n’est disponible pour cliquer sur un écran de connexion/consentement (tâches planifiées, appels serveur à serveur).
- Vous avez besoin de quelque chose d’opérationnel dans les deux minutes et gérerez vous-même la rotation.
Utilisez OAuth 2.1 quand…
- Une vraie personne connecte son propre claude.ai à ses propres accès Odoo.
- Vous voulez que chaque agent connecté soit listé, nommé et révocable individuellement.
- Vous préférez que personne n’ait jamais à copier un secret hors d’Odoo.
Les deux ne s’excluent pas
La plupart des déploiements Cledoo MCP finissent par utiliser les deux : OAuth pour les personnes de l’équipe qui parlent à Claude de leur propre pipeline commercial ou de leurs propres tâches, et une clé API pour une intégration automatisée unique qui tourne sans supervision. Cledoo MCP Classic (gratuit, On-Prem/Odoo.sh) embarque les deux mécanismes dès le premier jour — le choix se fait par connexion, pas comme une décision architecturale unique pour toute l’instance. Si vous avez ensuite besoin de restreindre ce qu’un agent connecté en OAuth peut faire au-delà des simples ACL Odoo — lecture seule sur les finances, aucune suppression nulle part — c’est ce qu’apporte la couche de gouvernance de Cledoo MCP Pro en plus, mais les mécanismes d’authentification décrits ici restent les mêmes dans les deux cas.