Choisir l'hébergement après un prototype : sans serveur vs conteneurs

Pourquoi l'hébergement devient difficile juste après le prototype

Un prototype semble rapide parce qu'il n'a à fonctionner que pour un petit groupe, pendant peu de temps, dans un environnement contrôlé. Vous testez peut‑être avec des données factices, un seul administrateur et quelques pages. Quand de vrais utilisateurs arrivent, la même appli se comporte différemment : plus de connexions, plus d'uploads, plus de rafraîchissements et davantage de cas limites.

Les décisions d'hébergement se compliquent parce que les prototypes sautent souvent les parties ennuyeuses qui déterminent si une appli survit en production : disponibilité, retries, limites de débit, gestion des secrets et comportement de la base de données sous charge. Quand vous avez finalement besoin de ces basiques, vous devez choisir entre des options qui semblent similaires mais se comportent très différemment.

Signes courants que votre setup a été dépassé :

• Les pages ralentissent quand quelques personnes utilisent l’appli en même temps
• Les tâches en arrière-plan échouent parfois, sans raison claire
• Les connexions à la base de données expirent ou vous obtenez « trop de connexions »
• Les déploiements font peur parce qu’un changement peut tout casser
• Vous trouvez des clés d’API ou des mots de passe en clair

Vous n’avez pas besoin d’une connaissance poussée en DevOps pour faire un bon choix d’hébergement. Il vous faut une méthode claire pour associer les besoins de votre appli au bon type d’hébergement, afin de ne pas reconstruire deux fois.

Quand on parle de « trafic, jobs et base de données », on entend généralement :

• Trafic : les utilisateurs qui chargent des pages et appellent des API. La question clé est l’usage : stable (prévisible) ou par pics (calme la majeure partie de la journée, puis très chargé).
• Jobs : le travail en arrière-plan, comme l’envoi d’emails, la génération de rapports, le traitement d’uploads ou la synchronisation de données. La question clé est : doit‑on garantir l’exécution même quand personne n’utilise activement l’appli ?
• Base de données : où votre appli stocke les données et l’état. La question clé est : a‑t‑elle besoin de connexions de longue durée, de migrations, de sauvegardes et d’une performance cohérente ?

Ce billet compare le sans serveur, les conteneurs et les plateformes gérées avec des tables de décision simples.

Ce qu’il faut noter avant de comparer les options

Avant de choisir sans serveur, conteneurs ou une plateforme gérée, écrivez ce que votre appli fait réellement au quotidien. Cela évite de choisir sur des impressions et de devoir tout reprendre ensuite.

Commencez par une carte simple de vos pages et flux. Listez les écrans principaux (page marketing, tableau de bord, paramètres, admin, paiement) et marquez ceux qui doivent être rapides à chaque fois. « Rapide à chaque fois » signifie en général la connexion, le premier écran après la connexion et tout ce qui touche à l’argent.

Ensuite, estimez le trafic de façon peu coûteuse. Pas besoin de chiffres exacts. Utilisez une étiquette comme faible, moyen, par pics ou inconnu. Par pics peut vouloir dire « on a 10 utilisateurs la plupart des jours, mais 5 000 le jour du lancement » ou « un partenaire webhook peut envoyer une rafale ». Si le trafic est inconnu, notez‑le aussi, car cela change ce que vous allez optimiser.

Séparez ensuite le travail en arrière-plan du chargement des pages. Beaucoup d’applis tiennent la route en démo mais échouent en production parce que les tâches en arrière-plan n’ont nulle part sûr où tourner. Exemples courants :

• Envoi d’emails ou SMS (inscription, reçus, réinitialisation de mot de passe)
• Import/Export (uploads CSV, sync de données)
• Tâches IA longues (générer des rapports, résumer des documents, traitement par lot)
• Travail média (redimensionnement d’images, traitement vidéo)
• Webhooks (logique de retry quand un autre service échoue)

Capturez ensuite vos besoins en données en mots simples. Pas besoin de choisir un fournisseur maintenant. Décrivez juste quel type d’état vous avez et ce qui arrive s’il est perdu :

• Données SQL (utilisateurs, paiements, permissions)
• Fichiers (uploads, factures, avatars)
• Recherche (full‑text, filtres, pertinence)
• Cache (accélérer les pages chaudes, limites de débit)

Enfin, notez les contraintes qui comptent plus que les détails techniques : délai de mise en production, budget et qui va maintenir le système. Si vous êtes fondateur solo sans équipe on‑call, dites‑le. Si vous avez besoin de quelque chose en 48 heures, dites‑le aussi.

