Mets ton API en prod
sans payer à la requête.
D’un MVP à 1 service à un cluster Kubernetes à 50 services — push-to-deploy sur PaaS, 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 d’egress surprise, 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 (~9 ms). Les misses descendent jusqu’à Postgres — ton boulot est de garder le hit ratio Redis > 80 % pour que le p99 reste sous 80 ms.
git push, prod en 90 secondes
Ton CI est ton runbook.
Deux chemins depuis le même repo Git. Chemin PaaS : connecter le repo, push sur main, conteneur build et rollout en ~90 secondes avec gate sur le 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 · same image runs on PaaS-CONTAINER 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 env chiffrées au repos avec clés KMS
- ✓Scope par service ; pas de pool de secrets partagé
- ✓Accès lecture loggés avec user + timestamp
- ✓API de rotation ; ancienne version utilisable 24 h
- ✓Injectés en env vars ou fichiers au start du conteneur
- ✓Export bulk vers .env (admin uniquement)
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 (replicas en quelques secondes) et on documente le difficile pour que ton runbook soit honnête.
Les replicas suivent la demande avec un lag de 60 s — assez vite pour absorber la croissance, assez lent pour ignorer le bruit. Min replicas = 2 (HA), max = 6 (plafond coût).
Débit soutenu par configuration
| config | req/s | p95 | €/mo | lecture |
|---|---|---|---|---|
| PaaS-CONTAINER · 1 replica | 120 rps | 85 ms | €60 | MVP / staging |
| PaaS-BUSINESS · 3 replicas + Redis | 600 rps | 110 ms | €242 | petite prod |
| 2× VPS-BUSINESS + LB-BUSINESS | 1 400 rps | 95 ms | €399 | self-hosted HA |
| PaaS-KUBERNETES · 6 replicas + LB | 4 200 rps | 80 ms | €1 508 | scale |
Estimations de dimensionnement. Le ratio pertinent est req/s par euro : un cluster VPS self-hosted bat le PaaS de 2 à 3×, 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. La vraie réponse, c’est un SLO publié (ex. 99,9 % de dispo mensuelle), un error budget que tu suis vraiment, et une status page qui dit la vérité. On fournit le contrat infra — tu fournis le contrat client, et l’écart entre les deux est ton boulot.
Chaque point est un incident réel qui mange dans le budget de 43 min/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 : PaaS-CONTAINER, push-to-deploy, zéro temps d’ops. Petite prod : PaaS-BUSINESS ou cluster VPS self-hosted — les deux marchent, le second est moins cher. Scale : Kubernetes managé dès que tu as 30+ services. La transition entre tiers est un changement de config, 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 bundles incluent des quotas de bande passante généreux sur chaque tier VPS, sans surprise 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 | capacité | composition | €/mo |
|---|---|---|---|
| MVP · push to deploy | ~1 M req/jour | PAAS-CONTAINER | € 60.48 |
| Production · PaaS | ~10 M req/jour | PAAS-BUSINESS | € 241.93 |
| Self-hosted · cluster VPS | ~30 M req/jour · HA | 2× VPS-BUSINESS · LB-BUSINESS | € 399.18 |
| Scale · Kubernetes managé | ~100 M req/jour · multi-AZ | 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 · push to deploy | €60 | Heroku · 2 dynos · 1 web + 1 worker | $50 | équivalent |
| Petite prod · 3 services · 2 workers | Production · PaaS | €242 | Render · 5 services · tier business | $125 | SaaS gagne |
| Mid prod · API multi-région | Self-hosted · cluster VPS | €399 | Fly.io · 6 machines + DB · 2 régions | $320 | équivalent |
| Scale · 50 services · K8s | Scale · Kubernetes managé | €1 508 | 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). PaaS-CONTAINER / PaaS-BUSINESS pour le push-to-deploy avec scaling managé. PaaS-KUBERNETES quand il faut de l’autoscale pod, plusieurs namespaces, un service mesh mTLS — typiquement au-delà de 20 services.
Comment gérer la CI/CD ?›
Bring your own — GitHub Actions, GitLab CI, CircleCI poussent tous sur le registry VMCloud puis déclenchent un deploy via API ou CLI. On ne te lock pas dans un pipeline propriétaire. Des workflows d’exemple sont publiés dans la doc.
Et les secrets / variables d’env ?›
Chiffrés au repos avec clés KMS, scope par service, audit log à la lecture. Rotation avec fenêtre de grâce 24 h pour qu’un deploy en cours ne casse pas les replicas. CLI permet l’export bulk vers .env (admin uniquement) pour DR.
Multi-région — supporté ?›
Oui. Monter deux clusters dans deux régions UE, GeoDNS devant, réplication Postgres async. Actif-actif pour les services stateless, actif-passif pour le stateful — avec runbooks de failover documentés. La plupart restent en mono-région jusqu’à ce qu’un contrat l’oblige.
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 notre add-on DB managé (à venir). Co-localiser DB et app est un piège dès que les deux grossissent.
RGPD + SOC 2 ?›
Infra opérée sous contrôles alignés SOC 2 et ISO 27001. DPA couvre les obligations RGPD du sous-traitant. Audit logs (deploys, lectures de secrets, actions admin) exportables en JSON pour ta propre collecte d’evidence SOC 2.
Prêt à shipper ?
D’un MVP à 1 service à un cluster Kubernetes à 50 services — même Dockerfile, même API secrets, factures prévisibles, pas de frais à la requête, données en UE.