Azure Data Factory

Azure Data Factory déplace les données d’un point à un autre : d’une base sur site vers un entrepôt cloud, d’une API vers un lac de données, d’un fichier déposé vers une table exploitable.

C’est un service ancien à l’échelle du cloud, présent dans une grande partie des systèmes d’information français équipés Azure. Pour beaucoup de DSI, il reste la colonne vertébrale de l’alimentation quotidienne, celle qu’on ne montre jamais en réunion mais qui tourne toutes les nuits.

Un service lié décrit une connexion : où se trouve la source, avec quelles informations d’identification. Un jeu de données décrit ce qu’on lit ou écrit, une table, un fichier, un dossier. Une activité est une opération unitaire, copier, exécuter une procédure, appeler un carnet de notes. Un pipeline enchaîne ces activités avec des conditions et des dépendances : c’est l’unité qu’on déclenche et qu’on supervise.

Reste le runtime d’intégration, c’est-à-dire le moteur qui exécute. C’est la notion la plus mal comprise et la plus structurante, alors elle mérite sa propre section.

Le runtime Azure est managé et s’exécute dans le cloud. C’est le réglage par défaut, sans rien à installer, mais il ne peut atteindre que des sources joignables depuis Internet ou par un réseau privé configuré.

Le runtime auto-hébergé est un agent installé sur une machine de votre réseau, et c’est la seule façon propre d’atteindre une base sur site derrière un pare-feu. L’agent initie lui-même la connexion sortante vers Azure, ce qui évite d’ouvrir un port entrant. Dans le contexte français, où beaucoup d’ERP restent hébergés en interne, ce composant décide souvent de la faisabilité du projet.

Un avertissement qui vaut cher : un runtime auto-hébergé installé sur une seule machine devient un point de défaillance unique, et cette machine finit toujours par redémarrer un mardi soir. Sur un flux critique, il se déploie sur plusieurs nœuds.

Le runtime SSIS, enfin, sert à rejouer des paquets existants sans les réécrire. C’est une passerelle de migration, utile quand l’historique est lourd et qu’une réécriture en bloc n’est pas finançable.

La facturation combine plusieurs assiettes, mais la surprise vient presque toujours de la même.

Les exécutions d’activité coûtent peu et ne sont jamais le poste principal. Le déplacement de données se facture au temps de copie multiplié par les unités d’intégration allouées, ce qui reste prévisible.

Ce sont les flux de données de mappage qui font monter l’addition. Ces transformations sans code s’exécutent sur un cluster Spark managé, facturé au temps de calcul, et il faut compter le temps de démarrage du cluster à chaque exécution si aucune durée de vie n’est configurée. Un flux court lancé toutes les quinze minutes peut ainsi passer plus de temps à démarrer qu’à travailler, pour un résultat identique.

Le réflexe qui économise le plus est simple : regrouper les traitements au lieu de multiplier les petits flux fréquents, et configurer une durée de vie de cluster pour mutualiser les démarrages. Cela ne demande pas de réécriture, seulement une relecture du planning.

Quand vous devez lire des sources sur site, d’abord. Le runtime auto-hébergé règle proprement un problème que peu d’outils traitent aussi bien, et sans ouvrir de port entrant. Quand votre système d’information est déjà sur Azure, ensuite, puisque authentification, réseau, supervision et facturation sont mutualisés. Et quand vous avez un historique SSIS que vous ne pouvez pas réécrire d’un coup.

Si vos transformations sont du SQL sur un entrepôt, en revanche, un outil de transformation dédié, versionné et testé sera plus lisible et moins cher que des flux de mappage. Si vous partez de zéro sur Microsoft, Data Factory dans Fabric reprend les mêmes notions dans un environnement unifié : autant commencer là et éviter une migration dans deux ans. Et si vous cherchez à orchestrer de la logique métier complexe, un orchestrateur centré sur le code offrira plus de finesse sur les dépendances et les tests.

Nous concevons les pipelines d’ingestion, avec le traitement incrémental, la gestion des rejets et la reprise après incident. Nous installons et dimensionnons les runtimes auto-hébergés, y compris en redondance quand le flux le justifie, et nous les supervisons.

Nous travaillons aussi la facture, en regroupant les flux et en réglant la durée de vie des clusters, et nous mettons en place le versionnement Git des pipelines avec le déploiement entre environnements. Quand la question de Fabric se pose, nous évaluons ce qui se transpose, ce qui se réécrit, et à quel moment cela vaut la peine.

Comment lire une base de données sur site depuis Azure Data Factory ?

En installant un runtime d’intégration auto-hébergé sur une machine du réseau interne. Cet agent initie lui-même la connexion sortante vers Azure, ce qui évite d’ouvrir un port entrant sur le pare-feu. C’est la seule méthode propre pour atteindre un ERP ou une base restée en interne. Sur un flux critique, il faut le déployer sur plusieurs machines pour éviter un point de défaillance unique.

Pourquoi ma facture Azure Data Factory est-elle si élevée ?

Le plus souvent à cause des flux de données de mappage, qui s’exécutent sur un cluster Spark managé facturé au temps de calcul, temps de démarrage compris. Un flux court lancé très fréquemment peut passer plus de temps à démarrer son cluster qu’à traiter les données. Regrouper les traitements et configurer une durée de vie de cluster réduit fortement le coût sans rien réécrire.

Faut-il migrer d’Azure Data Factory vers Fabric ?

Pas nécessairement. Data Factory dans Fabric reprend les mêmes notions de pipeline, d’activité et de jeu de données, mais dans un environnement unifié avec OneLake. Pour un nouveau projet sur Microsoft, commencer directement dans Fabric évite une migration ultérieure. Pour un existant qui fonctionne, la bascule se décide au cas par cas, notamment selon la dépendance à un runtime auto-hébergé.

Quelle différence entre Azure Data Factory et dbt ?

Ils ne font pas le même métier. Azure Data Factory déplace et orchestre : il va chercher la donnée là où elle est et la dépose ailleurs. dbt transforme la donnée une fois qu’elle est arrivée dans l’entrepôt, en SQL versionné et testé. Les deux se combinent très souvent, Data Factory pour l’ingestion et dbt pour la modélisation.

• Microsoft Fabric, où Data Factory se poursuit aujourd’hui.
• dbt, pour les transformations SQL, plus lisibles qu’un flux de mappage.
• Airflow et Dagster, pour l’orchestration centrée sur le code.
• Power BI, la restitution en bout de chaîne.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : runtime d’intégration auto-hébergé.