Réplication logique vs ETL par lots : choisir le style de synchronisation

Quel problème résolvons‑nous quand nous « synchronisons des données » ?

Les équipes copient des données entre systèmes parce que le travail n’a que rarement lieu au même endroit. Les ventes peuvent vivre dans un CRM, les paiements dans un outil de facturation, et les opérations dans un tableau de bord interne. Le support a besoin de la vue complète sans sauter d’un outil à l’autre, et les dirigeants veulent des rapports qui correspondent à ce qui s’est réellement passé.

Une « synchronisation fiable » est facile à décrire et difficile à maintenir : les bons enregistrements arrivent, rien d’important ne manque, et les mises à jour apparaissent assez vite pour être utiles. « Assez vite » dépend du besoin. Les contrôles antifraude peuvent nécessiter des minutes. Les rapports financiers mensuels peuvent tolérer des heures.

Quand une synchronisation tourne mal, cela ressemble généralement à des enregistrements manquants, des duplicatas, des champs obsolètes ou des mises à jour partielles (par exemple, un en‑tête de commande apparaît mais pas les lignes).

Un modèle mental utile est événements vs instantanés.

Les événements sont des changements individuels : « Commande #1842 créée », « statut changé en expédié », « remboursement émis ». Les approches basées sur le changement de données tendent à déplacer des événements et peuvent supporter un comportement quasi temps réel.

Les instantanés sont des copies planifiées : « chaque nuit, copier les commandes d’hier ». L’ETL par lots fonctionne souvent ainsi. C’est parfois plus simple, mais les données sont moins fraîches.

La plupart des débats sur réplication logique vs ETL par lots portent en réalité sur ce choix : avez‑vous besoin d’un flux d’événements continu, ou des instantanés périodiques suffisent‑ils pour que les gens aient confiance dans ce qu’ils voient ?

Réplication logique et ETL par lots, expliqués simplement

La réplication logique signifie que la base de données source envoie un flux de changements au fur et à mesure qu’ils se produisent. Au lieu de copier des tables entières, elle publie « ligne ajoutée », « ligne mise à jour » ou « ligne supprimée ». La destination applique ces changements dans l’ordre, ce qui lui permet de rester étroitement alignée sur la source.

L’ETL par lots consiste à prendre des instantanés selon un planning. Un job extrait des données (souvent « tout ce qui a changé depuis la dernière exécution »), les transforme si nécessaire, puis les charge dans la destination. Si la réplication ressemble à des mises à jour en direct, l’ETL par lots ressemble à une vérification toutes les heures (ou chaque nuit) pour rattraper le retard.

Ils s’exécutent généralement à des endroits différents. La réplication s’appuie près du journal de changements de la base et tourne en continu. L’ETL par lots est typiquement un job planifié qui s’exécute, s’arrête, puis repart.

Dans les deux cas, il faut répondre aux mêmes questions de confiance :

• Comment sont représentées les suppressions pour que la destination n’ait pas de lignes « fantômes » ?
• Que se passe‑t‑il si un même changement arrive deux fois (idempotence) ?
• Comment garder l’ordre correct quand beaucoup de lignes changent rapidement ?
• Comment éviter de manquer des changements lors de redémarrages ou de déploiements ?
• Comment détecter des lacunes, et pas seulement « le job a réussi » ?

Exemple : une commande est créée, puis son statut passe de « en attente » à « payée », puis elle est remboursée. La réplication enverra trois événements de changement. Un instantané quotidien ne capturera peut‑être que le statut final, sauf si vous concevez le processus par lots pour préserver les états intermédiaires.

Fraîcheur et latence : à quel point avez‑vous besoin d’être proche du temps réel ?

Avant de comparer la réplication et l’ETL par lots, définissez « assez frais » en termes métiers. Commencez par un nombre : « le support peut travailler avec des données âgées de 5 minutes » ou « la finance se contente des totaux d’hier ».

La fraîcheur est l’âge des données au moment où quelqu’un les utilise. La latence est le délai entre un changement à la source et l’apparition de ce même changement à la destination. Vous pouvez avoir une faible latence moyenne et quand même vous retrouver avec des données « vieilles » si la synchronisation cale souvent.

D’où vient réellement la latence

