Intégration de données sans cimetière de données : CDC, streaming d'événements et ETL — comparaison pour ERP/CRM/entrepôts

Qui relie ERP, CRM et gestion d’entrepôt veut généralement deux choses à la fois : les processus doivent s’exécuter de bout en bout (p. ex. commande → préparation → expédition → facture), et les données doivent être disponibles pour des analyses (p. ex. capacité de livraison, marges de contribution, taux de retours). En pratique, cela crée rapidement un écart entre « Nous en avons besoin aujourd’hui dans les rapports » et « Nous ne devons pas déstabiliser l’ERP en production ». C’est précisément là que se joue la réussite d’une intégration des données sans cimetière de données ou l’accumulation, sur des années, d’un mélange confus d’exports CSV, de jobs nocturnes, de tables fantômes et de copies de données non clarifiées.

Ce billet compare trois approches centrales : ETL (Extract, Transform, Load), CDC (Change Data Capture, c’est‑à‑dire la détection et le transfert des modifications de données) et Event Streaming (événements comme flux continu via un broker de messages). L’accent n’est pas mis sur les détails de programmation, mais sur les conséquences architecturales, la réalité opérationnelle, la qualité des données, les questions de sécurité et de déploiement – telles qu’elles apparaissent réellement dans des projets d’intégration entre systèmes d’entreprise.

Pourquoi les intégrations deviennent souvent un cimetière de données

Un cimetière de données naît rarement d’une mauvaise intention. Les causes typiques sont :

• Frontières système floues : l’ERP est un jour « maître », puis c’est le CRM, et l’entrepôt a sa propre logique d’état. Sans désignation claire d’une autorité des données (System of Record), les conflits sont inévitables.
• Exigences ad hoc : « Nous avons rapidement besoin d’un tableau de bord » conduit à des accès directs à l’ERP ; par la suite, des requêtes supplémentaires, des vues matérialisées ou des copies apparaissent. Chaque gain rapide déplace la charge opérationnelle et les responsabilités.
• Absence de contrats : les contrats d’interface (quels champs, quelle sémantique, quel versionnage) font défaut. Résultat : dérive de schéma – des champs changent de signification ou de structure sans que les systèmes en aval s’en aperçoivent à temps.
• Pas de concept d’exploitation : les jobs s’exécutent « quelque part », les identifiants sont dans des scripts, il n’y a pas d’alerte en cas de lacunes de données, et personne ne peut dire si un rapport est « complet ».

ETL, CDC et Event Streaming résolvent des parties différentes de ce problème. L’essentiel est de choisir l’approche en fonction de la criticité du processus, des exigences de latence et de la maturité opérationnelle – et de gérer le parcours d’intégration comme un produit, pas comme un artefact de projet ponctuel.

Situons clairement les concepts : ETL, CDC et Event Streaming

ETL signifie « Extract, Transform, Load » : les données sont extraites des systèmes sources, transformées (p. ex. nettoyées, agrégées, mappées) et chargées dans un système cible, souvent un entrepôt de données. Classiquement, cela se fait de manière batch, p. ex. la nuit ou toutes les heures.

CDC (Change Data Capture) décrit des mécanismes qui détectent les modifications de données et les transmettent sous forme de delta : enregistrements nouveaux/mis à jour/supprimés. La CDC peut être mise en œuvre via des horodatages, des triggers ou — opérationnellement souvent de la manière la plus propre — via les journaux de transactions de la base de données. L’objectif est généralement le quasi‑temps réel, sans effectuer constamment des extractions complètes.

Event Streaming désigne la publication d’événements (p. ex. « commande validée », « réception de marchandise enregistrée ») comme flux continu via un broker de messages (p. ex. des systèmes de type Kafka ou des concepts de bus de service). Les consommateurs s’abonnent aux événements et les traitent à leur rythme. Important : un événement n’est pas automatiquement « la vérité complète » des données, mais souvent un changement d’état avec contexte.

Comparaison selon les questions qui comptent vraiment en exploitation

Latence : à quelle rapidité les données doivent-elles réellement être ?

