Le scénario

Un pipeline de déploiement Microsoft Fabric doit être déclenché depuis un pipeline CI/CD externe (Azure DevOps), sans intervention humaine. La question qui se pose systématiquement : quel mécanisme d’authentification utiliser entre un système externe et l’API Fabric ?

Réponse courte : un Service Principal (identité Microsoft Entra ID dédiée à l’application, pas un compte utilisateur). Cet article documente comment le mettre en place de bout en bout, avec les erreurs réellement rencontrées, pas seulement le chemin heureux.

Ce qu’on construit

  • Un Service Principal Microsoft Entra ID
  • Deux workspaces Fabric reliés par un pipeline de déploiement (stages Development / Test)
  • Un pipeline Azure DevOps qui authentifie ce Service Principal et déclenche le déploiement via l’API REST Fabric
flowchart LR
    ADO["Azure DevOps<br/>tâche Bash@3"] -->|"1. client_credentials"| Entra["Microsoft Entra ID"]
    Entra -->|"2. access_token"| ADO
    ADO -->|"3. POST /deploy (Bearer token)"| Fabric["API REST Fabric"]
    Fabric --> Pipe["Pipeline de déploiement"]
    Pipe -->|"4. déclenche"| Dev["Stage Development"]
    Dev -->|"5. promotion"| Test["Stage Test"]

Étape 1. Le Service Principal

Dans Microsoft Entra ID, une App Registration classique suffit : un client_id, un tenant_id, et un secret. Trois éléments à bien distinguer :

  • tenant_id identifie l’annuaire Microsoft Entra
  • client_id identifie l’application elle-même (l’équivalent d’un nom d’utilisateur)
  • client_secret prouve son identité (l’équivalent d’un mot de passe)

Côté Azure DevOps, ces trois valeurs se configurent dans une Service Connection dédiée : Project Settings → Pipelines → Service connections → New service connection → Azure Resource Manager, puis authentification Service principal (manual) :

Configuration d’une Service Connection Azure DevOps avec un Service Principal Les champs à renseigner : Application (client) ID, Directory (tenant) ID, et le Client secret (credential “Service principal key”). Un clic sur “Verify” avant de sauvegarder confirme que les identifiants sont valides.

Quelques points d’attention :

  • Choisir l’authentification manuelle, pas automatique : ce Service Principal n’a pas nécessairement de rôle sur un abonnement Azure, seulement les permissions Fabric configurées plus loin.
  • Nommer la connexion de façon explicite (ici sc-fabric-sp) pour la retrouver facilement dans les tâches du pipeline et dans les journaux d’audit.
  • Sous Security, ne pas cocher “Grant access permission to all pipelines” par défaut : autoriser explicitement chaque pipeline qui en a besoin limite le rayon d’exposition du secret.

Étape 2. Activer les Service Principals côté tenant Fabric

Depuis mi-2025, Microsoft a scindé un ancien réglage unique en deux réglages distincts dans l’Admin Portal Fabric (Tenant settings → Developer settings) :

Les deux réglages tenant Fabric pour les Service Principals Les deux réglages tenant scindés depuis mi-2025 : “Service principals can call Fabric public APIs” (entouré) contrôle les appels API génériques, tandis que le réglage juste au-dessus gère spécifiquement la création de workspaces, connexions et pipelines de déploiement.

Le second réglage, plus spécifique, contrôle la création de workspaces, connexions et pipelines de déploiement :

Le réglage tenant pour la création de workspaces, connexions et pipelines de déploiement Le second réglage, spécifique aux pipelines de déploiement : sans lui activé, le Service Principal n’apparaît pas dans la recherche “Add people” des workspaces, même si le premier réglage (appels API génériques) est déjà activé.

  • Service principals can call Fabric public APIs : activé par défaut sur les nouveaux tenants
  • Service principals can create workspaces, connections, and deployment pipelines : désactivé par défaut, à activer explicitement

Sans le second réglage, le Service Principal reste invisible dans la recherche “Add people” des workspaces.

Étape 3. Le piège le plus instructif : deux modèles de permissions séparés

C’est le point qui a le plus surpris pendant l’implémentation. Ajouter le Service Principal comme Admin sur les deux workspaces ne suffit pas : le pipeline de déploiement a son propre système de permissions, totalement indépendant des rôles de workspace.

flowchart TB
    SP["Service Principal"]
    SP -->|"rôle Admin"| WSDev["Workspace Dev"]
    SP -->|"rôle Admin"| WSTest["Workspace Test"]
    SP -.->|"accès manquant par défaut"| PipeAccess["Pipeline de déploiement<br/>Manage access"]
    PipeAccess -->|"condition requise pour"| ListAPI["API List Deployment Pipelines"]

    style PipeAccess stroke:#ef4444,stroke-width:2px,stroke-dasharray: 4 2

Le panneau Pipeline access d’un pipeline de déploiement Fabric Le “Manage access” du pipeline de déploiement lui-même (pas des workspaces) : c’est ici, et seulement ici, qu’il faut ajouter le Service Principal avec le rôle Admin pour qu’il puisse lister et déclencher des déploiements, une permission totalement séparée des rôles accordés sur les workspaces Development et Test.

Sans l’accès “Admin” explicitement accordé sur le pipeline lui-même (via son “Manage access” dédié), l’API List Deployment Pipelines ne renvoie même pas le pipeline pour ce Service Principal, silencieusement, sans message d’erreur explicite sur la cause.

