Mets ton API en prod
sans payer à la requête.
D’un MVP à 1 service à un cluster Kubernetes complet — déploiement sur PaaS par un webhook que ta CI appelle, self-host sur VPS derrière un Load Balancer, ou Kubernetes managé avec autoscaling. Factures mensuelles prévisibles, pas de frais à la requête, pas de trafic facturé au Go, données en UE.
Anatomie d’une API moderne
Tu shippes du code, pas des factures surprises.
Tu fais tourner un SaaS, une API interne, un routeur de webhooks, une plateforme de jobs — tout ce qui traite des requêtes et stocke de l’état. Tu veux un stack qui ne pénalise pas le succès avec des frais à la requête, de l’egress opaque et des factures surprise.
Les cache hits s’arrêtent à Redis ; les misses descendent jusqu’à Postgres. Garder un bon taux de hit Redis, c’est ce qui tient la latence p95 — celle que la console mesure par environnement.
Ta CI construit, le webhook déploie
Ton CI est ton runbook.
Deux chemins depuis le même repo Git. Chemin PaaS : ta CI construit l’image, la pousse sur ton registre et appelle le webhook de déploiement ; la plateforme la déploie sur l’environnement qui suit la branche, derrière ton health check. Chemin VPS : docker compose up sur ta machine derrière un Load Balancer — même Dockerfile, plus de contrôle, pas de magie de scaling cachée. Tu choisis l’arbitrage, on supporte les deux.
Même Dockerfile · PaaS ou VPS
# Dockerfile · built by your CI · the same image runs on PaaS and on a VPSFROM node:22-alpine AS buildWORKDIR /appCOPY package*.json ./RUN npm ciCOPY . .RUN npm run buildFROM node:22-alpineWORKDIR /appENV NODE_ENV=productionCOPY --from=build /app/dist ./distCOPY --from=build /app/node_modules ./node_modulesEXPOSE 3000HEALTHCHECK --interval=10s --timeout=2s --retries=3 \CMD wget -q -O- http://127.0.0.1:3000/health || exit 1CMD ["node", "dist/server.js"]
- ✓Variables et secrets par environnement, saisis dans la console
- ✓Secrets en écriture seule : jamais réaffichés une fois enregistrés
- ✓Chaque modification journalisée (clé et auteur, jamais la valeur)
- ✓Colle un bloc .env : import tout-ou-rien
- ✓Exposés au conteneur en variables d’environnement
- ✓Les add-ons managés publient DATABASE_URL / REDIS_URL en secret
Scaler horizontalement sans facture surprise
Un pic ne doit pas te réveiller à 3 h.
Les services API stateless scalent en ajoutant des replicas. Le difficile, c’est aux frontières stateful : pool de connexions DB, saturation de la queue, rate limits downstream. On gère le facile pour toi (les replicas suivent ta cible CPU, dans les limites du plan) et on documente le difficile pour que ton runbook soit honnête.
Les replicas suivent la demande dans les bornes que tu fixes — ici min 2 (redondance) et max 6 (plafond coût), dans les limites du plan.
Dimensionnement par configuration
| config | €/mo | lecture |
|---|---|---|
| PAAS-CONTAINER | … | MVP / staging |
| PAAS-BUSINESS | … | petite prod |
| 2× VPS-BUSINESS + LB-BUSINESS | … | self-hosted HA |
| PAAS-KUBERNETES + LB-ENTERPRISE | … | scale |
Le débit dépend de ton code et de ton ratio de cache : dimensionne à partir de tes propres tests de charge. Le ratio pertinent est req/s par euro — un cluster VPS self-hosted gagne souvent sur le prix, mais tu perds du temps d’ops. Le PaaS gagne quand le temps d’équipe coûte plus cher que l’infra.
Des SLO alignés avec ton contrat
Ton SLA est signé, pas hand-waved.
Les clients B2B demandent un SLA avant de signer. Notre engagement infra, c’est 99 % de disponibilité mensuelle (CGV), mesurée à partir des alertes de supervision et des incidents déclarés. Toute promesse plus stricte à tes propres clients repose sur ton architecture — replicas, health checks, rollback testé — et sur un budget d’erreur que tu suis vraiment. L’écart entre les deux contrats, c’est ton boulot.
Chaque point est un incident qui consomme le budget du mois. Tant que la ligne reste sous le pointillé 50 % à mi-mois, tu peux continuer à livrer. Au-dessus, on freeze les deploys risqués.
Factures prévisibles, pas de surprise à la requête
PaaS pour la vitesse, VPS pour le rapport coût.
MVP : l’offre PaaS d’entrée, une image déployée par webhook depuis ta CI, zéro temps d’ops. Petite prod : PaaS avec auto-scaling ou cluster VPS self-hosted — les deux marchent, le second est moins cher. Scale : Kubernetes managé dès quelques dizaines de services. La même image passe d’une offre à l’autre : monter en gamme n’est pas un re-platform.
TCO = bundle + ops time + egress
La plupart des surprises en hébergement SaaS viennent de l’egress : AWS facture 0,09 $/Go sortant, ce qui produit des factures à 4 chiffres sur une API active. Nos VPS incluent du trafic ; au-delà, usage raisonnable (avertissement puis bridage) — jamais facturé au Go. Le temps d’ops est réel mais borné — même Dockerfile, mêmes env vars, même CI du PaaS au K8s.
| profil | composition | € HT/mois |
|---|---|---|
| MVP · déploiement par webhook | PAAS-CONTAINER | € 60.48 |
| Production · PaaS | PAAS-BUSINESS | € 241.93 |
| Self-hosted · cluster VPS | 2× VPS-BUSINESS · LB-BUSINESS | € 399.18 |
| Scale · Kubernetes managé | PAAS-KUBERNETES · LB-ENTERPRISE | € 1508.05 |
| Heroku · Standard-2X | par dyno | 1 Go RAM | $ 50 |
| Render · Standard | par service | 2 Go RAM | $ 25 |
| Fly.io · shared 4× / 4 GB | par machine | région UE | $ 33 |
| Vercel · Pro | par siège | + frais à l’usage | $ 20 |
| AWS · ECS Fargate (1 vCPU) | par tâche | hors egress | $ 36 |
Prix unitaires pour un service en config "petite prod". La comparaison pertinente se fait sur la facture entière : dyno + DB + redis + addons + egress.
| profil | VMCloud | €/mo | PaaS le plus proche | $/mo | lecture |
|---|---|---|---|---|---|
| MVP · 1 service · 1 worker | MVP · déploiement par webhook | €60,48 | Heroku · 2 dynos · 1 web + 1 worker | $50 | équivalent |
| Petite prod · 3 services · 2 workers | Production · PaaS | €241,93 | Render · 5 services · tier business | $125 | SaaS gagne |
| Prod intermédiaire · API haute disponibilité | Self-hosted · cluster VPS | €399,18 | Fly.io · 6 machines + DB · 2 régions | $320 | équivalent |
| Scale · 50 services · K8s | Scale · Kubernetes managé | €1 508,05 | AWS · ECS / EKS · + egress + ELB | $2 400 | VMCloud gagne |
Lecture : le PaaS a du sens pour un MVP — moins d’ops, coût comparable. L’équation bascule dès plusieurs services ou besoins DB / Redis non triviaux. Les plateformes AWS-class coûtent une fortune dès qu’on additionne egress, ELB, NAT et instances DB.
De vraies questions de vraies équipes
Des leads techniques qui hésitent entre PaaS, VPS et Kubernetes.
Compose, PaaS ou Kubernetes — lequel ?›
Compose sur VPS pour des stacks simples (1 à 5 services, un seul hôte). Le PaaS pour une image que ta CI pousse et que le webhook de déploiement met en service, avec scaling automatique sur les offres qui l’incluent. L’offre PaaS Kubernetes quand il faut un cluster complet — namespaces, Helm, service mesh Istio — typiquement au-delà de 20 services.
Comment gérer la CI/CD ?›
Bring your own — GitHub Actions, GitLab CI, CircleCI : ton pipeline construit l’image, la pousse sur ton registre, puis appelle le webhook de déploiement de l’application (jeton Bearer + corps JSON qui nomme l’image). Pas de pipeline de build propriétaire, pas de lock-in : la console te donne l’étape à ajouter à ta CI.
Et les secrets / variables d’env ?›
Définis par environnement dans la console, ou collés en bloc .env. Les secrets sont en écriture seule : une fois enregistrés, ils ne sont plus jamais réaffichés, et chaque modification est journalisée (clé et auteur, jamais la valeur). Les add-ons managés publient leur URL de connexion en secret.
Multi-région — supporté ?›
Pas en PaaS aujourd’hui : une application est hébergée dans nos centres de données OVHcloud en Europe (Paris, Amsterdam), Frankfurt servant de site de reprise et de sauvegarde, et la commande ne choisit pas de région. Si un contrat impose plusieurs sites, parles-en à notre équipe avant de commander.
Puis-je faire tourner ma propre DB / Redis sur le même VPS ?›
Oui en début de vie. Dès 1 Go de working set ou besoin de point-in-time recovery, les déplacer sur un VPS dédié ou sur un add-on managé du PaaS — PostgreSQL ou Redis selon l’offre. Co-localiser DB et app est un piège dès que les deux grossissent.
RGPD et conformité ?›
Hébergé dans des centres de données OVHcloud certifiés, en Europe. Le DPA couvre les obligations RGPD du sous-traitant. Le journal d’audit (déploiements, changements de configuration et de secrets) est consultable dans ton espace client pour nourrir tes propres preuves de conformité.
Prêt à shipper ?
D’un MVP à 1 service à un cluster Kubernetes complet — même Dockerfile, mêmes variables et secrets, factures prévisibles, pas de frais à la requête, données en UE.