Déployer en production sur Scalingo : add-ons, scaling et limites d'un PaaS souverain face à Heroku

Depuis la fin du plan gratuit de Heroku fin 2022, et depuis que la souveraineté s'est invitée dans les comités d'achat, beaucoup d'équipes françaises regardent Scalingo d'un œil neuf. La promesse est claire : la même expérience développeur que Heroku (git push, buildpacks, Procfile, add-ons), hébergée et opérée en France, avec une offre adossée à une infrastructure SecNumCloud pour les charges réglementées. Mais un PaaS est un contrat : on échange du contrôle contre de la vitesse. La vraie question est de savoir où s'arrête ce contrat une fois en production.

Cet article détaille un déploiement de production sur Scalingo, le fonctionnement des add-ons et du scaling, puis compare la plateforme à Heroku sur les critères qui pèsent réellement dans la décision.

Le modèle Scalingo en bref

Scalingo est un PaaS français né à Strasbourg. Les applications tournent dans des conteneurs sur une infrastructure européenne, principalement chez 3DS Outscale en région parisienne. Deux régions comptent en pratique :

• osc-fr1 : la région standard, hébergée en France.
• osc-secnum-fr1 : une région construite sur une infrastructure qualifiée SecNumCloud, destinée au secteur public, à la santé et aux charges sensibles. Scalingo est par ailleurs certifié HDS pour l'hébergement de données de santé.

Les briques sont familières à quiconque a utilisé Heroku : une app composée de types de conteneurs déclarés dans un Procfile (web, worker, clock…), des add-ons managés pour les bases de données, et une configuration injectée par variables d'environnement. Le build repose sur des buildpacks largement compatibles avec l'écosystème Heroku, ce qui explique que les migrations soient en général peu douloureuses.

Déployer une application pas à pas

Prenons une API Node.js classique avec une base PostgreSQL et un worker de tâches de fond. CLI scalingo installée et authentifiée :

# Créer l'app dans la région cible
scalingo --region osc-fr1 create acme-api

# Ajouter une base PostgreSQL managée
scalingo --app acme-api addons-add postgresql postgresql-starter-512

# Configuration applicative
scalingo --app acme-api env-set NODE_ENV=production LOG_LEVEL=info

# Déployer
git push scalingo main

La variable DATABASE_URL (ainsi que SCALINGO_POSTGRESQL_URL) est injectée automatiquement. Les processus sont déclarés dans le Procfile :

web: node dist/server.js
worker: node dist/worker.js
postdeploy: node dist/migrate.js

L'entrée postdeploy mérite d'être connue : elle s'exécute une fois après chaque déploiement réussi, avant que les nouveaux conteneurs ne reçoivent du trafic. C'est l'endroit naturel pour les migrations de schéma. En cas d'échec, le déploiement est annulé et l'ancienne version continue de servir le trafic, exactement le comportement souhaité en production.

L'application doit écouter sur le port fourni par la variable PORT et démarrer rapidement : la plateforme attend que le processus ouvre ce port avant de basculer le trafic. Les déploiements sans interruption sont la norme pour les conteneurs web, à condition que l'application gère proprement le signal SIGTERM.

Les add-ons : ce qui est managé, et ce qui ne l'est pas

Le catalogue Scalingo est volontairement resserré sur les briques essentielles, opérées en interne : PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch/OpenSearch, InfluxDB. Les plans couvrent tout le spectre, des instances mutualisées pour la recette jusqu'aux offres haute disponibilité avec réplication et bascule automatique, sauvegardes planifiées et restauration à un instant donné (PITR) sur les plans business.

Ce que vous obtenez :

• Montées de version et maintenance pilotées depuis le dashboard ou la CLI.
• Sauvegardes, restauration, accès aux logs et métriques de la base.
• Restriction d'accès réseau et connexions TLS.
• Des données stockées en France, opérées par une société française.

Ce que vous n'obtenez pas, comparé à Heroku Elements : une marketplace de centaines de services tiers branchés en une commande. Sur Scalingo, le monitoring (Datadog, Sentry), l'envoi d'e-mails, la recherche managée ou le stockage objet se consomment généralement directement chez l'éditeur, configurés par variables d'environnement. Ce n'est pas bloquant, mais cela implique davantage de câblage manuel et surtout une analyse de souveraineté pour chacune de ces dépendances. Héberger son application en France n'a guère de sens si les logs d'erreurs, chargés de données personnelles, partent vers un outil américain.

Pour le stockage de fichiers, le système de fichiers des conteneurs étant éphémère, on s'appuie classiquement sur un stockage objet compatible S3 chez un fournisseur européen (Outscale, OVHcloud, Scaleway).

