Pour la grande majorité des startups, un simple VPS Docker à quelques dizaines d'euros par mois suffit largement, et coûte dix fois moins cher qu'un Cloud public type AWS, GCP ou Azure. Ces hyperscalers ne deviennent pertinents que dans des cas précis : besoins GPU pour du machine learning, conformité réglementaire imposée, ou présence multi-région critique. Si vous n'êtes pas dans l'un de ces cas, foncer sur le Cloud public par défaut est probablement le mauvais réflexe. Voici comment trancher selon votre contexte.
Mon expérience terrain me montre que le Cloud public n'est pas toujours la meilleure option. Cet article vous aide à faire un choix éclairé selon votre contexte.
Les options d'hébergement en un coup d'œil
| Option | Coût mensuel | Compétences requises | Pour qui ? |
|---|---|---|---|
| SaaS/No-code (Lovable, Bubble) | Variable | Aucune | Phase POC, validation d'idée |
| PaaS (Heroku, Vercel, Railway) | 50-500€+ | Faibles | Prototypes, side-projects |
| VPS/Bare Metal (OVH, Scaleway) | 5-100€ | Moyennes (Docker) | 90% des startups |
| Cloud public IaaS (AWS, GCP, Azure) | 200-5000€+ | Élevées (SRE) | Cas très spécifiques |
La majorité des startups n'ont pas besoin de la dernière ligne
Le piège des crédits Cloud
AWS, GCP et Azure offrent des dizaines de milliers d'euros de crédits aux startups. Généreux ? Pas tant que ça en vrai. Ils font le pari que vous ne changerez pas d'hébergeur quand vos crédits auront expiré ou auront été consommés. C'est une technique assez classique d'acquisition.
Le problème : plus vous investissez sur une plateforme, plus il devient coûteux d'en sortir. Chez Wizbii, la migration d'OVH vers Google Cloud a pris plusieurs mois. Aujourd'hui, un retour sur OVH leur serait financièrement très judicieux, mais l'investissement sur GCP est tel que personne ne veut l'envisager.
Faire le bon choix au démarrage coûte infiniment moins cher que devoir migrer plus tard. Et un choix simple se révèle quasiment toujours le bon.
Le piège ne se limite pas au coût financier. Les crédits poussent à adopter des services managés propriétaires (files de messages, bases de données spécifiques, fonctions serverless) qui n'existent que chez cet hébergeur. Chaque service propriétaire que vous branchez est un clou de plus qui vous attache à la plateforme. Au début, c'est confortable : tout est intégré, tout fonctionne. Mais vous troquez une dépendance technique contre une dépendance commerciale, et cette dette-là ne se voit pas dans le code. Elle n'apparaît que le jour où vous voulez partir, et il est alors trop tard pour la rembourser facilement. C'est exactement la logique de la dette technique subie : un engagement qu'on prend sans le mesurer et qui se paie plus tard, au pire moment.
"Mais il faut pouvoir scaler !"
C'est l'argument numéro un. Et c'est un faux problème.
Le jour où vous devrez scaler, c'est que vous aurez un super problème : beaucoup de clients. À ce moment-là, vous aurez les moyens d'acheter les compétences nécessaires pour migrer. Uber, Google, Netflix : toutes ces entreprises ont fait des migrations majeures. Et à des niveaux de scale que 99,9% des startups ne connaîtront jamais.
Quelques chiffres concrets :
- Wizbii : 2-3 millions d'utilisateurs avec 3-4 serveurs Bare Metal
- BestOfMedia : 10M+ posts sur des forums sur 3 serveurs loin d'être saturés (il y a plus de 10 ans)
- Kelkoo : des millions de chiffre d'affaires sur une dizaine de serveurs il y a plus de 15 ans
Scaler trop tôt n'a pas de sens business. C'est souvent là pour rassurer un CEO ou un CTO "Architecte" qui pense en avoir besoin, pas pour répondre à un vrai problème.
Le vrai coût du Cloud public
Les Cloud publics vendent de la simplicité et promettent de vous éviter de recruter des experts (SRE, DevOps). La réalité est différente :
Les PaaS (Heroku, Vercel, Railway) sont effectivement simples. Mais excessivement chers dès que vous sortez du hobby project. Une app qui tourne sur un VPS à 20€/mois peut facilement coûter 200€+ sur Vercel.
Les IaaS (AWS, GCP, Azure) ne sont pas simples du tout. Ils nécessitent des compétences pointues pour être utilisés correctement. Sans expertise, vous allez :
- Payer des services dont vous n'avez pas besoin
- Mal configurer vos ressources
- Recevoir des factures surprises
Et l'expertise va se payer soit avec un poste quasi dédié qui vous coûtera 100K€+ chaque année ou un prestataire qui vous facturera tous les mois en plus de vos coûts d'hébergement.
Dans les deux cas, le coût global (financier et en complexité) est bien supérieur à un simple VPS.
Il y a aussi un coût caché qu'on chiffre rarement : la charge mentale. Sur un IaaS, la moindre décision (quel type d'instance, quel réseau virtuel, quelle politique IAM, quel service managé plutôt qu'un conteneur) ouvre un arbre de choix où chaque branche a ses pièges de facturation et de sécurité. Cette surface de décision permanente fatigue une petite équipe et détourne son attention du produit, c'est-à-dire de la seule chose qui crée de la valeur à ce stade. Un VPS, à l'inverse, vous met devant un nombre fini de choix que vous tranchez une fois pour toutes. Ce n'est pas qu'une question de prix sur la facture : c'est le nombre de sujets auxquels votre équipe doit penser chaque semaine. Pour une startup early-stage, réduire ce nombre est presque toujours plus rentable que d'optimiser une ligne de coût d'infrastructure. La sophistication a un prix, et il se paie en attention autant qu'en euros.
En phase de lancement ou de création d'équipe tech & produit, je vous aide à faire des choix d'infrastructure pragmatiques, sans sur-ingénierie ni factures surprises.
Ma recommandation : Docker sur VPS
Pour 90% des startups, voici le setup que je recommande :
Phase POC / Validation
Un SaaS comme Lovable suffit pour montrer vos idées à de premiers prospects. Pas besoin de code, pas besoin d'infra.
Phase Produit
Docker + docker-compose sur un VPS (OVH, Scaleway) :
- Coût : 5 à 50€/mois selon les besoins
- Mise en place : quelques heures, surtout avec l'aide de l'IA
- Maintenance : quelques jours par an maximum
La majorité des développeurs ne touchent jamais au déploiement au quotidien. Ils codent sur leur machine, poussent sur Git, et le CI/CD fait le reste. Ceux qui configurent l'infra n'y passent que quelques jours par an.
Autant leur laisser choisir des technologies qu'ils maîtrisent pour leur travail quotidien : le déploiement n'est pas le sujet.
C'est précisément le choix que j'ai fait chez Winter. Toute la plateforme tourne sur un VPS unique avec Docker et un reverse proxy Traefik, derrière un pipeline GitHub Actions qui construit les images et les déploie en SSH. Le coût d'hébergement se compte en dizaines d'euros, la mise en place a pris une poignée d'heures, et l'équipe ne pense quasiment jamais à l'infrastructure : elle pousse son code, le reste est automatique. À aucun moment ce setup n'a freiné le produit ou limité l'équipe. Le jour où il faudra scaler horizontalement, le passage à plusieurs nœuds ou à du Kubernetes sera un chantier circonscrit, mené avec un vrai problème de charge à résoudre, pas une anticipation théorique payée d'avance pendant des années.
Quand le Cloud public se justifie (vraiment)
Il existe des cas où AWS, GCP ou Azure sont pertinents. Ils sont rares :
- Entraînement de modèles ML : besoin de GPU à la demande, pics de charge très forts
- Conformité spécifique : certaines certifications imposent des hébergeurs précis (encore que les hyperscalers américains posent eux-mêmes des questions de conformité RGPD)
- Présence multi-région critique : si vous devez être présent sur 5 continents avec une latence minimale
Il existe aussi une approche intermédiaire qu'on oublie souvent : utiliser un Cloud public uniquement pour les briques où il excelle vraiment, tout en gardant le cœur de l'application sur un VPS. Stockage objet pour les fichiers, CDN pour les assets statiques, envoi d'emails transactionnels : ces services à l'usage sont peu coûteux et faciles à remplacer. La nuance entre « tout mettre chez un hyperscaler » et « ne rien y mettre » n'est pas binaire. Ce qui compte, c'est de rester maître de l'endroit où vit votre logique métier et vos données : le reste peut être branché et débranché sans douleur.
Si vous n'êtes pas dans ces cas, la question mérite d'être posée : avez-vous vraiment besoin d'un Cloud public ?
Et les investisseurs ? Les clients grands comptes ?
"Mon investisseur veut qu'on soit sur AWS." "Mon client grand compte exige GCP."
Ma réponse : ces situations existent, mais elles sont rares. Et quand elles arrivent, posez-vous la question : est-ce vraiment l'hébergement qui pose problème, ou autre chose ?
Un investisseur sérieux regarde votre traction, votre équipe, votre marché. Un client grand compte vérifie la sécurité, la disponibilité, la conformité. Le logo de votre hébergeur est rarement le vrai sujet.
Cela dit, certains contextes (secteurs réglementés, grands groupes avec des politiques IT strictes) peuvent imposer des contraintes réelles. À évaluer au cas par cas.
En résumé
| Situation | Recommandation |
|---|---|
| POC / Validation d'idée | SaaS no-code (Lovable, Bubble) |
| Startup early-stage | VPS + Docker (OVH, Scaleway) |
| Scale-up avec traction | VPS ou Bare Metal, évaluer au cas par cas |
| Besoins ML/GPU ou conformité spécifique | Cloud public justifié |
Chaque contexte est différent. L'important est de faire un choix éclairé, pas un choix par défaut. Et dans beaucoup de cas, la solution la plus simple est aussi la meilleure : c'est le fil rouge de tout ce que je rassemble dans mon guide pour outiller une entreprise sans sur-ingénierie.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous