Limites et compromis du cloud : coûts, latence, lock-in, souveraineté

Le cloud computing offre des avantages indéniables (élasticité, scalabilité, pay-as-you-go), mais il impose aussi des contraintes réelles : coûts qui explosent sans gouvernance, vendor lock-in, latence réseau incompressible, souveraineté des données, quotas et limites techniques. Ce guide vous explique les compromis à accepter et comment les anticiper avant de migrer vers le cloud.

Ce que vous allez apprendre

• Les pièges financiers du cloud (coûts cachés, egress, sur-dimensionnement)
• Le vendor lock-in et comment le mitiger
• Les limites techniques (latence, quotas, API rate limits)
• Les enjeux de souveraineté et conformité (RGPD, Cloud Act)
• Les cas où le cloud n’est pas adapté

Prérequis : Connaître les bases du cloud computing. Si besoin, commencez par Définition et promesses du cloud.

1. Coûts : le piège du pay-as-you-go

Le modèle pay-as-you-go est présenté comme un avantage (vous ne payez que ce que vous consommez), mais il peut rapidement devenir un cauchemar financier sans gouvernance stricte.

Le paradoxe du cloud

Promesse : “Plus besoin d’investir massivement, vous payez à l’usage”

Réalité : Sans contrôle, la facture cloud peut dépasser le coût d’une infrastructure on-premise classique.

Exemple concret : startup SaaS

Scénario :

• Mois 1-6 : Déploiement initial, 5 serveurs → 300 €/mois
• Mois 7 : Lancement marketing, 50 serveurs autoscalés → 3 000 €/mois
• Mois 8 : Oubli d’arrêter environnements de test → 5 000 €/mois
• Mois 12 : Base de données sur-dimensionnée + stockage jamais nettoyé → 8 000 €/mois

Sans optimisation : 96 000 €/an pour une infrastructure qui pourrait coûter 30 000 €/an bien gérée.

Les coûts cachés du cloud

💸 Egress (sortie de données)

Le piège : Les données qui entrent dans le cloud sont gratuites, celles qui sortent sont facturées (typiquement 0,05 à 0,12 €/GB selon les fournisseurs).

Exemple :

• Site e-commerce avec 10 TB de trafic sortant/mois
• Coût egress : 10 000 GB × 0,09 € = 900 €/mois juste pour la bande passante

Mitigation : CDN (CloudFront, Cloudflare), compression, cache navigateur

🗄️ Stockage cumulatif

Le piège : Les snapshots, sauvegardes et logs s’accumulent indéfiniment si non nettoyés.

Exemple :

• 100 snapshots horaires conservés pendant 1 an
• Base de données 500 GB → 500 GB × 100 snapshots = 50 TB
• Coût : 50 000 GB × 0,02 €/GB = 1 000 €/mois de stockage inutile

Mitigation : Lifecycle policies, rétention automatique (7 jours snapshots, 30 jours backups)

🔄 Transferts inter-région

Le piège : Copier des données entre régions coûte cher (0,02 €/GB).

Exemple :

• Réplication continue base de données eu-west-1 → us-east-1
• 500 GB répliqués/jour = 15 TB/mois
• Coût : 15 000 GB × 0,02 € = 300 €/mois juste pour la réplication

Mitigation : Réplication intra-région uniquement, compression, delta sync

⚡ Instances oubliées

Le piège : Environnements de dev/test non arrêtés la nuit/week-end.

Exemple :

• 10 serveurs dev (t3.medium) tournant 24/7
• Coût : 10 × 0,04 €/h × 730h/mois = 292 €/mois
• Si arrêtés 16h/jour en semaine : 97 €/mois (économie 67%)

Mitigation : Autoscaling schedule, Lambda shutdown automatique, tagging obligatoire

Checklist maîtrise des coûts

