i

Description

Coffre-fort ancien en bois précieux, renforcé de ferrures de laiton ouvragées.

Source

14GTR · 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.

Gestion de source pour les données : SQL et Power BI

Versionner des objets SQL de façon rejouable : scripts idempotents, state-based contre migration-based, SSDT/dacpac, Flyway, Liquibase.

En bref

• Versionner des objets SQL de façon rejouable : scripts idempotents, state-based contre migration-based, SSDT/dacpac, Flyway, Liquibase.
• Versionner Power BI de manière fusionnable : PBIP, PBIR, TMDL, diffs et fusions, pièges des binaires.
• Maîtriser encodages, BOM, fins de ligne et .gitattributes pour ne jamais corrompre un accent.
• Gérer gros fichiers, secrets, données de référence, kits d'installation et tags de release.
• Savoir où l'IA aide (diff de schéma, documentation, revue) et où elle est dangereuse.

Fil rouge illustratif : un datamart SQL Server alimenté par une application de force de vente terrain, avec rapports Power BI multilingues, livré en kits d'installation.

Sur cette page

1. Ce qui change avec les données
2. Ce que l'on versionne
3. State-based et migration-based pour SQL
4. Scripts idempotents
5. Outils SSDT, dacpac, Flyway, Liquibase
6. Versionner Power BI (PBIP, PBIR, TMDL)
7. Diffs et fusions de TMDL et de JSON de rapport
8. Encodages, BOM et fins de ligne
9. Gros fichiers et binaires
10. Secrets et données de référence
11. Kits d'installation et tags de release
12. Organisation du dépôt
13. Contribution de l'IA
14. Pièges récapitulatifs
15. Voir aussi

Niveau : 🟡→🔴

Ce qui change avec les données#

🟡 Niveau pratique

Versionner du code applicatif est « sans état » : on remplace les binaires. Versionner une base de données est différent : la base contient un état (tables remplies, historiques, paramétrages client) qu'on ne peut pas remplacer. Il faut donc versionner la manière d'évoluer (migrations) autant que la cible. Trois conséquences :

1. Chaque modification doit être rejouable sur un environnement existant (idempotence, non destructivité).
2. Deux branches qui modifient la même table produisent des migrations conflictuelles par l'ordre, sans conflit de fichiers.
3. Les rapports et le modèle sémantique consomment le schéma : le versionnement doit lier les couches (monorepo, PR coordonnées, tags communs).

Voir aussi CI/CD pour la data et la matrice Versionnement et industrialisation des rapports.

Ce que l'on versionne#

🟡 Niveau pratique

State-based et migration-based pour SQL#

🟡 Niveau pratique

Deux philosophies pour décrire l'évolution d'un schéma :

Approche hybride fréquente et saine : état cible pour les objets sans état (vues, procédures, fonctions : CREATE OR ALTER), migrations pour les objets à état (tables : ajout de colonne, changement de type, backfill de données).

Scripts idempotents#

🟡 Niveau pratique

Un script est idempotent s'il peut être rejoué plusieurs fois avec le même résultat et sans erreur. C'est la condition d'un déploiement fiable sur des environnements dans des états différents.

-- Procédure : état cible
CREATE OR ALTER PROCEDURE [dm].[p_Exemple]
AS
BEGIN
    SET NOCOUNT ON;
    -- ...
END;
GO

-- Colonne : migration idempotente
IF COL_LENGTH('dm.DIM_CLIENT', 'CLI_SEGMENT') IS NULL
    ALTER TABLE [dm].[DIM_CLIENT] ADD [CLI_SEGMENT] nvarchar(20) NULL;
GO

-- Donnée de référence : MERGE
MERGE [dbo].[_Parametre] AS T
USING (VALUES (N'SEUIL_COUVERTURE', N'0.80')) AS S([Nom], [Valeur])
   ON T.[Nom] = S.[Nom]
WHEN NOT MATCHED THEN INSERT ([Nom], [Valeur]) VALUES (S.[Nom], S.[Valeur]);
-- (pas de WHEN MATCHED UPDATE : ne pas écraser la personnalisation client)
GO

Règles :