Pour de nombreux rapports ERP, les données de « la nuit dernière » suffisent. Pour la conduite opérationnelle en entrepôt, « âgées de 5 minutes » peut déjà être trop lent (p. ex. en cas de stocks faibles). Ici, on retiendra :

• ETL fournit des fenêtres de mise à jour planifiables, mais n’est pas conçu pour être « instantané ».
• CDC est adapté si vous voulez répliquer rapidement des changements de données vers des systèmes de reporting ou de recherche sans remodeler la logique métier.
• Event Streaming convient lorsque les processus doivent réagir en temps quasi réel (p. ex. génération d’étiquettes d’expédition, mise à jour du statut client, déclenchement de notifications).

Une erreur fréquente est d’exiger du « temps réel » partout. Le temps réel accroît la complexité du monitoring, de la gestion des erreurs et de la cohérence des données. Il est pertinent de classifier : quelles données sont opérationnelles (critiques pour les processus), quelles sont analytiques (critiques pour le reporting), quelles sont archivées (audit / conformité) ?

Cohérence : que se passe-t-il en cas de défaillances partielles ?

Dans des intégrations distribuées, les défaillances partielles sont normales : coupures réseau, timeouts, verrous, fenêtres de maintenance. L’important est de savoir si votre approche les amortit de manière robuste.

• ETL fonctionne le plus souvent par lots. Si un lot échoue, l’état des données dans la cible est souvent consistant « jusqu’au point X », puis devient obsolète. Cela est souvent acceptable pour le reporting, tant que c’est transparent.
• CDC transmet des deltas. Si le processus se bloque, un retard (backlog) se crée. C’est maîtrisable, mais vous devez mesurer le lag (décalage) et alerter des seuils.
• Event Streaming déplace la responsabilité des erreurs vers les consommateurs. Il faut de l’idempotence (traiter plusieurs fois sans effet secondaire), des stratégies de retry et une Dead-Letter-Queue, sinon les erreurs restent « silencieuses » et n’apparaissent qu’au niveau métier.

La cohérence est aussi une question métier : « commande + positions + réservations » doit‑elle arriver comme un paquet, ou une cohérence éventuelle (mise en cohérence ultérieure) suffit‑elle ? Plus la dépendance par paquet est élevée, plus vous aurez besoin de limites transactionnelles et de règles claires d’ordonnancement.

Charge et risque pour l’ERP : quoi est sollicité et comment ?

Beaucoup de problèmes d’intégration sont en réalité des problèmes de performance et de verrous dans le système source. L’ERP est un système OLTP (Online Transaction Processing) : de nombreuses petites transactions, forte charge d’écriture, index sensibles.

• ETL extrait souvent de gros volumes. Sans fenêtres temporelles définies, Read‑Replica ou tables d’extraction ciblées, l’ETL peut ralentir l’ERP.
• CDC via les logs est généralement plus doux, car il exploite le flux de changements déjà présent. Une CDC basée sur des déclencheurs peut en revanche allonger les chemins d’écriture et constitue un risque sur des tables fortement sollicitées.
• Event Streaming évite la charge de lecture directe si les events proviennent directement de l’application. Si les events sont cependant « générés depuis la base de données », on se rapproche à nouveau de la CDC — avec des compromis similaires.

Règle pratique : si l’ERP est déjà dimensionné juste, l’intégration ne devrait pas commencer par des extractions complètes supplémentaires. Il est souvent judicieux d’abord de découpler, p. ex. via CDC vers un schéma de reporting ou d’intégration séparé, puis d’effectuer les transformations.

ETL au quotidien : adapté au reporting, dangereux en tant que liant de processus

ETL est pour beaucoup d’entreprises le point d’entrée, car il est conceptuellement tangible : « Nous récupérons les données, les préparons, les chargeons dans le DWH. » Pour des besoins BI classiques, cela reste pertinent.

Points forts de l’ETL

• Prévisibilité: Les exécutions nocturnes ou horaires sont aisément pilotables et s’adaptent aux fenêtres de maintenance.
• Logique de transformation centralisée: Le nettoyage, le mapping et l’historisation (p. ex. Slowly Changing Dimensions) sont établis dans le contexte DWH.
• Auditabilité: Avec des ID d’exécution, des comptages de lignes et des sommes de contrôle, vous pouvez retracer ce qui a été chargé et quand.