• Budgets et alertes configurés dès le jour 1 (outils du fournisseur ou FinOps tiers)
• Tagging obligatoire pour attribution par projet/équipe/environnement
• Right-sizing automatisé (analyseurs de performance du fournisseur)
• Reserved Instances/Savings Plans pour workloads stables (économie 40-60%)
• Lifecycle policies pour snapshots, logs, backups (rétention max 30 jours)
• Spot Instances pour workloads fault-tolerant (économie 70-90%)
• Shutdown automatique environnements non-prod (soirs, week-ends)

Le cloud n'est pas automatiquement moins cher

Mythe : “Le cloud coûte toujours moins cher que l’on-premise”

Réalité : Le cloud peut coûter 2 à 3 fois plus cher qu’une infrastructure classique si mal géré. Les économies viennent de :

• L’élasticité (scaler down quand inutilisé)
• L’automatisation (moins de ressources humaines)
• L’agilité (time-to-market réduit)

Mais si vous laissez tourner 100 serveurs 24/7 sans optimisation, vous payerez plus cher que des serveurs dédiés.

2. Vendor Lock-in : la dépendance au fournisseur

Le vendor lock-in est la dépendance forte à un fournisseur cloud qui rend la migration vers un autre coûteuse, longue et risquée.

Pourquoi le lock-in existe

Les fournisseurs cloud proposent des services managés propriétaires très pratiques mais non-portables :

Service AWS	Équivalent Azure	Équivalent GCP	Standard ouvert
Lambda	Functions	Cloud Functions	❌ Aucun
DynamoDB	Cosmos DB	Firestore	❌ Aucun
ECS	ACI	Cloud Run	✅ Kubernetes (portable)
RDS Aurora	Azure Database	Cloud SQL	⚠️ PostgreSQL (standard, mais config propriétaire)
S3	Blob Storage	Cloud Storage	✅ API S3 (de facto standard)

Glissez pour voir

Problème : Si vous utilisez Lambda + DynamoDB + Aurora, migrer vers Azure demande :

• Réécrire les fonctions Lambda → Azure Functions (syntaxe différente)
• Migrer DynamoDB → Cosmos DB (API différente, requêtes à adapter)
• Reconfigurer Aurora → Azure Database (paramètres propriétaires)

Coût estimé : 6 mois à 2 ans de refonte pour une application moyenne.

Niveaux de lock-in

Lock-in faible

Architecture portable : Utilise uniquement des standards ouverts.

Infrastructure:
  - VMs classiques (IaaS) → portable (Terraform)
  - Kubernetes → portable (manifests YAML standard)
  - PostgreSQL standard → portable (dump SQL)
  - Stockage objet S3-compatible → portable (API S3)

Migration : 1 à 3 mois (infrastructure as code + dump/restore bases)

Exemple : Application conteneurisée Kubernetes + PostgreSQL + S3

Lock-in moyen

Architecture mixte : Services managés partiellement portables.

Infrastructure:
  - Kubernetes managé (EKS/AKS/GKE) → portable avec effort
  - RDS PostgreSQL → portable (dump SQL, reconfiguration)
  - Redis managé → portable (dump/restore)
  - Load Balancer managé → reconfiguration nécessaire

Migration : 3 à 6 mois (reconfiguration infrastructure managée)

Exemple : Kubernetes + bases managées standards

Lock-in fort

Architecture propriétaire : Services 100% propriétaires.

Infrastructure:
  - Lambda/Functions → réécriture complète
  - DynamoDB/Cosmos DB → migration données + refonte queries
  - Aurora Serverless → reconfiguration complète
  - API Gateway propriétaire → remplacement
  - Queues propriétaires (SQS/Service Bus) → refonte messaging

Migration : 6 mois à 2 ans (refonte applicative quasi complète)

Exemple : Serverless natif (Lambda + DynamoDB + API Gateway)

Stratégies pour mitiger le lock-in

Stratégie #1 : Abstraction

Utiliser des couches d’abstraction pour isoler les dépendances cloud.

Exemple : Au lieu d’appeler directement DynamoDB dans le code :

# ❌ Lock-in fort : appel direct DynamoDB
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('users')
table.put_item(Item={'id': '123', 'name': 'Alice'})

