Vous gérez plusieurs applications qui partagent les mêmes données clients, produits ou commandes ? Vous avez un ERP, un site e-commerce et un CRM qui doivent rester en phase ? La synchronisation de bases de données est l'un des défis techniques les plus délicats en entreprise. Mal exécutée, elle crée des doublons, des incohérences, des pertes de données. Bien pensée, elle devient transparente.

Pourquoi la synchronisation de bases de données est complexe

Contrairement à ce qu'on pourrait croire, synchroniser deux bases n'est pas « juste » copier des données d'un côté à l'autre. Les vrais défis :

  • L'ordre des opérations. Si vous synchronisez A vers B, puis B vers A, vous créez une boucle infinie. Il faut un ordre établi.
  • Les mises à jour simultanées. Si deux systèmes modifient la même donnée au même moment, laquelle gagne ? Comment trancher ?
  • Les suppressions. Un enregistrement supprimé dans une base doit-il être supprimé partout, archivé, ou marqué comme inactif ?
  • Les délais. Une synchronisation en temps réel coûte cher en ressources. Une synchronisation toutes les heures peut créer des incohérences temporaires.
  • Les erreurs de réseau. La connexion s'interrompt. Que se passe-t-il ? On recommence du dernier point connu ? On recommence tout ?

Ces questions ne sont pas théoriques. Chaque jour, une PME découvre que ses commandes WooCommerce ne sont pas passées dans Dolibarr, ou que un client a été dupliqué trois fois.

Les trois approches principales

1. La synchronisation maître-esclave (unidirectionnelle)

Un système fait autorité (le maître). Les autres le lisent et se mettent à jour. Exemple : Dolibarr est votre ERP maître, WooCommerce importe vos produits et tarifs, mais n'en change pas l'état de stock en retour.

Avantages : simple à concevoir, pas de conflit, facile à déboguer.

Inconvénients : les modifications faites « côté esclave » sont perdues ou écrasées. À réserver aux cas où une seule source doit vraiment faire autorité.

2. La synchronisation bidirectionnelle avec dernier écrit gagne

Les deux bases peuvent se modifier. La dernière modification (par timestamp) écrase l'autre. Exemple : un produit est modifié à 14h32 dans WooCommerce et à 14h33 dans Dolibarr. La version Dolibarr gagne parce qu'elle est plus récente.

Avantages : flexible, permet l'édition partout.

Inconvénients : si vous ne contrôlez pas bien les timestamps (fuseaux horaires, pendules mal synchronisées), l'algorithme fait n'importe quoi. Et vous pouvez toujours perdre des modifications légitimes.

3. La synchronisation par identifiants uniques et log de changements

Chaque enregistrement a un ID unique global. Vous maintenez un journal (log) de qui a changé quoi, à quel moment, et dans quel système. À chaque synchronisation, vous rejouez les changements dans l'ordre. Si deux changements incompatibles se sont produits (deux modifications du même champ simultanément), une règle définie à l'avance les réconcilie.

Avantages : robuste, auditable, peu de pertes.

Inconvénients : plus complexe à implémenter. Demande de vraies compétences en architecture de données.

En pratique : les outils et les patterns

Synchronisation via API

