Azure Data Factory : Pipeline ETL en 13 Étapes [2026]

Azure Data Factory reste l’un des services les plus recherchés de l’écosystème Azure en France, avec plusieurs milliers de recherches mensuelles sur le sujet. Pourtant, la majorité des tutoriels disponibles datent d’avant l’arrivée de Microsoft Fabric et ne couvrent ni la tarification réelle du service, ni les pièges qui font grimper la facture en fin de mois. Ce tutoriel construit un pipeline ETL complet, de la fabrique de données jusqu’au monitoring, avec le détail exact des coûts par composant et les erreurs les plus fréquentes rencontrées en production.

L’objectif n’est pas de reproduire la documentation officielle, déjà exhaustive, mais de dérouler un scénario réaliste : copier des données brutes, les nettoyer, les agréger, puis les planifier et les surveiller comme le ferait une équipe data en production. Chaque étape inclut à la fois le geste dans l’interface graphique Data Factory Studio et l’équivalent en ligne de commande ou en JSON, pour que le pipeline reste reproductible et versionnable plutôt que dépendant d’une suite de clics.

Pourquoi Azure Data Factory reste incontournable en 2026

Azure Data Factory (ADF) est le service d’intégration de données serverless d’Azure. Il orchestre des pipelines qui copient, transforment et déplacent des données entre des sources aussi variées que Blob Storage, SQL Server, Salesforce ou des API REST. Contrairement à un ETL classique installé sur un serveur, ADF facture à l’usage : pas d’abonnement fixe, pas de licence par cœur de calcul.

Le service découpe sa facturation en quatre briques distinctes : l’orchestration des pipelines, le déplacement de données (Copy Activity), l’exécution des flux de mappage (Mapping Data Flows) et les heures d’Integration Runtime. Chacune a son propre tarif, et c’est justement là que beaucoup d’équipes se font surprendre. Un pipeline mal conçu qui déclenche trop d’exécutions ou qui laisse un cluster Spark tourner inutilement peut transformer une facture de 23 dollars par mois en plusieurs centaines de dollars.

Microsoft pousse activement la migration d’Azure Data Factory et d’Azure Synapse Pipelines vers Fabric Data Factory, avec des outils de conversion gratuits et guidés. Fabric ajoute du Copilot pour la création de pipelines, une intégration agentique capable d’écrire et de diagnostiquer des jobs Copy, et un support des DAG Apache Airflow. Mais ADF classique reste la porte d’entrée la plus simple pour qui démarre un projet de données sur Azure sans vouloir basculer tout son SI vers Fabric. C’est ce chemin que ce tutoriel va suivre.

Prérequis et versions utilisées dans ce tutoriel

Avant de commencer, réunissez les éléments suivants. Un abonnement Azure actif est indispensable, avec un compte disposant du rôle Contributeur (ou Propriétaire) sur le groupe de ressources cible. Le tutoriel utilise l’interface Azure Data Factory Studio, accessible directement depuis un navigateur, donc aucune installation locale d’IDE n’est strictement nécessaire pour les premières étapes. La documentation officielle Microsoft Learn liste l’ensemble des tutoriels complémentaires si vous souhaitez approfondir un scénario particulier après celui-ci.

Outil ou composant	Version / configuration utilisée	Obligatoire
Abonnement Azure	Pay-As-You-Go ou crédits Azure actifs	Oui
Azure CLI	Dernière version stable (az –version)	Recommandé
Azure Data Factory Studio	Interface web, aucune installation	Oui
Azure Storage Account	Niveau Standard, redondance LRS pour les tests	Oui
Base SQL cible	Azure SQL Database niveau Basic ou Serverless	Optionnel selon le scénario
Self-Hosted Integration Runtime	Dernière version du package MSI Windows	Uniquement pour sources on-premise
Navigateur	Edge ou Chrome à jour	Oui

Comptez environ 90 minutes pour dérouler l’ensemble des étapes, en incluant les temps d’attente liés au provisionnement des ressources Azure (la création d’une fabrique de données prend generalement moins de deux minutes, mais le premier démarrage d’un cluster de Data Flow peut prendre cinq à sept minutes). Prévoyez également un budget de test : les manipulations de ce tutoriel, si vous nettoyez les ressources ensuite, coûtent généralement moins de 2 euros.