Un exemple rapide : si vous avez un prototype avec un tableau de bord rapide, un trafic par pics au lancement, un job d’import quotidien et une base SQL, vous avez déjà assez d’éléments pour comparer les options sans deviner.

Sans serveur, conteneurs et plateformes gérées en termes simples

Choisir un hébergement après un prototype, c’est surtout décider combien du travail « faire tourner l’appli » vous voulez prendre en charge.

Sans serveur : le code s’exécute seulement quand il est nécessaire

Le sans serveur signifie que votre code se réveille à la demande et se rendort quand il n’y a rien à faire. Vous ne gérez pas un serveur en continu. Vous envoyez de petits morceaux de code (fonctions) ou un service web serverless, et la plateforme gère la mise à l’échelle.

Les compromis sont réels : les requêtes peuvent démarrer plus lentement après une période d’inactivité, et il faut souvent concevoir autour de limites (timeouts, exécution sans état, et patterns spécifiques pour les connexions DB). Le sans serveur est excellent pour le trafic par pics ou les API simples.

Conteneurs : vous contrôlez plus, et vous portez plus

Un conteneur est votre appli empaquetée avec son runtime, elle tourne de la même façon partout. Vous choisissez comment elle démarre, ce qui tourne à côté et comment elle utilise CPU et mémoire.

L’avantage est le contrôle : workers en arrière‑plan, runtimes prévisibles et moins de « règles de plateforme ». L’inconvénient est l’opérationnel : maintenir les services en bonne santé, définir les règles d’autoscaling, gérer les logs, les secrets, les patchs et la réponse aux incidents.

Plateformes gérées : le compromis

Les plateformes gérées se situent entre les deux. Vous déployez une appli et la plateforme l’exécute pour vous sur leur infra. « Managé » inclut souvent les étapes de build, HTTPS, autoscaling et des health checks basiques.

Ce qui reste de votre ressort : les bugs applicatifs, le design de la base de données, le comportement des jobs et éviter de commiter des secrets dans le repo.

Un modèle mental simple de tarification :

• Sans serveur : facturation à la requête et au temps de calcul. Peu coûteux à faible trafic ou trafic en rafales, mais la facture peut grimper sur une charge lourde et constante.
• Conteneurs : facturation pour une capacité réservée (machines qui tournent même au repos). Plus prévisible si la charge est stable.
• Plateformes gérées : en général un coût mensuel de base plus des options (DB, logs, bande passante). Souvent le plus simple à budgéter au début.

Les déploiements et rollbacks sont aussi différents :

• Sans serveur : déploiements rapides, mais plus d’éléments si vous avez beaucoup de fonctions. Les rollbacks sont généralement simples, mais le debug distribué entre fonctions est plus difficile.
• Conteneurs : releases versionnées propres et rollbacks rapides, mais vous devez mettre en place le processus.
• Plateformes gérées : « push to deploy » simple. Les rollbacks sont souvent en un clic, mais la personnalisation peut être limitée.

Si votre prototype est une petite API avec du trafic occasionnel et quelques tâches planifiées, le sans serveur peut être un bon départ à faible effort. Si vous avez déjà besoin d’une queue de workers, de jobs longue durée ou d’un contrôle strict du runtime, les conteneurs (ou une plateforme gérée qui supporte des workers) sont souvent plus sereins.

Table de décision partie 1 : schémas de trafic

Le trafic est la première chose à trier car il affecte le coût, la fiabilité et la quantité de travail pour garder le système stable.

Les cold starts importent si les utilisateurs les ressentent. Si votre appli gère des paiements, la connexion ou tout ce qui doit être instantané, une pause de 1–3 secondes peut nuire. Pour un outil admin interne, les cold starts importent moins.

Les besoins en temps réel changent souvent la réponse. Si vous avez besoin de WebSockets, de streaming long ou de collaboration en direct, les services long‑cours sont généralement plus simples. Les conteneurs ou les plateformes gérées sont souvent les moins pénibles. Certaines architectures serverless supportent le temps réel, mais elles ajoutent des pièces en plus et plus de façons de casser.

Les attentes sur l'autoscaling sont souvent trop optimistes. « Le sans serveur signifie échelle infinie » n'est pas la réalité pratique. Vous atteindrez des limites : plafonds de requêtes concurrentes, limites de connexions DB, et limites d'API tierces. Les conteneurs autoscalent aussi, mais réagissent plus lentement si vous ne gardez pas une capacité chaude.

Règle générale :

• Trafic stable : conteneurs ou plateforme gérée, restez simple.
• Trafic par pics : le sans serveur fonctionne bien pour les requêtes web en rafales, mais planifiez les cold starts et limites.
• Trafic inconnu : commencez simple, instrumentez tôt, et ajustez après avoir vu l’usage réel.

