18 février 2026

TMDL dans Fabric : deux routes pour le même fichier

Depuis qu’un modèle sémantique s’écrit en texte, il se relit et se versionne comme du code. Restent deux manières de le déployer, qui ne coûtent pas la même chose et ne s’adressent pas aux mêmes équipes.

Pendant des années, un modèle sémantique était un fichier binaire : on ne pouvait ni le relire à deux, ni voir ce qu’une modification avait changé, ni fusionner deux travaux. La revue se faisait en ouvrant l’outil et en regardant. Le format texte règle cela d’un coup : une mesure devient quelques lignes, un tableau de bord de différences redevient lisible, et la question du déploiement se pose enfin dans les mêmes termes que pour du code.

text

/// Revenue excluding tax, at invoice date.
measure 'Revenue ex tax' =
    SUMX ( Sales, Sales[quantity] * Sales[unit_price] )
    formatString: #,##0 €
    displayFolder: Measures\Sales

    annotation PBI_FormatHint = {"currencyCulture":"fr-FR"}

Cinq lignes qu’un collègue peut contester en revue. C’est tout l’enjeu, et c’est ce qui rend les deux routes ci-dessous comparables : elles partent du même fichier.

01La route intégrée

La plateforme propose des espaces de travail successifs (développement, recette, production) et un mécanisme qui pousse le contenu de l’un vers le suivant. Les règles de déploiement remplacent au passage ce qui doit changer : la source de données, un paramètre, une connexion. Rien à écrire, tout se règle dans une interface.

C’est la bonne route pour une équipe qui n’a pas de chaîne d’intégration et n’en veut pas. Elle a deux limites qu’il faut connaître avant de s’engager. Les règles de déploiement vivent dans la plateforme et non dans le dépôt : elles ne sont ni versionnées, ni relues, et personne ne sait dire ce qu’elles valaient il y a trois mois. Et le déclenchement reste manuel ou attaché à la plateforme : impossible de conditionner un déploiement à ce qu’une suite de tests soit passée ailleurs.

02La route par la chaîne d’intégration

L’autre route passe par la ligne de commande de la plateforme, installée dans un exécuteur, et pilotée par le même fichier de chaîne que le reste du dépôt. Le déploiement devient une étape parmi d’autres, avec ce que cela suppose : il s’exécute après les tests, il se rejoue, il laisse une trace.

yaml

deploy-semantic-model:
  stage: deploy
  image: python:3.12-slim
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  before_script:
    - pip install --quiet ms-fabric-cli
    # Service principal, not a named account: a pipeline must not stop working
    # because somebody changed team.
    - fab auth login -u $FAB_CLIENT_ID -p $FAB_CLIENT_SECRET --tenant $FAB_TENANT
  script:
    - fab import /Prod.Workspace/Sales.SemanticModel -i ./models/Sales.SemanticModel -f
    - fab import /Prod.Workspace/Sales.Report -i ./reports/Sales.Report -f
    # The refresh after import: without it the model is deployed but empty, and
    # the report shows blank cells to whoever opens it first.
    - fab job run /Prod.Workspace/Sales.SemanticModel -P refreshType=full

Le coût est réel et il est double. Il faut un principal de service, ses droits sur les espaces de travail, et la rotation de son secret : trois choses qui relèvent d’une équipe de plateforme et non d’une équipe décisionnelle. Et il faut accepter qu’une partie de ce que l’interface faisait gratuitement, comme substituer une source entre deux environnements, se réécrive en paramètres.

03Laquelle, et pour qui

Je ne crois pas qu’une des deux soit meilleure, et le critère n’est pas technique. La question à poser est : qui répond quand un rapport est faux un lundi matin. Si c’est l’équipe décisionnelle elle-même, la route intégrée lui rend son autonomie et lui évite de dépendre d’une chaîne qu’elle ne sait pas déboguer. Si c’est une équipe de plateforme qui répond déjà pour le reste, alors le modèle sémantique doit suivre le même chemin que le reste, sans quoi il devient le seul artefact dont personne ne connaît l’historique.

04Ce que je laisse de côté

Je ne dis rien des tests sur un modèle sémantique, qui sont le vrai manque de ces deux routes. On sait déployer, on ne sait pas vérifier automatiquement qu’une mesure rend le même résultat qu’avant, et c’est pourtant la seule chose qui distinguerait cette chaîne d’un simple transport de fichiers. Des solutions existent, aucune ne m’a paru assez simple pour être tenue par l’équipe après mon départ, et je préfère l’écrire que de laisser croire que la question est réglée.