10 — Analytics Platforms

Concevoir l'analytique et le traitement de données → entrepôts/big data (Synapse, Databricks, Fabric), ingestion (Data Factory), temps-réel (Stream Analytics) : choisir selon OLTP vs OLAP, batch vs streaming, volume et profil utilisateur.

A. Vocabulaire analytics

A.1 OLTP vs OLAP

🎯 Au 305 : dès qu'on dit "transactional / OLTP" → Azure SQL ou Cosmos. Dès qu'on dit "OLAP DW structuré pour BI récurrent" → Dedicated SQL pool / Fabric Warehouse.

A.2 MPP vs SMP (en 2 lignes)

• SMP (single machine, scale vertical) = Azure SQL DB / MI / on VM.
• MPP (N nodes en parallèle, scale horizontal) = Synapse Dedicated SQL pool (le seul MPP managé Azure).

Pourquoi ça compte : 100 TB à scanner → SMP rame, MPP splitte sur 60 nodes en parallèle.

A.3 HNS (Hierarchical Namespace)

• Sans HNS (Blob classique) : folders = préfixes (illusion). Rename /raw/2024 → /archive/2024 (1 TB) = re-copy tout.
• Avec HNS (ADLS Gen2) : vrais folders + atomic rename en ms. Hadoop/Spark exigent un vrai filesystem.

A.4 ABFS (driver ADLS Gen2)

