i

Description

Un long pipeline traversant une vallée de montagne

Source

U.S. Geological Survey · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

CI/CD pour la data : bases, datamarts, pipelines et rapports

Vous saurez ce qui rend le CI/CD différent quand le produit contient de la donnée : l'état persiste, le retour arrière est (presque) impossible, les environnements réalistes sont coûteux et…

En bref

• Vous saurez ce qui rend le CI/CD différent quand le produit contient de la donnée : l'état persiste, le retour arrière est (presque) impossible, les environnements réalistes sont coûteux et sensibles.
• Vous connaîtrez les deux philosophies de déploiement de base de données (état déclaratif : dacpac/SSDT ; migrations versionnées : Flyway/Liquibase/scripts), l'idempotence et le rejeu, le déploiement en kits.
• Vous saurez tester des données et des transformations (tests de schéma, de règles, de réconciliation, de non-régression de chiffres), organiser des environnements avec données anonymisées, et traiter la volumétrie.
• Vous aurez un panorama (état 2026-10) de dbt, des pipelines Fabric / Data Factory, des rapports Power BI en PBIP/TMDL et des deployment pipelines.
• Vous disposerez de notes /5 de maturité par pratique et d'une liste de limites propres à la donnée.

Pré-requis : le socle commun est dans 10 CI/CD ; la lecture de 07 Méthodes spécifiques data (section DataOps) aide.

Sur cette page

1. 1. Ce qui change quand le produit contient de la donnée
   1. 🟢 Novice — le code est jetable, la donnée non
   2. 🟡 Pratique — ce qui reste identique
   3. 🔴 Expert — trois couches à déployer, trois rythmes
2. 2. Versionner une base : état ou migrations
   1. 🟢 Novice — deux façons de décrire une base en code
   2. 🟡 Pratique — forces et faiblesses
   3. 🔴 Expert — l'approche hybride, la plus fréquente en entreprise
3. 3. Idempotence, rejeu et reprise
   1. 🟢 Novice — pourquoi tout doit pouvoir être rejoué
   2. 🟡 Pratique — patrons d'idempotence
   3. 🔴 Expert — MERGE, déterminisme et fenêtres de rejeu
4. 4. Déploiement en kits d'installation
   1. 🟢 Novice — pourquoi des « kits »
   2. 🟡 Pratique — anatomie d'un bon kit
   3. 🔴 Expert — compatibilité entre versions de kit
5. 5. Tester les données et les transformations
   1. 🟢 Novice — quatre familles de tests
   2. 🟡 Pratique — des tests de transformation sur jeux contrôlés
   3. 🔴 Expert — la non-régression de chiffres
6. 6. Environnements, données réalistes et anonymisées
   1. 🟢 Novice — le dilemme
   2. 🟡 Pratique — anonymiser sans casser les tests
   3. 🔴 Expert — conformité et responsabilité
7. 7. Volumétrie et temps de traitement
   1. 🟢 Novice — le test sur « 1 000 lignes » ne prouve rien sur 100 millions
   2. 🟡 Pratique — les mesures à intégrer
   3. 🔴 Expert — la volumétrie comme dimension de conception de pipeline
8. 8. dbt et la transformation en code
   1. 🟢 Novice — ce que c'est
   2. 🟡 Pratique — ce qu'il apporte au CI/CD data
   3. 🔴 Expert — limites de dbt
9. 9. Pipelines Fabric et Data Factory
   1. 🟢 Novice — orchestrer les mouvements de données
   2. 🟡 Pratique — CI/CD dans Fabric (état 2026-10)
   3. 🔴 Expert — idempotence d'un pipeline d'orchestration
10. 10. Rapports Power BI : PBIP, TMDL, deployment pipelines
    1. 🟢 Novice — un rapport est aussi du code
    2. 🟡 Pratique — ce que le texte permet
    3. 🔴 Expert — limites et subtilités
11. 11. Rollback impossible sur la donnée
    1. 🟢 Novice — on ne « dé-charge » pas facilement
    2. 🟡 Pratique — les parades
    3. 🔴 Expert — réversibilité comme critère d'architecture
12. 12. Qualité continue en production
    1. 🟢 Novice — le pipeline ne s'arrête pas au déploiement
    2. 🟡 Pratique — les cinq piliers d'observabilité des données
    3. 🔴 Expert — le coût du bruit et le contrat de service
13. 13. Limites propres à la data
    1. 🟢 Novice — ce que le CI/CD ne résout pas ici
    2. 🟡 Pratique — arbitrer l'investissement
    3. 🔴 Expert — dérive des sources et contrats
