Accueil A propos Tech Stack Projets Blog Tracker
Retour au Blog

Copy Job dans Fabric :
Le Guide Complet pour Data Engineers

Full copy, incremental load, CDC, column mapping, Watermark vs Change Data Feed... Tout ce que vous devez savoir sur la Copy Job de Data Factory pour industrialiser vos pipelines d'ingestion.

Sommaire
  1. C'est quoi une Copy Job ?
  2. Les 3 modes de copie : Full, Incremental, CDC
  3. Watermark vs Change Data Feed — le bon choix
  4. Column Mapping — transformer a la volee
  5. Copy Job vs Copy Activity vs Mirroring
  6. Copy Job Activity — le meilleur des deux mondes
  7. Bonnes pratiques et pieges a eviter
  8. Recapitulatif

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.

Inspiration

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
Update Methods

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.

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
Attention — Limitation Watermark

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 frequentsCDF (Change Data Feed)
  • Table append-only avec colonne de date fiableWatermark
  • Source non-Delta (SQL Server, Oracle, etc.)Watermark (CDF non disponible)
  • Besoin de capturer les suppressionsCDF, pas le choix
Mon conseil

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.

Impact sur les couts

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
En resume

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 :

  1. Un event trigger detecte un nouveau fichier dans ADLS
  2. Le pipeline lance une Copy Job Activity pour ingerer les donnees dans le Lakehouse
  3. Un Notebook Activity execute les transformations silver/gold
  4. 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.

JSON pipeline_with_copy_job.json
{
  "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

Piege #1 — Watermark sur table avec DELETE

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.

Piege #2 — Reset involontaire de l'incremental

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.

Piege #3 — Ne pas standardiser les noms entre environnements

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