Même une synchronisation simple empile plusieurs délais : capture (lorsque vous constatez les changements), transit (le déplacement des données), traitement (transformations et dédoublonnage), et application (écriture et indexation à la destination).

Un flux constant (réplication ou micro‑lots fréquents) produit une fraîcheur plus régulière, mais vous exploitez la synchronisation toute la journée. Les lots programmés sont plus faciles à raisonner, mais créent des pics : grosse charge à 2h00 du matin, puis données obsolètes jusqu’à la prochaine exécution.

Le quasi temps réel aide quand les gens prennent des décisions rapides ou que les clients voient le résultat. Un tableau de bord support doit afficher les nouvelles commandes rapidement pour qu’un agent ne promette pas quelque chose en rupture de stock. En revanche, si l’usage principal est un rapport hebdomadaire ou une facturation mensuelle, pousser chaque petite mise à jour instantanément ajoute de la complexité sans améliorer les résultats.

Une manière pratique de décider :

• Qui utilise les données synchronisées et quelles décisions prennent‑ils ?
• Qu’est‑ce qui casse si les données ont 15 minutes de retard ?
• Quel est le coût d’une exploitation continue (infrastructure et disponibilité des équipes) ?
• Quand la destination est‑elle la moins sollicitée ?
• Quelle fraîcheur vous engagez‑vous à tenir (et à communiquer) ?

Récupération après panne : revenir à un état correct après un incident

Les synchronisations échouent rarement de façon spectaculaire. Elles échouent de manière petite et ennuyeuse : un serveur redémarre, un incident réseau coupe une connexion, ou un job plante en plein chargement. L’objectif n’est pas « ne jamais échouer », mais « récupérer vers un état final correct ».

Les modes de défaillance courants incluent une panne de la source, une panne de la destination, un plantage du job en plein traitement, ou des données invalides qui violent des contraintes.

Avec la réplication logique, la récupération signifie généralement rejouer les changements depuis une position sauvegardée (souvent un offset de journal). Si la destination est indisponible, les changements s’accumulent jusqu’à son retour, puis sont appliqués dans l’ordre. C’est propre si vous gérez aussi le slot de réplication (ou équivalent) pour éviter qu’il ne grossisse indéfiniment lors de longues coupures.

Avec l’ETL par lots, la récupération signifie souvent relancer une fenêtre temporelle (par exemple « recharger hier » ou « recharger les 2 dernières heures »). Opérationnellement, c’est souvent simple, mais votre logique de chargement doit être sûre à relancer deux fois.

Le plus grand casse‑confiance est l’écriture partielle. Un crash après l’écriture de 70 % d’un lot peut laisser des duplicatas ou des lignes manquantes si vous n’y avez pas pensé. Des patterns qui aident dans les deux styles :

• Rendre les chargements idempotents pour qu’appliquer la même entrée deux fois donne le même état.
• Préférer des upserts basés sur une clé primaire stable.
• Avancer votre marqueur « dernier traité » seulement après un commit réussi.
• Conserver les lignes rejetées quelque part pour inspection et rejouage.

Les backfills (retraiter l’historique) sont là où la douleur apparaît. L’ETL par lots l’emporte souvent quand il faut retraiter un mois de données parce que les relances font déjà partie du design. La réplication peut aussi backfiller, mais c’est généralement un chemin séparé (instantané d’abord, puis appliquer les changements), donc testez‑le avant d’en avoir besoin.

Exemple : si une synchronisation de commandes plante après avoir écrit les lignes de commande mais avant d’écrire l’en‑tête, un chargement basé sur des upserts avec une transaction par commande (ou par lot) évite qu’une commande à moitié synchronisée subsiste.

Évolution du schéma : que se passe‑t‑il quand le modèle de données change ?

Les changements de schéma sont là où beaucoup de synchronisations perdent silencieusement la confiance. Un pipeline peut continuer à tourner pendant que le sens des données change sous‑jacemment. La réplication peut casser au niveau de la base, tandis que l’ETL casse souvent plus loin, dans les transformations et les rapports.

Les changements additifs sont les plus faciles : nouvelles colonnes, nouvelles tables, champs optionnels. Ils fonctionnent généralement si les consommateurs les traitent comme « supplémentaires » et que les valeurs par défaut ont du sens. Le piège est de supposer que chaque consommateur en aval remarquera le nouveau champ ou saura comment le backfiller.