Étape 1 : créer la fabrique de données (Data Factory)

Connectez-vous au portail Azure et recherchez “Data Factory” dans la barre de recherche. Cliquez sur Créer. Renseignez le groupe de ressources, la région (privilégiez une région européenne comme France Central ou West Europe pour des raisons de latence et de conformité RGPD) et un nom unique pour votre fabrique.

az group create --name rg-adf-tutoriel --location westeurope

az datafactory create \
  --resource-group rg-adf-tutoriel \
  --factory-name adf-tutoriel-shattered \
  --location westeurope

Une fois la ressource créée, ouvrez Azure Data Factory Studio depuis le portail. C’est dans cette interface graphique que vous allez construire l’intégralité du pipeline : sources de données, transformations, déclencheurs et supervision.

Étape 2 : provisionner le stockage source et cible

Un pipeline ETL a besoin d’au moins deux emplacements de stockage : une source et une destination. Pour ce tutoriel, créez un compte de stockage avec deux conteneurs Blob, l’un nommé “raw” pour les données brutes et l’autre “curated” pour les données transformées.

az storage account create \
  --name stadftutoriel2026 \
  --resource-group rg-adf-tutoriel \
  --location westeurope \
  --sku Standard_LRS \
  --kind StorageV2

az storage container create --name raw --account-name stadftutoriel2026
az storage container create --name curated --account-name stadftutoriel2026

Déposez ensuite un fichier CSV de test dans le conteneur “raw”. N’importe quel jeu de données tabulaire fait l’affaire : un export de ventes, un fichier de logs ou un jeu de données public. L’important est d’avoir des colonnes clairement typées (dates, nombres, texte) pour tester correctement les transformations à l’étape suivante.

Étape 3 : configurer les services liés (Linked Services)

Un service lié est la définition de connexion vers une source ou une destination de données : chaîne de connexion, identifiants, méthode d’authentification. Dans Data Factory Studio, allez dans l’onglet Gérer, puis Services liés, et cliquez sur Nouveau.

Sélectionnez Azure Blob Storage comme type de service lié. Pour l’authentification, privilégiez une identité managée système plutôt qu’une clé de compte de stockage stockée en clair. Cette approche évite d’avoir un secret à faire tourner régulièrement et s’aligne avec les recommandations de durcissement Azure. Accordez ensuite le rôle “Storage Blob Data Contributor” à l’identité managée de la fabrique sur le compte de stockage concerné.

az role assignment create \
  --assignee $(az datafactory show --name adf-tutoriel-shattered --resource-group rg-adf-tutoriel --query identity.principalId -o tsv) \
  --role "Storage Blob Data Contributor" \
  --scope $(az storage account show --name stadftutoriel2026 --resource-group rg-adf-tutoriel --query id -o tsv)

Testez la connexion depuis l’interface avant de continuer. Un échec à ce stade est presque toujours lié à un délai de propagation du rôle RBAC, qui peut prendre jusqu’à cinq minutes après l’attribution.

Étape 4 : définir les jeux de données (Datasets)

Un dataset pointe vers un emplacement précis à l’intérieur d’un service lié : un fichier, un dossier, une table. Créez un premier dataset de type “Delimited Text” pointant vers le conteneur “raw”, puis un second pointant vers “curated”. Cochez la case “Détecter automatiquement les types de colonnes” lors de l’aperçu du schéma pour gagner du temps sur le mapping.

C’est également à cette étape que vous paramétrez le format de fichier (encodage UTF-8, délimiteur virgule ou point-virgule selon l’origine des données, présence ou non d’un en-tête). Une erreur fréquente consiste à laisser le délimiteur par défaut sur une virgule alors que le fichier source, exporté depuis Excel en France, utilise un point-virgule.

Étape 5 : construire le pipeline avec une activité Copy

Dans l’onglet Auteur, créez un nouveau pipeline et glissez une activité “Copy data” sur le canevas. Dans l’onglet Source, sélectionnez le dataset pointant vers “raw”. Dans l’onglet Récepteur (Sink), sélectionnez le dataset pointant vers “curated”.

Voici la définition JSON équivalente d’une activité Copy simple, utile si vous préférez déployer votre pipeline via une pipeline CI/CD plutôt qu’à la souris :

