Infrastructure data cloud : services, coûts et migration
Le cloud a modifié l'architecture data de façon définitive. L'infrastructure data on-premise, les serveurs possédés, le stockage SAN, les appliances propriétaires, devient de plus en plus un choix legacy. Mais l'infrastructure data cloud n'est pas une chose unique. C'est un spectre de services et d'arbitrages qui exigent des décisions d'architecture délibérées.
Les services data cloud-native
Chaque grand fournisseur cloud propose une stack data complète. Voici ce que chacun inclut :
AWS : S3 (stockage), Glue (ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète →/catalogue), Redshift (warehouse), Athena (SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → serverless sur S3), EMR (Spark), SageMaker (ML), Kinesis (streaming), Lake Formation (gouvernance).
Google Cloud : GCS (stockage), BigQuery (warehouse + lake hybride), Dataflow (ETL streaming/batch), Vertex AI (ML), Pub/Sub (messaging), Dataplex (gouvernance).
Azure : ADLS Gen2 (stockage), Synapse Analytics (warehouse + lake), Data Factory (ETL), Azure ML, Event Hubs (streaming), Microsoft Purview (gouvernance).
Cloud Data Architecture Patterns
Vérification des acquis
1. D'après la leçon, quelle est la réponse pratique recommandée à la décision build vs. buy ?
2. Pourquoi la leçon estime-t-elle que les formats de tables ouverts (Iceberg, Delta Lake) et les frameworks de compute ouverts (Spark) ont de la valeur ?
3. D'après la leçon, quelle est la raison réelle la plus fréquente pour laquelle les organisations se retrouvent avec des architectures multi-cloud ?
4. Sélectionnez TOUTES les affirmations qui relèvent de l'argument pour ACHETER des produits éditeurs (par opposition à construire).
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les affirmations correctes sur l'infrastructure data cloud telle que présentée dans la leçon.
Sélectionnez toutes les réponses correctes.
La décision build vs. buy
Tout CDO affronte cette décision de façon répétée : construire des solutions sur mesure ou acheter des produits éditeurs ?
L'argument pour acheter : la vitesse de mise en valeur. Une implémentation Snowflake prend des semaines, pas des années. L'éditeur gère l'infrastructure, le tuning de performance et les mises à niveau. Votre équipe se concentre sur les problèmes de données, pas sur les problèmes d'infrastructure.
L'argument pour construire : le contrôle. Vous possédez le code, le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →, l'optimisation. Pas de vendor lock-in. Pas de mauvaise surprise sur la tarification à la requête. L'open source (Spark, Iceberg, Airflow) vous donne une flexibilité totale.
La réponse pratique : achetez les composants commodity (stockage, compute, orchestration en SaaS), construisez ce qui différencie votre business (modèles de données propriétairesdonnées propriétairesDonnées collectées directement auprès de vos clients et prospects via vos propres canaux : votre source la plus fiable et la plus conforme en matière de privacy.Voir la définition complète →, pipelines ML sur mesure, fonctionnalités spécifiques à votre domaine).
Architecture multi-cloud et cloud-agnostique
Le multi-cloud est séduisant sur le papier (pas de vendor lock-in, services best-of-breed) mais il a un coût réel : complexité opérationnelle, coûts de transfert de données, fragmentation des compétences des équipes. La plupart des organisations en multi-cloud le sont pour des raisons réglementaires (exigences de résidence des données) ou à la suite d'opérations de M&A, pas par choix délibéré.
Les formats de tables ouverts (Apache Iceberg, Delta Lake) et les frameworks de compute ouverts (Apache Spark) réduisent le lock-in sans imposer la complexité du multi-cloud. Utilisez-les comme couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète →.
L'architecture de coûts dans le cloud
Les coûts data dans le cloud ne sont pas anodins et sont faciles à sous-estimer. Les principaux postes :
- Stockage : peu cher mais il crocroLe Conversion Rate Optimization (CRO) est la pratique systématique visant à augmenter le pourcentage d'utilisateurs qui réalisent une action souhaitée, en s'appuyant sur la data, les tests et la recherche utilisateur.Voir la définition complète →ît avec la durée de rétention. Mettez en place des lifecycle policies, basculez les données vers des tiers moins chers après 90 jours, archivez après 1 an.
- Compute : le principal coût variable. Le coût des requêtes warehouse croît avec le volume de données scanné. Le clustering et le partitionnement réduisent ce volume, donc directement le coût.
- Egress : déplacer des données entre régions ou vers l'on-premise coûte cher. Concevez pour minimiser les mouvements de données inter-régions.
- Outils et licences : Snowflake, Databricks et outils similaires empilent leur tarification par-dessus les coûts cloud. Modélisez le coût total avant de vous engager.
Chez Spotify, une équipe dédiée à l'« optimisation des coûts de la data platform » a réduit la dépense cloud de 30 % sans réduire les fonctionnalités, grâce à des règles d'optimisation de requêtes, des politiques de rétention et une planification du compute. Un CDO qui ne possède pas l'architecture de coûts ne possède pas vraiment la data platform.
Stratégie de migration : de l'on-prem au cloud
La plupart des CDO héritent d'une part d'infrastructure on-premise. La migration cloud est presque toujours la bonne direction, mais elle demande du séquencement :
- Évaluer et inventorier : ce qui existe, ce que ça coûte, ce que ça supporte
- Identifier les candidats à faible risque : données historiques, données d'archive, workloads de reporting
- Lift-and-shift d'abord : déplacez les workloads avant de les optimiser, prouver que le cloud fonctionne réduit la résistance organisationnelle
- Refactoriser par incréments : optimisez vers des patterns cloud-native après stabilisation
- Décommissionner progressivement : n'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez l'on-premise qu'une fois les workloads cloud stables
Évitez le piège de tout ré-architecturer d'un coup. Beaucoup de migrations cloud échouent non par complexité technique, mais parce que le périmètre est trop ambitieux.
Quiz Questions
- Quelle est la principale raison pour laquelle la plupart des organisations adoptent le multi-cloud ?
A) Pour réduire les coûts
B) Pour des raisons réglementaires ou suite à des M&A
C) Pour améliorer les performances
D) Pour simplifier l'architecture
Réponse: B
- Quel est le principal avantage d'utiliser des formats de tables ouverts comme Apache Iceberg ?
A) Ils sont plus rapides que les solutions propriétaires
B) Ils réduisent les coûts de stockage
C) Ils réduisent le vendor lock-in sans nécessiter une architecture multi-cloud
D) Ils sont maintenus par les fournisseurs cloud
Réponse: C
- Dans la stratégie de migration cloud, quelle est la bonne séquence ?
A) Refactoriser d'abord, puis migrer
B) Tout migrer et optimiser simultanément
C) Inventorier → migrer les cas simples → lift-and-shift → refactoriser → décommissionner
D) Décommissionner l'on-premise avant de migrer
Réponse: C
À faire, tiré de cette leçon
Ces actions sont compilées dans le plan d'action du rôle.
- Migrer vers le cloud : inventaire, lift-and-shift, puis refactoring incrémental
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- DataLe build inutile est la première ligne à couper dans votre facture d'entrepôtdbt State est passé en disponibilité générale en septembre 2026 et promet de ne plus reconstruire ce qui n'a pas changé. Voici le playbook pour transformer cette promesse en baisse de facture mesurable, sans dégrader la fraîcheur des données que consomment vos métiers.
- DataRéduire les coûts cloud sans casser l'analytique : le playbook du CDOLes factures cloud explosent dans la plupart des grandes organisations, souvent sans que la valeur analytique ne suive. Ce playbook donne au CDO une séquence concrète pour reprendre le contrôle des dépenses sans sacrifier la performance des équipes data.
- DataArchitecture de données moderne : pourquoi la majorité des CDO construisent encore sur des fondations fragilesAlors que les entreprises investissent massivement dans leurs infrastructures de données, une réalité troublante s'impose : la plupart des architectures modernes reproduisent les mêmes erreurs structurelles que leurs prédécesseurs. Voici ce que tout CDO doit comprendre pour éviter de bâtir le data warehouse de demain avec les problèmes d'aujourd'hui.