La plupart des solutions SaaS modernes proposent des API pour interagir avec leurs données. Au lieu de toucher directement les bases, vous créez des tâches d'automatisation qui lisent une API, transforment les données, et les poussent dans une autre. Les avantages : c'est plus sûr (pas d'accès direct à la base), plus flexible (vous pouvez filtrer, transformer, valider), et plus facile à déboguer.

Pour Dolibarr et WooCommerce ensemble, vous pouvez écrire un script qui, toutes les heures, consulte l'API Dolibarr pour les produits modifiés depuis la dernière exécution, puis les push vers WooCommerce via son API REST.

ETL et outils no-code

Des outils comme Zapier, Make ou des solutions custom d'ETL (Extract-Transform-Load) gèrent la synchronisation sans code. Moins flexible, mais plus facile à maintenir pour une PME.

Event sourcing et Event Bus

Quand quelque chose change dans une base, on envoie un message (un événement) dans une queue (un bus). Les autres systèmes écoutent et réagissent. Redis, RabbitMQ ou Kafka gèrent ça. Très robuste, mais pour des projets plus costauds.

Les pièges courants et comment les éviter

Piège 1 : synchronisation trop fréquente. Si vous lancez une synchro toutes les 30 secondes, vous allez surcharger vos bases et vos API. Préférez une synchro toutes les heures, voire tous les jours, selon votre besoin métier. Les vrais changements continus d'inventaire ? Alors oui, cherchez du temps réel avec un WebSocket ou une queue.

Piège 2 : ne pas gérer les erreurs. Un appel API échoue. Vous ne gérez pas l'erreur ? La donnée reste orpheline. Vous devez logguer les erreurs, les rejouer plus tard, et alerter un admin si trop de tentatives échouent.

Piège 3 : les doublons. Deux enregistrements qui représentent la même entité finissent par coexister. Imposez une clé unique (un ID métier ou un hash) et fusionnez les doublons dès qu'ils sont détectés, plutôt que de les laisser s'accumuler.

Piège 4 : pas de stratégie de suppression. Faut-il vraiment supprimer les données ? Dans 90 % des cas, les archiver (marquées comme supprimées mais conservées) est plus sûr. Si vous avez vraiment besoin de supprimer (RGPD, par exemple), documentez le flux et testez-le.

Comment choisir votre approche

Quelques questions pour vous guider :

  • Les données changent-elles dans les deux systèmes, ou un seul est producteur ? (Maître-esclave suffit si un seul.)
  • Acceptez-vous des incohérences de quelques heures ? (Si non, temps réel nécessaire.)
  • Avez-vous des équipes tech internes, ou faites-vous appel à un prestataire ? (No-code vs custom.)
  • Quel est le coût d'une mauvaise synchro : une commande perdue ? Un client dupliqué ? (Évalue le risque.)

Dans la plupart des cas de PME, une synchro maître-esclave via API, avec logs d'erreur et rejoue quotidienne, suffit amplement. Commencez simple, puis adaptez.

Conclusion : commencer et ne pas se paralyser

La synchronisation parfaite n'existe pas. Le mieux est l'ennemi du bien. Mettez en place une première version simple, loggez tout, et itérez. Si vous avez une architecture SaaS complexe avec plusieurs bases, ou si vous reliez des outils comme Dolibarr et WooCommerce, consultez une équipe tech pour vous aider à concevoir le bon pattern. Cela vous évitera des mois de galère.

Avez-vous besoin de synchroniser plusieurs de vos systèmes ? Contactez-nous pour en discuter en détail.

Questions fréquentes

Cela dépend de votre métier. Un e-commerce a besoin d'un stock à jour rapidement (quelques heures au maximum). Une gestion administrative de devis peut se contenter d'une synchro quotidienne la nuit. Les synchronisations batch (toutes les heures ou la nuit) sont bien moins coûteuses en ressources. Évaluez votre vraie exigence métier avant de viser du temps réel.

C'est un conflit de fusion (merge conflict). Vous devez avoir une règle établie à l'avance : soit « le dernier gagne » (risqué), soit « seul le maître peut modifier ce champ » (maître-esclave), soit vous alertez un humain pour qu'il tranche. La plupart du temps, vous pouvez éviter ce problème en répartissant les champs : un système gère le tarif, l'autre gère la description. Chacun sa spécialité.

Ça dépend : pour du simple, une fonction cron + PHP/Python qui appelle les APIs suffit. Pour du plus complexe, Redis Queue ou RabbitMQ pour gérer les tâches. Pour du très temps réel et distribué, Kafka. Mais 80 % des PME n'ont besoin que d'une synchro API simple avec rejeu d'erreur. Ne sur-engineerez pas.