{
  "name": "CopyRawToCurated",
  "type": "Copy",
  "inputs": [{ "referenceName": "DatasetRawCsv", "type": "DatasetReference" }],
  "outputs": [{ "referenceName": "DatasetCuratedCsv", "type": "DatasetReference" }],
  "typeProperties": {
    "source": { "type": "DelimitedTextSource", "storeSettings": { "type": "AzureBlobStorageReadSettings", "recursive": true } },
    "sink": { "type": "DelimitedTextSink", "storeSettings": { "type": "AzureBlobStorageWriteSettings" } },
    "enableStaging": false
  },
  "policy": { "timeout": "0.01:00:00", "retry": 2, "retryIntervalInSeconds": 30 }
}

Le paramètre “retry” mérite votre attention. Deux tentatives avec un intervalle de 30 secondes suffisent pour absorber une majorité d’erreurs transitoires de réseau, sans pour autant masquer un vrai problème de configuration en boucle.

Étape 6 : ajouter une transformation avec un Mapping Data Flow

Un simple Copy déplace les données sans les transformer. Pour appliquer une vraie logique métier (filtrage, agrégation, jointure, nettoyage de colonnes), ajoutez un Mapping Data Flow. Dans l’onglet Auteur, créez un nouveau Data Flow et ajoutez une source pointant vers votre dataset “raw”.

Ajoutez ensuite une transformation “Filter” pour exclure les lignes incomplètes, puis une transformation “Aggregate” si vous souhaitez calculer des sommes ou des moyennes par catégorie. Terminez par un récepteur (Sink) pointant vers “curated”. Les Data Flows tournent sur un cluster Spark managé par Azure : le premier démarrage (cold start) prend entre cinq et sept minutes, ce qui surprend souvent les débutants qui pensent que le pipeline est bloqué.

source1 filter(
  !isNull(id) && !isNull(montant),
  disableUpdatePreview: true
) ~> FiltreLignesValides

FiltreLignesValides aggregate(
  groupBy(categorie),
  montant_total = sum(montant)
) ~> AgregationParCategorie

Ce code correspond au langage d’expression des Data Flows (Data Flow Script), visible en cliquant sur “Script” en haut à droite du canevas graphique. Il permet de versionner vos transformations sous forme de texte plutôt que de captures d’écran.

Étape 7 : configurer l’Integration Runtime adapté

L’Integration Runtime (IR) est le moteur de calcul qui exécute réellement vos activités. Data Factory propose trois types d’IR. L’Azure Integration Runtime managé convient à la majorité des scénarios cloud-to-cloud. L’Azure Managed VNET Integration Runtime ajoute une isolation réseau pour les environnements qui exigent une connectivité privée. Le Self-Hosted Integration Runtime s’installe sur une machine on-premise ou une VM, et sert à atteindre des sources de données qui ne sont pas exposées publiquement, comme une base SQL Server derrière un pare-feu d’entreprise.

Point important pour le budget : le Self-Hosted Integration Runtime est gratuit jusqu’à cinq nœuds. Seul le coût de la machine qui l’héberge (VM, électricité, maintenance) s’ajoute à la facture Azure. C’est souvent l’option la plus économique pour des scénarios hybrides, à condition d’avoir déjà une VM disponible.

# Téléchargement et enregistrement du Self-Hosted IR (à exécuter sur la VM on-premise)
# 1. Récupérer la clé d'authentification depuis Data Factory Studio > Gérer > Integration Runtimes
# 2. Installer le package MSI téléchargé depuis le portail
# 3. Enregistrer le runtime avec la clé fournie
.\DiaHostService.exe -RegisterNewNode "CLE_AUTHENTIFICATION_ICI"

Étape 8 : ajouter un déclencheur (Trigger) planifié

Un pipeline sans déclencheur ne s’exécute que manuellement. Pour automatiser l’ETL, ajoutez un déclencheur planifié. Dans l’onglet Auteur, ouvrez votre pipeline, cliquez sur Ajouter un déclencheur, puis Nouveau/Modifier. Choisissez un type “Schedule” et définissez une récurrence, par exemple toutes les nuits à 2h du matin.

Il existe aussi des déclencheurs basés sur les événements de stockage (Storage Event Trigger), qui lancent le pipeline automatiquement dès qu’un nouveau fichier apparaît dans un conteneur Blob. Cette approche évite d’attendre une fenêtre planifiée et convient mieux aux flux quasi temps réel.