14. 14. Notes de maturité des pratiques
15. 15. Contribution de l'IA
16. 16. Voir aussi

Niveau : 🟢→🔴

1. Ce qui change quand le produit contient de la donnée#

🟢 Novice — le code est jetable, la donnée non#

En CI/CD classique, déployer une nouvelle version remplace l'ancienne : l'application n'a pas d'état propre, on peut la reconstruire à l'identique. Dans un datamart, le produit est à la fois du code (tables, procédures, rapports) et un état (les lignes accumulées, historisées, parfois impossibles à reconstruire car la source a changé ou purgé).

Cinq conséquences, chacune développée plus loin :

🟡 Pratique — ce qui reste identique#

Les principes du socle (10 CI/CD) restent : tout versionné, reproductible, traçable, petits lots, promotion du même artefact, feedback rapide. La data ajoute des contraintes, elle n'invalide rien.

🔴 Expert — trois couches à déployer, trois rythmes#

Un produit BI se compose de couches aux rythmes et aux risques différents :

Il faut adapter le niveau de contrôle au risque de la couche : un rapport peut être déployé automatiquement après tests ; une migration qui supprime une colonne exige revue, sauvegarde vérifiée et fenêtre. Voir le thème Délais et industrialisation DataOps et Versionnement et industrialisation des rapports.

2. Versionner une base : état ou migrations#

🟢 Novice — deux façons de décrire une base en code#

🟡 Pratique — forces et faiblesses#