# ✅ Lock-in faible : abstraction via repository
class UserRepository:
    def save(self, user):
        # Implémentation DynamoDB cachée
        pass

# Code métier indépendant du cloud
repo = UserRepository()
repo.save(user)

Si migration vers PostgreSQL, seule la classe UserRepository change, pas le code métier.

Stratégie #2 : Standards ouverts

Privilégier les technologies portables.

Besoin	❌ Propriétaire	✅ Standard ouvert
Orchestration	ECS	Kubernetes
Base SQL	Aurora Serverless	PostgreSQL standard
Cache	ElastiCache	Redis auto-hébergé
Stockage	Glacier	S3-compatible (MinIO)
Messaging	SQS	RabbitMQ, Kafka

Glissez pour voir

Stratégie #3 : Multi-cloud sélectif

Ne pas mettre tous ses œufs dans le même panier… mais attention à la complexité.

Approche pragmatique :

• Compute/data : Cloud principal (Outscale, OVH, ou autre)
• Disaster Recovery : Cloud secondaire en standby (fournisseur différent)
• DNS/CDN : Service neutre (Cloudflare, Fastly)

Lock-in : pragmatisme avant dogme

Le lock-in n’est pas toujours un problème.

Si Lambda vous fait gagner 6 mois de développement et que vous n’avez aucune raison objective de changer de cloud dans les 5 prochaines années, utilisez Lambda.

Critères de décision :

• Startup en croissance rapide → lock-in acceptable (time-to-market critique)
• Entreprise réglementée → mitiger lock-in (risque changement législatif)
• Multinationale → multi-cloud si équipes matures

3. Latence réseau : la physique ne ment pas

Le cloud est accessible via Internet. Contrairement à un datacenter local, la latence réseau est incompressible et peut impacter les performances.

Distances et latences typiques

Trajet	Distance	Latence (aller-retour)
Paris ↔ eu-west-3 (Paris)	< 50 km	2-5 ms
Paris ↔ eu-west-1 (Irlande)	~800 km	15-25 ms
Paris ↔ us-east-1 (Virginie)	~6000 km	80-120 ms
Paris ↔ ap-southeast-1 (Singapour)	~11000 km	180-250 ms

Glissez pour voir

La vitesse de la lumière est la limite : Signal théorique = 300 000 km/s. Signal réel (fibre optique) = ~200 000 km/s.

Paris ↔ Singapour (11 000 km) : 11 000 / 200 000 = 55 ms minimum théorique (aller simple). En pratique : 90-125 ms aller simple (routeurs, switchs, congestion).

Impact métier de la latence

🌐 API REST classique

Latence acceptable : < 200 ms

Scénario : Application web appelant une API backend.

• Paris → eu-west-3 (Paris) : 5 ms → ✅ Excellent
• Paris → us-east-1 (Virginie) : 100 ms → ⚠️ Perceptible mais acceptable
• Paris → ap-southeast-1 (Singapour) : 200 ms → ❌ Lent

Mitigation : CDN, cache (Redis), API Gateway régional

💹 Trading haute fréquence

Latence acceptable : < 10 ms

Scénario : Ordres boursiers en temps réel.

• Seul datacenter on-premise à proximité de la bourse acceptable
• Cloud public incompatible (latence trop élevée)

Mitigation : Aucune (rester on-premise ou co-location bourse)

🎮 Jeux multijoueurs

Latence acceptable : < 50 ms

Scénario : Serveurs de jeu en temps réel.

• Solution : Déployer dans plusieurs régions proches des joueurs
• Joueurs EU → eu-west, joueurs US → us-east, joueurs Asie → ap-southeast

Mitigation : Multi-région + matchmaking géolocalisé

📊 Analytique batch

Latence acceptable : Secondes à minutes

Scénario : Traitement batch données (ETL, rapports).

• Latence réseau négligeable (traitement long)
• Optimiser débit (bande passante) vs latence

Mitigation : Aucune nécessaire

Checklist latence cloud

• Mesurer la latence réelle avant migration (ping, traceroute, tests de charge)
• Choisir la région la plus proche de vos utilisateurs principaux
• CDN pour contenus statiques (images, CSS, JS)
• Cache distribué (Redis, Memcached) pour données fréquemment lues
• Architecture multi-région si base utilisateurs mondiale
• Éviter chatty protocols (trop d’appels API successifs)

Latence cloud vs on-premise

On-premise local : 1-2 ms (LAN interne) Cloud même région : 2-10 ms (via Internet) Cloud région éloignée : 50-250 ms

Si votre application fait 100 appels API séquentiels pour afficher une page :

• On-premise : 100 × 2 ms = 200 ms
• Cloud eu-west : 100 × 5 ms = 500 ms
• Cloud us-east : 100 × 100 ms = 10 secondes 🐌

Solution : Réduire le nombre d’appels (batching, GraphQL, cache).

4. Souveraineté et conformité

RGPD et localisation des données

Le RGPD (Règlement Général sur la Protection des Données) impose des contraintes strictes sur le stockage et le transfert de données personnelles de citoyens européens.

Obligations :

• Données personnelles UE doivent rester dans l’UE (sauf exceptions)
• Transferts hors UE nécessitent des garanties (clauses contractuelles, certification)
• Droit à l’oubli, portabilité, transparence

Cloud public :

• ✅ Régions EU disponibles (eu-west-1 Irlande, eu-west-3 Paris, eu-central-1 Francfort)
• ⚠️ Certains services US-only (nouveautés AWS lancées d’abord aux US)
• ❌ Support technique peut accéder aux données depuis les US (selon contrat)

Clouds souverains :

• ✅ Outscale (France, certifié SecNumCloud ANSSI)
• ✅ OVH (France, données garanties UE)
• ✅ Scaleway (France, souverain)

Cloud Act (US)

Le Cloud Act (Clarifying Lawful Overseas Use of Data Act) est une loi américaine permettant aux autorités US d’exiger l’accès aux données stockées par des entreprises américaines, même si ces données sont physiquement en Europe.

Implications :

• AWS, Azure, GCP sont des entreprises US → soumises au Cloud Act
• Un juge US peut ordonner l’accès aux données stockées sur AWS eu-west-1 (Irlande)
• L’entreprise cloud est obligée de fournir les données (même si RGPD interdit)

Conflit RGPD vs Cloud Act :

• RGPD : Interdit transfert données UE vers US sans garanties
• Cloud Act : Oblige les entreprises US à fournir données même stockées en UE

Solutions :

1. Chiffrement bout-en-bout : AWS ne peut pas déchiffrer (vous gérez les clés)
2. Cloud souverain européen : Non soumis au Cloud Act (Outscale, OVH, Scaleway)
3. On-premise : Données ne quittent jamais vos locaux

Certifications et conformité

Secteur	Certification	Cloud compatible
Santé (France)	HDS (Hébergeur Données de Santé)	✅ AWS, Azure, Outscale, OVH
Sécurité (France)	SecNumCloud	✅ Outscale, OVH (partiel)
Finance	PCI-DSS	✅ AWS, Azure, GCP
Gouvernement US	FedRAMP	✅ AWS GovCloud, Azure Gov

Glissez pour voir

Conformité ne garantit pas souveraineté

Une certification ne protège pas du Cloud Act.

AWS/Azure peuvent être certifiés HDS (Hébergeur Données de Santé français) ET soumis au Cloud Act.

Pour une souveraineté totale : Cloud européen (Outscale, OVH) ou on-premise.

5. Limites techniques

Quotas et rate limits

Tous les clouds imposent des quotas (limites de ressources) et rate limits (nombre d’appels API/seconde) pour éviter l’abus.

Exemples AWS :

Ressource	Quota par défaut	Augmentable
Instances EC2	20 vCPU (région)	✅ Sur demande
Adresses IP élastiques	5	✅ Justification nécessaire
Appels API S3	3500 PUT/s, 5500 GET/s (préfixe)	✅ Partitionnement
Lambda concurrence	1000 exécutions simultanées	✅ Sur demande
RDS snapshots	100 (manuels)	❌ Limite dure