C’est un piège facile à reproduire en entreprise : un Service Principal peut avoir toutes les permissions nécessaires sur les workspaces et échouer quand même, parce que la permission manquante se trouve ailleurs.

Étape 4. Le bon outil pour le bon flux d’authentification

Premier réflexe naturel dans Azure DevOps : utiliser la tâche AzureCLI@2, couplée à une Service Connection Azure Resource Manager. Mauvais choix : cette tâche présuppose un contexte Azure Resource Manager valide et tente automatiquement un az account set sur un abonnement Azure, ce qui échoue si le Service Principal n’a aucun rôle ARM (normal, il n’en a pas besoin pour parler à Fabric).

L’API Fabric n’a rien à voir avec ARM. Une simple tâche Bash@3, avec des appels curl bruts et un token OAuth2 obtenu via le flux client credentials, suffit, sans dépendance artificielle à un abonnement Azure :

TOKEN=$(curl -s -X POST \
  "https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" \
  -d "scope=https://api.fabric.microsoft.com/.default" \
  | jq -r '.access_token')

Étape 5. Retrouver dynamiquement le pipeline de déploiement et ses stages

Plutôt que de coder en dur des GUID fragiles, le script liste les pipelines de déploiement et les stages disponibles, puis filtre par nom :

curl -s -X GET "https://api.fabric.microsoft.com/v1/deploymentPipelines" \
  -H "Authorization: Bearer $TOKEN" | \
  jq -r --arg NAME "deployPipeline1" '.value[] | select(.displayName==$NAME) | .id'

Étape 6. Déclencher le déploiement, et comprendre la réponse

curl -s -X POST "https://api.fabric.microsoft.com/v1/deploymentPipelines/$PIPELINE_ID/deploy" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"sourceStageId\": \"$SOURCE_STAGE_ID\", \"targetStageId\": \"$TARGET_STAGE_ID\"}"

Exécution réussie du pipeline Azure DevOps avec toutes les étapes vertes Le pipeline Azure DevOps complet, toutes les étapes en succès : authentification, listing du pipeline de déploiement, listing des stages, déclenchement du déploiement.

Point important : la réponse est un 202 Accepted, pas un succès final. L’API Fabric expose ici un pattern de Long Running Operation : le déploiement continue en arrière-plan, et son statut réel doit être vérifié séparément via l’en-tête x-ms-operation-id retourné.

Ce qui manque encore pour une vraie mise en production

Ce mécanisme fonctionne, mais il ne constitue pas à lui seul une solution industrialisée. Pour aller plus loin :

  • Remplacer le client_secret par une Workload Identity Federation (élimine la gestion et la rotation de secrets)
  • Ajouter une porte d’approbation avant tout déploiement vers un stage sensible
  • Vérifier réellement le statut final de l’opération (Succeeded/Failed) plutôt que de s’arrêter au 202
  • Étendre à un vrai modèle à 3 stades (Dev/Test/Production)

Les items du workspace Test avec le Service Principal comme Owner Résultat final dans le workspace Test : tous les items déployés (Lakehouse, environnement, notebooks) ont le Service Principal comme Owner (pas un compte utilisateur), la preuve que le déploiement automatisé a bien fonctionné sans aucune intervention humaine.

En résumé

L’authentification par Service Principal est la bonne réponse technique, mais la mettre en œuvre correctement révèle des subtilités qu’aucune documentation ne couvre entièrement : la séparation des permissions pipeline/workspace, le bon choix d’outil CI/CD selon le flux d’authentification réel, et la nature asynchrone des déploiements Fabric.

Sources officielles

  • Service principals in Fabric Data Warehouse : un Service Principal est une identité Microsoft Entra applicative ; accès accordé via Manage access au niveau du workspace ; jeton d’accès expirant en ~1 h ; obtention d’un jeton Fabric avec az account get-access-token --resource https://api.fabric.microsoft.com.
  • Service principals in Fabric Data Warehouse - Limitations : « Service principals are not supported for Git APIs. SPN support exists only for Deployment pipeline APIs. »
  • Developer tenant settings : « Service principals can call Fabric public APIs » est activé par défaut pour les nouveaux clients ; « Service principals can create workspaces, connections, and deployment pipelines » est désactivé par défaut et couvre les API Create Workspace, Create Connection et Create Deployment Pipeline.
  • Identity support (Fabric REST API) : chaque page d’API indique la prise en charge des Service Principals ; un appel échoue si une API ou un item dépendant ne prend pas en charge l’identité appelante.
  • Deployment Pipelines - Deploy Stage Content : POST /v1/deploymentPipelines/{id}/deploy avec sourceStageId et targetStageId ; réponse 202 Accepted avec en-têtes Location, x-ms-operation-id, deployment-id, Retry-After ; l’appelant doit avoir le rôle admin sur le pipeline de déploiement et être au moins contributor sur les workspaces source et cible ; scope Pipeline.Deploy ; maximum 300 items.
  • Long running operations (Fabric REST API) : modèle asynchrone à suivre après un 202.
  • The deployment pipelines process - Permissions : le rôle pipeline admin est distinct des rôles de workspace.
  • Set a service principal as a pipeline owner : jeton expirant ~1 h, endpoint api.fabric.microsoft.com, Contributor minimum sur le workspace.
  • Tutorial: End-to-end automation in Fabric : Service Principal, capacité et Azure DevOps de bout en bout.