Table de décision partie 2 : jobs en arrière‑plan et queues

Les jobs en arrière‑plan sont tout ce que votre appli doit faire hors des requêtes principales : envoyer des emails, redimensionner des images, synchroniser des données, facturer cartes ou appeler un modèle IA. Pour beaucoup de prototypes, c’est le facteur décisif, car les jobs révèlent ce qui casse quand les vrais utilisateurs arrivent.

La plupart des problèmes de jobs tiennent moins au « lieu d’exécution » qu’aux basiques : timeouts, retries, idempotence (pour éviter les duplications) et concurrence sûre.

Le sans serveur est excellent pour les jobs quand chaque tâche est courte et indépendante. Vous avez l’autoscaling automatique et ne payez que quand le travail tourne. Ça devient pénible quand les tâches atteignent régulièrement des limites de temps, demandent du CPU constant longtemps ou nécessitent de lourdes dépendances qui ralentissent les cold starts.

Les conteneurs sont souvent plus simples pour les jobs longue durée et les workers dédiés. Un conteneur worker peut consommer une queue, rester chaud et gérer de gros besoins en mémoire/CPU sans se heurter aux limites des fonctions. Le compromis est de gérer le scaling, les redémarrages et s’assurer qu’un seul worker traite un job à la fois.

Les plateformes gérées aident quand elles emballent les parties ennuyeuses : queues hébergées, planification, autoscaling des workers, dashboards d’erreurs et dead‑letter handling.

Exemple concret : un SaaS qui génère des factures PDF peut le faire en serverless si chaque génération est rapide. Si les clients commencent à uploader des factures volumineuses et que la génération prend des minutes, un worker en conteneur tirant d’une queue est généralement plus simple à exploiter et à déboguer.

Table de décision partie 3 : base de données et services stateful

Commencez par la partie la plus « collante » de votre appli : la base de données et tout ce qui garde l’état. Vous pouvez changer l’hébergement web plus tard. Déplacer des données et de l’état est là où les équipes perdent des semaines.

Si votre prototype utilise Postgres ou MySQL, gardez‑le. Un Postgres/MySQL managé est habituellement le choix le plus sûr car les upgrades, les problèmes de disque et les sauvegardes sont les causes les plus fréquentes d’échec en self‑host. Si vous utilisez SQLite, considérez‑le comme un signal d’alerte. OK pour une démo, mais ça casse vite dès que vous ajoutez des utilisateurs concurrents, plusieurs instances ou des jobs en arrière‑plan.

DB managée vs DB auto‑hébergée : ce qui casse

Auto‑héberger une base dans un conteneur peut marcher, mais les modes de panne sont ennuyeux et coûteux : disque plein, sauvegardes inexistantes, une mise à jour mineure casse une extension, ou un redémarrage corrompt des données à cause de volumes mal configurés. Une base managée réduit ces risques, surtout quand vous changez souvent le schéma.

Au‑delà de la DB, listez vos autres besoins stateful :

• Les uploads nécessitent généralement du stockage d’objets (pas le disque local de l’appli).
• La recherche rapide à grande échelle demande souvent un service de recherche séparé.
• Le cache requiert souvent un Redis managé si vous comptez sur des sessions, des limites de débit ou des requêtes chères.

Les limites de connexion importent plus qu’on ne le croit. Chaque connexion ouverte coûte de la mémoire côté base. Les apps serverless peuvent créer beaucoup de connexions courtes et déclencher des erreurs « too many connections ». La solution habituelle est le pooling : votre appli parle à un pool, et le pool réutilise un nombre plus petit de connexions vers la base.

Comment choisir : une démarche étape par étape

Comparer chaque feature sur chaque plateforme, c’est s’arrêter. Mieux : partez de la chose la plus susceptible de casser, puis choisissez l’option la plus simple qui l’empêche.

Étape 1 : Choisissez votre goulot actuel

Soyez honnête sur ce qui fait mal aujourd’hui, pas sur ce qui pourrait compter dans un an :

• Trafic : les pages sont lentes, des timeouts se produisent ou vous êtes limité par un tiers.
• Jobs en arrière‑plan : emails, imports, appels IA ou tâches planifiées échouent ou s’exécutent en double.
• Base de données/état : données incohérentes, migrations effrayantes ou fichiers/sessions stockés au mauvais endroit.

Une fois que vous avez choisi un goulot, ignorez la plupart du reste.

Étape 2 : Choisissez l’hébergement le plus simple qui élimine ce goulot

Visez le moins d’éléments mobiles possible qui répondent à votre besoin.