{
  "name": "DeclencheurNocturne",
  "type": "ScheduleTrigger",
  "typeProperties": {
    "recurrence": {
      "frequency": "Day",
      "interval": 1,
      "startTime": "2026-09-22T02:00:00Z",
      "timeZone": "Romance Standard Time"
    }
  }
}

Étape 9 : paramétrer le pipeline pour le réutiliser

Un pipeline codé en dur pour un seul fichier n’a que peu de valeur en production. Ajoutez des paramètres au niveau du pipeline (par exemple le nom du dossier source, la date de traitement) et référencez-les dans vos datasets via des expressions dynamiques. Cela permet de réutiliser le même pipeline pour traiter les données de différentes journées ou de différentes entités, simplement en changeant la valeur du paramètre au moment de l’exécution.

@concat('raw/', formatDateTime(pipeline().parameters.dateExecution, 'yyyy/MM/dd'), '/')

Cette expression construit dynamiquement un chemin de dossier basé sur la date passée en paramètre, un schéma courant pour organiser des données par partition temporelle.

Étape 10 : ajouter des retries conditionnels et gérer les échecs

Fabric Data Factory a introduit en 2026 les retries conditionnels d’activités, une fonctionnalité qui permet de définir des stratégies de réexécution différenciées selon le type d’erreur rencontrée plutôt qu’un simple nombre de tentatives fixe. Dans Azure Data Factory classique, vous pouvez reproduire une logique similaire en combinant l’activité “If Condition” avec les codes d’erreur retournés par l’activité précédente.

Ajoutez systématiquement un chemin d’échec (flèche rouge) après chaque activité critique, connecté à une activité “Web” qui envoie une notification vers Teams ou un webhook de supervision. Sans ce garde-fou, un pipeline planifié qui échoue silencieusement une nuit peut rester en échec pendant des jours sans que personne ne le remarque.

Étape 11 : publier et déployer le pipeline

Tant que vous n’avez pas cliqué sur “Publier tout”, vos modifications restent dans une branche de travail invisible en production. Pour un usage en équipe, connectez votre fabrique de données à un dépôt Git (Azure DevOps ou GitHub) depuis l’onglet Gérer. Cela active un vrai flux de collaboration avec des branches de fonctionnalités et des demandes de tirage, au lieu de modifications directes sur l’environnement live.

az datafactory pipeline create \
  --resource-group rg-adf-tutoriel \
  --factory-name adf-tutoriel-shattered \
  --name PipelineETLPrincipal \
  --pipeline @pipeline-definition.json

Étape 12 : surveiller les exécutions et diagnostiquer les échecs

L’onglet Superviser de Data Factory Studio liste chaque exécution de pipeline avec son statut, sa durée et le détail des activités. Cliquez sur une exécution pour ouvrir la vue Gantt et repérer immédiatement quelle activité a bloqué l’ensemble du flux. Pour un monitoring plus poussé, connectez votre fabrique à Azure Monitor et créez des alertes basées sur les métriques “Pipeline Failed Runs” ou “Activity Failed Runs”, en suivant le guide officiel de gestion des coûts et de la supervision.

az monitor metrics alert create \
  --name "AlerteEchecPipelineADF" \
  --resource-group rg-adf-tutoriel \
  --scopes $(az datafactory show --name adf-tutoriel-shattered --resource-group rg-adf-tutoriel --query id -o tsv) \
  --condition "count PipelineFailedRuns > 0" \
  --description "Alerte en cas d'échec de pipeline Azure Data Factory"

Étape 13 : maîtriser la facture avec les bonnes pratiques de coûts

La tarification d’Azure Data Factory se décompose en quatre lignes distinctes sur votre facture Azure. Comprendre chacune permet d’anticiper les dérapages avant qu’ils n’arrivent.

Composant facturé	Tarif	Remarque
Orchestration de pipeline	1 $ par 1 000 exécutions d’activité	Franchise gratuite de 1 000 runs par mois
Data movement (Copy Activity)	0,25 $ par DIU-heure	4 DIU par défaut, jusqu’à 256 en auto-détection
Mapping Data Flow (usage général)	environ 0,27 $ par vCore-heure	Cluster minimum de 8 vCores, démarrage 5-7 min
Mapping Data Flow (optimisé mémoire)	environ 0,34 $ par vCore-heure	Pour les jointures et agrégations lourdes
Integration Runtime SSIS managé	0,84 $ par nœud-heure	S’ajoute au coût de la VM sous-jacente
Self-Hosted Integration Runtime	Gratuit jusqu’à 5 nœuds	Seul le coût de la VM hôte s’applique