Risques typiques et motifs de « Datenfriedhof »

• Prolifération des accès directs: Plus d’analyses reposent directement sur des tables extraites, plus de « produits de données non officiels » voient le jour.
• Dérive de schéma sans alerte précoce: Si des champs changent dans l’ERP, cela n’est souvent détecté qu’à la prochaine exécution — ou pire : pas du tout, parce que des valeurs nulles « passent à travers ».
• Fenêtres batch qui se rétrécissent: Le volume de données augmente, les temps d’exécution s’allongent ; à terme l’ETL entre en conflit avec les sauvegardes, les réorganisations ou les chaînes de jobs ERP nocturnes.

Exemple concret : Un entrepôt a besoin chaque jour d’un rapport « articles sans stock mais avec commandes ouvertes ». En tant que rapport ETL, c’est acceptable. Mais si ce rapport sert de base à la planification opérationnelle, un retard de 24 heures devient soudainement critique d’un point de vue métier. L’ETL devient alors un « adhésif de processus » — et cela est rarement stable.

CDC : la voie pragmatique vers les deltas et le near-realtime

Le CDC est souvent le compromis pragmatique lorsque vous souhaitez acheminer des données d’ERP/CRM/entrepôt rapidement vers des moteurs de recherche, un Data Warehouse ou des bases d’intégration, sans repenser chaque logique métier comme un modèle d’événements.

Variantes de CDC et conséquences opérationnelles

• CDC par horodatage / High-Watermark: Vous lisez « tout depuis la dernière marque temporelle ». Simple, mais sensible aux corrections rétroactives, aux dérives temporelles et à l’absence d’événements de suppression.
• CDC basée sur des triggers: Les modifications sont également écrites dans des tables de changement. C’est fonctionnellement clair, mais cela augmente la charge d’écriture et nécessite des permissions propres ainsi qu’une maintenance lors des changements de schéma.
• CDC basée sur les logs: Les modifications sont dérivées du journal de transactions. Souvent plus performant et plus fidèle à l’état réel, mais requiert une configuration soignée, car la rétention des logs, les sauvegardes et les jobs de maintenance acquièrent une importance pour l’intégration.

Important pour les administrateurs : le CDC n’est pas « à activer une fois pour toutes ». Il faut surveiller le retard (lag), définir des procédures de resynchronisation (p. ex. reconstruction de tables individuelles) et déterminer la durée de conservation de l’historique des changements dans la cible.

Ce que le CDC fait particulièrement bien

• Allègement des extractions complètes: Après un snapshot initial, seuls les deltas sont transmis.
• Séparation claire OLTP vs. Analytics: Le reporting peut s’exécuter sur une base de données séparée ou un warehouse sans impacter l’ERP.
• Mise à disposition de données neutre sur le plan technique: Les équipes en aval peuvent itérer les étapes de transformation de manière indépendante.

Exemple pratique : Un CRM doit savoir, au jour le jour, si un client a des livraisons en attente, sans exécuter en permanence des requêtes complexes dans l’ERP. CDC reflète les tables ou vues pertinentes dans une base de données d’intégration ; le CRM lit depuis cette base. Résultat : moins de pics de charge dans l’ERP, et les requêtes peuvent être indexées de manière ciblée.

Event Streaming : lorsque les processus doivent réagir — et que vous assumez la responsabilité

Event Streaming est particulièrement pertinent lorsque vous ne voulez pas seulement copier des données, mais orchestrer des réactions de processus : changements d’état, notifications, tâches de suivi, intégrations avec des partenaires. Un événement est une « chose qui s’est produite » — incluant un horodatage, des identifiants et le contexte minimal nécessaire.

Points forts de l’Event Streaming

