Si vous travaillez avec Microsoft Fabric, vous avez probablement deja utilise des Copy Activities dans vos pipelines Data Factory. Mais connaissez-vous la Copy Job ? C'est l'outil d'ingestion simplifie de Fabric — et avec les dernieres mises a jour de fevrier 2026, il est devenu redoutablement efficace.
Dans cet article, on va decortiquer la Copy Job sous tous les angles : ses modes de copie, la gestion du CDC, le choix entre Watermark et Change Data Feed, le nouveau Column Mapping, et surtout quand l'utiliser (et quand ne pas l'utiliser). Le tout avec des exemples concrets et des recommandations terrain.
Cet article est inspire par l'excellent recap d'Antoine Wang sur les nouveautes Fabric de fevrier 2026, ou la Copy Job figure parmi les top features. J'ai voulu creuser le sujet en profondeur.
01. C'est quoi une Copy Job ?
La Copy Job est la solution d'ingestion simplifiee de Microsoft Fabric Data Factory. Son objectif : deplacer des donnees d'une source vers une destination sans ecrire de pipeline.
Contrairement a une Copy Activity classique (qui vit a l'interieur d'un pipeline), la Copy Job est un artefact autonome. Vous la configurez via une interface guidee, vous choisissez vos tables, et c'est parti.
Les avantages cles
- Zero code — interface guidee, pas besoin d'ecrire du JSON ou du M
- Gestion d'etat automatique — Fabric memorise le dernier run reussi et reprend la ou il s'est arrete
- Creation automatique des tables — si la table destination n'existe pas, Copy Job la cree
- Multi-schedule — un meme job peut avoir plusieurs planifications (quotidien + hebdo)
- Resilience — en cas d'echec, le prochain run repart du dernier etat valide, sans perte de donnees
Connecteurs supportes (destinations)
Azure SQL DB, Azure SQL MI, Azure Synapse SQL Pool, Fabric Lakehouse, Fabric Warehouse, SQL Server on-premises, Oracle, Snowflake, SQL Database in Fabric (Preview). Et cote sources : BigQuery, DB2, ODBC, SharePoint, Amazon RDS et bien d'autres.
02. Les 3 modes de copie : Full, Incremental, CDC
C'est la ou la Copy Job devient interessante. Vous n'etes pas limite a une simple copie brute — vous choisissez votre strategie de chargement en fonction du cas d'usage.
Full Copy
A chaque execution, toutes les donnees sont copiees de la source vers la destination. Simple, previsible, mais couteux en compute sur les gros volumes. A utiliser pour les tables de reference, les dimensions statiques, ou les premieres charges initiales.
Incremental Copy
Le premier run fait une copie complete. Les runs suivants ne copient que les lignes nouvelles ou modifiees depuis la derniere execution. C'est le mode ideal pour les tables volumineuses qui changent peu.
Deux mecanismes possibles :
- Watermark — base sur une colonne incrementale (timestamp ou entier croissant)
- Change Data Feed (CDF) — capture native des changements Delta (insert, update, delete)
CDC Replication
Le mode le plus puissant. Active le Change Data Capture pour repliquer les insertions, mises a jour et suppressions en continu. Essentiel pour les tables avec des operations de type MERGE ou SCD (Slowly Changing Dimensions).
| Mode | Premiere exec. | Exec. suivantes | Cas d'usage |
|---|---|---|---|
| Full Copy | Tout copier | Tout re-copier | Tables petites, dimensions statiques |
| Incremental | Tout copier | Seulement les deltas | Tables volumineuses, append-mostly |
| CDC | Tout copier | Insert + Update + Delete | Tables avec MERGE/SCD |
En plus du mode de copie, vous choisissez la methode d'ecriture : Append (ajouter), Merge (upsert via une cle primaire), ou Overwrite (ecraser). Combinez CDC + Merge pour une replication fidele de votre source.
03. Watermark vs Change Data Feed — le bon choix
C'est LA question que tout Data Engineer se pose en configurant une Copy Job incrementale depuis un Lakehouse. Depuis fevrier 2026, vous avez le choix entre deux approches. Voyons les differences.
Change Data Feed (CDF)
- Capture les INSERT, UPDATE et DELETE
- Natif Delta Lake — zero configuration cote source
- Detecte les suppressions physiques
- Pas besoin de choisir une colonne
- Ideal pour les tables avec MERGE
Watermark
- Base sur une colonne timestamp / entier croissant
- Fonctionne meme sans CDF active
- Compatible sources non-Delta
- Ne detecte PAS les suppressions
- Ideal pour les tables append-only
Le mode Watermark ne detecte pas les suppressions physiques (DELETE). Si votre table source contient des deletes, utilisez imperativement le CDF. Sinon, votre destination conservera des lignes fantomes qui n'existent plus dans la source.
Comment choisir ?
La regle est simple :
- Table Delta avec MERGE/UPDATE/DELETE frequents → CDF (Change Data Feed)
- Table append-only avec colonne de date fiable → Watermark
- Source non-Delta (SQL Server, Oracle, etc.) → Watermark (CDF non disponible)
- Besoin de capturer les suppressions → CDF, pas le choix
Pour un Lakehouse Fabric, activez toujours le CDF sur vos tables cibles (delta.enableChangeDataFeed = true). Meme si vous n'en avez pas besoin aujourd'hui, ca ne coute rien et ca vous donne la flexibilite pour plus tard.
04. Column Mapping — transformer a la volee
C'est l'une des nouveautes les plus attendues de la Copy Job. Le Column Mapping permet de renommer des colonnes et convertir des types de donnees directement pendant la copie — y compris en mode CDC.
Pourquoi c'est un game changer
Avant cette feature, si vos noms de colonnes source et destination ne correspondaient pas (par exemple CustID cote source et customer_id cote Lakehouse), vous deviez ajouter un Dataflow Gen2 ou un Notebook entre les deux pour faire la transformation. Ca signifiait :
- Un artefact supplementaire a maintenir
- De la consommation de CU (Capacity Units) pour une transformation triviale
- Plus de complexite dans le pipeline
Desormais, le Column Mapping pousse cette logique directement dans la Copy Job. Moins d'artefacts, moins de compute, moins de maintenance.
Column Mapping : ce qui est supporte
Renommage de colonnes (source → destination), conversion de types (string → int, date → timestamp...), et ce sur les 3 modes : Full Copy, Incremental Watermark, et CDC Replication.
En eliminant les couches de transformation intermediaires (Dataflow, Notebook), le Column Mapping reduit directement la consommation de Capacity Units. C'est du compute en moins, sans compromis sur la qualite des donnees.
05. Copy Job vs Copy Activity vs Mirroring
Fabric propose trois outils de deplacement de donnees. Lequel utiliser ? Voici un comparatif clair.
| Critere | Copy Job | Copy Activity | Mirroring |
|---|---|---|---|
| Complexite | Faible (guidee) | Moyenne (pipeline) | Faible (automatique) |
| Orchestration | Autonome ou via Pipeline | Toujours dans un pipeline | Automatique continu |
| Transformation | Column Mapping | Column Mapping + expressions | Aucune |
| CDC | Oui (CDF + Watermark) | Via configuration manuelle | Oui (natif, temps reel) |
| Scheduling | Multi-schedule integre | Via triggers pipeline | Continu (pas de schedule) |
| Cas d'usage ideal | Ingestion batch/incr. multi-tables | Orchestration complexe | Replication temps reel |
Copy Job = ingestion simplifiee multi-tables sans pipeline. Copy Activity = quand vous avez besoin d'orchestration complexe (conditions, boucles, dependances). Mirroring = replication temps reel sans latence, mais sans transformation possible.
06. Copy Job Activity — le meilleur des deux mondes
Depuis janvier 2026, la Copy Job Activity est en GA. C'est une brique qui permet d'executer une Copy Job a l'interieur d'un pipeline Data Factory.
Pourquoi c'est puissant ? Parce que vous combinez la simplicite de la Copy Job (configuration guidee, gestion d'etat automatique, multi-tables) avec la puissance d'orchestration des pipelines (conditions, boucles, dependances, event triggers).
Cas d'usage concret
Imaginons un workflow d'ingestion :
- Un event trigger detecte un nouveau fichier dans ADLS
- Le pipeline lance une Copy Job Activity pour ingerer les donnees dans le Lakehouse
- Un Notebook Activity execute les transformations silver/gold
- Un email est envoye au data owner avec le rapport d'execution
Tout ca dans un seul pipeline, avec la Copy Job qui gere automatiquement l'incremental et le schema mapping.
{
"name": "IngestAndTransform",
"activities": [
{
"name": "IngestFromSource",
"type": "CopyJob",
"typeProperties": {
"copyJobId": "<your-copy-job-id>"
}
},
{
"name": "TransformSilver",
"type": "SparkNotebook",
"dependsOn": [
{ "activity": "IngestFromSource", "conditions": ["Succeeded"] }
]
}
]
}
07. Bonnes pratiques et pieges a eviter
Les bonnes pratiques
1. Activez le CDF par defaut sur vos tables Delta
Meme si vous faites du full copy aujourd'hui, activez delta.enableChangeDataFeed = true. Ca vous donne la flexibilite de passer en incremental sans reconfiguration.
2. Utilisez le Truncate avant Full Load
Si vous faites un full copy vers une destination existante, activez l'option Truncate destination before full load. Cela evite les doublons et garantit une synchronisation parfaite.
3. Parametrisez vos connexions avec Variable Library
Pour le CI/CD, externalisez vos connexions dans une Variable Library. La meme Copy Job peut etre deployee en dev, staging et prod avec des connexions differentes injectees a chaque stage.
4. Privilegiez la Copy Job Activity pour l'orchestration
Si votre ingestion fait partie d'un workflow plus large (transformation, notification, validation), encapsulez la Copy Job dans un pipeline via la Copy Job Activity plutot que de dupliquer la logique.
Les pieges a eviter
Si votre source fait des DELETE physiques et que vous utilisez le mode Watermark, la destination ne sera jamais nettoyee. Les lignes supprimees cote source resteront dans la destination. Utilisez le CDF pour ces cas.
Modifier la colonne incrementale dans les settings de la Copy Job declenche un reset automatique. Le prochain run fera un full copy complet. Soyez vigilant si vous editez une Copy Job en production.
Si vous utilisez la Variable Library ou les Relative References pour le CI/CD, vos artefacts doivent avoir les memes noms en dev, staging et prod. LH_Dev vs LH_Prod va casser le deploiement.
Σ Recapitulatif
Voici ce qu'il faut retenir sur la Copy Job :
| Feature | Statut | A retenir |
|---|---|---|
| Copy Job | GA | Ingestion simplifiee, multi-tables, zero pipeline |
| Incremental Copy (CDF) | GA | Capture INSERT + UPDATE + DELETE natif Delta |
| Incremental Copy (Watermark) | GA | Alternative sans CDF, pas de detection des DELETE |
| Column Mapping (CDC) | GA | Renommage et conversion de types pendant la copie |
| Copy Job Activity | GA | Copy Job orchestree dans un pipeline |
| Variable Library | GA | Parametrisation des connexions pour CI/CD |
| CDC SAP → S3/GCS | PREVIEW | Replication multi-cloud depuis SAP Datasphere |
La Copy Job n'est plus un simple outil de copie brute. Avec le Column Mapping, le choix CDF vs Watermark, et l'integration dans les pipelines via la Copy Job Activity, c'est devenu un outil d'ingestion complet qui couvre la majorite des cas d'usage courants en Data Engineering.
Mon conseil : si vous utilisez encore des Copy Activities "nues" pour de l'ingestion multi-tables sans logique d'orchestration complexe, migrez vers des Copy Jobs. La gestion d'etat automatique et le multi-schedule natif vont vous simplifier la vie.
Des questions ou des retours d'experience ? Retrouvez-moi sur LinkedIn.
Sources & References
- What is Copy Job in Data Factory - Microsoft Learn
- Copy Job Enhancements on Incremental Copy and CDC - Microsoft Fabric Blog
- Change Data Capture (CDC) in Copy Job - Microsoft Learn
- Comparing Copy Job, Mirroring, Copy Activity - Microsoft Learn
- Copy Job Activity GA - Microsoft Fabric Blog
- Microsoft Fabric Top 3 Nouveautes Fevrier 2026 - Antoine Wang