Pour une petite équipe qui exécute quelques pipelines quotidiens sans Data Flow lourd, la facture mensuelle tourne généralement autour de 23 dollars, et reste sous la barre des 50 dollars. À l’inverse, une entreprise qui fait tourner des centaines de pipelines avec des transformations Data Flow complexes peut voir sa facture grimper entre 1 270 et plus de 2 500 dollars par mois. L’écart tient presque toujours au nombre d’heures de cluster Spark consommées par les Data Flows, qui sont de loin le poste le plus coûteux du service.

Trois leviers réduisent concrètement la facture. Réduisez le TTL (Time To Live) des clusters de Data Flow pour éviter de payer un cluster qui reste chaud sans exécution active. Regroupez les petites activités de copie en batchs plutôt que de multiplier les runs individuels, pour rester sous la franchise gratuite d’orchestration. Enfin, privilégiez le Self-Hosted Integration Runtime pour les charges hybrides récurrentes plutôt que l’IR managé, dès lors que vous disposez déjà d’une VM sous-utilisée.

Azure Data Factory face à Synapse Pipelines et Fabric Data Factory

Trois produits Microsoft se recoupent aujourd’hui sur l’orchestration de données, ce qui crée une vraie confusion pour les équipes qui démarrent un projet. Azure Data Factory reste l’option la plus simple pour un besoin ETL classique sur Azure, avec une tarification granulaire par composant. Azure Synapse Pipelines reprend le même moteur d’exécution mais l’intègre directement à l’environnement Synapse Analytics, ce qui a du sens si vos données finissent de toute façon dans un entrepôt Synapse ou un lac de données exploité par Spark.

Fabric Data Factory va plus loin en intégrant Copilot pour générer et diagnostiquer des pipelines, une fonctionnalité d’intégration agentique capable d’écrire et d’opérer des jobs Copy ainsi qu’un support natif des DAG Apache Airflow avec un mode d’écriture “code-first” piloté par des agents IA. Microsoft propose des outils de migration gratuits pour faire basculer les pipelines Azure Data Factory ou Synapse existants vers Fabric Data Factory, y compris les Mapping Data Flows, désormais disponibles en préversion dans Fabric avec un assistant de migration guidé.

Pour une équipe qui débute et n’a pas encore de licence Fabric, Azure Data Factory reste le point d’entrée le plus rapide et le moins coûteux. La bascule vers Fabric se justifie surtout quand l’organisation adopte déjà l’écosystème Fabric complet pour la Business Intelligence et le lakehouse.

Un autre critère de choix, souvent négligé, concerne l’équipe qui va maintenir le pipeline dans la durée. Azure Data Factory, avec son interface stable depuis plusieurs années, convient bien à des équipes qui veulent une courbe d’apprentissage courte et une documentation abondante en français. Fabric Data Factory, plus récent, évolue vite : de nouvelles fonctionnalités comme les Variable Libraries ou l’intégration agentique sortent régulièrement en préversion, ce qui demande une veille technique plus soutenue pour suivre les changements de comportement d’une version à l’autre. Ce rythme d’évolution n’est pas un défaut en soi, mais il change la charge de maintenance à anticiper avant de migrer un pipeline critique en production.

Trois cas d’usage concrets pour un pipeline Azure Data Factory

Au-delà de l’exemple pédagogique de ce tutoriel, trois scénarios reviennent le plus souvent dans les projets réels. Le premier est la consolidation de ventes multi-magasins : chaque point de vente dépose un export quotidien dans un conteneur Blob dédié, et un pipeline Data Factory les agrège chaque nuit dans une table Azure SQL Database consultée le lendemain matin par les équipes commerciales. Ce scénario s’appuie presque entièrement sur des activités Copy et un Data Flow d’agrégation simple, sans nécessiter de calcul distribué lourd.