Les changements cassants sont risqués : renommages, changements de type, colonnes supprimées ou modification du sens d’une valeur. Ils peuvent échouer vite (erreurs de job) ou échouer lentement (les données arrivent mais sont incorrectes).

Comment évoluer en sécurité

Maintenez la compatibilité assez longtemps pour migrer :

• Versionnez les schémas ou les payloads (v1, v2) pour que l’ancien et le nouveau puissent coexister.
• Passez une période de compatibilité où anciens et nouveaux champs existent.
• Backfill avant de basculer la logique qui dépend de la nouvelle forme.
• Supprimez des champs seulement après avoir confirmé que rien ne les consulte.

Où les mappings cassent

La plupart des vraies cassures se produisent dans la colle entre systèmes. Exemple : votre ETL joint orders à customers par customer_id. S’il est renommé en client_id, la jointure peut devenir des correspondances toutes nulles et produire quand même des lignes.

Surveillez les points fragiles : conversions de type, jointures qui supposent que les clés ne changent jamais, et règles en aval comme « status prend l’une de ces valeurs ».

Sécurité et propriété : qui est autorisé à synchroniser quoi ?

Les questions de sécurité sont similaires dans les deux approches, mais les risques apparaissent à des endroits différents. La réplication tourne souvent en continu avec un large accès en lecture aux changements. L’ETL par lots s’exécute sur un planning, mais peut extraire de plus larges tranches de données en une fois. Dans les deux cas, visez les permissions minimales permettant à la synchronisation d’accomplir sa tâche.

Utilisez un compte de service dédié, pas la connexion d’une personne. Donnez un accès en lecture seule exactement aux tables, colonnes ou vues nécessaires, et limitez les points de connexion. Quand c’est possible, exposez une « vue de synchronisation » dédiée qui filtre déjà les données que la destination ne doit jamais voir.

Les champs sensibles sont ceux qui surprennent les équipes. Même si la destination a besoin d’un enregistrement, elle n’a peut‑être pas besoin de tout. Décidez tôt d’omettre, masquer ou tokeniser les coordonnées personnelles, les informations de paiement ou les notes internes. Chiffrez les données en transit et stockez les secrets dans un gestionnaire de secrets approprié, pas dans les configs du pipeline.

La gouvernance évite les disputes sans fin plus tard :

• Choisissez une source de vérité pour chaque champ (pas seulement pour chaque table).
• Documentez si la destination peut écrire en retour.
• Décidez comment les conflits sont gérés (dernier écrit gagne, ignorer les modifications de la cible, revue manuelle).
• Définissez des règles de rétention pour les données copiées dans la destination.

L’audit est la dernière pièce de confiance. Vous devriez pouvoir répondre : qui a accédé aux données, qu’est‑ce qui a changé, et quand cela a été chargé. Une pratique simple consiste à porter un id de run traçable et des horodatages pour suivre une mise à jour de bout en bout.

Que surveiller pour que la synchronisation reste digne de confiance

Une synchronisation n’est utile que si vous pouvez lui faire confiance un mardi au hasard. Quelle que soit l’approche, la surveillance doit vous dire à quel point vous êtes en retard, à quelle fréquence vous échouez, et si les chiffres ont toujours du sens.

Trois signaux santé quotidiens :

• Retard/latence : à quel point la destination est en retard sur la source
• Taux d’erreur : échecs, réessais et enregistrements envoyés dans un bucket de « dead‑letter » ou « lignes échouées »
• Débit : lignes ou événements traités par minute, et chutes soudaines vers quasiment zéro

Puis ajoutez un petit ensemble de contrôles de qualité des données qui attrapent les problèmes silencieux. Choisissez quelques tables importantes (commandes, factures, tickets) et validez‑les de manière répétable. Si hier la source a 1 240 commandes, la destination ne devrait pas en avoir 1 180 sauf raison connue.

Contrôles couvrant souvent beaucoup de cas :

• Comptes de lignes par jour (ou par heure pour les flux critiques)
• Totaux devant correspondre (somme des montants, nombre de commandes payées)
• Taux de null sur champs requis (email, statut, horodatages)
• Unicité des clés (pas de order_id dupliqués)
• « Vérité des suppressions » : les enregistrements annulés ou supprimés disparaissent aussi en aval (ou sont marqués)

