Le mois dernier, sur une instance Odoo 19 d'un client qui fait de la distribution, on a vu remonter dans les logs un avertissement qu'on n'avait jamais croisé : les endpoints /xmlrpc, /xmlrpc/2 et /jsonrpc sont dépréciés. Rien ne cassait, tout tournait. Mais c'est exactement le genre de ligne qu'on a appris à ne pas ignorer, parce que le connecteur qui la déclenche, lui, finira par s'arrêter un jour. En l'occurrence, c'était le module qui synchronise les commandes depuis leur boutique en ligne.
Cet avertissement, beaucoup d'intégrateurs et d'éditeurs de connecteurs le voient remonter en ce moment. Il annonce un changement de fond dans la façon dont les systèmes tiers parlent à Odoo. Le XML-RPC, qui sert de colonne vertébrale aux intégrations Odoo depuis la version 6.1, est sur la sellette. Son remplaçant s'appelle la JSON-2 API, et il est arrivé avec Odoo 19.
Ce que faisait XML-RPC, et pourquoi Odoo veut le retirer
Pendant des années, à peu près toutes les intégrations Odoo passaient par là. Un script Python qui importe des articles, un connecteur Prestashop, une passerelle vers un WMS, un export comptable vers un outil tiers : tout ça appelait execute_kw sur l'endpoint XML-RPC pour lire et écrire dans les modèles Odoo. C'est robuste, c'est documenté, ça marche depuis quinze ans.
Le problème, c'est que XML-RPC montre son âge. Le protocole renvoie systématiquement un code HTTP 200, même quand la requête échoue, ce qui oblige à décortiquer le corps de la réponse pour savoir si l'appel a réussi (oduist, novembre 2025). L'authentification repose sur le couple identifiant utilisateur plus mot de passe transmis à chaque appel. Et le XML reste verbeux à parser, sans compter qu'avec PHP 8 l'extension XML-RPC n'est même plus disponible par défaut (documentation Odoo 19.0).
JSON-RPC, qui existe depuis la version 8, partageait les mêmes services sous-jacents (common, db, object) et hérite des mêmes limites. Les deux sont aujourd'hui dépréciés ensemble.
Ce que la JSON-2 API change concrètement
La nouvelle API expose une route /json2 et fonctionne en HTTP standard, avec des en-têtes pour l'authentification et une URL de base cohérente. Elle se distingue du vieux monde sur trois plans, et chacun répond à un point de douleur connu.
D'abord, l'authentification passe par un bearer token plutôt que par le mot de passe utilisateur transmis en clair à chaque requête (Apideck, mars 2026). On peut créer des « service users » avec un token dédié par cas d'usage, ce qui veut dire qu'on coupe l'accès d'un connecteur sans toucher aux autres. Pour qui gère plusieurs intégrations sur une même base, c'est un vrai gain de propreté.
Ensuite, JSON-2 renvoie des codes HTTP qui veulent dire quelque chose : un 404 quand la ressource n'existe pas, un 500 sur erreur serveur, au lieu du 200 universel de XML-RPC. Vos scripts de monitoring vont enfin pouvoir détecter un échec sans parser le contenu de la réponse.
Enfin, chaque base Odoo génère désormais une documentation vivante à l'adresse /doc. On y navigue dans les champs, on voit les méthodes publiques, on filtre par modules installés (y compris vos modules custom) et on copie des exemples de code prêts à l'emploi (oduist, « XMLRPC is dead »). Attention quand même : exécuter un appel depuis cette interface tape sur votre base de production, pas sur un bac à sable.
Un point qui ne change pas, et c'est important : les permissions restent basées sur l'utilisateur, pas sur l'endpoint. Vous ne pouvez pas régler finement les droits appel par appel. Ce sont toujours les règles d'enregistrement et les ACL d'Odoo qui s'appliquent. Le modèle de sécurité ne se réinvente pas, il se réauthentifie autrement.
Le calendrier, où ça devient confus
Voilà le point sur lequel un intégrateur peut vraiment vous éviter une mauvaise surprise, parce que les sources se contredisent.
Fin 2025, à peu près tout le monde annonçait la même échéance : suppression des endpoints XML-RPC et JSON-RPC dans Odoo 20, à l'automne 2026. C'est ce qu'on lit chez Apideck, chez oduist, et c'est même la raison invoquée dans une issue ouverte sur le connecteur Odoo de n8n, où un utilisateur s'inquiète que le node continue d'appeler les vieux endpoints condamnés (issue GitHub n8n, novembre 2025). La version française de la documentation Odoo 19 reprend d'ailleurs encore cette date.
Sauf que la documentation Odoo 19 en anglais, elle, raconte autre chose. Elle annonce désormais une suppression repoussée à Odoo 22 (automne 2028), avec une étape intermédiaire sur Odoo Online en 21.1 (hiver 2027) (documentation Odoo 19.0). Autrement dit, l'échéance couperet a glissé de deux ans entre la communication initiale et la doc à jour, et la traduction française n'a pas suivi.
Notre lecture, en tant que praticiens : on ne se fie pas à une date qui circule sur des blogs de fin 2025, on se fie à la doc anglaise tenue à jour. Le retrait n'est donc pas pour cet automne. Mais la dépréciation, elle, est bien réelle dès la 19, et l'avertissement dans les logs ne va pas disparaître. Le bon réflexe n'est pas de migrer dans la panique, c'est de planifier la bascule sur les douze à dix-huit mois qui viennent, en commençant par les connecteurs les plus critiques.
Qui doit s'en préoccuper, et dans quel ordre
Si vous avez des scripts d'import en masse maison, ce sont eux qu'on regarderait en premier : ils sont souvent écrits une fois, oubliés, et personne ne se souvient de qui les maintient. Un connecteur e-commerce du commerce (Prestashop, Shopify, WooCommerce) dépend de son éditeur, qui devra publier une version compatible JSON-2. Le cas n8n montre que même des outils populaires traînent encore sur les vieux endpoints. Les passerelles EDI et les scripts de migration de données entrent dans la même catégorie.
Un détail pratique sur le rate limiting : la JSON-2 API n'impose pas de quota propre, mais votre hébergeur, lui, peut brider les gros volumes. Un import de plusieurs milliers d'appels d'affilée a toutes les chances d'être ralenti (oduist, novembre 2025). Ça vaut le coup de tester un import volumineux en conditions réelles avant de basculer un flux de production.
Si vous démarrez une intégration neuve aujourd'hui sur Odoo 19, le choix est simple : partez sur JSON-2 directement. Inutile de construire sur une fondation déjà condamnée. Pour une intégration qui doit rester compatible avec des versions plus anciennes (14 à 18), XML-RPC reste le plus universel, le temps que le parc se mette à jour.
Côté code Odoo cette semaine
Semaine plutôt calme sur le dépôt public odoo/odoo, hors le flot habituel de traductions. Un commit retient quand même l'attention, et il rejoint le thème du jour : les changements silencieux qui peuvent casser du custom.
Owl 3 commence à essaimer dans le front
Le 28 mai, un commit de refactoring a remplacé les appels reactive à un seul argument par des appels proxy, signe que la bascule du framework front d'Odoo (Owl) vers sa version 3 progresse sur master 00f830f. Le changement touche une douzaine de modules d'un coup, dont web, website, website_sale, le point de vente et l'éditeur de contenu. Concrètement, si vous maintenez des composants JavaScript sur mesure qui s'appuient sur ces primitives de réactivité, c'est le genre d'évolution à tester sérieusement avant de migrer vers une future version 20. Ça ne casse rien sur une instance standard, mais du code tiers mal aligné sur la nouvelle API peut se mettre à dysfonctionner sans message d'erreur clair.
Rien de neuf côté l10n_fr
Sur la localisation française, pas de commit notable cette semaine dans la fenêtre des sept derniers jours. C'est le calme avant la prochaine vague, vu tout ce qui se prépare autour de la facturation électronique pour l'automne.
Vous avez des connecteurs ou des scripts qui parlent à Odoo en XML-RPC et vous vous demandez ce qu'il faut anticiper ? Parlons-en.