Maîtriser ses coûts de stockage sur Microsoft Fabric : Zoom sur les niveaux de stockage et le lifecycle management de OneLake

Une convergence attendue avec les bonnes pratiques Azure

Avant d’entrer dans le détail, il faut souligner ce que cette annonce signifie en termes d’architecture cloud. En effet, les niveaux Hot / Cool / Cold ne sont pas une nouveauté en soi : ils existent depuis des années sur Azure Blob Storage et Azure Data Lake Storage Gen2, où ils constituent un levier d’optimisation des coûts bien rodé. Toute organisation ayant industrialisé un datalake sur Azure a déjà mis en place des politiques de tiering pour ses zones d’archivage, ses snapshots ou ses logs.

Jusqu’ici, OneLake — bien qu’étant techniquement construit sur ADLS Gen2 — n’exposait pas ces niveaux. Toutes les données reposaient dans le tier Hot, ce qui posait un vrai problème de scalabilité économique sur les workloads d’archivage. Cette annonce comble cette lacune et marque une convergence importante : Fabric n’est plus uniquement une plateforme analytique de nouvelle génération, c’est aussi une plateforme qui adopte les bonnes pratiques FinOps héritées de l’écosystème Azure. Pour les équipes qui pilotent à la fois des workloads Fabric et des datalakes Azure historiques, cela simplifie considérablement la gouvernance et l’harmonisation des politiques de rétention.

Les trois niveaux de stockage OneLake

OneLake propose désormais trois tiers à choisir selon le profil d’accès des données :

• Hot — pour les données actives, fréquemment consultées. C’est le tier par défaut, celui de l’ensemble des données OneLake aujourd’hui.
• Cool — pour les données moins fréquemment accédées, avec un coût de stockage significativement réduit.
• Cold — pour la rétention long terme, avec le coût de stockage le plus bas.

Le compromis fondamental à intégrer : les tiers Cool et Cold offrent un stockage moins cher, mais entraînent en contrepartie des coûts de transaction plus élevés ainsi que des frais de récupération de données lors des lectures. Autrement dit, plus une donnée est « froide », moins elle coûte à conserver, mais plus elle coûte à consulter.

Le tier d’un fichier peut être modifié de plusieurs façons : directement à l’upload, via le tier par défaut du workspace, manuellement, ou — c’est tout l’intérêt de la nouveauté — automatiquement via une politique de lifecycle management.

Le lifecycle management : l’automatisation au service du FinOps

Concrètement, les politiques de lifecycle management permettent de définir des règles automatiques de transition entre tiers, basées sur trois critères :

• la date de création du fichier,
• la date de dernière modification,
• la date de dernier accès.

Une fois définies, ces politiques s’exécutent en tâche de fond, sans intervention humaine. Exemples de règles typiques :

• Déplacer vers Cool les fichiers non modifiés depuis 30 jours, puis vers Cold après 90 jours.
• Pour un chemin donné, déplacer en Cool les fichiers non accédés depuis 30 jours, avec retour automatique en Hot dès qu’ils sont à nouveau consultés.

Cette approche dynamique aligne en permanence le tier de stockage sur le pattern d’accès réel, sans figer la donnée dans un état coûteux.

Cas d’usage concrets côté clients

Archivage réglementaire

Les obligations RGPD, mais aussi les exigences sectorielles dans la banque-finance (LCB-FT, MiFID II, conservation 5 à 10 ans) ou dans la santé (hébergement HDS, dossiers médicaux à 20 ans) imposent de conserver des volumes importants de données rarement consultées. Stocker ces archives en tier Cold permet de réduire drastiquement la facture sans renoncer à la disponibilité immédiate en cas de contrôle.

Historisation des couches bronze d’une architecture médaillon

Dans une approche médaillon (bronze / silver / gold), la couche bronze conserve les données brutes ingérées, dont seule une petite fraction récente est réellement réutilisée par les pipelines d’ingestion incrémentale. Une politique qui bascule en Cool après 30 jours et en Cold après 90 jours sur la zone bronze peut générer des économies substantielles, tout en gardant les données disponibles pour un re-traitement ponctuel.

Snapshots de conformité et audits périodiques

De nombreuses organisations conservent des snapshots ponctuels (clôtures comptables mensuelles, états des systèmes en fin d’année fiscale, jeux de données figés pour audit) qui ne sont consultés que quelques fois par an, voire jamais. Le tier Cold est taillé pour ce profil, à condition d’avoir anticipé le pic de CU lors de la lecture.

L’analyse FinOps

L’article de Microsoft illustre l’intérêt de la fonctionnalité avec un exemple concret : un workspace contenant 10 To de données bronze à conserver pendant 5 ans, avec un audit annuel lisant 1 To.

Soit jusqu’à 82 % d’économies en passant de Hot à Cold.

C’est ici que se trouve le vrai sujet d’architecture. En effet, les écarts de consommation CU entre les tiers sont massifs : la lecture d’1 To sur le tier Cool consomme environ 80 fois plus de CU qu’en Hot, et le tier Cold pousse ce ratio à environ 255 fois.

Il est donc recommandé de prévoir des montées de capacité temporaires lorsqu’il devient nécessaire d’accéder aux données archivées.

Mise en route

1. Ouvrir le workspace dans Microsoft Fabric
2. Aller dans Workspace settings > OneLake > Lifecycle management
3. Créer une règle de cycle de vie
4. 

La gestion peut également se faire via les nouvelles API OneLake Lifecycle Management, ce qui ouvre la voie à une industrialisation complète des politiques de tiering dans une approche Infrastructure-as-Code.

Conclusion

Avec les niveaux de stockage et le lifecycle management, OneLake gagne en maturité et s’aligne sur les standards FinOps de l’écosystème Azure.

Ainsi, pour les organisations qui hébergent de gros volumes historiques sur Fabric — couches bronze, archives réglementaires, snapshots de conformité — la fonctionnalité représente un levier d’économie majeur, à condition d’être adoptée avec méthode : analyse des patterns d’accès et définition de politiques cohérentes avec la stratégie de données de l’entreprise.