Page mise à jour le
Ce que l'API permet
Ce que Odoo expose réellement
Repris de la documentation publique de l'éditeur, pas d'une plaquette commerciale. Le lien vers cette documentation est en bas de page.
Les mêmes objets que dans l'écran
Partenaires, commandes de vente, factures, articles, mouvements de stock, employés : ce que le module installe, l'API l'expose. On cherche, on lit, on crée, on confirme une commande avec la même action que le bouton de l'interface. L'intérêt n'est pas d'avoir « une API ». C'est que la règle de gestion — un stock insuffisant, une facture déjà comptabilisée — s'applique aussi à l'agent. Il se prend les mêmes refus qu'un humain, et c'est souhaitable.
Les droits du compte, pas un super-accès
Chaque appel s'exécute avec les droits de l'utilisateur de la clé. Un commercial ne voit pas la paie ; un agent branché sur son compte non plus. Pour un usage continu, Odoo recommande un utilisateur dédié, sans mot de passe de connexion, avec le minimum de droits. C'est plus de travail au départ, et c'est le seul réglage qui limite la casse si la clé fuit. Une clé sur le compte administrateur est une dette, pas une commodité.
Une action métier plutôt qu'une série de rustines
La documentation insiste sur un point trop souvent ignoré : chaque appel vit dans sa propre transaction. Confirmer une commande puis créer une facture en deux temps, c'est s'exposer à ce qu'un autre utilisateur change le dossier entre les deux. On appelle l'action métier qui fait les deux, ou on la fait écrire. Un agent qui enchaîne des mini-gestes « comme à l'écran » sur un ERP concurrent est un agent qui corrompt des stocks.
Une documentation qui dépend de *votre* base
Les modèles disponibles varient d'une base à l'autre, selon les applications et les modules. Odoo pointe vers la page de documentation dynamique de l'instance, pas vers un catalogue universel. Avant d'automatiser, on ouvre cette page sur *votre* Odoo. Promettre « on se branche sur les factures » sans avoir vu les champs du module comptable installé, c'est vendre un Odoo qui n'existe pas.
External JSON-2 API — documentation Odoo 19.0 (nouvel onglet) — Consultée le 21-08-2026. Accès API externe réservé aux offres Custom. Clé d'une durée maximale de trois mois. XML-RPC / JSON-RPC prévus pour retrait en Odoo 22 (automne 2028).
Trois automatisations concrètes
Ce qu'on met en place avec
Trois situations réelles, décrites comme du travail plutôt que comme de la technique.
Créer la commande là où le stock se tient
Un devis signé ailleurs — mail, boutique, formulaire — devient une commande Odoo, avec les articles du catalogue, pas une ligne libre. L'agent s'arrête si l'article n'existe pas, s'il est archivé, ou si le client n'a pas de conditions de paiement. Vous confirmez. Le stock et la facturation partent du même objet. Recréer la commande dans un tableur « en attendant Odoo » est exactement ce qu'on cherche à tuer.
Facturer les commandes livrées, pas les commandes oubliées
L'agent liste les commandes livrées non facturées, prépare la facture via l'action prévue par Odoo, et vous la présente. Une commande partiellement livrée n'est pas facturée comme une commande complète. Les acomptes déjà émis se voient sur le partenaire. C'est du travail d'administration des ventes, pas de la magie : Odoo le fait déjà, mal, quand personne n'ouvre la liste le vendredi.
Tenir les partenaires à jour sans double saisie
Un nouveau client dans le CRM, un changement d'adresse, un SIRET corrigé : l'agent met à jour le partenaire Odoo, ou le crée s'il n'existe pas, sans écraser une adresse de livraison distincte de l'adresse de facturation. Les doublons évidents se signalent. Odoo est strict sur les contacts ; un agent qui fusionne trop tôt mélange commandes et compta. On signale, on ne fusionne pas en silence.
Limites
Ce que cette intégration ne fera pas
Les contraintes qu'on rencontre pour de vrai. Les découvrir maintenant coûte une lecture ; les découvrir en cours de projet coûte le projet.
Pas d'API externe sur One App Free ni Standard
La documentation Odoo 19, lue le 21 août 2026, l'écrit : l'accès à l'API externe n'est disponible que sur les offres Custom, pas sur One App Free ni Standard. C'est une limite de contrat, pas un oubli de configuration. Si votre Odoo cloud est en Standard, le projet s'arrête là ou change d'offre. On le vérifie avant le premier devis d'intégration, parce que « on verra avec l'éditeur » n'est pas un planning.
Une clé qui expire, et qu'on ne revoit plus
Odoo impose une durée maximale de trois mois à une clé, et n'affiche sa valeur qu'une fois, à la création. Un agent en production a donc un calendrier de rotation, pas une clé « pour toujours » dans un fichier. Oublier de tourner la clé, c'est une automatisation qui meurt un lundi matin sans message clair. On le prévoit, on le teste, on ne le découvre pas à l'échéance.
Les anciens accès distants sont en sursis
Les anciens protocoles d'accès encore vus sur des bases anciennes sont documentés comme devant disparaître avec Odoo 22, annoncé pour l'automne 2028. Un projet neuf s'appuie sur l'API actuelle, JSON-2. Un projet ancien se planifie une migration, pas un « ça marche encore ». Brancher un agent sur un accès déjà daté, c'est acheter un travail à refaire dans deux ans.
Ce que brancher Odoo demande vraiment
On vérifie l'offre, on crée un utilisateur dédié avec le minimum de droits, on génère une clé courte, on lit la documentation dynamique de la base. Ensuite on choisit *une* action métier à automatiser — pas « tout Odoo ». Un ERP se branche par le bord, une commande ou une facture, pas par le centre. Les modules custom du partenaire intégrateur se recensent : ils ajoutent des champs que l'agent doit connaître, ou des blocages que l'écran ne montre pas.
Sources
Chaque affirmation de cette page renvoie au texte qui fait foi. En cas d'écart entre cette page et la source, c'est la source qui a raison.
- External JSON-2 API — Odoo 19.0 (nouvel onglet)
Source de la restriction d'offre (Custom uniquement) et de la durée maximale des clés. Consultée le 21-08-2026.
Vos questions
On a Odoo Standard : peut-on quand même automatiser ?
Pas via l'API externe, d'après la documentation 19 lue le 21 août 2026. Il reste des chemins moins propres : export programmé, module sur mesure installé *dans* la base, saisie manuelle. Aucun de ces chemins n'est « l'API Odoo ». Si l'automatisation justifie un passage en Custom, c'est un arbitrage de contrat avec l'éditeur, pas un réglage que l'intégrateur active. On ne commence pas le développement en espérant que le plan change en cours de route.
Faut-il un module sur mesure en plus de l'API ?
Souvent oui, dès que le geste métier n'existe pas en une seule action — réserver du stock, facturer un abonnement atypique, pousser une commande vers un WMS. L'API appelle ce qui est déjà là. Ce qui n'est pas là s'écrit en module, se teste, se documente. C'est pour ça que cette page pointe vers le développement sur mesure plutôt que vers un agent générique. Un agent qui contourne Odoo en écrivant dans les tables n'est pas un agent, c'est une dette.
Quelle version viser pour un projet neuf ?
La 19, avec l'API JSON-2, parce que c'est celle que l'éditeur documente comme le présent, et parce que les anciens protocoles ont une date de fin. Une base encore en 16 ou 17 se traite comme un héritage : on automatise ce qui est stable, on ne s'appuie pas sur ce qui va être retiré, et on inscrit la montée de version dans le même projet si l'horizon est court. Deux projets séparés — automatiser, puis migrer — coûtent plus cher qu'un seul, mal cadré.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.