Serverless vs conteneurs : quelle architecture convient à votre SaaS ?

Le sans serveur et les conteneurs résolvent différents problèmes. Choisir le mauvais vous coûte des mois de retouche. Un produit SaaS qui démarre sur Kubernetes lorsqu'il compte 50 utilisateurs dépense 2 000 $/mois sur une infrastructure dont il n'a pas besoin. Un produit qui démarre sans serveur et atteint 100 000 requêtes/seconde découvre que les démarrages à froid détruisent sa latence P99. Les deux erreurs coûtent cher à inverser.

Ce guide compare les solutions sans serveur par rapport aux conteneurs avec des chiffres de coûts réels, des compromis spécifiques et un cadre de décision que vous pouvez appliquer à votre architecture cloud aujourd'hui.

Ce que signifie le sans serveur en pratique

L'architecture sans serveur signifie que vous écrivez des fonctions, les déployez et laissez le fournisseur de cloud gérer les serveurs, la mise à l'échelle et la disponibilité. Vous ne provisionnez pas d'instances. Vous ne corrigez pas les systèmes d'exploitation. Vous ne configurez pas les équilibreurs de charge.

Les trois plateformes sans serveur dominantes en 2026 sontAWS Lambda,Fonctions Vercel, etTravailleurs Cloudflare. Chacun fonctionne différemment sous le capot :

• AWS Lambdaexécute votre code dans des conteneurs isolés qui tournent à la demande. Vous payez par invocation (0,20 $ par million de requêtes) plus le temps d'exécution (0,0000166667 $ par Go-seconde). Les démarrages à froid vont de 100 ms à 3 secondes en fonction de la durée d'exécution et de la taille du package.
• Fonctions Vercelenveloppe AWS Lambda avec une meilleure expérience de développeur. Les déploiements ont lieu sur git push. Vous obtenez des URL d’aperçu pour chaque branche. Le niveau gratuit couvre 100 000 appels de fonctions/mois.
• Travailleurs Cloudflarefonctionne sur des isolats V8 en périphérie, pas sur des conteneurs. Les démarrages à froid sont inférieurs à 5 ms. Vous payez 0,50 $ par million de requêtes après le niveau gratuit de 100 000 requêtes/jour.

Le modèle de tarification est le même dans les trois : vous payez pour ce que vous utilisez. Zéro trafic signifie zéro coût. Cela rend les produits SaaS sans serveur attrayants au lancement, lorsque le trafic est imprévisible et que chaque dollar compte.

Ce que signifient les conteneurs dans la pratique

Les conteneurs Docker regroupent le code de votre application, votre environnement d'exécution et vos dépendances dans une seule image qui s'exécute de la même manière sur n'importe quelle machine. Vous créez l'image une fois, la transférez dans un registre et la déployez où vous le souhaitez.

L'orchestration des conteneurs est la couche qui gère ces images en production.Kubernetesest la plateforme d'orchestration dominante, mais ce n'est pas la seule option :

• Docker + serveur uniquefonctionne pour les produits en phase de démarrage. Exécutez vos conteneurs sur un VPS à 20 $/mois avec Docker Compose. Aucune surcharge d’orchestration. Vous gérez les redémarrages et les déploiements manuellement ou avec un simple script.
• AWS ECS/Google Cloud Runvous offre une orchestration de conteneurs gérée sans toute la complexité de Kubernetes. Vous définissez vos conteneurs, définissez des règles de mise à l'échelle et la plateforme s'occupe du reste. Cloud Run facture par requête comme sans serveur, mais exécute des conteneurs complets.
• Kubernetes (EKS, GKE, auto-hébergé)vous donne un contrôle total sur la planification, la mise en réseau et l'allocation des ressources. Cela nécessite un ingénieur DevOps dédié ou une équipe familiarisée avec les manifestes YAML, les graphiques Helm et les contrôleurs d'entrée.
• Fly.io / Chemin de ferpropose un juste milieu : déployez des conteneurs Docker avec une simple CLI, bénéficiez d'une mise à l'échelle automatique et payez en fonction de l'utilisation des ressources. Aucune connaissance Kubernetes requise.