Si le trafic pose problème, le sans serveur ou une plateforme gérée suffit souvent car ils scale sans que vous tuniez des serveurs. Si les requêtes sont longues ou que vous avez besoin de WebSockets, les conteneurs peuvent être plus simples que de lutter contre des limites.

Si ce sont les jobs, priorisez une vraie queue et un worker qui sait retryer proprement. Ça peut rester serverless si vous contrôlez les timeouts et les retries. Sinon, un petit worker conteneur est plus simple à raisonner.

Si la DB est le souci, obtenez d’abord une DB managée stable. Le choix de l’hébergement applicatif compte moins que d’avoir des sauvegardes, des migrations et des limites de connexions claires.

Étape 3 : Faites un petit test de charge et un test de panne

Restez petit. Vous cherchez des points de rupture évidents.

Test de charge : simulez un pic modéré (par ex. 5–10x votre trafic normal pendant 10 minutes) et surveillez erreurs et temps de réponse.

Test de panne : faites planter volontairement quelque chose et confirmez la récupération. Le test le plus simple est un redémarrage. Pour les jobs, faites échouer un job volontairement, vérifiez qu’il retrye et qu’il ne crée pas de doublons.

Étape 4 : Définissez un flux de déploiement basique

Il vous faut un chemin minimal sûr du code à la prod :

• Staging et production (même si le staging est minuscule)
• Un processus de déploiement qui n’est pas basé sur des clics manuels
• Un plan de rollback (idéalement une commande ou un réglage)

Si vous ne pouvez pas expliquer votre rollback en une phrase, votre hébergement n’est pas assez "simple".

Étape 5 : Planifiez ce que vous allez surveiller

Choisissez quelques signaux que vous vérifierez vraiment chaque semaine : taux d’erreur, latence et échecs de jobs suffisent souvent. Ajoutez un indicateur DB (requêtes lentes ou nombre de connexions) si l’app est DB‑intensive.

Pièges courants qui causent des reprises coûteuses

Le moyen le plus rapide de perdre un mois est de choisir l’hébergement sur l’apparence « pro » plutôt que sur ce que fait vraiment votre appli. Le bon choix est souvent celui que votre équipe peut faire tourner calmement chaque semaine, pas celui avec le diagramme le plus cool.

Un piège : choisir les conteneurs parce que ça semble professionnel, puis réaliser que personne ne veut gérer l’ops. Les conteneurs sont bien, mais ils impliquent souvent de gérer mises à jour, monitoring, règles de scaling et incidents. Si votre équipe est petite, ce travail arrive au pire moment.

Le piège inverse pour le serverless : débuter facilement, puis se faire mordre quand le travail est trop long. Si vous avez du traitement vidéo, d’imports lourds, des appels IA en chaîne ou de la génération de rapports qui prennent des minutes, vous pouvez atteindre des limites de temps ou voir les coûts exploser. Les équipes ajoutent alors des queues et des workers, et finissent par repenser l’architecture sous pression.

Déclencheurs de reprise à surveiller :

• Considérer les secrets comme secondaire (clés dans le code, .env partagés, pas de rotation)
• Livrer des changements de schéma et du code en une seule étape, sans rollback sûr
• Choisir une plateforme qui rend les flows d’auth compliqués (callbacks, stockage de session, domaines personnalisés)
• Ne pas planifier tôt le stockage des uploads (où les fichiers vivent, comment fonctionnent les permissions)
• Supposer que le temps réel fonctionnera « tout seul » (WebSockets, connexions longues, consommateurs en arrière‑plan)

Exemple concret : un prototype peut utiliser une librairie de login simple, stocker les fichiers sur le disque local et exécuter un job nocturne dans le serveur web. Ça tient en démo, mais en production ça casse dès que vous avez plusieurs instances ou que vous déployez une nouvelle version.

Exemple : passer un prototype généré par IA en production

Un fondateur lance un prototype IA construit avec un outil comme Replit ou Cursor. Ça marche sur un laptop. Après le lancement, ça commence à échouer en production : déconnexions aléatoires, emails envoyés deux fois et la DB qui time‑out pendant les pics.

Ceci arrive parce que les prototypes mêlent souvent tout : requêtes web, travail en arrière‑plan (imports, emails) et accès DB dans le même processus. Quand le trafic augmente, tout se dispute les mêmes ressources.

Parcours dans la table de décision

Trafic : le lancement crée un trafic par pics. Cela oriente vers une couche front/API qui scale vite. Les fonctions serverless conviennent bien pour la couche web/API si les requêtes sont courtes et sans état. Si les requêtes sont longues ou si vous avez besoin d’un contrôle fin du runtime, un petit service conteneur est plus sûr.