Le deuxième scénario concerne l’ingestion de journaux applicatifs à des fins d’analyse de sécurité ou de conformité. Ici, un déclencheur basé sur les événements de stockage lance le pipeline dès qu’un nouveau fichier de logs arrive, plutôt que d’attendre une fenêtre planifiée. Le volume étant souvent imprévisible, il est recommandé de laisser Data Factory ajuster automatiquement le nombre de DIU alloués à l’activité Copy plutôt que de fixer une valeur statique, pour éviter les ralentissements lors des pics de trafic.

Le troisième scénario, plus complexe, est la migration progressive d’un entrepôt de données on-premise vers Azure. Dans ce cas, le Self-Hosted Integration Runtime devient central : il tourne sur une VM à l’intérieur ou à proximité du réseau d’entreprise et extrait les données d’un SQL Server historique vers Azure Data Lake Storage, sans jamais exposer la base de données directement sur Internet. Ce schéma hybride, gratuit jusqu’à cinq nœuds côté Integration Runtime, permet d’étaler une migration sur plusieurs mois sans devoir tout basculer d’un coup.

Sécuriser vos pipelines : identités managées, chiffrement et résidence des données

Un pipeline ETL manipule souvent des données sensibles : fichiers clients, exports comptables, journaux applicatifs. Azure Data Factory chiffre par défaut les données au repos et en transit, mais la sécurité réelle du service dépend surtout de la façon dont vous configurez les accès. La règle de base reste la même que sur le reste d’Azure : aucune identité humaine ne devrait détenir de clé d’accès permanente à un service lié. Utilisez systématiquement des identités managées, combinées à des rôles RBAC scoppés au strict nécessaire (un compte de stockage précis, pas l’abonnement entier).

Pour les organisations soumises à des exigences de résidence des données, comme les administrations ou les acteurs de la santé, deux réglages comptent particulièrement. D’abord, le choix de la région Azure : France Central garde les données sur le territoire français, tandis que West Europe (Pays-Bas) reste dans l’Union européenne mais hors de France. Ensuite, l’activation d’un Managed VNET Integration Runtime permet de faire transiter les données via un réseau privé plutôt que par l’Internet public, ce qui réduit la surface d’exposition et facilite les audits de conformité RGPD.

Activez également le chiffrement avec une clé gérée par le client (Customer-Managed Key) si votre politique de sécurité interne l’exige, en s’appuyant sur Azure Key Vault. Cette configuration donne à votre organisation le contrôle total sur la rotation et la révocation des clés de chiffrement, plutôt que de dépendre uniquement des clés gérées par Microsoft. Enfin, journalisez systématiquement les accès et les modifications de pipeline vers Log Analytics ou un SIEM externe : en cas d’incident, retracer qui a modifié quelle activité et à quel moment fait souvent la différence entre une investigation rapide et plusieurs jours d’incertitude.

5 erreurs fréquentes à éviter avec Azure Data Factory

Laisser les clés de compte de stockage en clair dans les services liés. Utilisez systématiquement une identité managée plutôt qu’une clé stockée dans la configuration du service lié, qui reste exposée à quiconque a accès en lecture à la fabrique de données.

Ignorer le coût des Data Flows en environnement de développement. Le mode débogage des Data Flows garde un cluster actif pendant une durée définie (par défaut 60 minutes), même si vous n’exécutez aucun test pendant ce temps. Pensez à désactiver le mode débogage en fin de session de travail.

Multiplier les petites activités Copy au lieu de les regrouper. Chaque exécution d’activité compte dans le calcul de l’orchestration. Mille petits fichiers copiés un par un consomment la totalité de la franchise gratuite mensuelle en une seule journée.

Oublier de paramétrer les délimiteurs et l’encodage des fichiers texte. Un fichier CSV exporté en France utilise souvent un point-virgule et un encodage Windows-1252, alors que Data Factory suppose par défaut une virgule et de l’UTF-8.

Ne pas versionner les pipelines dans Git. Travailler directement sur l’environnement live sans intégration Git rend impossible tout retour arrière propre en cas d’erreur de configuration, et bloque toute collaboration à plusieurs sur la même fabrique de données. Prévoyez au minimum une branche “collaboration” partagée par l’équipe et une branche “adf_publish” générée automatiquement, qui contient le code compilé prêt à déployer vers un environnement de production distinct.

Exemple de sortie attendue après exécution

