Connecter Odoo au reste de votre système d'information est rarement « plug-and-play ». Entre les API, la gestion des doublons et les erreurs réseau, une synchronisation mal pensée peut corrompre vos données aussi vite qu'elle les met à jour. Voici une méthode concrète pour construire une intégration fiable, idempotente et observable.
Pourquoi la synchronisation de données pose problème
Dès qu'Odoo doit échanger des données avec un autre outil — une boutique e-commerce, un CRM, un entrepôt de données ou un logiciel métier — on quitte le confort d'une base unique. Chaque système possède son propre modèle de données, ses propres identifiants et son propre rythme de mise à jour. Le piège classique consiste à écrire un script qui « pousse » les enregistrements une fois et fonctionne en démonstration, mais qui échoue dès le premier incident : un timeout réseau, un produit en double, ou un champ obligatoire absent.
Une intégration solide repose sur trois principes non négociables : l'idempotence (rejouer une opération ne crée pas de doublon), la gestion explicite des erreurs (un échec partiel ne doit jamais laisser les données dans un état incohérent) et l'observabilité (on doit pouvoir répondre à « qu'est-ce qui a été synchronisé, quand, et pourquoi ça a échoué ? »).
Choisir le bon point d'entrée : XML-RPC ou JSON-RPC
Odoo expose nativement deux API d'accès externe : XML-RPC et JSON-RPC. Les deux permettent d'authentifier un utilisateur puis d'appeler les méthodes ORM (search_read, create, write, unlink). XML-RPC reste le plus documenté et le plus simple à intégrer depuis Python. Voici le squelette d'une connexion authentifiée :
import xmlrpc.client
URL = "https://votreinstance.odoo.com"
DB = "votre_base"
USER = "integration@exemple.com"
KEY = "cle_api"
common = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/common")
uid = common.authenticate(DB, USER, KEY, {})
models = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/object")
# Lire les clients modifiés depuis hier
clients = models.execute_kw(DB, uid, KEY, 'res.partner', 'search_read',
[[['write_date', '>', '2026-05-28 00:00:00']]],
{'fields': ['id', 'name', 'email', 'ref'], 'limit': 200})
Bonne pratique dès le départ : créez un utilisateur technique dédié avec une clé d'API plutôt que d'utiliser un compte humain. Vous isolez ainsi les droits, vous tracez les actions de l'intégration dans les logs Odoo, et vous évitez qu'un changement de mot de passe ne casse la synchronisation.
Rendre la synchronisation idempotente
C'est le cœur du sujet. La question à se poser n'est pas « comment créer cet enregistrement ? » mais « comment garantir qu'il existe exactement une fois, quel que soit le nombre d'exécutions ? ». La réponse passe par une clé de correspondance stable entre les deux systèmes — souvent un identifiant externe stocké dans un champ dédié (le champ ref sur res.partner, ou un champ personnalisé x_external_id).
Le motif « upsert » devient alors trivial : on cherche d'abord par la clé externe, puis on met à jour si l'enregistrement existe, sinon on le crée.
def upsert_partner(models, db, uid, key, ext_id, vals):
existing = models.execute_kw(db, uid, key, 'res.partner', 'search',
[[['ref', '=', ext_id]]], {'limit': 1})
if existing:
models.execute_kw(db, uid, key, 'res.partner', 'write',
[existing, vals])
return existing[0]
vals['ref'] = ext_id
return models.execute_kw(db, uid, key, 'res.partner', 'create', [vals])
Avec ce schéma, relancer le job après un crash ne produit aucun doublon. C'est aussi ce qui permet de passer sereinement d'une synchronisation complète à une synchronisation incrémentale.
Incrémental plutôt que complet : la synchronisation par delta
Resynchroniser l'intégralité d'une base à chaque exécution ne tient pas à l'échelle : au-delà de quelques milliers d'enregistrements, les temps de traitement explosent et vous saturez l'API. La solution est la synchronisation par delta : ne traiter que ce qui a changé depuis le dernier passage.
Odoo expose deux champs précieux pour cela : write_date (dernière modification) et create_date. En stockant un curseur — l'horodatage de la dernière exécution réussie — vous filtrez ensuite sur write_date > curseur. Pensez à conserver une petite marge de sécurité (quelques minutes) pour absorber les écarts d'horloge entre serveurs, et traitez les enregistrements par pages avec limit et offset afin de ne jamais charger un volume ingérable en mémoire.
Gérer les erreurs sans corrompre les données
Une synchronisation en production rencontrera des erreurs : c'est une certitude, pas une éventualité. Trois familles d'incidents méritent une stratégie distincte. Les erreurs transitoires (timeout, coupure réseau, 503) se traitent par une logique de retry avec back-off exponentiel — on réessaie après 1, puis 2, puis 4 secondes. Les erreurs de données (champ obligatoire manquant, contrainte violée) ne doivent jamais être réessayées indéfiniment : on isole l'enregistrement fautif dans une file d'erreurs et on poursuit le reste du lot. Enfin, les erreurs fatales (authentification refusée, base inaccessible) doivent stopper le traitement immédiatement et alerter.
La règle d'or : un échec sur un enregistrement ne doit jamais bloquer ni corrompre les autres. On isole, on journalise, on continue.
Observabilité : savoir ce qui s'est passé
Une intégration que l'on ne peut pas auditer est une bombe à retardement. À chaque exécution, enregistrez au minimum : la date de début et de fin, le nombre d'enregistrements lus, créés, mis à jour et en échec, ainsi que le détail des erreurs avec leur identifiant externe. Ce tableau de bord, même rudimentaire, transforme une boîte noire en un système diagnosticable. Le jour où un commercial signale « mon client n'apparaît pas dans Odoo », vous répondez en trente secondes au lieu de plonger dans les logs pendant une heure.
En résumé
Une synchronisation fiable avec Odoo tient en quatre piliers : un accès API propre via un utilisateur technique, une logique d'upsert idempotente fondée sur une clé externe stable, un traitement incrémental par delta pour passer à l'échelle, et une gestion des erreurs qui isole les incidents sans propager la casse. Ces principes ne dépendent ni de votre secteur ni du système connecté à Odoo — ils sont universels.
Chez AldenSync, c'est précisément notre métier : concevoir des intégrations Odoo robustes, qui tournent sans surveillance et qui résistent aux imprévus du quotidien. Vous avez un projet de synchronisation, une migration de données ou une intégration multi-systèmes à fiabiliser ? Contactez notre équipe pour en discuter et découvrir comment nous pouvons sécuriser vos flux de données.