• Découplage: Le producteur et le consommateur n’ont pas à être disponibles en même temps. Cela réduit la fragilité lors des fenêtres de maintenance.
• Mise à l’échelle via les consommateurs: Plusieurs systèmes peuvent utiliser le même événement (p. ex. CRM, expédition, BI), sans que l’ERP doive livrer séparément pour chaque cible.
• Transparence du flux: Avec une bonne supervision, vous voyez le débit, l’engorgement et les taux d’erreur par consommateur.

Risques et hypothèses erronées typiques

• «On envoie des événements, alors la qualité des données sera correcte»: Les événements véhiculent aussi des états erronés si des validations en amont font défaut. La qualité des données reste une discipline métier.
• On oublie l’idempotence: Des événements en double surviennent (retry, réseau, rebalancing). Les consommateurs doivent tolérer le traitement en double, p. ex. via des identifiants d’événement uniques et des contrôles «déjà traités».
• Gestion du schéma et des versions: Les messages d’événement sont des contrats d’interface. Sans versioning et plan de dépréciation, c’est le chaos, mais plus rapide.
• La garantie d’ordre n’est pas gratuite: Beaucoup de Broker offrent l’ordre seulement au sein de partitions/keys définies. Sur le plan métier, il doit être clair quelle clé (p. ex. ID de commande) garantit l’ordre.

Scénario concret : Dans l’entrepôt, une sortie de marchandises est enregistrée. L’ERP doit facturer, le CRM doit mettre à jour le statut du client, et le portail de suivi doit fournir une information d’expédition. L’Event Streaming peut désaccoupler cela proprement. Mais si la facturation doit impérativement avoir lieu avant le changement de statut, vous avez besoin soit d’une coordination de processus (p. ex. Saga/Chorégraphie) soit de règles claires indiquant qui est l’orchestrateur. Sinon, les états vont «vaciller».

Aide à la décision : quelle approche convient à quel objectif ?

Dans les projets d’intégration, une mauvaise décision de fond coûte cher. Une classification pragmatique :

Si votre objectif est principalement le reporting et l’analytique

Si votre objectif est une synchronisation opérationnelle et rapide

• Point de départ : CDC pour la réplication de tables/objets, complété par des services légers pour validation et résolution de conflits.
• Si des chaînes de réaction réelles sont nécessaires : Event Streaming, mais uniquement avec ownership défini et responsabilité opérationnelle par consommateur.

Si votre objectif est le couplage des processus entre ERP/CRM/entrepôt

• Point de départ : Event Streaming ou intégration basée sur messages, complétés par des canaux de retour (accusés de réception) et des chemins d’erreur.
• ETL ici uniquement pour des flux annexes (p.ex. rapprochements quotidiens, archivage, BI), pas comme déclencheur pour des actions opérationnelles.

Important : dans la réalité, c’est rarement « soit l’un soit l’autre ». De nombreuses architectures stables combinent : événements pour les processus, CDC pour la fourniture de données et ETL/ELT pour les modèles de reporting.

Conséquences architecturales à clarifier tôt

Souveraineté des données et questions de Golden Record

Qui peut modifier quoi ? Un « Golden Record » est l’enregistrement de données valide du point de vue métier pour un objet (client, article, commande). Si plusieurs systèmes écrivent, vous avez besoin de règles de gestion des conflits : priorités, clarification manuelle ou approches MDM (Master Data Management). Sans ces règles, l’intégration devient un ticket permanent « Pourquoi les données sont-elles différentes ? ».

Gestion des erreurs comme conception, pas comme rattrapage

Qu’il s’agisse d’ETL, de CDC ou d’Event Streaming : vous avez besoin de classes d’erreurs définies. Une tripartition éprouvée :

• Erreurs techniques (timeout, réseau, verrous temporaires) : réessai automatique avec backoff.
• Erreurs sémantiques (champ obligatoire manquant, statut inconnu) : mise en quarantaine / Dead-Letter, avec capacité de création de ticket.
• Conflits de processus (ordre violé, double réservation) : processus de clarification métier, souvent avec décision manuelle.

Sans mécanisme de quarantaine, vous vous retrouvez avec « l’intégration est verte, mais des cas individuels manquent ». C’est le chemin le plus rapide vers le cimetière des données, car personne ne sait plus quel état des données est « vrai ».