• Protéger avec IF EXISTS/IF NOT EXISTS ou CREATE OR ALTER ; éviter DROP non gardé.
• Ne pas écraser les valeurs personnalisées par le client : installation non destructive, séparer paramétrage standard et spécifique.
• Ordre : numéroter les scripts (010_Core, 020_…) pour que l'ordre de rejeu soit déterministe.
• Transactions : envelopper les changements de schéma à plusieurs étapes ; attention aux opérations DDL non transactionnelles.
• Un script, un sujet ; commentaires d'en-tête (objet, version, tickets) mais pas de journal de corrections dans le corps : l'historique est dans la GDS.

Outils SSDT, dacpac, Flyway, Liquibase#

🔴 Niveau expert

Choisir : un projet SSDT est le meilleur filet pour un schéma complexe (références vérifiées, comparaison cible/base) ; Flyway/Liquibase pour des équipes qui privilégient la migration explicite ; scripts maison quand le produit génère une grande partie du schéma par programmes (comme un datamart piloté par métadonnées) — à condition d'automatiser les contrôles (syntaxe, ordre, idempotence, test de rejeu à blanc).

# Exemple : déployer un dacpac en bloquant toute perte de données
sqlpackage /Action:Publish /SourceFile:Datamart.dacpac `
  /TargetConnectionString:"..." /p:BlockOnPossibleDataLoss=True /p:DropObjectsNotInSource=False

Versionner Power BI (PBIP, PBIR, TMDL)#

🟡 Niveau pratique

Le fichier .pbix est un zip binaire : pas de diff, pas de fusion, historique opaque. Le format projet Power BI (PBIP) décompose l'artefact en dossiers texte :

MonRapport.pbip                      (pointeur)
MonRapport.SemanticModel/
    definition.pbism
    definition/
        model.tmdl
        relationships.tmdl
        tables/
            FAITS.tmdl
            CLIENT.tmdl
        cultures/
            fr-FR.tmdl  en-US.tmdl     (traductions)
MonRapport.Report/
    definition.pbir
    definition/
        report.json
        pages/
            pages.json
            <id-page>/page.json
            <id-page>/visuals/<id-visuel>/visual.json

• TMDL (Tabular Model Definition Language) : syntaxe texte lisible du modèle sémantique (tables, colonnes, mesures DAX, relations, rôles RLS, cultures). Une table = un fichier ; les mesures sont lisibles ligne à ligne.
• PBIR : format de définition de rapport en fichiers JSON (un visuel = un fichier) : diffs ciblés, fusion possible. Le format remplace l'ancienne définition monolithique report.json (PBIR-Legacy) : d'après la documentation Power BI (état 2026-10), PBIR est en disponibilité générale et constitue le format de rapport par défaut ; un rapport PBIR-Legacy modifié puis enregistré est converti automatiquement en PBIR.
• Git intégré à Fabric / Power BI : synchronise un espace de travail avec un dépôt Git (Azure DevOps ou GitHub) ; sérialise dans ces formats. Pas de support TFVC : une raison supplémentaire de migrer pour un projet qui veut l'intégration native au service.
• Les rapports clients liés à un modèle par identifiant : les lineageTag des mesures/colonnes assurent la continuité des rapports qui y sont connectés ; modifier une mesure en place (et jamais supprimer/recréer) préserve le lien. C'est un invariant à protéger par revue.

Diffs et fusions de TMDL et de JSON de rapport#

🔴 Niveau expert

TMDL : indentation significative (comme YAML) et mesures multi-lignes. Les fusions échouent surtout par :

• Indentation modifiée d'un côté (reformatage) → conflit sur tout le bloc.
• Réordonnancement de colonnes/mesures par Desktop → diff bruyant.
• Identifiants lineageTag générés : deux ajouts concurrents ne les mélangent pas, mais une copie d'objet duplique le tag (à renouveler).
• Annotations internes (PBI_QueryRelationships, etc.) régénérées.

Parades : conventions de formatage uniques, éditer des blocs distincts (une personne par table), git diff --word-diff, résolution manuelle puis ouverture dans Desktop pour valider, et garder les fusions de modèle petites et fréquentes.

JSON de rapport (PBIR) : un visuel par fichier limite les conflits ; mais le positionnement (x, y, largeur) et les identifiants de pages changent dès qu'on déplace un objet. Sur un conflit, privilégier la version d'un seul côté (page entière) plutôt qu'une fusion fine.

git diff --word-diff=color -- "*.tmdl"
git diff --stat main...feature -- "*.Report/*"
# Outil de fusion : configurer un mergetool pour TMDL/JSON
git config merge.tool vscode
git config mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED'

Contexte : équipe 3-15 personnes, rapports d'entreprise multilingues ; appréciations d'expert (NOTATION).

Encodages, BOM et fins de ligne#

🔴 Niveau expert

Sujet vital pour du contenu multilingue accentué : une erreur d'encodage détruit les accents sans message d'erreur.

Lecture : UTF-8 avec BOM est, pour les .sql et .ps1 exécutés sous Windows, le seul encodage décodé correctement dans tous les cas ; UTF-8 sans BOM est la norme attendue par d'autres outils (Node, Markdown/YAML, TMDL/JSON écrits par Power BI Desktop). Règle d'équipe : un encodage par type de fichier, documenté, vérifié automatiquement.

Fins de ligne : LF dans le dépôt (normalisation) ; CRLF sur disque Windows si l'outil le veut. Les fichiers TMDL écrits par Desktop sont en CRLF.

.gitattributes type :

# Normalisation par défaut : texte détecté, LF dans le dépôt
* text=auto

# Sources SQL et PowerShell : texte
*.sql  text working-tree-encoding=UTF-8 eol=lf
*.ps1  text eol=lf

# Fichiers écrits par Power BI Desktop : ne pas modifier les fins de ligne
*.tmdl text eol=crlf
*.pbir text eol=crlf
*.json text

# Binaires : jamais touchés
*.pbix binary
*.zip  binary
*.png  binary
*.bak  binary

Remarques d'expert :

• working-tree-encoding convertit à la lecture/écriture (utile pour cp1252 ↔ UTF-8) mais ne gère pas le BOM à votre place : il faut contrôler la présence de BOM par un hook ou un script de validation.
• Les fichiers *.sql « avec BOM » sont à détecter dans un pre-commit : lire les 3 premiers octets EF BB BF.
• Sous TFVC, il n'y a pas de normalisation automatique ; l'encodage est celui du fichier stocké (propriété de type de fichier : encodage détecté au add). Un outil qui « réécrit » un fichier avec un autre encodage provoque un changeset parasite.
• Ne jamais lire puis réécrire un fichier dont on ne connaît pas l'encodage avec un outil qui suppose UTF-8 : tous les accents du fichier sont corrompus, pas seulement la ligne éditée.
• sed -i et certains outils suppriment les CR des fichiers CRLF : privilégier des traitements binaires (Python) ou l'éditeur du projet.

# Contrôle : tous les .sql ont-ils un BOM UTF-8 ?
Get-ChildItem -Recurse -Filter *.sql | ForEach-Object {
    $b = [System.IO.File]::ReadAllBytes($_.FullName) | Select-Object -First 3
    if (-not ($b[0] -eq 0xEF -and $b[1] -eq 0xBB -and $b[2] -eq 0xBF)) { $_.FullName }
}
# Écriture d'un fichier avec BOM
$enc = New-Object System.Text.UTF8Encoding $true
[System.IO.File]::WriteAllText($chemin, $contenu, $enc)

Gros fichiers et binaires#

🔴 Niveau expert

• Ne pas versionner : sauvegardes .bak, exports massifs, caches Power BI (cache.abf), localSettings.json, dossiers bin/obj/node_modules.
• .pbix inévitables (anciens rapports) : Git LFS (avec verrouillage), ou stockage d'artefacts hors dépôt ; mieux : les convertir en PBIP.
• Jeux de données d'exemple : petits (quelques Mo) ; sinon, script générateur versionné plutôt que la donnée.
• Taille d'historique : un binaire ajouté puis supprimé reste dans l'historique : git filter-repo pour purger (02).
• TFVC accepte les binaires sans extension, mais la base de collection grossit ; surveiller.

Seuils d'ordre de grandeur (à adapter) : alerter à partir de ~10 Mo par fichier, refuser au-delà de ~100 Mo sans LFS (plafonds d'hébergeur à vérifier).

Secrets et données de référence#

🔴 Niveau expert

Secrets : chaînes de connexion, mots de passe, clés de stockage, jetons. Dans un projet data, ils se cachent dans : fichiers de configuration appsettings, scripts PowerShell de déploiement, paramètres de sources de données Power BI (expressions.tmdl avec serveur et base), pipelines. Règles : authentification intégrée/identités managées plutôt que mots de passe ; coffre pour le reste ; paramètres par environnement hors dépôt ; analyse de secrets à chaque PR (détails).

Données de référence (paramètres, listes de valeurs, libellés traduits) :

• Les versionner sous forme de scripts rejouables (MERGE sans écrasement du paramétrage client) ou de fichiers .csv triés et stables (colonnes dans un ordre fixe, tri par clé) pour un diff propre.
• Ne pas versionner de données personnelles (RGPD) ; pour des jeux de test, anonymiser/synthétiser.
• Séparer standard (livré, versionné) de personnalisé/projet (client, hors produit ou dans un dossier dédié) ; héritage et ordre de priorité documentés.
• Traductions : fichier source unique (table de libellés), génération vers les cultures du modèle ; le diff des traductions doit être lisible (une ligne par clé et par langue).

Kits d'installation et tags de release#

🔴 Niveau expert

Un kit d'installation est l'ensemble ordonné des scripts (SQL, PowerShell) qui installe ou met à niveau le produit. Il se génère depuis les sources et se rejoue sur des environnements existants.

Invariants à garantir :

1. Reproductibilité : le kit d'une version doit pouvoir être régénéré exactement depuis le tag correspondant.
2. Ordre déterministe et idempotence (voir plus haut).
3. Traçabilité : la version installée est inscrite dans la base (table de version) et dans le journal d'installation ; on relie version ↔ tag ↔ changeset/commit.
4. Intégrité : somme de contrôle du kit ; signature du tag.
5. Exécution fiable : les options d'exécution documentées (ex. sqlcmd -x -X pour désactiver substitution de variables et commandes) ; un kit qui « s'installe avec succès » en corrompant des accents ou en sautant des fichiers est pire qu'un échec franc : faire échouer bruyamment.

Tags de release :

git tag -s v9.1.2 -m "Kit 9.1.2 — correctifs consolidation"
git push origin v9.1.2
git describe --tags        # v9.1.2-3-gabc1234 : 3 commits après le tag
git archive --format=zip --prefix=kit-9.1.2/ v9.1.2 -o kit-9.1.2.zip

Sous TFVC : un changeset de référence documenté + branche de release + (éventuellement) label ; consigner le numéro de changeset dans les notes de livraison.

Organisation du dépôt#

🔴 Niveau expert

Proposition d'arborescence pour un projet datamart + BI en monorepo :

/Datamart/        scripts SQL numérotés (010_Core, 020_..)
/Reports/         projets PBIP (SemanticModel + Report)
/Tools/           scripts PowerShell, outils internes
/Docs/            documentation Markdown
/Releases/        (éventuellement) instantanés figés, un dossier par version
/.gitattributes   /.gitignore   /.tfignore (si TFVC)
/CHANGELOG.md     suivi métier versionné

• Un README par dossier structurant (rôle, contenu, conventions) ; un README qui contredit le code est un défaut au même titre qu'un test rouge.
• Changelog : séparer le journal de travail quotidien (local, non archivé) du suivi métier par version (archivé).
• Pas de journal de corrections dans le code : l'historique de la GDS suffit ; l'en-tête porte la version et les métadonnées.

Contribution de l'IA#

Exemples de prompts :

Voici deux versions d'une table TMDL (avant/après). Liste les changements
fonctionnels (mesures ajoutées, expressions DAX modifiées, relations changées)
et signale tout risque de rupture pour des rapports liés par lineageTag.
N'invente rien : cite la ligne concernée.

Écris un script T-SQL idempotent qui ajoute la colonne [CLI_SEGMENT] nvarchar(20)
NULL à [dm].[DIM_CLIENT] si elle n'existe pas, sans toucher aux données.
Ajoute un test de vérification final qui lève une erreur si la colonne manque.

Limites à garder en tête : l'IA n'exécute pas vos migrations ni ne connaît vos données ; elle « corrige » volontiers un accent ou une indentation qu'il fallait préserver ; elle peut proposer de supprimer et recréer un objet dont l'identité compte (mesure, colonne liée). La responsabilité de la mise en production reste humaine. Voir IA et outils et la synthèse transverse.

Pièges récapitulatifs#

🔴 Niveau expert

Voir aussi#

• Panorama des GDS · Git en profondeur · TFVC en profondeur · Git vs TFVC · Stratégies de branches
• CI/CD pour la data · CI/CD
• Matrice BI : versionnement et industrialisation des rapports
• Bonnes pratiques Power BI transverses · Glossaire

✻ Rédigé par Claude Sonnet 5.5