(Notes d'expert pour une équipe de 3 à 8 développeurs SQL Server ; dépendent de la discipline.)

Le paramètre BlockOnPossibleDataLoss de SqlPackage est une garde majeure : il bloque le déploiement si le delta peut faire perdre des données (suppression de table/colonne, rétrécissement de type). Bonne pratique documentée : le désactiver en développement, le garder activé en recette et production avec le même dacpac et des profils de publication différents (état 2026-10).

# Générer un script de déploiement SANS l'exécuter, pour relecture (production)
sqlpackage /Action:Script `
  /SourceFile:".\bin\Release\Datamart.dacpac" `
  /TargetConnectionString:"$cnxProd" `
  /OutputPath:".\delta_prod.sql" `
  /p:BlockOnPossibleDataLoss=True `
  /p:DropObjectsNotInSource=False

# Rapport de dérive : ce qui diffère entre le dacpac et la base cible
sqlpackage /Action:DeployReport `
  /SourceFile:".\bin\Release\Datamart.dacpac" `
  /TargetConnectionString:"$cnxProd" `
  /OutputPath:".\drift.xml"

DropObjectsNotInSource=False est le réglage prudent : l'outil ne supprime pas ce qui n'est pas dans le projet (objets créés par un tiers, tables de staging, éléments propres au client).

🔴 Expert — l'approche hybride, la plus fréquente en entreprise#

Dans les faits, on combine :

1. État pour les objets sans données ou rejouables : procédures, vues, fonctions (CREATE OR ALTER), droits. Le dépôt contient la dernière version.
2. Migrations pour les tables à données : ajout de colonne avec valeur par défaut, scission, fusion, transformation de type, backfill.
3. Un journal d'application (table dbo._SchemaHistory ou équivalent) indiquant version, date, auteur, empreinte du script, durée, résultat.

Modèle de script de migration idempotent et sûr :

-- 2026_10_07__Ajout_colonne_statut_visite.sql
SET XACT_ABORT ON;
BEGIN TRAN;

IF NOT EXISTS (SELECT 1 FROM sys.columns
               WHERE object_id = OBJECT_ID(N'[dbo].[VISITE]')
                 AND name = N'STATUT_COD')
BEGIN
    ALTER TABLE [dbo].[VISITE] ADD [STATUT_COD] varchar(10) NULL;
END;

-- Backfill borné et rejouable (ne touche que ce qui n'est pas encore rempli)
UPDATE v SET v.[STATUT_COD] = 'REALISEE'
FROM   [dbo].[VISITE] AS v
WHERE  v.[STATUT_COD] IS NULL
  AND  v.[DATE_REALISATION] IS NOT NULL;

COMMIT;

(Attention : un ALTER TABLE … ADD suivi d'un UPDATE référençant la nouvelle colonne dans le même lot peut échouer à la compilation (nom de colonne inconnu) ; séparer en lots GO, ou utiliser EXEC('…'), selon l'outil d'exécution. Sur grosse table, découper l'UPDATE par tranches — voir section 7.)

Outils de déploiement continu pour SQL : l'intégration à Azure Pipelines/TFS se fait par tâches d'installation SqlPackage, sqlcmd ou des scripts PowerShell ; sqlcmd a des options qui modifient le comportement (variables, interprétation de commandes) à connaître — en cas d'usage de kits, voir la section suivante. Voir GDS et données SQL/BI.

3. Idempotence, rejeu et reprise#

🟢 Novice — pourquoi tout doit pouvoir être rejoué#

Un script est idempotent si l'exécuter deux fois (ou dix) donne le même état que l'exécuter une fois. En data, c'est vital : un chargement tombe à 03 h 12 sur 4 tables sur 10 ; la reprise doit être sûre, sans doublons ni trous. Sans idempotence, chaque incident demande un nettoyage manuel — la principale source d'erreurs de production.

🟡 Pratique — patrons d'idempotence#

Patron « delete-insert par partition logique » (simple, robuste, rejouable) :

DECLARE @DateExploitation date = '2026-10-06';   -- paramètre, jamais GETDATE() dans le traitement

BEGIN TRAN;
DELETE FROM [dm].[FACT_VISITE] WHERE [DATE_VISITE] = @DateExploitation;

INSERT INTO [dm].[FACT_VISITE] ([VISITE_ID], [DATE_VISITE], [COMMERCIAL_ID], [CLIENT_ID], [DUREE_MIN])
SELECT s.[VISITE_ID], s.[DATE_VISITE], s.[COMMERCIAL_ID], s.[CLIENT_ID], s.[DUREE_MIN]
FROM   [staging].[VISITE] AS s
WHERE  s.[DATE_VISITE] = @DateExploitation;
COMMIT;

🔴 Expert — MERGE, déterminisme et fenêtres de rejeu#

• MERGE de SQL Server : puissant mais historiquement entouré de défauts documentés ; pour les cas critiques, beaucoup d'équipes préfèrent les instructions explicites UPDATE puis INSERT (dans la même transaction, avec verrous adaptés) ou le patron delete-insert. À vous d'évaluer sur votre version ; à vérifier : l'état des corrections de bogues selon votre version/CU.
• Déterminisme : un traitement qui dépend de l'heure, d'un NEWID(), d'un ordre non spécifié (TOP sans ORDER BY), d'une table non figée ne se rejoue pas à l'identique. Les clés de substitution (surrogate keys) générées par séquence posent le même problème : elles varient d'un rejeu à l'autre, donc on garde une clé naturelle stable pour la réconciliation (voir aussi le thème Qualité des données).
• Fenêtre de rejeu : définir jusqu'où l'on peut rejouer (7 jours ? 2 ans ?) selon ce que la source conserve. Au-delà, le rejeu est impossible et la donnée devient non reconstructible : traiter l'historique comme un actif à sauvegarder.
• Reprise partielle : un orchestrateur capable de relancer à partir de l'étape en échec, pas depuis le début, économise des heures sur gros volumes — à condition que chaque étape soit idempotente.

4. Déploiement en kits d'installation#

🟢 Novice — pourquoi des « kits »#

Dans beaucoup de contextes B2B, on ne déploie pas soi-même chez le client : on livre un kit (ensemble versionné de scripts, de binaires, de rapports et d'un mode d'emploi) installé par un administrateur — parfois l'éditeur, parfois le client. Le CI/CD produit alors un artefact de livraison qu'on peut installer n fois, dans n environnements, sans qu'on puisse réparer à la main.

🟡 Pratique — anatomie d'un bon kit#

Trois principes d'ingénierie du kit :

1. Le kit se construit dans le pipeline, pas à la main : un artefact unique, signé ou empreinté, publié avec sa version.
2. Le kit s'installe d'abord par le pipeline sur un environnement de recette dans les mêmes conditions que chez le client (mêmes outils, même ligne de commande) — sinon le kit réussit en recette et échoue chez le client.
3. Le kit contient son propre test : un script de contrôle qui rapporte « installé et conforme » ou la liste des écarts.

🔴 Expert — compatibilité entre versions de kit#

Le kit N+1 doit pouvoir s'installer sur N et idéalement sur N-1 (saut de version), car les clients ne montent pas à chaque version. Ce qui implique :

• une table de version installée que le kit lit pour décider quelles migrations jouer ;
• des migrations cumulatives (le kit contient la chaîne N-2→N-1→N, ou un script de saut validé) ;
• une matrice de tests de montée de version automatisée (N-1→N, N-2→N) dans le pipeline, avec des bases d'exemple « figées » représentant chaque version ;
• un traitement explicite des personnalisations client (objets ajoutés, paramètres modifiés) : la montée de version ne doit pas les perdre — d'où DropObjectsNotInSource=False et le paramétrage non destructif.

Voir aussi la gestion des versions parallèles : stratégies de branches, TFVC en profondeur.

5. Tester les données et les transformations#

🟢 Novice — quatre familles de tests#

🟡 Pratique — des tests de transformation sur jeux contrôlés#

Un test de transformation s'écrit comme un test unitaire : un jeu d'entrée minuscule et construit à la main qui couvre les cas limites, une sortie attendue, une comparaison automatique.

-- Test : le dédoublonnage de visites garde la plus récente synchronisation
-- Préparation (dans une base de test ou un schéma [tests])
TRUNCATE TABLE [tests].[VISITE_ENTREE];
INSERT INTO [tests].[VISITE_ENTREE] (VISITE_ID, CLIENT_ID, DATE_VISITE, DATE_SYNC) VALUES
  ('V1','C1','2026-10-01','2026-10-01T10:00'),
  ('V1','C1','2026-10-01','2026-10-01T12:00'),   -- doublon de synchro : on garde 12:00
  ('V2','C2','2026-10-02','2026-10-02T09:00');

EXEC [dm].[p_Charge_FACT_VISITE] @Source = 'tests', @DateExploitation = '2026-10-02';

-- Vérification : attendu = 2 lignes, V1 avec la synchro de 12:00
IF (SELECT COUNT(*) FROM [tests].[FACT_VISITE_SORTIE]) <> 2
   OR NOT EXISTS (SELECT 1 FROM [tests].[FACT_VISITE_SORTIE]
                  WHERE VISITE_ID='V1' AND DATE_SYNC='2026-10-01T12:00')
    THROW 50001, 'Echec test dedoublonnage visites', 1;

Des cadres de test existent (tSQLt pour SQL Server, notamment ; à vérifier son état de maintenance sur votre version) ; l'essentiel est l'habitude : un cas qui a causé un incident devient un test de non-régression.

Tests de données exécutés à chaque chargement (contrôles bloquants ou avertissements) :

-- Contrôles post-chargement : retourne une ligne par anomalie
SELECT 'Doublon de clé' AS controle, COUNT(*) AS nb
FROM (SELECT VISITE_ID FROM [dm].[FACT_VISITE] GROUP BY VISITE_ID HAVING COUNT(*) > 1) d
HAVING COUNT(*) > 0
UNION ALL
SELECT 'Fait sans commercial', COUNT(*)
FROM [dm].[FACT_VISITE] f
LEFT JOIN [dm].[DIM_COMMERCIAL] c ON c.COMMERCIAL_ID = f.COMMERCIAL_ID
WHERE c.COMMERCIAL_ID IS NULL
HAVING COUNT(*) > 0
UNION ALL
SELECT 'Volume du jour hors tolérance', 1
WHERE (SELECT COUNT(*) FROM [dm].[FACT_VISITE] WHERE DATE_VISITE = CAST(GETDATE()-1 AS date))
      < 0.5 * (SELECT AVG(n*1.0) FROM (SELECT COUNT(*) n FROM [dm].[FACT_VISITE]
                WHERE DATE_VISITE >= DATEADD(day,-35,CAST(GETDATE() AS date))
                  AND DATE_VISITE <  CAST(GETDATE()-1 AS date) GROUP BY DATE_VISITE) x);

Le dernier contrôle est de type comportemental (volumétrie du jour comparée à la moyenne récente) : il attrape les chargements partiels que les règles d'intégrité ne voient pas.

🔴 Expert — la non-régression de chiffres#

Le test le plus précieux et le plus négligé : comparer les indicateurs clés avant/après une modification. Principe : un jeu de requêtes témoins (10 à 30 indicateurs × quelques périodes × quelques périmètres) est exécuté sur l'environnement de référence et sur l'environnement modifié ; l'écart est calculé ; tout écart doit être expliqué (changement voulu, documenté) ou corrigé.

# Comparaison de chiffres témoins entre deux bases (squelette)
$requetes = Get-Content .\temoins.json | ConvertFrom-Json   # { nom, sql, tolerance }
foreach ($r in $requetes) {
    $ref = Invoke-Sqlcmd -ServerInstance $srv -Database $baseRef -Query $r.sql
    $new = Invoke-Sqlcmd -ServerInstance $srv -Database $baseNew -Query $r.sql
    $ecart = [math]::Abs($ref.valeur - $new.valeur)
    if ($ecart -gt $r.tolerance) {
        Write-Warning "$($r.nom) : référence $($ref.valeur), nouveau $($new.valeur)"
        $echecs++
    }
}
if ($echecs) { exit 1 }

Points d'attention : tolérances (arrondis, flottants) à définir ; jeux de dates figés (on ne compare pas « hier ») ; explication écrite des écarts attendus (sinon le test est désactivé au premier échec). Même idée pour les mesures d'un modèle sémantique : exécuter des requêtes DAX témoins avant/après et comparer. Voir Tests et fiabilité des chiffres et Recette et validation métier.

6. Environnements, données réalistes et anonymisées#

🟢 Novice — le dilemme#

Pour tester sérieusement un traitement de données, il faut des données qui ressemblent à la réalité : mêmes volumes, mêmes cas tordus, mêmes distributions. Or la réalité contient des données personnelles et commerciales sensibles (RGPD). Trois options, avec leur compromis :

(Notes d'expert, contexte : données de force de vente avec noms de clients et de contacts ; équipes de 3 à 8 personnes.)

🟡 Pratique — anonymiser sans casser les tests#

Principes :

• Préserver la structure : les relations (clé étrangère, hiérarchies), les distributions (répartition par région, par commercial), les cas limites (valeurs nulles, caractères spéciaux, doublons) — sinon on teste autre chose que la production.
• Remplacer de façon déterministe : un même client doit recevoir le même pseudonyme dans toutes les tables et à tous les rejeux (sinon les jointures cassent). On utilise un hachage avec sel secret ou une table de correspondance.
• Traiter les champs libres (commentaires de visite) : ils contiennent souvent des données personnelles non structurées ; les vider ou les remplacer.
• Conserver ce qui ne l'est pas : les montants, dates, quantités ne sont généralement pas personnels mais peuvent permettre une ré-identification en combinaison ; évaluer le risque.

-- Pseudonymisation déterministe d'un nom client (exemple pédagogique)
UPDATE c
SET    c.NOM = CONCAT('Client_', CONVERT(varchar(12), HASHBYTES('SHA2_256', CONCAT(c.CLIENT_ID, @sel)), 2)),
       c.ADRESSE = 'Adresse anonymisée',
       c.EMAIL = CONCAT(c.CLIENT_ID, '@exemple.invalid')
FROM   [dbo].[CLIENT] AS c;
-- @sel est un secret conservé hors du dépôt ; le script s'exécute sur la COPIE, jamais sur la production.

🔴 Expert — conformité et responsabilité#

La pseudonymisation (RGPD) reste une donnée personnelle tant que la clé de correspondance existe ; seule une anonymisation irréversible sort du champ. Conséquences : l'environnement de recette avec données pseudonymisées demeure soumis aux règles d'accès, de durée de conservation, de journalisation. Voir le thème Sécurité, confidentialité, conformité. Consultez le DPO et la politique de votre organisation : ce dossier ne constitue pas un avis juridique.

7. Volumétrie et temps de traitement#

🟢 Novice — le test sur « 1 000 lignes » ne prouve rien sur 100 millions#

Un traitement correct sur un petit jeu peut être inutilisable sur le volume réel : plan d'exécution différent, verrouillage, journal de transactions qui gonfle, fenêtre de traitement dépassée. La volumétrie est un risque de projet, pas un détail d'implémentation.

🟡 Pratique — les mesures à intégrer#

• Temps de traitement par étape, tracé à chaque exécution (table de journal) : sans historique, on ne voit pas la dérive.
• Test de charge périodique sur un environnement à volume proche de la production (au moins mensuel, ou à chaque évolution majeure).
• Seuils d'alerte : durée totale > X % de la fenêtre disponible ; croissance du temps > Y % sur 4 semaines.
• Découpage en lots : opérations massives (UPDATE, DELETE) par tranches pour limiter le journal et les verrous.

-- Suppression/mise à jour par tranches pour éviter journal et verrous excessifs
DECLARE @n int = 1;
WHILE @n > 0
BEGIN
    UPDATE TOP (50000) [dbo].[VISITE]
       SET [STATUT_COD] = 'REALISEE'
     WHERE [STATUT_COD] IS NULL AND [DATE_REALISATION] IS NOT NULL;
    SET @n = @@ROWCOUNT;
END;

🔴 Expert — la volumétrie comme dimension de conception de pipeline#

Quand le temps de traitement devient contraignant, les leviers sont d'abord algorithmiques (réduire les données traitées : chargement incrémental plutôt que complet, partitionnement, index adaptés, éviter les fonctions scalaires par ligne) avant d'être matériels. Chaque levier a son prix en complexité : le chargement incrémental exige une fiabilité du suivi des changements (une ligne modifiée à la source mais non détectée est une erreur silencieuse) ; il se combine avec un rechargement complet périodique de contrôle. Les mesures de temps sont sensibles à l'environnement partagé (ressources variables) : mesurer en temps CPU, répéter, ne pas comparer deux exécutions simultanées. Voir Performance et volumétrie.

8. dbt et la transformation en code#

🟢 Novice — ce que c'est#

dbt (data build tool) est un outil qui permet d'écrire les transformations de données sous forme de requêtes SQL (des « modèles ») versionnées dans un dépôt, avec dépendances automatiquement déduites, tests déclaratifs (unicité, non-nullité, relation, valeurs acceptées) et documentation générée (dont le graphe de lignage). Il s'exécute dans l'entrepôt de données (approche ELT) : dbt orchestre le SQL, il ne déplace pas les données.

🟡 Pratique — ce qu'il apporte au CI/CD data#

Exemple de test déclaratif :

models:
  - name: fact_visite
    columns:
      - name: visite_id
        tests: [unique, not_null]
      - name: commercial_id
        tests:
          - relationships: { to: ref('dim_commercial'), field: commercial_id }

Pertinence pour SQL Server : des adaptateurs existent pour SQL Server, Azure SQL, Fabric Warehouse (état 2026-10, à vérifier pour votre version et la maturité de l'adaptateur correspondant) ; l'orchestration dans Fabric ou Azure DevOps est possible. Une alternative sans dbt reste valable : des procédures stockées versionnées avec un orchestrateur maison + tests SQL (voir section 5). dbt n'est pas obligatoire ; ses idées (graphe, tests déclaratifs, environnements, documentation) le sont davantage.

🔴 Expert — limites de dbt#

• Son modèle suppose des transformations en SQL pur ; les traitements procéduraux complexes (curseurs, SQL dynamique, boucles) s'adaptent mal.
• La gestion des schémas persistants (index, partitions, droits, objets non gérés) est limitée : il crée des tables, il ne remplace pas un projet de base de données pour l'infrastructure.
• Compétence supplémentaire à acquérir (Jinja, packages) ; en équipe SQL Server traditionnelle, le bénéfice dépend de la taille du graphe de transformations (à partir de quelques dizaines de modèles, le gain devient net — ordre de grandeur indicatif).

9. Pipelines Fabric et Data Factory#

🟢 Novice — orchestrer les mouvements de données#

Un pipeline de données (Azure Data Factory, ou Data Factory dans Microsoft Fabric) orchestre des activités : copie, appel de notebook, procédure stockée, flux de données, conditions et boucles, avec déclencheurs planifiés ou événementiels. Il est lui-même un artefact à versionner et déployer — un pipeline modifié dans l'interface sans versionnement est du code de production sans historique.

🟡 Pratique — CI/CD dans Fabric (état 2026-10)#

Fabric propose deux mécanismes complémentaires :

• Intégration Git : un espace de travail (workspace) est relié à une branche d'un dépôt (Azure DevOps ou GitHub) ; les éléments sont sérialisés en fichiers, la validation (commit) et la mise à jour (update) se font depuis l'interface ou par API.
• Pipelines de déploiement : promotion de contenus d'un espace de travail à l'autre (développement → test → production) avec règles de déploiement (par exemple, changer la source de données par étape).

Chaque espace de travail correspond à un environnement. Les éléments pris en charge évoluent vite (état 2026-10 : la prise en charge des éléments Data Factory, notamment les pipelines de données, est documentée ; d'autres éléments restent en préversion ou partiels) — vérifiez la liste des éléments pris en charge sur la documentation Microsoft Learn avant de concevoir. Pour l'automatisation complète, la bibliothèque fabric-cicd (Python, maintenue par Microsoft ; état à vérifier) et les API REST Fabric permettent de scripter le déploiement depuis Azure DevOps ou GitHub Actions.

🔴 Expert — idempotence d'un pipeline d'orchestration#

Un pipeline qui copie des données doit être rejouable : copie vers une zone de transit puis chargement idempotent (section 3), paramètre de fenêtre temporelle passé à l'exécution, table de contrôle des lots (watermark), gestion des échecs partiels (relance de l'activité en échec seulement). Les SaaS sources imposent quotas et pagination : un rejeu massif peut dépasser les limites d'API — prévoir le plafonnement et le reprise à partir du dernier curseur. Pour l'architecture Fabric/OneLake, voir 04 Reporting Power BI, architecture OneLake et difficultés et pièges.

10. Rapports Power BI : PBIP, TMDL, deployment pipelines#

🟢 Novice — un rapport est aussi du code#

Historiquement, un rapport Power BI était un fichier binaire (.pbix) : impossible à comparer, à fusionner, à relire. Le format projet Power BI (PBIP) décompose le rapport et le modèle sémantique en fichiers texte dans un dossier, donc versionnables par Git (ou TFVC). Le modèle sémantique se décrit en TMDL (Tabular Model Definition Language), un format texte lisible, indenté, un fichier par table, bien adapté aux différences et aux revues. Le rapport lui-même se sérialise au format PBIR (une définition par page et visuel, en JSON).

MonRapport.pbip
MonRapport.SemanticModel/
  definition/
    model.tmdl
    tables/
      FACT_VISITE.tmdl
      DIM_COMMERCIAL.tmdl
    relationships.tmdl
    cultures/ fr-FR.tmdl ...
MonRapport.Report/
  definition/
    pages/ ... visuals/ ...

(état 2026-10 : PBIP, TMDL et PBIR sont les formats de développement de référence ; vérifier le statut GA/préversion de chaque composant et de la fonctionnalité de rapport PBIR sur la documentation Microsoft actuelle.)

🟡 Pratique — ce que le texte permet#

Chaîne type :

Pipelines de déploiement Power BI/Fabric : promouvoir un contenu d'une étape à l'autre en conservant les liens ; les règles de déploiement substituent la source de données et les paramètres selon l'étape (par exemple, la base de développement devient la base de production). Les comparaisons entre étapes (« qu'est-ce qui diffère ? ») aident à la revue.

🔴 Expert — limites et subtilités#

• Les données ne sont pas dans le projet : promouvoir le modèle ne déplace pas les données ; un rafraîchissement est nécessaire en destination, avec sa propre durée et ses éventuels échecs.
• Droits et sécurité (RLS) : les rôles de sécurité font partie du modèle ; tester la sécurité par rôle dans le pipeline (requêtes exécutées sous identité de rôle) est un contrôle d'intégrité essentiel. Voir Sécurité RLS et accès.
• Multilingue : les traductions (cultures) sont des fichiers texte comme les autres ; elles se génèrent depuis une source de métadonnées et se valident (aucune clé manquante). Voir Accessibilité et multilingue.
• Modes de stockage : Import, DirectQuery, Direct Lake, composite — le déploiement et le test varient (en Direct Lake, la dépendance aux éléments Fabric sous-jacents impose de déployer dans le bon ordre ; à vérifier selon l'état de la fonctionnalité). Voir 10 Bonnes pratiques Power BI transverses et 11 Checklist de projet reporting.
• Édition en ligne vs dépôt : modifier un modèle directement dans le service crée une dérive par rapport au dépôt ; décider qui fait foi (le dépôt) et verrouiller l'édition en production.

11. Rollback impossible sur la donnée#

🟢 Novice — on ne « dé-charge » pas facilement#

Revenir en arrière sur du code, c'est redéployer l'ancienne version. Revenir en arrière sur de la donnée, c'est restaurer un état antérieur… et perdre tout ce qui s'est produit depuis. Trois situations :

🟡 Pratique — les parades#

1. Expand/contract (parallel change) : on ajoute le nouveau (colonne, table) sans supprimer l'ancien, on bascule les consommateurs, on supprime l'ancien dans une version ultérieure, quand plus rien ne le lit. Le retour arrière reste possible pendant toute la phase intermédiaire.
2. Sauvegarde vérifiée avant les opérations destructrices : une sauvegarde restaurée en test est une sauvegarde ; une sauvegarde jamais restaurée est un espoir.
3. Copie de sécurité ciblée : SELECT * INTO [archive].[VISITE_20261007] FROM [dbo].[VISITE] avant migration lourde (volume permettant).
4. Table temporelle (system-versioned temporal table) de SQL Server pour retrouver l'état passé de certaines tables : utile, mais pas une sauvegarde (coût de stockage, rétention).
5. Instantané / clone quand la plateforme le permet (à vérifier selon la plateforme : Azure SQL, Fabric Warehouse offrent des fonctions de restauration à un instant et de clonage ; les limites varient).
6. Roll-forward : corriger par une migration corrective plutôt que revenir en arrière.

🔴 Expert — réversibilité comme critère d'architecture#

Concevoir pour la réversibilité : ne jamais écraser, toujours ajouter (tables de faits en ajout avec versions, historisation), séparer la zone brute (immuable, rejouable) de la zone transformée (reconstructible). Si la zone brute est conservée, tout ce qui en dérive est recalculable : le rollback devient « recalculer depuis le brut avec la version précédente du code ». C'est l'argument le plus fort en faveur d'une couche de données brutes conservées ; son coût (stockage, RGPD : durée de conservation, droit à l'effacement) doit être arbitré avec le DPO. Voir Sources et contrats de données.

12. Qualité continue en production#

🟢 Novice — le pipeline ne s'arrête pas au déploiement#

En CI/CD classique, la production est surveillée pour des pannes. En data, la production est surveillée pour des dégradations silencieuses : le chargement réussit, mais les données sont fausses ou en retard. D'où la qualité continue : des contrôles automatiques à chaque exécution de la chaîne de production.

🟡 Pratique — les cinq piliers d'observabilité des données#

Boucle de qualité continue :

🔴 Expert — le coût du bruit et le contrat de service#

• Fatigue d'alerte : trop d'alertes → plus personne ne lit. Règle : chaque alerte doit mener à une action ; sinon on la supprime ou on la rétrograde. Mesurer le taux d'alertes actionnables.
• SLO de données : « le datamart est disponible à 7 h, 99 % des jours ouvrés » est un engagement mesurable ; la fraîcheur devient un indicateur de service. Voir Exploitation et support et Exploitation, supervision et capacité.
• Journal de traitement (table de suivi des exécutions : lot, début, fin, lignes, statut, message d'erreur) : base de toute analyse de performance et d'incident ; la même table sert à la reprise.

13. Limites propres à la data#

🟢 Novice — ce que le CI/CD ne résout pas ici#

Aux limites générales du CI/CD (10 CI/CD, section 8) s'ajoutent des limites propres à la donnée :

🟡 Pratique — arbitrer l'investissement#

Le gain marginal du CI/CD data est maximal là où il y a : plusieurs environnements, plusieurs versions en parallèle, livraisons répétées, incidents d'installation passés, rotation d'équipe. Il est minimal pour un traitement unique et stable, un prototype, ou un environnement sans valeur de reprise. Évaluez en heures perdues par mois aujourd'hui (installations, corrections, attentes) contre le coût de mise en place.

🔴 Expert — dérive des sources et contrats#

Les sources SaaS ou applicatives changent sans prévenir : colonne ajoutée, type modifié, valeur d'énumération nouvelle. Le pipeline doit détecter (comparaison de schéma, contrôles de domaine), isoler (zone d'atterrissage tolérante, transformations strictes) et alerter — le contrat de données (schéma, sémantique, SLA) transforme la surprise en changement géré. Voir Sources et contrats de données et Difficultés et pièges SQL Server SaaS.

14. Notes de maturité des pratiques#

Appréciations d'expert, contextuelles (équipe de 3 à 8 personnes, datamart SQL Server/Azure SQL, rapports Power BI, livraison en kits, état 2026-10). Voir NOTATION. Trois colonnes : valeur apportée, effort de mise en place (5 = très élevé), maturité de l'écosystème d'outils.

Lecture : les meilleurs rapports valeur/effort sont versionner, idempoter, journaliser, tester les données à chaque chargement, automatiser le déploiement en recette. Les pratiques les plus tendance (dbt, déploiement continu, rollback automatique) sont moins prioritaires que ces fondamentaux.

15. Contribution de l'IA#

Prompt d'exemple :

Voici le schéma actuel de la table [dbo].[VISITE] et la modification souhaitée (ajout d'une colonne STATUT_COD
avec valeur par défaut calculée depuis DATE_REALISATION). Écris un script T-SQL IDEMPOTENT :
- vérifie l'existence avant de modifier ;
- fait le backfill par tranches de 50 000 lignes ;
- ne contient aucune instruction destructrice ;
- se termine par une requête de contrôle (nombre de lignes à NULL).
Liste ensuite les risques (verrous, journal, compatibilité avec la version précédente du code) et le plan de repli.

16. Voir aussi#

• Socle : 10 CI/CD · 07 Méthodes spécifiques data · 04 Scrum et data · 13 Pièges et bonnes pratiques
• Outils : GDS et données SQL/BI · Git vs TFVC · Azure DevOps / TFS
• Matrices : Conduite de projet data · Développement BI · Intégration et livraison continues
• Reporting : 04 Reporting Power BI · OneLake architecture · SQL Server SaaS architecture
• Glossaire · Bibliographie

✻ Rédigé par Claude Sonnet 5.5