Monitoring, alerting et traçabilité

Pour la direction IT et l’exploitation, des questions concrètes comptent : combien d’enregistrements/événements par heure ? Quelle est l’ampleur du retard ? Quelle interface provoque le plus de réessais ? L’ETL a besoin de monitoring d’exécution (début/fin, comptage de lignes), la CDC a besoin de métriques de lag, l’Event Streaming nécessite des métriques de retard des consommateurs et des taux de Dead-Letter. S’y ajoutent des logs avec corrélation (p. ex. ID de commande), afin que les incidents de support ne se terminent pas en captures d’écran.

Sécurité et conformité : les copies de données sont une responsabilité

L’intégration génère des copies. Les copies signifient de nouvelles surfaces d’attaque et de nouvelles questions de conservation. Points typiques qui arrivent trop tard dans les projets :

• Principe du moindre privilège : les comptes ETL et CDC devraient uniquement lire ce qui est nécessaire. Pour les producteurs/consommateurs d’événements, des comptes de service avec des droits minimaux sont obligatoires.
• Gestion des secrets : les mots de passe dans des scripts ou le planificateur de tâches sont un classique. Mieux : un gestionnaire centralisé de secrets ou au moins une rotation et un audit rigoureux.
• DSGVO et suppression : si une suppression/neutralisation est effectuée dans l’ERP, il faut être clair sur ce qui se passe dans le DWH/Data Lake/stream. CDC doit refléter les événements de suppression, ETL nécessite une logique de suppression ou d’anonymisation.

Déploiement et migration : comment éviter les intégrations big-bang

Surtout pour des processus ayant évolué, une transition progressive est plus stable. Une démarche pragmatique :

1. Inventaire: Quels flux de données existent (incl. Excel, SFTP, accès directs à la base de données) ? Lesquels sont critiques pour le processus ?
2. État cible stable par domaine: par ex. « le statut de stock provient du WMS, le statut des commandes de l’ERP, la communication client du CRM ».
3. Exploitation parallèle avec rapprochement: CDC/ETL fonctionnent d’abord en mode « shadow », les résultats sont comparés à l’état précédent (rapports de delta, échantillonnages).
4. Basculement avec repli: Pour les intégrations opérationnelles : passage à une source Event/CDC, mais avec un plan de repli clair (par ex. requêtes en lecture seule ou batch temporaire).
5. Nettoyage: Désactiver les anciens jobs, retirer les accès, consolider la documentation et la responsabilité. Sans cette étape, le cimetière de données subsistera, simplement avec une nouvelle décoration.

La gestion des attentes est importante : une intégration n’est jamais « terminée ». De nouveaux champs, de nouveaux processus, de nouveaux sites – tout cela impacte les flux de données. Les équipes performantes définissent donc un mode de maintenance : gestion des versions, tests, validations, ajustements du monitoring.

Conclusion : L’intégration des données sans cimetière de données exige de la technique — et de la clarté opérationnelle

ETL reste un outil solide pour le reporting, tant que vous maîtrisez les calendriers d’exécution, les contrats de données et la croissance des fenêtres de batch. CDC est souvent la voie pragmatique vers des états de données à jour, soulage les systèmes sources et crée une séparation nette entre OLTP et analyse. Event Streaming est pertinent lorsque les processus doivent réagir et que plusieurs systèmes consomment des événements — mais il exige une gestion des erreurs rigoureuse, une gestion des versions et une responsabilité par consommateur.

Dans la pratique, la question décisive n’est pas « quelle technologie est moderne », mais : quelle latence et quelle fiabilité nos processus exigent-ils — et quelle capacité opérationnelle pouvons-nous soutenir durablement ? Si vous clarifiez cela tôt, les intégrations peuvent être conçues pour croître sans se dégrader.

Si vous souhaitez moderniser de manière structurée vos intégrations entre ERP, CRM et entrepôt — y compris le concept d’exploitation, les contrats de données et le parcours de migration — parlez-en avec nous :

Pour ce sujet, Change Data Capture (Cdc) et l’intégration ERP sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.

Discuter d’un projet ou d’une modernisation avec Net-Base.