Stockage, requêtes, reprise ETL, formation : une migration vers un lakehouse ne se résume jamais à une ligne budgétaire unique. Voici la décomposition poste par poste pour une ETI gérant 50 à 200 To, avec les ordres de grandeur 2026 de Snowflake, Databricks et BigQuery.
Dès qu'un comité de direction demande "combien ça coûte de migrer vers un lakehouse", la réponse honnête est qu'il n'existe pas de chiffre unique. Ce n'est pas que les éditeurs soient évasifs ; c'est que le coût d'une migration n'est pas une ligne budgétaire unique, mais une combinaison de coûts de calcul, de volume de données, de temps d'ingénierie, de cycles de test et de l'état des données existantes. Pour une ETI gérant entre 50 et 200 To, cette combinaison se traduit par des écarts de budget considérables selon les choix d'architecture et la plateforme cible.
Les ordres de grandeur publiés pour des migrations d'entreprise donnent une première borne : pour un périmètre de plus de 50 To avec dépendances complexes et scope réglementaire, les budgets se situent entre 300 000 et plus de 1 000 000 de dollars. Ce chiffre englobe le conseil, l'intégration et le changement, mais il masque la structure réelle des coûts, qui se décompose en quatre postes bien identifiables : le stockage, le calcul des requêtes, la reprise des pipelines ETL existants, et la montée en compétence des équipes.
Le stockage est l'argument économique le plus souvent mis en avant pour justifier une migration. Les coûts de stockage des entrepôts historiques tournent à 3 à 5 fois ce que coûte la même donnée sur du stockage objet avec Iceberg. Cette différence s'explique par le couplage historique entre stockage et calcul dans les architectures d'entrepôt traditionnelles, un couplage que les formats de table ouverts comme Parquet ou Delta Lake permettent de casser.
En valeur absolue sur les plateformes cloud en 2026 :
Pour une ETI à 100 To, le poste stockage pur se situe donc, sur Snowflake ou BigQuery, autour de 2 300 dollars par mois, hors toute optimisation de compression ou de hiérarchisation entre stockage chaud et froid. C'est rarement le poste qui fait dérailler un budget de migration, mais c'est celui qui justifie historiquement l'argumentaire commercial en faveur du lakehouse.
C'est ici que les trois plateformes se distinguent le plus nettement, et que les écarts de coût mensuel peuvent devenir significatifs selon le profil d'usage de l'ETI.
Un crédit coûte 2,00 dollars en Standard, 3,00 dollars en Enterprise et 4,00 dollars en Business Critical sur AWS US East ; un entrepôt X-Small consomme 1 crédit par heure, et chaque taille supérieure double cette consommation ; le stockage coûte 23 dollars par téraoctet par mois. La facturation se fait à la seconde pendant que l'entrepôt tourne, avec un minimum de 60 secondes à chaque démarrage. Un entrepôt medium (4 crédits/heure) tournant 10 heures par jour en édition Enterprise coûte environ 1 200 dollars par mois rien qu'en compute. Pour les gros comptes, des engagements de capacité à partir de 100 000 crédits annuels réduisent le prix unitaire de 25 à 45 %, un engagement à 3 ans sur 500 000 crédits pouvant faire passer l'édition Enterprise de 3,00 à environ 1,65 dollar par crédit.
Databricks facture en unités propriétaires (DBU) dont le tarif dépend fortement du type de calcul choisi. Les entrepôts SQL coûtent 0,22 dollar par DBU en classique, 0,55 en pro et 0,70 en serverless. Les modes classique et pro tournent dans le compte cloud du client, qui paie donc en plus les machines sous-jacentes, tandis que le mode serverless démarre en quelques secondes, s'arrête à l'inactivité et inclut les machines dans son tarif de 0,70 dollar. Concrètement, un entrepôt SQL de taille medium consomme 24 DBU par heure, soit 16,80 dollars de l'heure en serverless, et une taille small qui reste active dix heures par jour coûte 84 dollars cette journée-là, qu'elle ait traité quatre requêtes ou quatre mille. C'est un point d'attention central pour une ETI : le coût Databricks dépend moins du volume de requêtes que de la discipline d'extinction automatique des clusters.
BigQuery se distingue par un modèle à la donnée traitée plutôt qu'au temps de calcul. Le service facture 6,25 dollars par Tio de données scannées, avec le premier Tio gratuit chaque mois, plus 0,023 dollar par Gio par mois pour le stockage actif, les 10 premiers Gio étant gratuits. Pour les volumes importants et réguliers, il est possible d'acheter de la capacité en slots, à partir de 0,04 dollar par heure de slot en édition Standard et 0,06 en Enterprise, vendue par réservations de 100 slots minimum. Le point de bascule entre les deux modèles est documenté : une réservation Enterprise de 100 slots tenue un mois entier coûte 4 380 dollars, ce qui permet de scanner 701 Tio en on-demand, de sorte que l'on-demand reste le modèle le moins cher tant que l'on ne scanne pas plusieurs centaines de Tio par mois.
Pour une ETI à 100-200 To avec des usages BI classiques (tableaux de bord, reporting mensuel, quelques pipelines batch), BigQuery en on-demand reste souvent le choix le plus prévisible tant que la discipline de requêtage (partitionnement, clustering) est respectée. Sans cette discipline, la facture peut déraper rapidement : une analyse récente illustre qu'un simple SELECT * sur 10 To coûte 62,50 dollars, et que le partitionnement peut réduire ce coût de 90 %.
C'est systématiquement le poste que les comités de direction minorent le plus dans leurs premières estimations. Réécrire des pipelines ETL historiques (souvent développés sur des années, avec de la logique métier enfouie dans des procédures stockées ou des scripts SSIS/Informatica) vers des pipelines ELT natifs du lakehouse demande un travail d'ingénierie qui dépasse largement le simple transfert de données.
La modernisation d'un entrepôt de données implique typiquement de migrer depuis des systèmes sur site ou de première génération cloud vers des plateformes lakehouse ou entrepôt cloud, de redessiner les pipelines ETL en flux ELT, et de mettre en place une gouvernance de données unifiée. Chacune de ces trois briques a un coût d'ingénierie propre, et c'est souvent la combinaison des trois qui explique les écarts entre les estimations initiales et les budgets finaux constatés sur le terrain.
Les retours d'expérience publiés par les éditeurs eux-mêmes donnent une fourchette de gains post-migration, mais ils ne disent rien du coût de la bascule. Sur un périmètre comparable à une ETI de taille significative, un cas documenté de migration de 133 téraoctets de données télécom critiques depuis Cloudera et de l'on-premise vers un lakehouse a mesuré une amélioration de 90 % des performances de requête, avec des requêtes qui prenaient des heures et se terminent désormais en minutes. Mais ce résultat suppose un travail préalable de réécriture complet des pipelines, qui reste la part la plus coûteuse en jours-homme d'un projet de ce type.
Sur le volet méthodologique, les retours convergent sur un point : ne pas migrer en bloc. Plutôt que de tenter une migration "big bang", les organisations devraient commencer par un pilote, évaluer les performances, puis monter en charge progressivement, ce qui réduit les risques, améliore la qualité des données et limite la perturbation des opérations. Ce phasage a un coût direct : il allonge le calendrier mais répartit le risque budgétaire, ce qui est généralement préférable pour une ETI qui ne peut pas se permettre un arrêt prolongé de son reporting réglementaire ou financier.
Le quatrième poste, souvent traité comme un à-côté, conditionne en réalité la capacité de l'ETI à exploiter la nouvelle architecture sans dépendre indéfiniment d'un prestataire externe. Les playbooks de migration identifient systématiquement ce risque : les plus gros risques d'une migration tiennent aux trous de gouvernance, aux incompatibilités de schémas, aux ruptures d'intégration avec les outils BI historiques, et aux lacunes de compétences des équipes sur Spark et les formats lakehouse.
Pour une équipe data interne qui maîtrisait SQL sur un entrepôk classique, la bascule vers un lakehouse implique l'apprentissage de concepts nouveaux : formats de table ouverts (Delta Lake, Iceberg), notebooks Spark, orchestration de pipelines déclaratifs, gouvernance via un catalogue unifié. Ce n'est pas une formation ponctuelle de deux jours mais un accompagnement sur plusieurs mois, avec un existant qui continue de tourner pendant la transition. C'est précisément le type d'accompagnement que propose notre offre de formation aux équipes data en transition, pour limiter la dépendance externe une fois le projet livré.
En assemblant les quatre postes pour un scénario médian de 100 To avec un usage BI classique et quelques pipelines batch quotidiens :
Les gains annoncés par les éditeurs restent réels mais s'accompagnent toujours d'un investissement initial substantiel. Les organisations ayant migré rapportent des réductions de coût de 25 à 75 %, portées non seulement par des requêtes moins chères mais par l'élimination de systèmes redondants, de copies de données dupliquées et de la surcharge de gouvernance multi-plateforme. Mais ce retour sur investissement ne se matérialise qu'après 12 à 18 mois dans la majorité des cas documentés, ce qui doit être intégré dans tout arbitrage budgétaire présenté en comité de direction.
Aucune des trois plateformes n'est universellement la moins chère : le choix dépend du profil d'usage réel.
Dans tous les cas, le chiffrage initial doit intégrer les quatre postes ensemble, et non le seul coût d'infrastructure mis en avant par les calculateurs des éditeurs. C'est le type d'arbitrage que nous accompagnons lors des phases de cadrage avec nos clients, avant tout engagement contractuel sur une plateforme. Pour un diagnostic chiffré adapté à votre volumétrie et à votre stack existante, contactez notre équipe.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus