T'es pas cloud native, t'es cloud piégé

date: Dec 1 2025 6 min de lecture

Le cloud devait faire gagner du temps. Maintenant il faut une équipe FinOps pour comprendre la facture.

.cloud.devops.opinion.finops

Le cloud devait tout simplifier. Plus de hardware à gérer. Plus de capacity planning. Tu déploies et ça scale

À la place on a eu 200+ services AWS, des factures qui demandent un doctorat pour être comprises, et un nouveau métier appelé “FinOps Engineer” dont le seul but c’est de comprendre pourquoi tu paies 50k€/mois

Le cloud nous a sauvés de la gestion des serveurs. Puis il a créé toute une industrie de consultants pour gérer le cloud

La promesse vs la réalité

La promesse: Concentre-toi sur ton code, pas l’infra. Ne paie que ce que tu utilises. Scale à l’infini

La réalité: T’as besoin de consultants AWS pour architecturer ton système. T’as besoin d’ingés FinOps pour comprendre ta facture. T’as besoin d’ingés DevOps spécialisés en CloudFormation. T’as besoin d’ingés sécu qui connaissent les policies IAM

Le cloud a pas éliminé les ops. Il a juste fait en sorte que les ops demandent des certifications vendor-specific

Une VM ça demande quelqu’un qui connaît Linux. AWS ça demande quelqu’un qui connaît Linux ET 47 services propriétaires ET comment ils interagissent ET leurs modèles de pricing ET leurs gotchas

On a échangé un type de complexité pour un autre. Sauf que maintenant tu peux pas googler les réponses parce que chaque setup est un flocon de neige unique de services managés

Le coût humain dont personne ne parle

“Mais les services managés font gagner du temps”

Ah bon ? Comptons les gens dont t’as maintenant besoin:

  • Un solutions architect pour designer le système
  • Un ingé DevOps pour l’implémenter
  • Un analyste FinOps pour surveiller la facture
  • Un spécialiste sécu pour IAM et la compliance
  • Un consultant quand quelque chose casse d’une façon que personne ne comprend
  • Un commercial du vendor pour expliquer pourquoi tes reserved instances couvrent pas ce que tu pensais

Compare ça à une VM:

  • Quelqu’un qui connaît Linux

Le cloud a pas réduit les effectifs. Il les a spécialisés. Et les gens spécialisés coûtent plus cher

La taxe connaissance

Ton dev junior peut SSH dans une VM et comprendre ce qui se passe. Il peut lire les logs, checker les process, piger la situation

Ton dev junior peut pas débugger pourquoi les cold starts Lambda tuent ta p99 latency sans une semaine à lire la doc AWS. Il peut pas comprendre pourquoi ses requêtes DynamoDB coûtent 500€/mois sans apprendre les RCUs, WCUs, et scan vs query. Il peut pas comprendre pourquoi son setup VPC marche pas sans comprendre les NAT gateways, les route tables, et les security groups

Le cloud a une taxe connaissance. Chaque service propriétaire c’est un nouveau truc à apprendre. Un nouveau set de gotchas. Un nouveau modèle de pricing à comprendre

Et cette connaissance expire. AWS déprécie des services. Change les prix. Modifie les comportements. Ton expertise durement acquise a une date de péremption

Les connaissances PostgreSQL durent une carrière. Les connaissances DynamoDB durent jusqu’à ce qu’Amazon décide de pousser un nouveau truc

Le piège des crédits

Voilà comment ça marche:

  1. AWS/GCP/Azure file 100k€ de crédits à ta startup
  2. Tu construis tout sur leurs services propriétaires
  3. Les crédits expirent après 2 ans
  4. Ta facture c’est maintenant 8k€/mois
  5. Migrer coûterait 6 mois de temps ingénieur
  6. T’es piégé. Pour toujours

C’est pas un bug. C’est le business model

Et qui en bénéficie ? Les cloud vendors. Les consultants. Les speakers de conf. Les programmes de certif. Tout le monde sauf la boîte qui paie la facture

L’absurdité FinOps

On a inventé une discipline entière pour comprendre les factures cloud

Réfléchis à ça. Le pricing est tellement complexe, tellement opaque, tellement plein de gotchas que les boîtes embauchent des employés à temps plein juste pour comprendre ce qu’elles paient

Les frais de data processing NAT Gateway. Les coûts de transfert cross-AZ. Les charges d’ingestion CloudWatch. Le pricing des requêtes S3. La facturation Lambda à la milliseconde. Le suivi d’utilisation des reserved instances

Une VM coûte 15€/mois. C’est la facture. C’est tout. Pas de surprises. Pas de frais cachés. Pas d’analyste dédié nécessaire

Les vrais trade-offs

Le cloud a de vrais avantages:

  • Pas de hardware à gérer
  • Une infra globale disponible instantanément
  • Une vraie élasticité pour les workloads imprévisibles
  • Des bases de données managées qui gèrent les backups et le failover

Mais sois honnête sur les coûts:

  • Du vendor lock-in qui s’accumule avec le temps
  • Une complexité de pricing qui demande du staff dédié
  • Des silos de connaissance autour des services propriétaires
  • Des coûts de sortie qui grandissent avec chaque service adopté

La question c’est pas “cloud vs pas cloud”. C’est “est-ce que les trade-offs valent le coup pour TA situation”

Pour une startup avec 100k€ de crédits et zéro expérience ops ? Peut-être

Pour une boîte qui paie le prix du marché avec des workloads prévisibles ? Fais le calcul

L’état d’esprit flexibilité

J’utilise AWS quand ça a du sens. J’utilise Lambda quand c’est le bon outil. Le cloud c’est pas le mal

Mais je fais aussi tourner des workloads sur des VMs simples. Parce que parfois un VPS à 15€ fait le même taf que 300€ de services managés

L’objectif c’est la flexibilité:

  • Utiliser des standards ouverts quand c’est possible
  • Éviter les services propriétaires quand des alternatives existent
  • Calculer les coûts de sortie avant d’adopter de nouveaux services
  • Se demander si la complexité est nécessaire

Cloud native ça devrait vouloir dire “tourne partout”. Pas “tourne que sur AWS”

Le mot de la fin

Le cloud devait nous sauver de la complexité infra. À la place il a créé un nouveau type de complexité qui demande des consultants, des certifications, et des analystes de coûts dédiés

C’est pas du progrès. C’est un type différent de lock-in

Avant de te lancer à fond dans les services managés, demande-toi: est-ce que ça me fait vraiment gagner du temps, ou est-ce que j’échange juste un set de problèmes pour un autre ? Et qui en bénéficie vraiment ?

Le cloud c’est un outil. Utilise-le intelligemment. Laisse-le pas t’utiliser

Vous avez aimé cet article ? Partagez-le !

Sofiane Djerbi
Sofiane Djerbi

Architecte Cloud & Kubernetes, Expert FinOps.

Commentaires