Glissez pour voir

Conséquence : Si vous lancez 100 serveurs d’un coup sans avoir demandé l’augmentation du quota, seuls 20 démarreront (quota 20 vCPU).

Mitigation :

• Demander les augmentations de quotas avant le lancement
• Anticiper la croissance (demander quota × 3)
• Monitorer les limites (AWS Trusted Advisor)

Limites de scalabilité

Le cloud scale… mais pas infiniment instantanément.

Limites réelles :

• Autoscaling : 1-5 minutes pour démarrer une nouvelle instance (boot + health check)
• Base de données : Scale vertical limité (instance max ~1 TB RAM), scale horizontal complexe (sharding)
• API Gateway : 10 000 req/s max (augmentable, mais délai 2 semaines)

Exemple : Pic de trafic × 100 en 30 secondes (lancement produit, tweet viral)

• ❌ Autoscaling ne suivra pas (trop lent à démarrer instances)
• ✅ Solution : Pre-warming (instances standby) ou serverless (Lambda scale instantané)

Indisponibilités cloud

Les clouds publics tombent en panne. Rarement, mais ça arrive.

Exemples récents :

• AWS us-east-1 (2021) : Panne 5h → Reddit, Slack, Disney+ impactés
• Azure (2023) : Panne DNS mondiale 2h → Teams, Outlook indisponibles
• GCP (2019) : Panne réseau 4h → YouTube, Gmail ralentis

SLA réels :

• 99.9% = 8h 45min d’indisponibilité max/an
• 99.99% = 52 min/an
• 99.999% = 5 min/an (uniquement multi-région active-active)

Le cloud n'est pas magique

Mythe : “Le cloud ne tombe jamais en panne”

Réalité : Même AWS tombe parfois. La différence vs on-premise :

• ✅ Équipes AWS de 1000+ personnes pour réparer vite
• ✅ Transparence (status.aws.amazon.com)
• ❌ Vous ne contrôlez pas la résolution (dépendance totale)

Pour la HA critique : Déployer multi-région (mais coût × 2).

6. Quand le cloud n’est PAS adapté

Certains cas d’usage sont incompatibles avec le cloud public :

❌ Latence ultra-faible requise

• Trading haute fréquence (< 1 ms)
• Contrôle industriel temps-réel
• Jeux competitifs esport (< 10 ms)

Solution : On-premise ou edge computing

❌ Contraintes de souveraineté strictes

• Données secret défense
• Infrastructures critiques (OIV)
• Pays avec interdiction cloud étranger

Solution : Cloud souverain (Outscale SecNumCloud) ou on-premise

❌ Workloads 100% stables

• Serveurs tournant 24/7 toute l’année sans variation
• Pas de pics de trafic

Solution : Serveurs dédiés peuvent être moins chers (calcul TCO sur 3 ans)

❌ Bande passante massive continue

• Streaming vidéo 4K non-stop
• Backup continu de pétaoctets

Solution : Egress cloud trop cher, préférer CDN ou on-premise

À retenir

Le cloud computing impose des compromis à bien comprendre avant migration :

1. Coûts : Pay-as-you-go avantageux SI bien géré (gouvernance FinOps obligatoire)
2. Vendor lock-in : Réel mais mitigeable (abstraction, standards ouverts)
3. Latence : Incompressible (physique), choisir région proche utilisateurs
4. Souveraineté : RGPD + Cloud Act = choisir cloud européen si critique
5. Limites techniques : Quotas, rate limits, indisponibilités existent

Le cloud n’est pas une solution miracle. C’est un outil puissant qui nécessite expertise, gouvernance et compromis.

Prochaines étapes

Définition et promesses du cloud

Comprenez les 5 caractéristiques fondamentales du cloud

Définition et promesses

Résilience et haute disponibilité

Concevez des architectures tolérantes aux pannes

Résilience, HA, DR

Modèles de déploiement

Choisissez entre cloud public, privé, hybride ou multi-cloud

Modèles de déploiement

×

📖 Voir la documentation →