Faut-il choisir le cloud pour son infra ?

En startup, la question ne se pose même plus : on part sur AWS, GCP ou Azure dès le jour 1. Le cloud est devenu une doctrine, un réflexe. Mais après plus de 15 ans à concevoir des architectures — du VPS à deux euros au serverless multi-région — j'ai appris une chose : le meilleur choix d'infrastructure, c'est celui qui correspond à votre stade. Pas celui qui impressionne sur un schéma d'architecture.

Le cloud, une doctrine de startup

Aujourd'hui, proposer un déploiement sur un simple serveur en entretien technique, c'est presque suspect. Le cloud est devenu le choix par défaut — parfois avant même d'avoir un premier utilisateur. Les raisons sont compréhensibles : c'est ce qu'on enseigne, c'est ce que les investisseurs comprennent, et les cloud providers font un marketing redoutable. AWS à lui seul propose plus de 200 services. Le problème, c'est que ce réflexe court-circuite la réflexion. On ne se demande plus « de quoi ai-je besoin ? » mais « quel service AWS répond à ça ? ». Et on se retrouve avec des architectures qui résolvent des problèmes qu'on n'a pas encore.

Les vrais avantages du cloud

Soyons honnêtes : le cloud a des atouts indéniables. La scalabilité à la demande est réelle — quand votre trafic passe de 100 à 100 000 requêtes par minute, vous ne voulez pas gérer ça manuellement. Les services managés (bases de données, files de messages, CDN) vous épargnent des semaines de configuration et de maintenance. La haute disponibilité multi-région est quasi impossible à reproduire seul. Et pour certains use cases — du machine learning au big data en passant par le serverless — le cloud est tout simplement sans équivalent. Je ne suis pas anti-cloud. J'ai architecturé des systèmes entiers sur AWS et GCP, et je continue de le faire. Mais je refuse de croire que c'est la seule réponse valable.

Le piège du vendor lock-in et des coûts

Le premier piège est silencieux : le vendor lock-in. Vous utilisez Lambda, DynamoDB, SQS, Cognito, et avant de vous en rendre compte, chaque composant de votre stack est propriétaire. Migrer vers un autre provider ? C'est un chantier de plusieurs mois. Le deuxième piège est financier. Au début, les crédits gratuits et les free tiers masquent la réalité. Mais quand le trafic monte, la facture suit une courbe exponentielle. Il suffit d'ouvrir la grille tarifaire d'un seul service AWS pour comprendre : entre les tiers, les paliers, les coûts par requête, par Go transféré, par million d'invocations — rares sont les personnes capables de vous dire précisément combien vous paierez à la fin du mois. J'ai vu des startups early-stage dépenser 3 000 à 5 000 euros par mois sur AWS pour des workloads qui tourneraient sur un serveur dédié à 50 euros. Le troisième piège est la complexité. Chaque service ajouté est un service à monitorer, à sécuriser, à comprendre. La surface d'attaque augmente, la dette technique aussi, et l'onboarding de nouveaux développeurs devient un parcours du combattant.

L''alternative pragmatique : commencer simple

Pour la majorité des projets early-stage, la réalité est plus simple qu'on ne le pense. Un Docker Compose sur un VPS Hetzner à 20 euros par mois peut faire tourner une API, une base PostgreSQL, un Redis et un worker — avec des performances largement suffisantes pour les premiers milliers d'utilisateurs. C'est boring, et c'est exactement le point. Pas de latence réseau entre services, pas de cold starts, pas de surprises sur la facture. Le déploiement tient dans un script de 20 lignes. Le monitoring, c'est un docker stats et quelques alertes. Quand le projet grandit et que les besoins réels émergent — scaling horizontal, haute disponibilité, services spécialisés — alors on migre. Mais on migre avec une connaissance concrète de ses besoins, pas avec des hypothèses.

Mon approche : le cloud chirurgical

Ma philosophie, c'est le cloud chirurgical : utiliser le cloud pour ce qu'il fait objectivement mieux, et garder le reste simple. Concrètement, ça donne : le stockage objet (S3) pour les fichiers et assets — imbattable en coût et fiabilité. Un CDN (CloudFront, Cloudflare) pour la distribution statique mondiale. Les services managés ciblés — un SES pour l'emailing transactionnel, un CloudWatch pour le monitoring, un service d'authentification quand le besoin est réel. Mais le compute, la base de données, le cache ? Tant que le projet ne justifie pas la complexité cloud, un serveur bien configuré fait le travail. L'idée n'est pas de rejeter le cloud — c'est de choisir service par service au lieu d'y aller en bloc. Et quand un projet atteint l'échelle qui justifie du serverless ou du Kubernetes, je suis le premier à le recommander. Si vous hésitez sur votre stratégie d'infrastructure ou si vous voulez un regard extérieur sur votre architecture cloud, parlons-en.