Cloud managé ou VPS : le calcul que je refais à chaque projet

Le débat « cloud ou serveur dédié » se tient presque toujours au mauvais niveau : celui du prix mensuel affiché. Ce n'est pas là que ça se joue. Le cloud managé achète des choses précises, et la vraie question est de savoir si vous en avez besoin maintenant.

Ce que le cloud managé achète réellement

Quatre choses, et il vaut la peine de les nommer séparément parce qu'on n'en veut presque jamais les quatre à la fois.

• L'élasticité. Absorber une charge multipliée par dix sans intervention. Précieux si votre trafic est réellement irrégulier — inutile s'il est stable, ce qui est le cas de la majorité des applications métier.
• L'exploitation déléguée. Sauvegardes, correctifs, réplication, bascule. C'est de loin le poste le plus sous-estimé : une base de données managée n'achète pas de la puissance, elle achète le fait de ne pas se lever la nuit.
• Les garanties de disponibilité. Un engagement contractuel, opposable. Cela compte si vos propres clients vous en demandent un.
• Les services d'infrastructure prêts à l'emploi. File de messages, stockage objet, distribution de contenu. Réimplémenter ces briques correctement coûte bien plus que de les louer.

Ce que ça coûte, au-delà de la facture

Trois coûts réels qui n'apparaissent pas dans le comparateur de prix.

Le trafic sortant. C'est la ligne qui surprend le plus. L'entrée est gratuite, la sortie est facturée — et une application qui sert des images ou des vidéos sort beaucoup. Sur un profil très chargé en médias, ce poste peut dépasser le calcul lui-même.

La complexité d'exploitation. Rôles, réseau virtuel, règles de pare-feu, infrastructure décrite en code. C'est un métier. Sur une petite équipe, ce temps est pris quelque part — généralement sur le produit.

La dérive silencieuse. Les ressources managées se créent en un clic et s'oublient. Sans étiquetage rigoureux et sans revue de facture, une part significative de la dépense finit par payer des environnements dont plus personne ne se souvient.

Là où le VPS gagne, et pourquoi

Pour un produit en phase de démarrage, à charge stable et à équipe très réduite, une machine unique correctement tenue est presque toujours le meilleur choix — et l'écart de coût est d'un ordre de grandeur, pas de quelques pourcents.

La raison n'est pas seulement financière. C'est la simplicité de diagnostic : un incident se règle avec ssh, docker compose ps et docker logs. Pas de console à quatorze onglets, pas de politique de droits à démêler avant de lire un journal. Sur une équipe d'une personne, ce temps de diagnostic pèse plus lourd que la facture.

Le prix à payer est en revanche parfaitement identifiable, et il faut le regarder en face :

• Les sauvegardes sont à votre charge — et une sauvegarde jamais restaurée n'est pas une sauvegarde. La date du dernier test de restauration se note.
• Il n'y a aucune reprise automatique. La machine tombe, le service tombe.
• La cohabitation de plusieurs applications se gère à la main : plafonds mémoire par conteneur, ports du reverse proxy, disque partagé.

Le seuil de bascule

Trois signaux, et un seul suffit :

1. L'indisponibilité coûte plus qu'un mois de facture managée. À partir de là, payer la redondance est un calcul, plus une préférence.
2. La charge est réellement irrégulière — pointes d'un facteur cinq ou plus. L'élasticité cesse d'être théorique.
3. L'exploitation manuelle mange plus d'une journée par mois. Ce temps a un coût, et il est presque toujours supérieur à l'écart de facture.

La migration progressive, dans le bon ordre

Quand la bascule se justifie, elle ne se fait pas d'un bloc. L'ordre qui limite le risque :

1. Externaliser l'état d'abord — base de données managée, puis stockage objet. C'est là qu'est le risque de perte, et c'est ce qui bénéficie le plus de l'exploitation déléguée.
2. Mettre en place l'observabilité avant de basculer le trafic. Migrer sans mesure, c'est perdre la capacité de dire si la nouvelle plateforme fait mieux ou moins bien.
3. Déplacer le calcul en dernier — c'est la partie sans état, donc la plus facile à faire revenir en arrière.

Et une règle qui vaut pour les deux mondes : décrire l'infrastructure en code dès le premier jour. Sur un VPS, cela signifie un fichier Compose versionné et un SERVER.md tenu à jour. C'est ce qui rend la migration future possible — et c'est ce qui manque le plus souvent quand elle devient nécessaire.