Les problèmes de cohérence se cachent souvent dans les gaps : mises à jour tardives, suppressions manquantes, ou événements appliqués hors ordre. Suivez le plus ancien horodatage non traité et échantillonnez périodiquement des enregistrements pour confirmer que la version la plus récente est présente.

Pour l’alerte, gardez‑la ennuyeuse et exploitable. Fixez des seuils (par exemple : retard supérieur à 15 minutes, taux d’erreur au‑dessus de 1 %, débit sous le seuil pendant 10 minutes) et maintenez un runbook qui répond : que vérifier en premier, comment rejouer en sécurité, et comment confirmer que tout est redevenu correct.

Étape par étape : comment choisir la bonne approche de synchronisation

Soyez clair sur qui utilisera les données. Un rapport financier, un tableau support et une règle de tarification automatisée consomment les mêmes tables de façons différentes. Si les décisions sont sensibles au temps, des données tardives ne sont pas juste ennuyeuses — elles peuvent être fausses.

Un processus de décision simple :

1. Nommer les consommateurs et leurs décisions. Listez les écrans, rapports et processus dépendants de la synchronisation et ce qu’ils impactent.
2. Fixer des cibles, pas des impressions. Mettez d’accord la fraîcheur (secondes, minutes, heures), la correction (quelles erreurs sont acceptables), et le coût (infrastructure, temps d’ingénierie, charge opérationnelle).
3. Choisir le pattern le plus simple qui atteint les cibles. Utilisez la réplication quand vous avez besoin du quasi temps réel et d’une capture de changement prévisible. Utilisez des micro‑lots quand « toutes les quelques minutes » suffit. Utilisez un lot nocturne pour reporting et snapshots historiques. Les solutions hybrides sont courantes.
4. Planifier la récupération. Décidez jusqu’où vous pouvez rejouer, comment lancer un backfill, et comment garder les chargements idempotents.
5. Définir les contrôles de confiance et la propriété. Choisissez les validations prouvant la santé (comptes, totaux, horodatage de dernière mise à jour, contrôles ponctuels) et nommez qui est alerté et qui corrige les données.

Exemple concret : si le support a besoin du statut d’une commande pendant qu’il parle à un client, les minutes comptent, donc la réplication ou le micro‑lot conviennent. Si la finance a besoin des chiffres journaliers, un lot nocturne suffit souvent.

Erreurs fréquentes qui rendent les données synchronisées peu fiables

Le piège le plus grand est de supposer que des données « fraîches » sont automatiquement « correctes ». Un pipeline peut avoir quelques secondes de retard et être quand même faux parce qu’une jointure a changé, un filtre a été ajouté, ou une ligne a été dupliquée. Sans validation, vous ne remarquerez souvent rien avant qu’un tableau ne paraisse étrange ou qu’un client se plaigne.

Les suppressions sont une autre omission fréquente. Les deux approches doivent prévoir ce que signifie « supprimé ». Si le Système A supprime physiquement une ligne mais que le Système B n’insère que des mises à jour, les rapports dériveront. Les soft‑deletes posent autant de problèmes si le flag de suppression et l’horodatage ne sont pas transmis.

Erreurs récurrentes :

• Traiter la fraîcheur comme objectif principal et sauter les comptes de base, totaux et contrôles ponctuels
• Synchroniser inserts et updates, mais pas suppressions, merges ou états désactivés
• Hardcoder des mappings de champs qui cassent silencieusement quand une colonne est renommée, scindée ou change de type
• Ne pas avoir de plan de backfill quand des données historiques doivent être corrigées
• Alerter seulement sur les échecs de job, pas sur le retard, les données manquantes ou la dérive lente

Exemple : votre CRM marque un client comme « inactive » au lieu de le supprimer. Votre ETL ne copie que les clients où status = active. Un mois plus tard, les rapports de revenus semblent corrects, mais les métriques de rétention sont gonflées parce que les clients inactifs n’ont jamais été synchronisés (ou jamais supprimés). Tout paraissait frais, mais la correction était déjà fausse.

Checklist rapide avant de déclarer la synchronisation « terminée »

