Pourquoi nous auto-hébergeons nos SaaS sur des VPS (et ce que ça nous coûte)

Nos produits SaaS tournent sur des serveurs virtuels européens, avec Docker Compose, un reverse proxy Caddy, et pas un seul service cloud managé. En 2026, ce choix détonne assez pour mériter une explication — d'autant qu'il n'est pas une posture : c'est un arbitrage daté, documenté en interne, avec des renoncements que nous listons aussi honnêtement que les bénéfices.

Les trois raisons du choix

La prévisibilité des coûts. Un SaaS en démarrage vit une asymétrie dangereuse : les revenus croissent linéairement (des abonnements), les coûts cloud peuvent croître par surprise (un pic, une fuite de requêtes, un service mal borné). Des serveurs à prix fixe alignent la courbe de coûts sur ce que nous savons prévoir. Nous savons au centime près ce que coûtera l'infrastructure le mois prochain — une sérénité qui vaut, pour nous, plus que l'élasticité.

La souveraineté des données. Nos clients nous confient des contacts, des leads, des données commerciales. Les héberger chez un prestataire européen, sur des machines que nous administrons, simplifie radicalement le volet RGPD (pas de transfert hors UE à documenter) et les réponses aux questions de leurs propres DPO.

La réversibilité. Notre infrastructure, c'est du Docker standard, du PostgreSQL standard, un reverse proxy standard. Changer de fournisseur de VPS est une affaire d'heures, pas de mois. Aucune de nos briques n'existe que chez un fournisseur.

Le vrai sujet : survivre sans autoscaling

L'objection classique est légitime : « et quand la charge monte ? » Notre réponse tient en un principe : la protection de la ressource est dans l'application, pas dans l'infrastructure. Concrètement, trois étages de garde-fous, présents dans chaque produit :

• Des quotas par organisation : chaque client a des limites d'usage liées à son offre, comptées dans Redis. Un client ne peut pas consommer la ressource des autres.
• Du rate limiting aux points d'entrée sensibles (connexion, APIs publiques, formulaires) — des fenêtres fixes, simples à raisonner.
• Des plafonds par conteneur (CPU, mémoire) : si un composant s'emballe, il s'étrangle seul au lieu d'emporter la machine.

Et en amont de tout cela, le cache HTTP absorbe le trafic public. Ce modèle a une conséquence assumée : en cas de pic extrême, nous dégradons (des 503 propres avec Retry-After sur le surplus) plutôt que de payer une élasticité que notre modèle économique n'exige pas. Un SaaS B2B par abonnement n'a pas le profil de trafic d'un site de billetterie — choisir son infrastructure, c'est d'abord connaître son profil de charge.

Ce que ce choix exige (la partie qu'on ne vous vend pas)

L'auto-hébergement n'est pas une économie, c'est un transfert : on échange de la facture contre de la compétence et de la rigueur. Trois exigences non négociables, tirées de notre pratique :

Des sauvegardes restaurées, pas des sauvegardes faites. Chaque produit a ses sauvegardes chiffrées et externalisées — et notre checklist de mise en production impose une restauration réellement testée avant toute ouverture. Une sauvegarde jamais restaurée est une hypothèse, pas une protection. C'est le point sur lequel nous avons vu le plus d'équipes découvrir le problème le jour où il était trop tard.

Une supervision qui précède les incidents. Santé de chaque service, erreurs groupées, alertes par email et webhook — construites comme un produit interne, avec une règle : l'observabilité ne doit jamais devenir elle-même une charge qui fait tomber le reste.

Une checklist de mise en production bloquante. Secrets, TLS, accès restreints, DNS, restauration testée, alerte de bout en bout rejouée : la liste est écrite, et rien ne s'ouvre au public tant qu'elle n'est pas verte. L'auto-hébergement pardonne peu l'à-peu-près.

À qui nous déconseillons ce chemin

À la plupart des équipes, en fait — et ce n'est pas une coquetterie. Si personne chez vous n'a envie d'administrer des serveurs (pas seulement la compétence : l'envie durable), si votre trafic est imprévisible par nature, ou si votre différenciation se joue ailleurs que sur les coûts et la souveraineté, un PaaS ou des services managés achèteront votre focus à bon prix. Nous écrivons un comparatif complet des trois familles d'hébergement dans notre catégorie outils — avec les mêmes critères que nous appliquons à nous-mêmes.

Ce qu'il faut retenir

Nous auto-hébergeons parce que trois conditions sont réunies : la compétence d'exploitation existe dans l'équipe, notre profil de charge est prévisible et cappable applicativement, et la souveraineté des données est un argument commercial dans notre marché. Retirez une des trois conditions, et notre choix deviendrait une erreur. C'est peut-être la seule leçon générale de ce retour d'expérience : les bonnes décisions d'infrastructure ne sont pas des convictions, ce sont des conditions — vérifiez les vôtres avant de copier qui que ce soit.