Le modèle de coût des conteneurs est différent de celui du sans serveur. Vous payez pour le temps de calcul, que les demandes arrivent ou non. Un conteneur fonctionnant 24h/24 et 7j/7 sur ECS coûte entre 30 $ et 150 $/mois en fonction de l'allocation du processeur et de la mémoire. Mais le coût reste prévisible à mesure que le trafic augmente, tandis que les factures sans serveur peuvent augmenter en cas de pics soudains de trafic.

Sans serveur vs conteneurs : la comparaison

Quand le sans serveur gagne

L'architecture sans serveur est le bon choix lorsque vos charges de travail sont pilotées par des événements, que votre trafic est imprévisible et que votre équipe ne souhaite aucune gestion de l'infrastructure.

Charges de travail basées sur les événements.Un point de terminaison webhook qui traite les événements de paiement Stripe. Un redimensionneur d'image qui se déclenche lorsque les utilisateurs téléchargent des fichiers. Un service de notification qui se déclenche lors des modifications de la base de données. Ces charges de travail s'exécutent pendant quelques millisecondes, se produisent de manière imprévisible et restent inactives la plupart du temps. Payer un conteneur pour attendre ces événements est un gaspillage d’argent.

API à trafic variable.Un produit SaaS qui reçoit 100 requêtes/heure pendant la nuit et 10 000 requêtes/heure pendant les heures de bureau bénéficie d'une mise à l'échelle automatique sans serveur. Vous ne payez pas pour les heures calmes et vous ne vous démenez pas pour évoluer pendant les heures chargées.

Des startups qui veulent zéro opération.Si votre équipe est composée de deux fondateurs et d'un concepteur, passer du temps sur les configurations Docker et les manifestes Kubernetes enlève du temps à la création de fonctionnalités. AWS Lambda et Vercel vous permettent de déployer avec un git push et de vous concentrer sur votre produit.

Quand les conteneurs gagnent

Les conteneurs Docker sont le bon choix lorsque vos charges de travail s'exécutent sur des périodes prolongées, que votre trafic est prévisible ou que votre architecture nécessite un contrôle précis des ressources.

Processus de longue durée.Un service de transcodage vidéo qui traite les fichiers pendant 10 à 30 minutes par tâche. Un serveur d'inférence d'apprentissage automatique qui charge un modèle de 2 Go en mémoire. Un serveur WebSocket qui détient des connexions persistantes. Les fonctions sans serveur expirent après 15 minutes sur Lambda (moins sur les autres plateformes). Les conteneurs fonctionnent aussi longtemps que vous en avez besoin.

Des modèles de trafic prévisibles.Un produit SaaS B2B avec 500 utilisateurs d'entreprise génère un trafic constant pendant les heures de bureau. Les coûts des conteneurs restent stables entre 100 $ et 300 $/mois. Le même trafic sur Lambda peut coûter entre 400 et 800 $/mois, car vous payez à la demande plutôt qu'à l'heure.

Microservices complexes.Lorsque vous disposez de plus de 10 services devant communiquer sur des réseaux internes, partager des bases de données et maintenir des connexions persistantes, l'orchestration de conteneurs vous offre une découverte de services, des vérifications de l'état et des politiques réseau que les plates-formes sans serveur n'offrent pas.

Charges de travail GPU.La formation de modèles ML, l'inférence en temps réel et le traitement d'images/vidéo nécessitent un accès GPU. AWS Lambda ne prend pas en charge les GPU. Les conteneurs sur les instances compatibles GPU (ECS, GKE ou bare metal) vous offrent un accès direct au matériel.

L’approche hybride : utiliser les deux