Mettez d’accord la définition de « terminé » en nombres clairs, propriété définie, et récupération prouvée. Une synchronisation qui paraît correcte le jour 1 peut dériver quand de vraies modifications et de vraies pannes apparaissent.

• Promesse de fraîcheur documentée. Définir le délai cible, où il est mesuré, et ce qui se passe en cas de dépassement.
• Source de vérité explicite. Pour les champs clés (statut, prix, email client), documenter quel système l’emporte et si les mises à jour sont unidirectionnelles ou bidirectionnelles.
• Récupération testée de bout en bout. Simulez une panne et confirmez que vous pouvez rejouer ou relancer sans duplicatas ni lignes manquantes.
• Règles de changement de schéma en place. Décidez qui approuve les changements, comment ils sont déployés, et comment gérer renommages, changements de type et colonnes supprimées.
• Monitoring exploitable. Surveillez retard, taux d’erreur et contrôles de données centraux, avec des alertes qui disent à la personne d’astreinte quoi faire ensuite.

Contrôle de réalité : si delivery_instructions est ajouté aux commandes, votre processus doit rendre évident s’il se synchronise automatiquement, échoue bruyamment, ou est ignoré sans risque.

Exemple réaliste : synchroniser les commandes entre deux systèmes

Imaginez une entreprise avec des commandes stockées dans PostgreSQL. Deux équipes ont besoin de ces données : le support veut un tableau en direct pour répondre « où en est ma commande ? », et la finance veut des chiffres journaliers stables pour la clôture et le reporting.

Elles utilisent une approche mixte au lieu d’imposer un seul outil pour tout.

Pour le support, elles utilisent la réplication logique afin que les nouvelles commandes et les mises à jour de statut apparaissent rapidement dans une base optimisée en lecture qui alimente le tableau de bord. Pour la finance, elles exécutent un ETL par lots une fois par jour après les heures ouvrées. Il charge les commandes finalisées dans l’entrepôt de reporting, applique les règles métiers (taxes, remises, remboursements), et produit un instantané quotidien qui ne change pas sous leurs pieds.

Puis un changement de schéma arrive : l’équipe produit ajoute refund_reason. Le support le veut immédiatement. La réplication peut transmettre la nouvelle colonne rapidement, tandis que le job par lots peut la traiter comme optionnelle au départ (valeur par défaut « unknown ») jusqu’à ce que la logique de reporting soit prête.

Un jour, la destination du support est indisponible pendant 3 heures. À son retour, la réplication rattrape depuis la position sauvegardée. L’étape clé n’est pas seulement « ça a repris », mais « c’est correct » : ils vérifient les comptes de commandes pour la fenêtre d’indisponibilité et échantillonnent quelques commandes récentes de bout en bout.

Chaque matin, ils vérifient un petit ensemble de signaux avant de faire confiance aux chiffres : retard de réplication, compte source vs destination des commandes pour les dernières 24 heures, duplicatas dans les tables financières, succès du batch plus lignes chargées par exécution, et un échantillon de commandes à forte valeur vérifié dans les deux systèmes.

Étapes suivantes : rendre la synchronisation visible et facile à exploiter

Après avoir choisi une approche (ou un hybride), le vrai travail est de faire de la synchronisation quelque chose en laquelle les gens peuvent avoir confiance chaque jour. Choisissez un objectif mesurable et traitez‑le comme un indicateur produit. Pour la plupart des équipes, le premier objectif est soit la fraîcheur (à quel point les données sont récentes) soit la précision (à quelle fréquence elles sont erronées).

Commencez petit : une table, un flux d’événements, ou un workflow qui compte (comme les commandes ou les tickets). Stabilisez ce chemin, puis reproduisez le modèle. S’étendre avant de pouvoir détecter et corriger les problèmes crée un plus gros désordre, plus vite.

Une vue « statut de synchronisation » pratique pour les équipes non techniques inclut généralement le retard actuel vs la cible, la dernière réussite, la dernière erreur, le volume traité aujourd’hui vs la fourchette attendue, et une courte note sur quoi faire quand le statut est rouge.

Si vous voulez construire rapidement des écrans d’administration internes comme celui‑ci, une plateforme no‑code comme AppMaster (appmaster.io) peut vous aider à livrer une vue de monitoring et l’ajuster au fil des besoins, sans réécrire tout quand le schéma ou le workflow évolue.