Le scaling : vertical, horizontal et autoscaling

Le scaling sur Scalingo se joue sur deux axes, par type de conteneur :

• Vertical : la taille du conteneur (S, M, L, XL, 2XL…), qui fixe la mémoire et la part de CPU disponibles.
• Horizontal : le nombre de conteneurs, la répartition de charge entre conteneurs web étant assurée par le routeur de la plateforme.

# 3 conteneurs web de taille M, 2 workers
scalingo --app acme-api scale web:3:M worker:2:M

# Autoscaling des conteneurs web sur le CPU
scalingo --app acme-api autoscalers-add \
  --container-type web --metric cpu --target 0.7 \
  --min-containers 2 --max-containers 8

L'autoscaler peut s'appuyer sur plusieurs métriques (CPU, RAM, temps de réponse, requêtes par minute et par conteneur). Quelques recommandations issues du terrain :

• Gardez au moins deux conteneurs web en production, pour la disponibilité comme pour absorber un redémarrage.
• Préférez le temps de réponse ou le RPM pour les API limitées par les I/O : le CPU reste souvent bas alors que la base sature.
• Scaler l'app ne scale pas la base. Doubler les conteneurs web double les connexions ; dimensionnez votre pool (ou ajoutez un pooler type PgBouncer côté app) avant d'activer l'autoscaling.
• Les workers ne sont pas autoscalés nativement sur la longueur d'une file ; si c'est un besoin, pilotez scale via l'API depuis votre propre job.

Scalingo vs Heroku : le comparatif

Côté expérience développeur, les deux sont très proches : une application qui tourne sur Heroku tourne en général sur Scalingo avec des ajustements mineurs (stack, buildpack, variables d'environnement). La décision est donc rarement technique. Elle se joue sur trois questions : vos données doivent-elles rester sous juridiction européenne ? Avez-vous besoin de HDS ou de SecNumCloud ? Dépendez-vous fortement d'add-ons Heroku sans équivalent direct ?

Les limites d'un PaaS, souverain ou non

Soyons honnêtes : Scalingo partage les limites structurelles de tout PaaS, plus quelques-unes qui lui sont propres.

• Système de fichiers éphémère : tout ce qui est écrit sur disque disparaît au redémarrage. Uploads, fichiers générés et caches doivent aller vers du stockage objet ou Redis.
• Plafond de taille de conteneur : les charges très gourmandes en mémoire (analytique en mémoire, gros modèles de ML) atteignent vite le haut de la gamme. Pas de GPU non plus.
• Contrôle réseau limité : pas de VPC fin, de service mesh personnalisé ou de ports TCP arbitraires comme sur Kubernetes. L'intégration avec des systèmes on-premise demande de l'anticipation (filtrage par IP, options dédiées à discuter avec l'éditeur).
• Modèle de charge : requêtes HTTP très longues, orchestration de workflows complexes ou charges stateful s'y prêtent mal. Déportez le travail lourd vers des workers asynchrones.
• Coût à l'échelle : un PaaS facture le confort. Pour quelques dizaines d'applications, c'est généralement moins cher qu'une équipe plateforme. Au-delà d'une certaine taille de parc, un Kubernetes managé sur un cloud européen peut devenir plus rentable, à condition d'intégrer le coût humain de son exploitation.

Checklist de mise en production

• Au moins deux conteneurs web, gestion de SIGTERM et endpoint de santé.
• Migrations dans postdeploy, rétrocompatibles avec la version précédente du code (expand/contract).
• Base sur un plan business avec réplication et PITR pour tout ce qui est critique ; restauration testée régulièrement.
• Log drain vers votre stack de logs et alertes sur le temps de réponse et les redémarrages de conteneurs.
• Review apps activées via scalingo.json sur les pull requests, avec un jeu de données anonymisé.
• Secrets uniquement en variables d'environnement, avec rotation, jamais dans le dépôt.
• Audit de souveraineté de chaque SaaS tiers consommé par l'application.

Quand choisir Scalingo

Scalingo est un excellent choix pour les équipes produit qui veulent livrer vite sans équipe plateforme dédiée, en particulier quand la souveraineté des données ou la conformité HDS/SecNumCloud est une exigence et non un simple bonus. C'est la trajectoire naturelle de sortie de Heroku pour les organisations européennes. Il devient moins pertinent dès que vos charges réclament un contrôle réseau fin, des GPU, de très grosses instances ou un parc si large qu'une plateforme Kubernetes managée s'autofinance. Dans beaucoup d'organisations, la bonne réponse est mixte : Scalingo pour les applications web et API standard, Kubernetes pour les quelques charges qui le justifient vraiment.