Jobs : l’envoi d’emails et les imports CSV ne doivent pas se produire dans la requête web. Les pics ralentissent les serveurs web et les retries créent des doublons. Les jobs ont besoin d’une queue et d’un worker pouvant tourner plus longtemps qu’un timeout de requête typique.

Base de données et auth : les timeouts viennent souvent d’un nombre excessif de connexions et de requêtes lentes. Les problèmes d’auth sous charge résultent souvent de cookies mal configurés, d’un stockage de session manquant ou de timeouts quand la DB est sollicitée.

Combo d’hébergement réaliste pour ce cas :

• Sans serveur ou service web managé pour l’API (scaling rapide pour trafic par pics)
• Une queue managée + un worker (conteneur ou runner managé) pour emails/imports
• Une base de données managée avec pooling (et monitoring de base)
• Un stockage de secrets managé pour éviter d’avoir des clés codées en clair

Il ne s’agit pas du stack le plus fancy, mais de séparer les responsabilités pour qu’un problème (imports) n’emmène pas tout le système.

Plan simple pour la première semaine : stabiliser, puis optimiser

La première semaine doit viser la fiabilité avant l’optimisation des coûts :

• Jour 1 : ajouter logs de requêtes, suivi d’erreurs et health checks pour rendre les échecs visibles.
• Jour 2 : déplacer emails et imports dans une queue + worker, ajouter de l’idempotence (pas de double envoi).
• Jour 3 : corriger les timeouts DB avec du pooling, des index pour les requêtes lentes et des timeouts sensés.
• Jour 4 : stabiliser l’auth (sessions, cookies, redirections) et ajouter des limites de débit basiques.
• Jour 5 : load tester les flux principaux et définir des limites de scaling pour éviter une facture surprise.

Checklist rapide et prochaines étapes

Pour choisir l’hébergement après un prototype sans vous perdre dans des comparaisons sans fin, gardez la décision petite et pratique. Vous ne choisissez pas la plateforme « pour toujours ». Vous choisissez l’étape la plus sûre pour des utilisateurs réels.

Commencez par ces vérifs :

• Forme du trafic : surtout stable ou avec des pics ? Notez si les utilisateurs sont majoritairement dans une région.
• Durée des jobs : les tâches sont‑elles rapides (secondes) ou longues (minutes) ? Besoin de retries, de planification ou de livraison garantie ?
• Croissance DB : à quelle vitesse les données vont‑elles croître et avez‑vous besoin de migrations ou de backups stricts bientôt ?
• État et fichiers : stockez‑vous des uploads, sessions ou fichiers générés qui doivent survivre aux redémarrages ?
• Propriété par l’équipe : qui est de garde en cas de panne, et qui est à l’aise avec le déploiement et le debug ?

Avant d’ouvrir au public, mettez en place les « basiques production minimum » :

• Backups testés : pas seulement activés, mais restaurés au moins une fois.
• Logs consultables : requêtes, jobs et erreurs DB au même endroit.
• Alertes d’erreur : prévenir un humain rapidement, avec suffisamment de contexte pour agir.
• Rollbacks : un moyen de revenir sur un mauvais déploiement sans super‑héros.

Gardez volontairement une chose simple. Pour beaucoup d’équipes, c’est utiliser une base de données managée et éviter les opérations DB personnalisées tôt, même si le choix du runtime évolue ensuite. Notez aussi ce que vous décidez de reporter (multi‑région, autoscaling parfait, queues complexes) pour que ça ne devienne pas une surprise plus tard.

Prochaines étapes utiles pour la plupart des équipes :

• Documenter vos choix sur une page : runtime, jobs/queue, base de données, stockage et qui gère quoi.
• Faire un petit essai en production : une release limitée avec vraie surveillance, puis corriger les problèmes majeurs.
• Load tester un flux clé : inscription, paiement ou votre endpoint principal, pour détecter les limites évidentes.
• Pratiquer une panne : redémarrer l’appli, casser une valeur de config ou simuler un backlog de queue et observer le comportement.
• Fixer une date de revue : deux semaines après le lancement, décider si vous restez ou si vous améliorez un élément.

Si vous héritez d’un code généré par IA déjà fragile, il vaut la peine de corriger les fondamentaux (auth, secrets, retries, accès DB) avant de changer l’hébergement. FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation des prototypes générés par IA pour les rendre prêts pour la production : durcissement sécurité et préparation au déploiement. Ils offrent un audit de code gratuit pour mettre en lumière les problèmes qui font échouer les migrations d’hébergement.