La documentation principale d’Odoo indique que le service RPC hérité de base de données est supprimé dans Odoo 20. Les API XML-RPC et JSON-RPC plus larges sont déconseillées depuis la version 19.0, mais Odoo 20 ne supprime pas tous les services hérités. Odoo documente que les services common et object restent disponibles jusqu’à Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Les équipes d’intégration doivent donc identifier le service utilisé par chaque connexion externe, au lieu de considérer la prise en charge RPC héritée comme une seule fonctionnalité avec une unique date de suppression.
La page de l’événement Americas d’Odoo indiquait qu’Odoo 20 serait publié lors de son événement de San Francisco les 2 et 3 septembre 2026. (Oxp26 Americas Introduction) La planification de la mise à niveau peut dès maintenant prendre en compte la suppression documentée du service de base de données, mais les décisions de production doivent être vérifiées par rapport à la documentation finale de la version 20 d’Odoo.
La suppression concerne un service spécifique
Odoo identifie `/xmlrpc`, `/xmlrpc/2` et `/jsonrpc` comme des points de terminaison hérités déconseillés depuis la version 19.0. Dans ces API, le service de base de données est supprimé dans Odoo 20, tandis que les services common et object doivent rester disponibles jusqu’à Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Une intégration utilisant un service conservé peut continuer à fonctionner après une mise à niveau vers Odoo 20, mais le point de terminaison seul ne garantit pas la compatibilité.
Un système peut utiliser différents services via l’interface RPC héritée. Un examen d’intégration doit donc consigner à la fois le point de terminaison et le service appelé. Décrire une application uniquement comme une intégration XML-RPC ou JSON-RPC ne montre pas si elle dépend d’une opération supprimée dans Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
La disponibilité prolongée des services common et object est temporaire. Odoo prévoit de supprimer les deux dans Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Les équipes peuvent distinguer le travail urgent sur les appels au service de base de données de la migration des services conservés, mais les deux nécessitent un plan.
JSON-2 modifie le contrat de requête
Odoo documente JSON-2 comme l’API de remplacement. Son format de point de terminaison est `/json/2/<model>/<method>`, avec le modèle et la méthode inclus dans l’URL. (Odoo master Docs: Reference External API) La migration implique donc davantage que le simple remplacement du chemin de base dans un client RPC existant. Chaque opération doit être associée à la route de modèle et de méthode appropriée.
JSON-2 exige des arguments nommés dans un corps de requête JSON, plutôt que des arguments RPC positionnels. (Odoo master Docs: Reference External API) Les wrappers existants, les middlewares et les clients générés peuvent supposer que l’ordre des arguments détermine le sens. Ces composants doivent être examinés individuellement. Rediriger une requête héritée vers le nouveau point de terminaison ne fonctionnera pas si le client continue à construire des paramètres positionnels.
Pour chaque opération migrée, les équipes doivent documenter le modèle cible, la méthode et les arguments nommés requis par JSON-2. (Odoo master Docs: Reference External API) Les requêtes doivent ensuite être testées dans l’environnement Odoo 20 concerné, en particulier lorsqu’une bibliothèque d’intégration partagée construit des appels pour plusieurs applications. Des comparaisons statiques de charges utiles ne peuvent pas confirmer la façon dont le serveur ou le client gère la requête complète.
L’authentification doit également changer
JSON-2 utilise une authentification par clé API bearer. (Odoo master Docs: Reference External API) Les travaux de migration doivent couvrir la création des clés, leur stockage sécurisé, la gestion de l'en-tête d'autorisation et le remplacement des clés. Les proxies, les passerelles et les bibliothèques clientes doivent être vérifiés pour s'assurer qu'ils conservent l'en-tête lors du transfert des requêtes. La journalisation, la surveillance et la gestion des erreurs doivent également être examinées afin que les identifiants ne soient pas exposés.
La documentation établit la méthode d'authentification, mais chaque organisation doit déterminer comment les clés API s'intègrent à ses contrôles d'identifiants. (Odoo master Docs: Reference External API) Cela inclut l'attribution des responsabilités pour les clés, le contrôle des endroits où elles peuvent être utilisées et la définition de la manière dont les intégrations concernées seront mises à jour lorsqu'une clé est remplacée.
Les champs binaires ont un changement de compatibilité distinct
Le journal des modifications de l'ORM d'Odoo enregistre un autre changement RPC d'Odoo 20, la représentation des champs binaires ajoute `BinaryValue.filename`. (Odoo master Docs: Orm Changelog) C'est distinct de la suppression du service de base de données, car cela modifie les données renvoyées plutôt que la disponibilité du service. Les applications qui lisent, transforment ou valident des réponses contenant des champs binaires doivent être incluses dans les tests de compatibilité.
Le journal des modifications confirme que le membre `filename` est ajouté, mais son effet pratique dépend du client. (Odoo master Docs: Orm Changelog) Les tests doivent vérifier si les schémas stricts, les sérialiseurs, les comparaisons de réponses et les transformations en aval acceptent le membre supplémentaire. Les clients qui ignorent les champs inconnus peuvent ne nécessiter aucun ajustement, mais ce comportement doit être vérifié plutôt que supposé.
Comment cadrer l'audit d'intégration
Commencez par identifier les connexions qui utilisent `/xmlrpc`, `/xmlrpc/2` ou `/jsonrpc`, que Odoo signale comme des points de terminaison obsolètes. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) L'inventaire doit couvrir les applications développées en interne, les intergiciels, les processus planifiés et les connecteurs tiers lorsque la configuration ou le code source est disponible. Attribuez un responsable à chaque connexion afin que son objectif et son état puissent être vérifiés.
Ensuite, classez chaque connexion par service hérité. L'utilisation du service de base de données nécessite une remédiation pour Odoo 20, tandis que l'utilisation des services common et object reste documentée comme disponible jusqu'à Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) Cela permet un plan par phases : traiter d'abord l'incompatibilité Odoo 20, puis fixer des dates de migration pour les appels obsolètes restants.
Pour les intégrations qui migrent vers JSON-2, consignez la route `/json/2/<model>/<method>`, les arguments de requête nommés et l'authentification par clé API bearer requise par l'interface de remplacement. (Odoo master Docs: Reference External API) Les cas de test doivent couvrir les requêtes réussies, l'authentification rejetée, les arguments nommés non valides et le traitement par l'application des données renvoyées. Ajoutez des cas pour les champs binaires partout où ces champs apparaissent.
Confirmez le comportement final d'Odoo 20
Les détails de la suppression sont tirés de la documentation développeur master d'Odoo, tandis que le calendrier de publication annoncé provient d'une page d'événement indiquant qu'Odoo 20 serait publié lors de l'événement Americas de septembre 2026. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API; Oxp26 Americas Introduction) Avant le déploiement, les équipes doivent revérifier la documentation de la version Odoo 20 publiée, ainsi que l'édition et la version exactes qu'elles prévoient d'utiliser.
L'utilisation d'un point de terminaison RPC obsolète ne prouve pas en soi qu'une intégration cessera de fonctionner dans Odoo 20, car les services common et object restent documentés comme disponibles jusqu'à Odoo 22. Inversement, un fonctionnement réussi sur une version antérieure n'établit pas la compatibilité d'un appel au service de base de données après sa suppression. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
Liste de contrôle de décision pour la mise à niveau
Avant d'approuver une mise à niveau vers Odoo 20, les décideurs doivent demander un registre des intégrations montrant chaque point de terminaison obsolète, le service appelé, son responsable et la remédiation prévue. Les dépendances au service de base de données doivent avoir un remplacement testé. Les intégrations restant sur les services common ou object doivent avoir une date de migration distincte reflétant leur suppression documentée dans Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
La revue doit confirmer que les implémentations JSON-2 placent le modèle et la méthode dans l’URL, utilisent des arguments JSON nommés et s’authentifient avec une clé API bearer. Lorsque des champs binaires sont présents, les tests doivent tenir compte de l’ajout de `BinaryValue.filename`. (Odoo master Docs: Reference External API; Odoo master Docs: Orm Changelog) Ces vérifications distinguent la suppression immédiate du service de base de données d’Odoo 20 de la suppression ultérieure des autres services hérités restants.