XML-RPC en sursis : migrer vos intégrations Odoo vers l'API JSON-2

Si vous maintenez une intégration qui parle à Odoo depuis un ERP tiers, une marketplace, un script de synchronisation ou un connecteur no-code, il y a de fortes chances qu'elle passe encore par /xmlrpc/2 ou /jsonrpc. Ces deux portes d'entrée sont désormais marquées comme dépréciées dans Odoo 19, et l'éditeur pousse ouvertement vers une remplaçante, l'API JSON-2 ¹. Le sujet paraît lointain tant que tout fonctionne. Il cesse de l'être le jour où une montée de version casse la connexion en silence.

Ce qui est confirmé

Les endpoints historiques /xmlrpc, /xmlrpc/2 et /jsonrpc sont dépréciés à partir d'Odoo 19 ². Concrètement, ils continuent de répondre, mais ils génèrent des avertissements dans les logs serveur à chaque appel. L'équipe de n8n a d'ailleurs ouvert un ticket public parce que son nœud Odoo déclenche ces warnings sur les instances 19 ². Le message est clair : ces routes vivent en sursis.

La remplaçante s'appelle JSON-2. Elle change plusieurs choses de fond dans la façon d'appeler un modèle Odoo à distance.

• L'URL porte le modèle et la méthode. On appelle /json/2/<model>/<method> au lieu d'empaqueter tout dans un corps générique ¹.
• L'authentification passe par une clé d'API, transmise dans l'en-tête Authorization: bearer. Le couple login plus mot de passe disparaît de la boucle d'appel ¹.
• Tous les arguments sont nommés. Il n'existe aucun moyen d'appeler une méthode avec des arguments positionnels en JSON-2 ¹.
• Les codes HTTP redeviennent significatifs. Là où l'ancienne API renvoyait un statut 200 même en cas d'erreur applicative, JSON-2 remonte des 404, 422, 500 selon le cas réel ¹.

Ce dernier point mérite une pause. Avec XML-RPC, un client mal écrit pouvait considérer une réponse comme un succès alors que le serveur signalait une erreur dans le corps du message. Avec JSON-2, un dépassement de limite renvoie par exemple un HTTP 422, et une clé révoquée un HTTP 403 ³. Votre couche d'appel peut enfin distinguer un vrai succès d'un échec sans parser le contenu à la main.

Ce qui reste à préciser

La date de suppression effective n'est pas figée de la même manière selon les sources. Le ticket n8n indique une suppression planifiée dès Odoo 20 ². D'autres lectures de la feuille de route décrivent plutôt un mode hérité maintenu pendant Odoo 20, avec un retrait repoussé à une version ultérieure, souvent citée autour d'Odoo 22 ⁴. Odoo 20 est attendu à l'Odoo Experience de Bruxelles, prévue du 24 au 26 septembre 2026 ⁴.

Je retiens la lecture prudente. Traitez la dépréciation comme une horloge qui tourne, sans miser sur une échéance précise. Le coût de la migration ne change pas selon qu'elle tombe en 2026 ou en 2028 ; ce qui change, c'est le confort de la faire avant que quelque chose casse en production.

Comment aborder la migration côté praticien

Le premier réflexe utile ne demande pas une ligne de code. Chaque base Odoo 19 expose une documentation vivante et générée automatiquement à l'adresse /doc de l'instance ¹. Vous y parcourez les modèles installés, leurs champs, les méthodes publiques exposées, avec des exemples d'appel prêts à copier. C'est le meilleur point de départ pour vérifier quelles méthodes votre intégration utilise réellement et si elles sont bien disponibles côté JSON-2.

Ensuite, la conversion suit un schéma assez mécanique. Un appel execute_kw sur res.partner avec la méthode search_read devient une requête POST sur /json/2/res.partner/search_read, avec un corps JSON où domain, fields, limit et context sont tous nommés. La clé d'API se crée depuis les préférences utilisateur d'Odoo et remplace l'authentification par mot de passe. Le gain n'est pas seulement réglementaire. Un appel qui renvoie un vrai code HTTP simplifie votre monitoring et vos retries.

Un tableau aide à cadrer l'effort.

Le piège le plus courant concerne les connecteurs tiers que vous n'avez pas écrits. Un module de synchronisation e-commerce, un middleware de facturation ou un outil d'automatisation embarque parfois sa propre couche RPC. Vous ne migrez pas seulement votre code ; vous dépendez du rythme de mise à jour de chaque éditeur tiers. Le ticket n8n illustre exactement ce décalage : l'outil continuait d'appeler les endpoints dépréciés bien après leur signalement ².

Notre lecture

Cette dépréciation n'est pas un événement, c'est un audit à programmer. Avant toute chose, listez tout ce qui parle à vos instances Odoo par RPC, y compris les scripts oubliés et les connecteurs achetés. Interrogez le /doc de votre base pour confirmer la disponibilité JSON-2 des méthodes concernées. Puis migrez d'abord les intégrations que vous maîtrisez de bout en bout, et ouvrez un ticket chez vos éditeurs tiers pour le reste.

Le passage à JSON-2 apporte un bénéfice concret au-delà de la conformité de version : des codes HTTP honnêtes et une authentification par clé rendent vos intégrations plus faciles à surveiller et à sécuriser. Autant profiter de la contrainte pour nettoyer une couche d'appel qui, souvent, traîne depuis plusieurs versions. La fenêtre exacte de retrait reste discutée, mais aucune de ses versions ne rend l'attente rentable.

Sources

• External JSON-2 API, documentation Odoo 19.0 : https://www.odoo.com/documentation/19.0/developer/reference/external_api.html
• Issue n8n « Odoo Node still uses deprecated RPC endpoints (Odoo 19+) » : https://github.com/n8n-io/n8n/issues/21545
• External RPC API, documentation Odoo 19.0 : https://www.odoo.com/documentation/19.0/developer/reference/external_rpc_api.html
• Odoo 20 Preview 2026, OBS Solutions : https://www.odoo-bs.com/blog/global-5/odoo-20-preview-493