Une fois le pipeline exécuté avec succès, l’onglet Superviser affiche un résumé similaire à celui-ci :

Pipeline: PipelineETLPrincipal
Statut: Succeeded
Heure de début: 2026-09-22T02:00:14Z
Durée: 00:04:32
Activités exécutées: 3
  - CopyRawToCurated: Succeeded (durée 00:01:12, lignes copiées: 48213)
  - DataFlowFiltreAgregation: Succeeded (durée 00:03:05, lignes en sortie: 6427)
  - NotificationSucces: Succeeded (durée 00:00:02)

Le champ “lignes copiées” et “lignes en sortie” permet de vérifier rapidement que le volume de données traité correspond à vos attentes. Un écart important entre les deux, sans filtre volontaire dans le Data Flow, signale généralement un problème de mapping de schéma.

Guide de dépannage : 8 problèmes courants et leurs solutions

Erreur “Forbidden” lors du test de connexion d’un service lié. Le rôle RBAC attribué à l’identité managée n’a pas encore propagé. Patientez cinq minutes et retestez, ou vérifiez que le rôle exact “Storage Blob Data Contributor” a bien été assigné au bon scope.

Le Data Flow reste bloqué sur “En file d’attente” pendant plusieurs minutes. C’est le comportement normal du démarrage à froid d’un cluster Spark managé, qui prend entre cinq et sept minutes. Activez un pool Data Flow en mode “Always On” en environnement de production critique pour éliminer ce délai, en sachant que cela facture le cluster en continu.

Message “BadRequest: type mismatch” lors du mapping de colonnes. Le schéma détecté automatiquement diffère entre la source et la destination. Ouvrez l’onglet “Projection” du dataset concerné et forcez manuellement le type de colonne attendu (chaîne, entier, date).

Le Self-Hosted Integration Runtime apparaît “Hors ligne” dans le portail. Vérifiez que le service Windows “Diahostservice” tourne bien sur la machine hôte et que les ports sortants 443 et 8060 ne sont pas bloqués par un pare-feu d’entreprise.

Le déclencheur planifié ne se déclenche jamais. Vérifiez que le déclencheur a bien été démarré (statut “Started”) après publication, et non simplement enregistré. Un déclencheur créé mais jamais démarré reste inactif indéfiniment sans message d’erreur explicite.

Facture Azure anormalement élevée sur la ligne Data Factory. Consultez la vue “Cost Analysis” du portail Azure filtrée sur la ressource Data Factory, puis croisez avec l’onglet Superviser pour identifier quel pipeline consomme le plus d’heures de Data Flow. C’est presque toujours un cluster Data Flow oublié en mode débogage actif.

Erreur de délimiteur ou d’encodage sur un fichier CSV français. Rouvrez le dataset, changez le délimiteur de colonnes en point-virgule et forcez l’encodage en Windows-1252 ou ISO-8859-1 selon l’origine du fichier, plutôt que de laisser la détection automatique.

Le pipeline échoue avec “Timeout” sur une grosse copie de fichier. Augmentez la valeur de “timeout” dans la politique de l’activité Copy, et envisagez d’activer le parallélisme en augmentant le nombre de DIU alloués (jusqu’à 256 en auto-détection) pour accélérer le transfert.

Le pipeline s’exécute avec succès mais la table cible reste vide. Vérifiez en priorité le mapping de schéma dans l’onglet “Mapping” de l’activité Copy : si aucune colonne source n’a été associée à une colonne cible, Data Factory peut considérer l’exécution comme réussie tout en n’écrivant aucune ligne. Vérifiez aussi que le filtre appliqué dans un Data Flow en amont n’exclut pas silencieusement l’intégralité du jeu de données.

Conseils avancés pour aller plus loin

Une fois le pipeline de base maîtrisé, plusieurs axes permettent de le rendre plus robuste. Ajoutez des Variable Libraries pour centraliser les valeurs de configuration partagées entre plusieurs pipelines, comme les noms d’environnement ou les chemins de dossiers standards. Cette fonctionnalité, apparue avec l’orchestration modernisée de Fabric Data Factory, introduit aussi les “connection references” pour pointer vers des sources externes sans jamais exposer les secrets dans le code du pipeline, et les “item references” pour lier dynamiquement des lakehouses ou des notebooks.