• ABFS (abfss://) = driver Hadoop pour ADLS Gen2 → code Spark/Hive marche tel quel.
• Remplace l'ancien WASB (Blob classique).
• 🎯 Migration Hadoop on-prem → Azure : ADLS Gen2 + ABFS.

A.5 POSIX ACLs vs RBAC

• RBAC = accès gros grain (Storage Account / container niveau).
• POSIX ACLs (HNS) = granularité dossier/fichier.
• Best practice : RBAC pour le large + ACLs pour le métier fin par dossier.

A.6 HTAP (Hybrid Transactional/Analytical)

Idée : faire de l'analyse sur tes données OLTP en quasi-temps réel, sans ralentir l'OLTP.

Le problème : tu as Cosmos DB qui prend les commandes (OLTP, ultra-rapide). Si tu lances une grosse query d'analytics dessus pour faire un dashboard, ça ralentit les écritures clients. La solution HTAP : Azure recopie en arrière-plan tes data OLTP vers une copie analytique séparée (~5 min de latence). Tu queries cette copie sans impacter l'OLTP.

Services Azure qui font du HTAP : Synapse Link (legacy) et Fabric Mirroring (moderne).

A.7 Data Governance : Microsoft Purview vs Unity Catalog

Le problème : dans une boîte, tu as 50 sources de data (SQL on-prem, Azure SQL, Cosmos, Databricks, fichiers SharePoint, AWS RDS, etc.). Comment savoir qui possède quoi, qui peut accéder à quoi, où vivent les PII ?

🎯 "Gouvernance sur tout l'estate (au-delà de Databricks)" → Purview. "Gouvernance interne Databricks" → Unity Catalog.

A.8 Concepts à connaître en awareness (sans deep-dive)

Tu n'as pas besoin de maîtriser ces concepts en profondeur pour le 305, mais tu dois reconnaître les mots-clés si une question les utilise.

Medallion architecture (Bronze / Silver / Gold)

Façon d'organiser un data lake en 3 couches : bronze (data brute), silver (nettoyée), gold (agrégée prête pour BI). C'est juste une convention d'organisation des dossiers.

Delta Lake

Format de fichier moderne au-dessus de Parquet (format compressé pour analytics). Ajoute des features transactions ACID + rollback temporel que Parquet pur n'a pas. Utilisé par défaut par Databricks et Fabric.

Lakehouse pattern

Idée moderne de combiner data lake (stockage cheap) + data warehouse (queries rapides) dans une seule plateforme au lieu de les avoir séparés. Poussé par Databricks (Delta Lake) et Microsoft Fabric (OneLake).

Unités pricing

Tu n'as pas à connaître les détails, juste savoir qu'elles existent :

• DWU = unité Synapse Dedicated SQL pool
• DBU = unité Databricks
• vCore = unité générique Azure SQL / Synapse Serverless

B. ADLS Gen2 — fondation du data lake

B.1 C'est quoi

Storage Account + HNS activé → vrais folders, ACLs POSIX, optimisé big data. Fondation data lake Azure compatible Hadoop/Spark/Databricks/Synapse.

B.2 Caractéristiques

• Built sur Blob → tiers (Hot/Cool/Cold/Archive), lifecycle, encryption marchent
• Multi-protocol : Blob API + ADLS driver (abfss://) + NFSv3
• Compatible natif : Hadoop, Spark, Databricks, Synapse
• Organisation type :

/raw       → brut ingéré (immutable, partitionné par date)
/cleansed  → nettoyé (silver)
/curated   → prêt analytics (gold)

B.3 Tiers / SKU

• Performance : Standard / Premium (low-latency)
• Redundancy : LRS / ZRS / GRS / RA-GRS / GZRS
• Access tiers Blob : Hot / Cool / Cold / Archive (lifecycle policies)

B.4 Quand l'utiliser

• Workload big data / analytics nécessitant vrai filesystem (Spark, Hadoop).
• Besoin granularité ACLs POSIX dossier/fichier (vs RBAC SA-level).
• Migration Hadoop on-prem → cloud (avec ABFS driver).
• Medallion architecture (bronze/silver/gold).

B.5 Pièges 305

• 🚨 HNS = irréversible → cocher à la création (sinon SA = Blob classique).
• 🚨 WASB driver legacy → utiliser ABFS (abfss://) pour ADLS Gen2.
• 🚨 Tier Archive incompatible avec lecture Spark directe (rehydrate avant).

C. Synapse Analytics — la plateforme unifiée

C.1 C'est quoi

Plateforme unifiée : DW + big data + integration + viz dans un seul Workspace. Couvre OLAP MPP, query data lake serverless, Spark, KQL, pipelines.

C.2 Les composants du Workspace

Synapse n'est pas UN service mais un container qui héberge plusieurs "pools" + features. Tu choisis le bon outil selon ton besoin :

C.3 Quel composant pour quel scénario — LE tableau exam

C.4 Charger data du lake → Dedicated SQL pool (vue d'ensemble)

Tu n'as pas à connaître les commandes T-SQL, juste savoir qu'il y a 3 façons :

🎯 Au 305 : si la question dit "load data du lake vers le Dedicated SQL pool en 2026" → COPY statement.

C.5 Synapse Link — les 4 variantes (awareness)

Synapse Link = HTAP : réplique data OLTP vers Synapse pour analytics, sans impacter l'OLTP.

⚠️ 2026 : MS pousse Fabric Mirroring pour nouveaux projets (GA pour Azure SQL DB / Snowflake / SQL MI / PostgreSQL flex ; Cosmos DB Mirroring = Preview, NoSQL uniquement). Synapse Link for Cosmos DB = « no longer supported for new projects » (ne plus l'utiliser en greenfield) — mais Synapse Link reste un concept d'objectif AZ-305.

C.6 Pièges 305

• 🚨 Dedicated SQL pool ≠ Azure SQL DB. MPP analytics ≠ SMP OLTP.
• 🚨 Serverless SQL pool = query files sans provisioning (différent de Dedicated qui est provisionné).
• 🚨 PolyBase legacy, COPY moderne → MS recommande COPY pour nouveaux projets.
• 🚨 Synapse Pipelines = ADF sous le capot, juste intégré dans le workspace.

💡 Détail DP-203 (hors scope AZ-305) : Dedicated SQL pool exige un choix de distribution table par table (Hash / Round-robin / Replicate) pour perf. À savoir que ça existe au 305, pas à choisir.

D. Azure Databricks

D.1 C'est quoi

Plateforme Spark managée par Databricks (partner MS). Référence pour ML / data science avancé + Delta Lake + Unity Catalog governance.

D.2 Architecture rapide

D.3 Tiers / SKU

Pricing : DBU + VMs Azure sous-jacentes (double facturation).

D.4 Quand l'utiliser

• ML / Data Science avancé (MLflow natif excellent vs Synapse Spark).
• Delta Lake medallion architecture (ACID, time-travel, MERGE).
• Streaming massif / complex events / fraud detection ML scoring.
• Migration Hadoop on-prem (alternative à Synapse Spark).

D.5 Synapse Spark pool vs Databricks

🎯 Question 305 : "ML avancé / Delta Lake medallion / Unity Catalog" → Databricks. "Plateforme unifiée Azure sans ML poussé" → Synapse.

D.6 Pièges 305

• 🚨 Standard tier ≠ prod : pas d'Unity Catalog, RBAC, SSO, audit → toujours Premium en prod.
• 🚨 Photon = activé par défaut sur DBR 9.1 LTS+ (dépend du runtime/compute, pas du tier). Les vrais différenciateurs Premium = Unity Catalog, RBAC, SSO, audit.
• 🚨 Pricing double : DBU et VMs Azure (penser au TCO).
• 🚨 All-purpose cluster oublié allumé = facture explose → préférer Job clusters auto-terminate.

E. Azure Data Factory (ADF)

E.1 C'est quoi

ETL/ELT orchestration drag-and-drop + code. Pipeline d'activités pour ingérer, transformer, charger data multi-sources vers Azure.

E.2 Architecture rapide

E.3 Les 3 Integration Runtimes

E.4 Triggers types

E.5 Pricing

Pas de tier ADF — pricing par :

• Pipeline orchestration (per activity run)
• Data movement (per DIU/hour)
• Data Flow (per vCore-hour cluster Spark sous le capot)

E.6 ADF vs Synapse Pipelines

Même engine sous le capot. Différence :

• ADF standalone : service séparé, simple, intégration avec n'importe quel target.
• Synapse Pipelines : ADF intégré dans le workspace Synapse → orchestration unifiée Spark/SQL pool + UI partagée.

🎯 "Multi-sources vers data lake, projet greenfield" → ADF ou Synapse Pipelines (les 2 OK). Si Synapse déjà en place → Pipelines pour cohérence.

E.7 Pièges 305

• 🚨 Self-hosted IR obligatoire pour accès on-prem (outbound only).
• 🚨 Data Flow = Spark sous le capot → coûte plus cher que Copy Activity simple.
• 🚨 Tumbling Window ≠ Schedule : Tumbling = incrémental avec watermark, Schedule = cron.
• 🚨 Azure-SSIS IR = pour lift-and-shift SSIS legacy, pas pour nouveaux ETL.

🚨 ADF — Schema Drift detection : Quand le schema source change (colonne ajoutée/renommée) → Mapping Data Flow le détecte automatiquement via l'option "Allow schema drift" (à activer dans Source + Sink settings). Use case : ingestion CSV partenaires dont structure évolue sans préavis → schema drift accepte les colonnes nouvelles, les propage en sortie sans casser le pipeline. ⚠️ Distractor exam : "détecter colonnes ajoutées dans CSV source automatiquement" → ADF Mapping Data Flow + Allow schema drift (pas pipeline Copy Activity manuel, pas Synapse pipeline qui n'a pas cette feature aussi développée).

F. Stream Analytics (awareness 305)

F.1 C'est quoi

Service managé de stream processing. SQL-like queries (T-SQL extensions) sur des flux en quasi-temps réel. No-code/low-code.

F.2 Quand l'utiliser

• IoT telemetry → filter + aggregate → dashboard / alertes.
• Détection simple d'événements (seuil dépassé, count par fenêtre).
• ETL streaming léger sans code.

F.3 Stream Analytics vs Databricks Streaming

🎯 Question 305 : "Streaming simple SQL-like no-code" → Stream Analytics. "Streaming complex events + ML" → Databricks Streaming.

F.4 Sources / cibles supportées

• Inputs : Event Hubs, IoT Hub, Blob/ADLS
• Outputs : Power BI (live dashboard), Cosmos DB, Azure SQL, Blob/ADLS, Event Hubs, Functions

G. Microsoft Fabric (awareness 305)

Plateforme analytics unifiée moderne lancée par MS en 2023. MS pousse Fabric comme l'évolution de Synapse + Power BI + ADF dans une seule expérience SaaS.

G.1 Composants Fabric (vue 305)

G.2 Quand le mentionner au 305

• "Plateforme analytics unifiée moderne all-in-one" → Microsoft Fabric (réponse 2025+).
• "Replica near-real-time OLTP pour analytics, projet nouveau" → Fabric Mirroring (Synapse Link sunset progressivement).
• 🎯 Au 305 : awareness suffisant. Pas de deep dive sur la config.

G.3 Pièges 305

• 🚨 Synapse encore objectif d'exam AZ-305 actuel — Fabric mentionné en awareness "futur direction".
• 🚨 Fabric ≠ Synapse. Fabric inclut Synapse-like features mais c'est une nouvelle plateforme SaaS avec OneLake comme storage unifié.

H. Architectures types AZ-305

Modern DW (le grand classique)

[Sources] → [ADF / Synapse Pipelines] → [ADLS Gen2 raw→cleansed→curated]
                                                ↓
                          [Synapse Spark / Databricks] (transform)
                                                ↓
                          [Synapse Dedicated SQL pool] → [Power BI]

Real-time (streaming + batch combinés)

[Sources] → [Event Hub / Kafka]
   ├─ [Stream Analytics / Databricks Streaming] → Cosmos/SQL real-time
   └─ [ADF + Databricks/Synapse] → ADLS → DW → Power BI

HTAP (Synapse Link)

[Cosmos OLTP] → [Synapse Link] → [Synapse Spark/SQL] (analytics SANS impact OLTP)
[Azure SQL OLTP] → [Synapse Link] → [Synapse]

Lakehouse moderne (Databricks ou Fabric)

[Sources] → [ADF/Spark] → [ADLS Gen2 / OneLake + Delta Lake]
                              ├─ /bronze (raw)
                              ├─ /silver (cleansed)
                              └─ /gold (BI-ready)
                              ↓
                          [Databricks SQL / Fabric Warehouse / Power BI]

Serverless data lake query

[ADLS Gen2 avec CSV/Parquet] ←──── OPENROWSET ──── [Synapse Serverless SQL pool]
                                                    pay-per-TB scanné, zéro provisioning

I. Decision tree analytics

Par source de data

D'où vient ta data ?
├─ Data lake (fichiers CSV/Parquet/JSON sur ADLS) ?
│   ├─ Query ad-hoc / ponctuel, zéro provisioning  → Synapse Serverless SQL pool 
│   ├─ DW structuré récurrent pour BI              → Synapse Dedicated SQL pool (load depuis lake)
│   ├─ Transformation big data / ML                → Databricks (recommandé) ou Synapse Spark
│   └─ Plateforme moderne unifiée (greenfield)     → Microsoft Fabric (Lakehouse + Warehouse)
│
├─ Base OLTP (Cosmos / Azure SQL / SQL Server) ?
│   ├─ Besoin analytics quasi-live sans impacter   → Synapse Link / Fabric Mirroring (HTAP)
│   └─ Analytics offline batch                     → ADF/Spark → ADLS → DW
│
├─ Streaming (Event Hub / Kafka / IoT) ?
│   ├─ Simple aggregations SQL-like, no-code       → Stream Analytics
│   └─ Complex events / ML scoring temps-réel      → Databricks Streaming
│
├─ Source on-prem (SQL Server, Oracle, files) ?
│   └─ Ingestion vers Azure                        → ADF + Self-hosted IR
│
└─ Multi-sources SaaS (Salesforce, SAP, etc.) ?
    └─ Orchestration ETL                           → ADF (70+ connectors)

Par besoin business

Quel est ton objectif ?
├─ BI / Power BI dashboards récurrents             → Dedicated SQL pool / Fabric Warehouse
├─ Data Science / ML avec MLflow                   → Databricks Premium 
├─ Exploration ad-hoc data lake (1× par mois)      → Serverless SQL pool
├─ Lift-and-shift DW SQL Server / Teradata         → Dedicated SQL pool (+ ADLS staging + ADF transport)
├─ Lift-and-shift SSIS packages                    → ADF + Azure-SSIS IR
├─ Time-series / logs analytics KQL                → Azure Data Explorer (ou Synapse Data Explorer pool)
├─ Dashboard temps-réel IoT/devices                → Event Hub → Stream Analytics → Power BI
├─ Détection fraude streaming + ML                 → Event Hub → Databricks Streaming
├─ Gouvernance data multi-source (catalogue, PII)  → Microsoft Purview 
├─ Gouvernance interne Databricks                  → Unity Catalog
└─ Migration Hadoop on-prem complète               → Databricks (ou Synapse Spark) + ADLS Gen2 + ABFS

K. Scénarios 305 → outil

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Distribution (retail) — Modern Data Warehouse batch nocturne

Contexte business : Enseigne de distribution, système financier on-prem (1 TB, +5%/an), batch nocturne qui doit finir avant 3h. Besoin : reporting analytique + self-service pour le management, base future pour la data science. Données company confidential. Choix architectural : pipeline ELT par batch ADF → ADLS Gen2 (couches medallion) → Dedicated SQL pool → Power BI, dans une Landing Zone hub-and-spoke. Le Dedicated SQL pool (MPP) traite gros volumes pour du BI récurrent. Architecture / pattern :

• Ingestion : ADF + Self-hosted IR (pour lire la source on-prem), Tumbling Window + watermark pour l'incrémental
• Stockage : ADLS Gen2 (HNS), couches bronze/silver/gold, chiffré at-rest + in-transit
• Transform : Databricks (ou Synapse Spark) silver→gold ; chargement vers le Dedicated SQL pool via COPY statement
• Serving : Power BI ; gouvernance Purview (classification PII, lineage) Trade-offs assumés :
• Gain : MPP scalable pour le BI, pause/resume du pool hors fenêtres = coût maîtrisé, fenêtre bout-en-bout < 90 min tenable
• Perte : données en J+1 (pas de temps réel) ; le Dedicated SQL pool coûte même à faible charge (atténué par le pause) Pièges à éviter :
• Charger les gros volumes via bcp/SqlBulkCopy (lent) → utiliser COPY statement
• Oublier le Self-hosted IR pour la source on-prem (l'Azure IR ne voit pas le on-prem)
• HNS est irréversible : l'activer dès la création du Storage Account 📐 Réf. Architecture Center — ADF baseline en Azure Landing Zone (medallion lakehouse) : architecture de référence avec hub-and-spoke, landing zones CAF, sécurité confidentielle, fenêtre < 90 min. Lien

Scénario 2 : Mobilité (IoT) — Streaming temps réel vers dashboard

Contexte business : Opérateur de flotte, 10 000 véhicules envoyant de la télémétrie (position, vitesse, alertes). Besoin : dashboard live + alertes, latence minimale, sans équipe streaming dédiée. Choix architectural : Event Hubs → Stream Analytics → Power BI, avec capture vers ADLS pour pouvoir rejouer. Stream Analytics choisi car il filtre/agrège en SQL-like, sans code. Architecture / pattern :

• Ingest : Event Hubs (partitionné par véhicule/zone) ; Event Hubs Capture → ADLS Gen2 (replay/recovery)
• Process : Stream Analytics (fenêtres temporelles, agrégations) ; sortie directe Power BI (dataset streaming)
• Archivage froid : sortie parallèle Blob/ADLS pour un batch ultérieur Trade-offs assumés :
• Gain : la plus faible latence event→Power BI sur Azure ; aucun code ; déployable en minutes
• Perte : pas de ML complexe inline ; Stream Analytics peu rentable si le débit est faible / pas vraiment temps réel Pièges à éviter :
• Power BI ne gère pas le partitionnement de sortie → aligner les clés en amont
• SU > 80% = signal pour scale-out ; throttling Event Hubs = quota dépassé
• Pour du scoring ML temps réel (anti-fraude), passer à Databricks Structured Streaming (autre scénario) 📐 Réf. Architecture Center — Stream processing with Azure Stream Analytics : pattern de référence streaming, considérations Cost (tarif par SU) et Operational Excellence (monitoring SU/Event Hubs). Lien

Scénario 3 : Industrie multi-domaines — BI self-service unifiée (greenfield Fabric)

Contexte business : Groupe industriel avec plusieurs domaines data (production, ventes, supply), équipes métier autonomes voulant du self-service BI sans dupliquer la donnée, gouvernance à l'échelle du tenant. Projet neuf 2026. Choix architectural : Microsoft Fabric (OneLake + Lakehouse + Warehouse + Power BI Direct Lake), gouverné par Purview, dans des Data Management Landing Zones CAF. Fabric choisi car OneLake stocke la donnée une seule fois pour tous les moteurs. Architecture / pattern :

• Stockage unique : OneLake (format Delta) → pas de copies entre domaines
• Ingest/transform : Data Pipelines + Notebooks Fabric (medallion par domaine)
• Serving : Warehouse (T-SQL) + Power BI Direct Lake (lecture directe du Delta, sans import)
• Temps réel optionnel : Mirroring (Azure SQL DB / Snowflake en GA ; Cosmos DB NoSQL en preview)
• Gouvernance : Purview dans une Data Management Landing Zone (1 par tenant Entra) ; capacité Fabric par domaine Trade-offs assumés :
• Gain : une seule copie de donnée pour tous les moteurs, Direct Lake = pas de refresh d'import, pause de capacité = coût flexible
• Perte : plateforme SaaS récente (moins mature que Synapse+Databricks séparés) ; le sizing de capacité impacte pipelines ET requêtes en même temps Pièges à éviter :
• Cosmos DB mirroring encore en Preview (NoSQL only) → pas en prod ; Synapse Link Cosmos « non supporté pour les nouveaux projets »
• Fabric ≠ Synapse : nouvelle plateforme, OneLake comme storage unifié (ne pas confondre les composants)
• Dimensionner la capacité Fabric selon la maturité/prévisibilité du domaine (partagée vs dédiée) 📐 Réf. CAF — Azure architecture for a unified data platform (Data Management Landing Zones) : place Purview + capacité Fabric en DMLZ, gouvernance tenant-wide, séparation domaines/plateforme. Lien

DEMO

Demo Portail — Créer un Data Factory

1. Data factories > + Create
2. Onglet Basics : sub, RG, name (globalement unique), region
3. Onglet Git configuration : optionnel (Azure DevOps / GitHub pour versionning)
4. Onglet Networking : Public / Private (Managed VNet)
5. Review + Create
6. Une fois créé : Open Azure Data Factory Studio (UI séparée)

Demo Portail — Synapse workspace + SQL pool + Spark pool

1. Créer le workspace

1. Azure Synapse Analytics > + Create
2. Onglet Basics : RG, Workspace name, Region
3. Select Data Lake Storage Gen2 : Storage Account avec HNS + File system name raw
4. Onglet Security : SQL admin login + password + (recommandé) Entra admin
5. Onglet Networking : Managed virtual network : Enable, Public access : Disabled (prod)
6. Review + Create (5-10 min)
7. Ouvrir : Open Synapse Studio

2. Dedicated SQL pool

1. mysynapse > Analytics pools > SQL pools > + New
2. Name mydw, Performance level DW100c
3. Review + Create → Pause/Resume via la blade pour économiser

3. Apache Spark pool

1. mysynapse > Analytics pools > Apache Spark pools > + New
2. Name myspark, Node size Medium, Autoscale 3-10 nodes
3. Automatic pausing : Enabled (15 min idle), Spark version 3.4
4. Review + Create

📝 Pour Serverless SQL pool : il est créé automatiquement à la création du workspace (built-in, pas à provisionner).

Demo Portail — Créer un Databricks workspace

1. Azure Databricks > + Create
2. Onglet Basics : RG, Workspace name, Region, Pricing Tier : Premium
3. Onglet Networking : VNet injection si isolation
4. Review + Create → Launch Workspace
5. Dans Databricks UI :
   • Compute > + Create cluster (autoscale, runtime, Photon enabled)
   • Workspace > Create > Notebook (Python/SQL/Scala)
   • Jobs > + Create Job pour scheduler
   • Catalog (Unity Catalog) : metastore + catalogs + schemas

Demo Portail — ADLS Gen2 + POSIX ACL

1. Storage accounts > + Create
2. Onglet Basics : RG, Name (globalement unique), Performance Standard, Redundancy LRS/ZRS/GRS
3. Onglet Advanced : Hierarchical namespace : Enabled (irréversible)
4. Review + Create
5. Créer container : Storage Account > Containers > + Container → name raw
6. Créer folders : raw > + Add Directory → year=2026, month=01
7. POSIX ACL : naviguer vers le folder > ⋯ > Manage ACL
   • Access : Add principal (user/group/SP) + Read/Write/Execute
   • Default : ACL héritée par nouveaux fichiers du folder
   • Save

⚠️ HNS = irréversible, à cocher impérativement à la création pour tout workload analytics.

Demo Portail — ADF pipeline simple (Blob → SQL DB)

Concept-level (pas step-by-step Data Flow).

1. Studio ADF > Manage > Linked services > + New :
   • Azure Blob Storage (auth via Managed Identity)
   • Azure SQL Database (auth MI + rôle db_datawriter)
2. Author > Datasets > + New :
   • Source : Blob > DelimitedText (CSV)
   • Sink : SQL DB > Table cible
3. Author > Pipelines > + New :
   • Drag Copy data activity → configurer Source + Sink + Mapping
   • (Optionnel) Data Flow : Filter → Derived Column → Aggregate → Sink
4. Author > Triggers > + New :
   • Schedule (cron) ou Event-based (blob créé) ou Tumbling Window (incrémental watermark)
5. Debug dans le designer → Publish all pour activer

Demo Portail — ADF Self-hosted IR (accès on-prem)

1. Studio ADF > Manage > Integration runtimes > + New > Self-Hosted
2. Donner un name → générer 2 auth keys (sauvegarder)
3. Télécharger l'Integration Runtime agent (Windows)
4. Installer sur VM on-prem (ou Azure VM faisant proxy)
5. Entrer l'auth key → register → status Running dans ADF
6. Linked Services peuvent pointer SQL Server on-prem, file shares, etc.