Le dimensionnement d’une capacité Microsoft Fabric est la décision la plus structurante d’un projet, et c’est presque toujours celle qui est prise le plus vite. Une référence trop grande se paie tous les mois sans rien apporter. Une référence trop petite se paie en throttling, en rapports lents et en confiance perdue — un coût bien plus difficile à rattraper.
La bonne nouvelle : la décision est mesurable. Voici la méthode que j’applique, et les seuils qui font réellement basculer l’arbitrage.
Pourquoi le raisonnement habituel ne fonctionne pas ici
Sur la plupart des services cloud, on paie ce que l’on consomme. Sur Fabric, on achète un débit : une capacité F64 met 64 Capacity Units à disposition en permanence, qu’on les utilise ou non. Le raisonnement « je commence petit, ça grandira avec l’usage » ne s’applique donc pas de la même manière.
Deux conséquences pratiques. D’abord, une capacité inutilisée la nuit coûte exactement autant qu’une capacité saturée. Ensuite, tous les traitements d’un espace de travail — notebooks Spark, entrepôt, rafraîchissements, modèles sémantiques, pipelines — puisent dans la même réserve. Le dimensionnement n’est pas une question de performance isolée, c’est une question d’arbitrage entre équipes.
Étape 1 — Mesurer avant d’acheter
Ne dimensionnez jamais sur une estimation de volumétrie. Le lien entre volume de données et consommation de CU est trop indirect pour être prédictif.
Démarrez sur une capacité payée à l’usage, que l’on peut suspendre, pendant deux à quatre semaines représentatives — en incluant une clôture mensuelle si votre activité en comporte une. Installez l’application Microsoft Fabric Capacity Metrics dès le premier jour.
Ce que vous cherchez n’est pas le pic. C’est :
- la consommation moyenne lissée sur 24 heures ;
- la présence, ou non, d’une dette de lissage reportée d’un jour sur l’autre ;
- les trois traitements les plus coûteux, presque toujours responsables de l’essentiel de la consommation.
Étape 2 — Comprendre ce que le smoothing vous fait économiser
Le smoothing est le mécanisme qui rend Fabric économiquement viable. Le coût d’une opération en arrière-plan est réparti sur 24 heures au lieu d’être imputé à l’instant où elle s’exécute.
Concrètement : un rafraîchissement de dix minutes qui consommerait instantanément 200 CU ne sature pas une F64. Son coût est étalé, et la capacité absorbe le pic. Sans ce mécanisme, il faudrait dimensionner sur le pic instantané — donc acheter plusieurs fois trop de capacité.
C’est pourquoi dimensionner sur le pic est l’erreur la plus coûteuse que l’on puisse commettre ici. Elle conduit systématiquement à surpayer.
La contrepartie est que le lissage crée une dette. Si la consommation quotidienne dépasse durablement ce que la capacité peut absorber, cette dette s’accumule et finit par déclencher du throttling — parfois plusieurs heures après le traitement qui en est la cause. C’est ce décalage qui rend le diagnostic contre-intuitif : le rapport qui ralentit à 10 h peut être la conséquence d’un pipeline lancé à 3 h.
Étape 3 — Identifier le seuil qui décide vraiment
Pour beaucoup d’organisations, le choix ne se fait pas sur la performance mais sur les licences.
En dessous de la F64, chaque personne qui consulte un rapport Power BI a besoin d’une licence Pro individuelle. À partir de la F64, la consultation est incluse dans la capacité.
L’arbitrage est arithmétique : comparez le surcoût annuel du passage à la F64 au coût des licences Pro qu’il supprime. Le point de bascule se situe généralement autour de quelques centaines de lecteurs. En dessous, une capacité plus petite associée à des licences Pro reste plus économique — même si la puissance de la F64 serait confortable.
Vérifiez également les fonctionnalités conditionnées à la référence, et non à la puissance brute : certaines, dont plusieurs capacités liées à Copilot, ne sont pas disponibles sur les plus petites références. Une F8 « suffisante en puissance » peut se révéler bloquante sur une fonctionnalité attendue.
| Situation | Direction raisonnable |
|---|---|
| Moins de 100 lecteurs de rapports | Petite capacité + licences Pro |
| Plusieurs centaines de lecteurs | F64, pour l’économie de licences |
| Charges Spark lourdes, peu de lecteurs | Dimensionner sur le calcul, pas sur les licences |
| Plusieurs métiers, exigences de service différentes | Plusieurs capacités séparées |
Étape 4 — Séparer avant d’agrandir
Le réflexe face au throttling est d’augmenter la capacité. C’est parfois la bonne réponse ; souvent, c’est la plus chère.
Quand un traitement d’une équipe dégrade les rapports d’une autre, le problème n’est pas la taille de la capacité, c’est le partage. Deux capacités moyennes séparées coûtent fréquemment moins qu’une grande capacité unique, et elles garantissent une isolation que la puissance n’apporte pas.
Isolez en priorité ce qui a une exigence de service distincte : les rapports de direction, les environnements de développement, et les charges d’ingénierie lourdes et irrégulières.
La réservation : après, jamais avant
La réservation annuelle offre une remise substantielle contre un engagement de douze mois. C’est un excellent levier — une fois le régime de croisière connu.
La prendre dès le départ revient à figer une erreur de dimensionnement pour un an. Attendez d’avoir deux à trois mois de mesures stables, puis réservez le socle de consommation, en laissant la marge de croissance en paiement à l’usage.
Ce qu’il faut retenir
- Mesurez deux à quatre semaines avant d’acheter quoi que ce soit.
- Dimensionnez sur la consommation moyenne lissée, jamais sur le pic.
- Traitez le seuil F64 comme un arbitrage de licences, pas de performance.
- Face au throttling, envisagez la séparation avant l’agrandissement.
- Réservez seulement une fois le régime de croisière établi.
Et surtout : instrumentez dès le premier jour. Une plateforme Data ne meurt presque jamais d’un problème technique. Elle meurt d’une facture que plus personne ne sait expliquer.