Pensez également à découper vos pipelines complexes en sous-pipelines réutilisables, appelés via l’activité “Execute Pipeline”. Cette architecture modulaire facilite les tests unitaires et limite l’impact d’une modification à un seul composant plutôt qu’à l’ensemble du flux. Enfin, pour les environnements réglementés, activez le diagnostic logging vers un espace de travail Log Analytics : cela conserve un historique complet des exécutions au-delà de la rétention par défaut de l’onglet Superviser, utile en cas d’audit ou d’investigation post-incident.

Dernier conseil, souvent sous-estimé : documentez chaque pipeline directement dans l’interface, via le champ description disponible sur chaque activité et chaque pipeline. Six mois après la mise en production, personne ne se souvient exactement pourquoi telle activité applique tel filtre précis. Une description de deux phrases suffit généralement à éviter des heures de reverse engineering lors d’une future maintenance ou d’un transfert de compétences vers un nouveau membre de l’équipe.

Nettoyer les ressources après le tutoriel

Pour éviter toute facturation résiduelle, supprimez le groupe de ressources créé au début du tutoriel une fois vos tests terminés. Cette commande supprime en une seule opération la fabrique de données, le compte de stockage et toutes les ressources associées.

az group delete --name rg-adf-tutoriel --yes --no-wait

Vérifiez également, avant la suppression, qu’aucun déclencheur planifié n’est resté actif ailleurs si vous avez dupliqué certaines ressources dans un autre groupe. Un déclencheur orphelin continue de facturer des exécutions même si personne ne consulte plus les résultats.

Questions fréquentes sur Azure Data Factory

Azure Data Factory est-il gratuit ?

Non, mais le modèle 100 % à l’usage rend le coût d’entrée très bas. Sans exécution de pipeline, vous ne payez rien. Une petite équipe avec quelques pipelines quotidiens simples reste généralement sous les 50 dollars par mois.

Quelle est la différence entre Azure Data Factory et Fabric Data Factory ?

Azure Data Factory est un service Azure autonome dédié à l’orchestration ETL. Fabric Data Factory intègre les mêmes concepts de pipeline dans l’environnement unifié Microsoft Fabric, avec en plus Copilot, l’intégration agentique et le support natif d’Apache Airflow. Microsoft propose des outils gratuits pour migrer de l’un vers l’autre.

Combien coûte une activité de copie de données (Copy Activity) ?

0,25 dollar par DIU-heure. Par défaut, une activité Copy utilise 4 DIU, mais Data Factory peut monter automatiquement jusqu’à 256 DIU pour accélérer un transfert volumineux, ce qui augmente proportionnellement le coût.

Le Self-Hosted Integration Runtime est-il vraiment gratuit ?

Oui, jusqu’à cinq nœuds. Seul le coût de la machine virtuelle ou du serveur qui héberge le runtime s’ajoute à votre facture, ce qui en fait l’option la plus économique pour les scénarios hybrides avec des sources on-premise.

Peut-on utiliser Azure Data Factory sans écrire de code ?

Oui, l’interface Data Factory Studio permet de construire l’intégralité d’un pipeline par glisser-déposer, sans une ligne de code. Le code JSON et les scripts de Data Flow restent accessibles pour ceux qui préfèrent versionner leurs pipelines en texte.

Pourquoi mon Data Flow met-il autant de temps à démarrer ?

Les Data Flows s’exécutent sur un cluster Spark managé qui démarre à froid, ce qui prend entre cinq et sept minutes par défaut. Un pool Data Flow configuré en mode “Always On” élimine ce délai, au prix d’une facturation continue du cluster.

Azure Data Factory convient-il aux petites structures en France ?

Oui, notamment grâce au modèle de facturation à l’usage et à la franchise gratuite de 1 000 exécutions de pipeline par mois. Les régions Azure France Central et West Europe permettent en plus de garder les données dans l’Union européenne pour des raisons de conformité RGPD.

Comment surveiller les coûts d’Azure Data Factory en continu ?

Utilisez la vue “Cost Analysis” du portail Azure filtrée sur la ressource Data Factory, et croisez-la avec l’onglet Superviser de Data Factory Studio pour identifier précisément quel pipeline ou quel Data Flow consomme le plus d’heures de calcul.

Azure Data Factory : Pipeline ETL en 13 Étapes, 90 Min [2026]