Accueil›Blog›Test technique architecture cloud-native data : serverless, managed services
Guide recrutement data
Test technique architecture cloud-native data : serverless, managed services
Une architecture cloud-native optimise l utilisation des services managés pour minimiser l opérationnel. En entretien Architect, on évalue la capacité à choisir entre managed et self-hosted selon les contraintes.
Data Builder·Juin 2025·6 min de lecture·Data Engineer · Data Architect
1Principes d une architecture cloud-native data
Question discriminante
Quels sont les principes d une architecture data cloud-native ?
- Services managés par défaut — utiliser BigQuery, Snowflake, Cloud Composer plutôt que de gérer son propre cluster Spark ou Airflow
- Infrastructure as Code — toute l infrastructure est définie en Terraform. Reproductible, versionné, auditeable
- Autoscaling — les ressources scalent automatiquement selon la charge. Pas de capacité statique
- Pay-per-use — payer uniquement ce qui est consommé. Serverless pour les charges variables
- Séparation stockage/compute — stocker dans S3/GCS, calculer avec des services éphémères
2Managed vs self-hosted : la matrice de décision
Question discriminante
Comment décidez-vous entre un service managé et une solution self-hosted ?
| Critère | Managed recommandé | Self-hosted envisageable |
|---|
| Taille équipe | < 5 Data Engineers | > 10 avec DevOps dédié |
| Budget opérationnel | Pas de budget infra | Budget DevOps disponible |
| Customisation | Besoins standard | Besoins très spécifiques |
| Conformité | Cloud certifié suffit | Air-gap obligatoire |
| Volume | Coût managed acceptable | Coût managed prohibitif (TB/jour) |
3Serverless pour la data
Question discriminante
Quels services serverless data utilisez-vous et dans quels cas ?
- BigQuery — serverless SQL. Payer uniquement les octets scannés. Idéal pour les requêtes ad-hoc
- Snowflake Serverless — pas de warehouse à gérer. Pour les workloads très intermittents
- Cloud Run (GCP) — conteneurs serverless pour les APIs ML et les scripts d ingestion. Scale to zero
- AWS Lambda — fonctions event-driven pour les petits traitements (< 15 min, < 10GB RAM)
- Databricks Serverless — notebooks et jobs sans cluster à gérer. Startup en 10 secondes
4Gérer le vendor lock-in
Question discriminante
Comment concevez-vous une architecture qui évite le vendor lock-in tout en profitant des services managés ?
- Formats ouverts — stocker en Parquet/Iceberg/Delta dans S3/GCS. Lisible par tous les engines
- Abstraction SQL — dbt abstrait le SQL spécifique au warehouse. Changer de warehouse = changer l adapter dbt
- Interfaces standardisées — Apache Arrow, OpenLineage, OpenTelemetry : standards ouverts pour l interopérabilité
- Accepter un certain lock-in — les fonctionnalités managées (BigQuery ML, Snowflake Cortex) sont pratiques. Documenter les dépendances et évaluer le risque
5Architecture multi-cloud : réalité ou buzzword
Question discriminante
Dans quels cas une architecture multi-cloud data est-elle justifiée ?
- Réalité rare — 90% des architectures n ont pas besoin d être multi-cloud. La complexité opérationnelle est énorme
- Justifications valides — acquisition d une entreprise sur un autre cloud, obligation réglementaire de résilience, négociation tarifaire
- Approche pragmatique — stocker dans S3 (AWS) et calculer dans BigQuery (GCP) via BigQuery Omni ou BigLake. Plus simple qu un vrai multi-cloud
- Apache Iceberg — catalog REST + fichiers S3/GCS = portabilité maximale entre clouds
6Modèle de coûts cloud-native
Question discriminante
Comment modélisez-vous les coûts d une architecture data cloud-native avant de la construire ?
- Coûts variables — compute (par seconde ou par octet scanné) + stockage (par GB/mois) + réseau (egress)
- Simuler la croissance — modéliser les coûts à x2, x10 et x100 du volume actuel. Les architectures cloud-native scalent en coût lineairement
- Reserved capacity — si la charge est prévisible, réserver du compute à l avance (30-70% d économie)
- Outil de sizing — AWS Pricing Calculator, Google Cloud Pricing Calculator, Snowflake Cost Estimator
7Grille par niveau
| Niveau | Maitrise | Signal GO | NO-GO |
|---|
| Confirmé | Services managés courants, Infrastructure as Code basique | Utilise des services managés par défaut, a déployé avec Terraform | Installe tout sur des VMs manuellement |
| Senior | Matrice managed/self-hosted, vendor lock-in, modélisation des coûts | Justifie ses choix managed vs self-hosted, modélise les coûts avant de construire | Ne peut pas expliquer le trade-off managed vs self-hosted |
Vous recrutez un Data Architect ou Data Engineer Lead ?
Premier entretien gratuit. Rapport GO/NO-GO sous 48h.