La meilleure architecture cloud pour la plupart des produits SaaS en 2026 n'est pas purement sans serveur ou purement conteneurisée. C'est un hybride.

Sans serveur pour votre couche API.Votre API REST ou GraphQL gère un trafic variable, exécute des cycles requête/réponse de courte durée et bénéficie d'une mise à l'échelle automatique. Déployez-le sur Vercel, Lambda ou Cloudflare Workers. Coût au lancement : 0 $.

Conteneurs pour les tâches et les travailleurs en arrière-plan.Votre processeur de file d'attente de courrier électronique, votre générateur de rapports, votre pipeline de données et vos tâches cron s'exécutent en tant que conteneurs Docker sur ECS, Fly.io ou un simple VPS. Ces charges de travail s'exécutent en continu, traitent les données en masse et ne nécessitent pas de mise à l'échelle par requête. Coût : 20 $ à 100 $/mois pour un seul conteneur de travail.

Ce modèle hybride maintient votre facture d'infrastructure à moins de 50 $/mois au lancement tout en vous offrant la flexibilité de faire évoluer les composants individuels de manière indépendante. Votre API s'adapte à 10 000 utilisateurs simultanés sans aucune modification de configuration. Vos travailleurs en arrière-plan évoluent en ajoutant davantage de réplicas de conteneur lorsque la profondeur de la file d'attente augmente.

Comparaison des coûts à différentes échelles

Les chiffres réels comptent plus que les modèles de tarification théoriques. Voici ce que coûte le sans serveur par rapport aux conteneurs à trois étapes de croissance pour un produit SaaS typique avec une API, une base de données et un traitement des tâches en arrière-plan.

0-1 000 utilisateurs : la phase de lancement

Sans serveur :0 $ à 20 $/mois. Le niveau gratuit de Vercel couvre votre API. Une base de données Postgres gérée sur Neon ou Supabase coûte entre 0 et 25 $/mois. Infrastructure totale : moins de 25$/mois.

Conteneurs :50$-150$/mois. Une petite tâche ECS ou une instance Fly.io exécute votre API (20 $ à 50 $/mois). Une base de données gérée ajoute 25 à 50 $/mois. Un travailleur de fond ajoute 20 à 50 $ supplémentaires/mois.

Gagnant : sans serveur.À ce stade, vous dépensez de l’argent pour le développement de produits, et non pour leur mise à l’échelle. Chaque dollar économisé sur l’infrastructure est consacré à la création de fonctionnalités.

1 000-10 000 utilisateurs : phase de croissance

Sans serveur :100$ à 500$/mois. Les invocations Lambda évoluent de manière linéaire. Les coûts de base de données augmentent entre 50 et 200 $/mois. Vous commencez à payer pour Vercel Pro (20 $/mois) pour obtenir des limites plus élevées.

Conteneurs :150$ à 400$/mois. Votre conteneur API s'adapte à 2 à 3 répliques (60 $ à 150 $/mois). Les coûts de la base de données sont les mêmes. Les travailleurs en arrière-plan pourraient avoir besoin d'une deuxième instance (40 $ à 100 $/mois).

Gagnant : dépend du modèle de trafic.Si votre trafic est intense (application grand public), le sans serveur gagne toujours. Si votre trafic est stable (B2B SaaS), les conteneurs avancent car vous cessez de payer la prime par demande.

10 000-100 000 utilisateurs : phase de mise à l'échelle

Sans serveur :500 $ à 5 000 $/mois. Les coûts Lambda augmentent rapidement lorsque les volumes de demandes sont élevés. La tarification Vercel Enterprise entre en jeu. Vous commencez à atteindre les limites de concurrence et devez demander des augmentations à AWS.

Conteneurs :300 $ à 2 000 $/mois. Votre API s'exécute sur 4 à 8 réplicas de conteneurs avec un équilibreur de charge. Les coûts augmentent avec l'allocation du processeur et de la mémoire, et non par requête. La courbe des coûts s'aplatit car l'ajout d'une réplique de conteneur gère des milliers de requêtes supplémentaires par seconde.

