Stack · API
Les API d'Odoo : XML-RPC, JSON-RPC, REST
Odoo expose son ORM, pas une API métier. C'est une force — tout est accessible — et un piège : rien ne vous empêche d'écrire la requête qui met la base à genoux.
Odoo n’expose pas une API métier. Il expose son ORM — c’est-à-dire ses modèles, ses champs et ses méthodes, tels quels. Tout ce qu’un utilisateur peut faire dans l’interface, un appel peut le faire, avec les mêmes droits.
C’est une architecture ouverte, cohérente et documentée. C’est aussi un fusil chargé : rien ne vous empêche d’écrire, en trois lignes, l’appel qui immobilise un worker pendant deux minutes.
Ce qui est exposé
Deux protocoles natifs et stables : XML-RPC et JSON-RPC. Ils donnent accès aux opérations de l’ORM — rechercher, lire, créer, écrire, supprimer, et appeler les méthodes des modèles.
Concrètement, on manipule des modèles (sale.order, product.product, stock.quant) et non des ressources abstraites. C’est plus direct qu’une API REST, et moins guidé : rien ne vous dit qu’un champ est calculé, coûteux, ou qu’il déclenche une cascade d’écritures.
Ce qui n’est pas exposé
Il n’y a pas de webhook sortant. Odoo ne prévient personne quand quelque chose change. C’est la lacune la plus structurante pour une intégration : le monde extérieur doit interroger, ou bien il faut construire le mécanisme de notification.
Nous le construisons quand la réactivité l’exige — une file d’événements dans un module dédié, consommée par le système cible. Mais ce n’est pas une case à cocher, c’est un développement, avec sa maintenance.
L’utilisateur technique : non négociable
Un connecteur ne doit jamais s’authentifier avec le compte d’un humain, ni avec l’administrateur.
| Mauvaise pratique | Pourquoi c’est grave |
|---|---|
| Compte administrateur | Le connecteur peut tout écrire ; une erreur devient un incident global |
| Compte d’un salarié | Les traces attribuent les écritures à quelqu’un qui n’a rien fait |
| Mot de passe en clair dans le code | Il finira dans un dépôt Git, c’est mécanique |
La bonne pratique tient en une phrase : un utilisateur technique dédié, une clé d’API, les droits strictement nécessaires, le secret hors du dépôt. Le jour d’un audit, on sait exactement ce que le connecteur a écrit.
La volumétrie : où ça casse
Il n’existe pas de limite de débit. Personne ne vous arrêtera : c’est votre base qui pliera.
Les erreurs que nous voyons le plus :
- Lire tous les champs alors que trois suffisent. Sur un modèle large, la différence est d’un ordre de grandeur.
- Lire des champs calculés non stockés en masse. Chacun déclenche un calcul par enregistrement — c’est le tueur silencieux.
- Filtrer côté client. Ramener 50 000 lignes pour en garder 12 : le filtre appartient au serveur.
- Écrire ligne par ligne. Créer 5 000 enregistrements en 5 000 appels prend des heures ; par lots, des minutes.
- Synchroniser en pleine journée. Un balayage complet à 14 h ralentit tout le monde, et personne ne fait le lien.
Ce que nous faisons
- Utilisateur technique + clé d’API, droits minimaux, secrets hors dépôt.
- Lectures ciblées, filtrées côté serveur, paginées.
- Écritures par lots, avec transaction et reprise.
- Traitements lourds hors heures ouvrées.
- Un module Odoo distinct pour la file d’événements quand la réactivité l’impose.
Les limites, dites franchement
Pas de webhook natif : la réactivité se paie. Soit en fréquence d’interrogation, soit en développement. Il n’y a pas de troisième voie.
L’ORM impose de connaître le modèle. Un champ mal compris produit des données fausses qui passent inaperçues des mois. C’est pour ça que nous documentons le mapping champ par champ, et que nous le faisons relire.
La performance dépend de votre base, pas d’une moyenne. Les chiffres se mesurent chez vous : voir performance.
Pour l’usage concret de ces API, voir les connecteurs.
Questions fréquentes
Odoo a-t-il une API REST ?
Pas au sens classique dans le cœur. Odoo expose son ORM en XML-RPC et JSON-RPC, ce qui est plus puissant et moins guidé qu’une API REST : vous n’appelez pas des ressources métier, vous appelez des modèles et des méthodes. Une façade REST peut être ajoutée par module quand un partenaire l’exige.
Odoo peut-il notifier un système externe ?
Pas nativement. Il n’y a pas de webhook sortant standard. Cela se construit — automatisation qui pousse un appel, ou file d’événements dans un module dédié — mais ça se conçoit, ça ne se coche pas.
Faut-il utiliser le compte administrateur pour l'intégration ?
Non, jamais. Un utilisateur technique dédié, avec une clé d’API et les droits strictement nécessaires. Cela évite qu’un connecteur puisse tout écrire, et surtout : les traces indiquent qui a fait quoi. Un connecteur qui écrit sous l’identité d’un humain rend tout audit impossible.
Quelle volumétrie l'API supporte-t-elle ?
Il n’y a pas de chiffre universel : tout dépend de ce que vous appelez. Lire 10 000 enregistrements sur trois champs est rapide ; en lire 1 000 avec des champs calculés non stockés peut prendre des minutes et saturer un worker. La volumétrie se teste sur votre base, pas sur une brochure.
Comment ne pas écrouler la base ?
En lisant peu et en écrivant par lots. Ne demander que les champs nécessaires, filtrer côté serveur, paginer, éviter les champs calculés dans les lectures de masse, et faire les gros traitements en dehors des heures ouvrées. La plupart des incidents de performance que nous reprenons viennent d’un connecteur qui lit tout, tout le temps.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.