Gagnant : les conteneurs.À cette échelle, le modèle de tarification par requête du sans serveur joue contre vous. Un seul conteneur traitant 1 000 requêtes/seconde coûte 50 $/mois. Le même débit sur Lambda coûte plus de 500 $/mois.

Ce que Savi recommande pour la plupart des produits SaaS

Démarrez sans serveur. Déplacez des charges de travail spécifiques vers des conteneurs lorsque les données vous le demandent.

Pour 90 % des produits SaaS que nous construisons chez Savi, la bonne architecture au lancement est :Next.js sur Vercel (sans serveur) + Postgres géré sur Neon ou Supabase + un seul conteneur de travail en arrière-plan sur Fly.io ou Railway. Coût total de l'infrastructure : 0 $ à 50 $/mois.

Cette configuration gère 0 à 10 000 utilisateurs sans modifications architecturales. Lorsque vous atteignez 10 000 utilisateurs, vous disposez de revenus, de données d’utilisation et de goulots d’étranglement spécifiques que vous pouvez identifier. Ensuite, vous déplacez le goulot d'étranglement, et uniquement le goulot d'étranglement, vers un conteneur. Peut-être que votre point de terminaison d'API qui génère des rapports PDF prend 30 secondes et expire sur Lambda. Conteneurisez ce point de terminaison. Gardez tout le reste sans serveur.

Cette approche fonctionne car elle optimise la contrainte qui compte le plus à chaque étape. Au lancement, votre contrainte est le temps et l’argent. Le sans serveur vous offre les deux. À grande échelle, votre contrainte est la rentabilité et la latence. Les conteneurs vous offrent les deux.

Drapeaux rouges : lorsque les équipes choisissent la mauvaise architecture

N'adoptez pas Kubernetes avant d'avoir plus de 50 microservices ou des exigences de conformité spécifiques qui l'exigent.Kubernetes est un outil puissant pour orchestrer des systèmes distribués à grande échelle. C'est aussi un travail à temps plein à entretenir. Une startup avec 3 services exécutant Kubernetes paie entre 500 et 1 500 $/mois en coûts de cluster géré et consacre 10 à 20 heures/semaine au travail DevOps qu'un déploiement Vercel éliminerait.

Ne restez pas sans serveur lorsque votre facture Lambda dépasse 1 000 $/mois.À ce stade, exécutez les chiffres sur les conteneurs. Vous constaterez souvent que 3 à 4 répliques de conteneurs à 200 $/mois gèrent la même charge qui coûte plus de 1 000 $ sur Lambda.

Ne choisissez pas une architecture cloud basée sur ce qu'utilise Netflix ou Uber.Ces entreprises comptent plus de 500 ingénieurs, des équipes de plateforme dédiées et des volumes de trafic qui nécessitent une infrastructure personnalisée. Votre produit SaaS avec 2 000 utilisateurs et 3 ingénieurs a besoin d'une pile ennuyeuse et prévisible qui expédie rapidement les fonctionnalités.

Ne confondez pas l'orchestration de conteneurs avec Docker.Docker est simple. Vous écrivez un Dockerfile, créez une image et l'exécutez. Kubernetes est complexe. Il ajoute la mise en réseau, la découverte de services, la gestion des secrets, les contrôleurs d'entrée et une courbe d'apprentissage abrupte. Vous pouvez utiliser Docker sans Kubernetes. La plupart des produits en phase de démarrage devraient le faire.

Le but de votre architecture cloud n'est pas d'être impressionnant sur un tableau blanc. Il s'agit de maintenir votre produit en fonctionnement, vos factures prévisibles et votre équipe de fournir des fonctionnalités au lieu de lutter contre l'infrastructure.

Questions fréquemment posées