Le serverless est probablement le terme cloud le plus malheureusement nommé de la décennie. Sans serveur, vraiment ? Évidemment non — il y a toujours un serveur, simplement il est invisible pour vous, et facturé à l’usage seul. Cette confusion sémantique fait croire à des débutants que le serverless est magique et toujours moins cher. La réalité est plus nuancée : c’est un outil tactique qui excelle sur certains profils de charge et explose financièrement sur d’autres. Cette page décortique ce qu’est réellement le serverless, ses trois familles (FaaS event-driven, FaaS HTTP, containers serverless), le cycle de vie d’une invocation, les cinq pièges classiques, et défend une opinion claire sur quand l’utiliser et quand l’éviter.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Pourquoi le serverless n’est pas « sans serveur » mais « serveur invisible »
- Les 3 familles : FaaS event-driven, FaaS HTTP, containers serverless
- Le cycle de vie d’une invocation, du cold start au kill
- Les 5 pièges classiques : latence cold start, lock-in, debugging, durée max, coût à l’échelle
- Quand choisir le serverless et quand l’éviter par défaut
Prérequis : avoir compris la grille XaaS. Si besoin, lisez d’abord IaaS, PaaS, SaaS, FaaS, CaaS.
1. Le serverless n’est pas « sans serveur »
Section intitulée « 1. Le serverless n’est pas « sans serveur » »Le mot serverless est entré dans le vocabulaire cloud en 2014 avec le lancement d’AWS Lambda. Il a été retenu pour son effet marketing, malgré son inexactitude technique évidente. Une définition honnête tient en deux propriétés :
Le serveur est invisible. Vous ne provisionnez ni VM, ni container engine, ni runtime. Vous écrivez une fonction (un bout de code), vous la déployez, le fournisseur exécute. Tout ce qui est en dessous (OS, container, scheduler, scaling) est abstrait — vous n’y avez ni accès ni visibilité directe.
La facturation suit l’usage strict. Vous payez uniquement quand votre fonction s’exécute, à la milliseconde près sur la plupart des plateformes. Quand la fonction est inactive, vous payez zéro. Cette propriété est l’argument économique principal du serverless, et elle est réelle — à condition d’opérer dans le bon profil de charge.
Une fois cette définition posée, on peut parler des trois familles concrètes que recouvre le terme.
2. Les 3 familles de serverless
Section intitulée « 2. Les 3 familles de serverless »Sous l’étiquette « serverless » se cachent en réalité trois modèles techniques distincts qu’il est important de distinguer pour comprendre les arbitrages.
FaaS event-driven — la fonction réveillée par un événement
Section intitulée « FaaS event-driven — la fonction réveillée par un événement »Une fonction qui se déclenche en réponse à un événement : un fichier déposé sur un bucket, un message qui arrive dans une file, une horloge cron, une mise à jour de base de données. C’est le modèle historique introduit par AWS Lambda en 2014.
Cas d’usage typiques : pipelines ETL, traitement asynchrone de fichiers, automation interne, webhooks, réactions à des événements infrastructure (auto-tagging à la création de ressource, scan de sécurité automatique).
FaaS HTTP — la fonction qui sert une API
Section intitulée « FaaS HTTP — la fonction qui sert une API »Variante du précédent où l’événement déclencheur est une requête HTTP entrante via une API Gateway. La fonction reçoit la requête, la traite, retourne une réponse. C’est l’usage le plus visible aujourd’hui — beaucoup d’API REST modernes sont construites en FaaS HTTP.
Cas d’usage typiques : API backend léger, microservices courts, prototypes rapides, endpoints peu sollicités où le coût zéro à charge nulle est attractif.
Containers serverless — la frontière avec le CaaS
Section intitulée « Containers serverless — la frontière avec le CaaS »Plateformes qui acceptent une image OCI (container) plutôt qu’une fonction inline, mais conservent les propriétés serverless : scaling à zéro, facturation à l’usage, pas de gestion d’infrastructure. Cloud Run (GCP), App Runner (AWS), Container Instances Consumption (Azure) entrent dans cette catégorie.
C’est le modèle qui monte le plus vite depuis 2022, parce qu’il combine la portabilité d’une image container (cf. CaaS) et le pricing zéro à zéro charge du FaaS, sans le lock-in du SDK propriétaire.
Tableau comparatif des plateformes 2026
Section intitulée « Tableau comparatif des plateformes 2026 »| Plateforme | Famille | Durée max | Cold start typique | Pricing |
|---|---|---|---|---|
| AWS Lambda | FaaS event + HTTP | 15 min | 100–500 ms (Node.js), 1–10 s (Java) | 0,20 $/M req + 0,0000167 $/Go-s |
| Azure Functions Consumption | FaaS event + HTTP | 5 min (extensible 60) | 200 ms–2 s | 0,20 $/M req + 0,000016 $/Go-s |
| GCP Cloud Functions Gen 2 | FaaS event + HTTP | 9 min (extensible 60) | 200 ms–1 s | 0,40 $/M req + 0,0000025 $/Go-s |
| AWS Fargate Spot | Container serverless | illimité | démarrage container 10–60 s | 0,012 $/vCPU-h + 0,0013 $/Go-h |
| GCP Cloud Run | Container serverless | 60 min | 200 ms–10 s | 24 M req gratuites/mois puis 0,40 $/M |
| AWS App Runner | Container serverless | illimité | 5–30 s | 0,007 $/Go-s + 0,064 $/vCPU-h |
| Cloudflare Workers | FaaS Edge | 30 s CPU time | < 5 ms | 0,30 $/M req |
Cette diversité permet de choisir la plateforme adaptée au profil, mais elle a aussi son revers : chaque plateforme impose son SDK et son format d’événement, ce qui crée le lock-in dont on parle plus loin.
3. Le cycle de vie d’une invocation
Section intitulée « 3. Le cycle de vie d’une invocation »Comprendre physiquement ce qui se passe quand votre fonction s’exécute est la clé pour anticiper les pièges. Voici la séquence détaillée pour un Lambda typique en réponse à une requête HTTP via API Gateway.
Étape 1 — Réception de l’événement. Une requête HTTP arrive sur API Gateway. AWS résout le routage et déclenche l’invocation de votre Lambda associée.
Étape 2 — Choix d’un container. AWS cherche un container actif déjà chargé avec votre code. S’il en trouve un disponible, on saute directement à l’étape 5 (warm start, latence ~10 ms). Sinon, on enchaîne les étapes 3 et 4 (cold start).
Étape 3 — Provisionnement d’un nouveau container. AWS lance un container Firecracker (micro-VM ultra-légère), monte votre runtime (Node.js, Python, Java…), charge votre code applicatif. Cette phase prend 100 ms à 10 s selon le langage et la taille du package — c’est le fameux cold start.
Étape 4 — Init phase. Votre code est chargé en mémoire, les variables globales, les connexions externes (DB, cache) initialisées. Si vous établissez une connexion PostgreSQL dans cette phase plutôt que dans la fonction handler, vous payez l’init une fois au lieu d’à chaque requête.
Étape 5 — Exécution du handler. Votre fonction handler(event, context) reçoit l’événement, le traite, retourne une réponse. C’est la seule phase qui contient votre logique métier.
Étape 6 — Retour de la réponse. La réponse remonte vers API Gateway, qui la formate et la renvoie au client.
Étape 7 — Idle ou kill. Le container reste actif et inactif quelques minutes (~5 à 15 min selon le fournisseur), prêt à servir une autre requête. S’il reste inactif trop longtemps, AWS le détruit pour libérer des ressources. La prochaine invocation après destruction redémarrera par un cold start complet.
Cette mécanique explique trois comportements observés en production : la latence imprévisible (cold start aléatoire), le bénéfice de garder la fonction « chaude » (provisioned concurrency), et le coût caché de stocker du contexte dans une variable globale persistant entre invocations.
4. Les avantages réels du serverless
Section intitulée « 4. Les avantages réels du serverless »Au-delà du marketing, le serverless apporte quatre bénéfices concrets qui justifient son adoption sur les bons profils de charge.
Coût zéro à charge nulle. C’est le bénéfice le plus évident : si votre fonction n’est invoquée que 100 fois par jour, vous payez quelques centimes par mois. Comparé à une VM 24/7 qui coûte 50 € minimum, l’économie est massive sur les workloads à très faible utilisation. Pour un endpoint d’admin sollicité 50 fois par jour, le serverless est 1 000 fois moins cher qu’une VM dédiée.
Scaling automatique sans configuration. Vous n’avez ni Auto Scaling Group à paramétrer, ni Kubernetes HPA à tuner, ni capacity planning à faire. Le fournisseur scale horizontalement votre fonction de 0 à plusieurs milliers d’instances simultanées en quelques secondes. Pour un workflow saisonnier (Black Friday, fin de mois comptable), c’est plus simple qu’un autoscaler classique.
Maintenance OS = zéro. Pas d’OS à patcher, pas de runtime à mettre à jour manuellement, pas de CVE à suivre sur la couche système. Le fournisseur opère ces couches, vous ne touchez qu’au code applicatif. Sur une équipe sans DevOps dédié, c’est un soulagement opérationnel réel.
Time-to-deploy très court. aws lambda update-function-code prend 30 secondes pour pousser une nouvelle version. Combiné à une CI/CD, vous pouvez itérer plusieurs fois par jour sans rituel de déploiement complexe.
5. Les 5 pièges classiques du serverless
Section intitulée « 5. Les 5 pièges classiques du serverless »Voici les pièges que je vois systématiquement dans les projets serverless mal cadrés. Si votre architecture en cumule plusieurs, c’est peut-être que le serverless n’est pas le bon outil pour ce cas d’usage.
❄️ Cold start imprévisible
Le piège : la première invocation après inactivité prend 100 ms à 10 s au lieu de quelques ms. Un endpoint qui répond habituellement en 50 ms peut soudainement timeout à 5 s.
Cas typique : application web à trafic faible, où chaque utilisateur unique déclenche un cold start. La latence perçue est désastreuse.
Mitigation : provisioned concurrency (paie pour garder N containers chauds), choix d’un runtime rapide (Node.js, Go, Rust > Java), limitation de la taille du package, init perezzeux des dépendances.
🔒 Vendor lock-in fort
Le piège : chaque plateforme impose son SDK, son format d’événement, son IAM, ses limites. Un Lambda AWS ne tourne pas tel quel sur Azure Functions ou Cloud Functions.
Cas typique : équipe qui découvre après 18 mois qu’elle veut bouger vers un fournisseur souverain — la migration impose une réécriture complète.
Mitigation : containers serverless (Cloud Run, App Runner) plutôt que FaaS pur, framework portable type Knative ou OpenFaaS, séparation stricte logique métier / handlers fournisseur.
🐛 Debugging difficile
Le piège : pas de SSH sur la fonction, pas de strace, pas de top. Vous diagnostiquez via les logs CloudWatch / App Insights, qui arrivent avec délai et sont volumineux.
Cas typique : bug de performance qui n’apparaît que sous charge réelle, impossible à reproduire en local. Plusieurs jours perdus à instrumenter.
Mitigation : tracing distribué dès le J1 (X-Ray, OpenTelemetry), logs structurés JSON, Lambda Powertools, frameworks d’invocation locale (SAM Local, LocalStack).
⏱️ Durée d'exécution limitée
Le piège : 15 min max sur Lambda, 5 min sur Functions Consumption (extensible à 60), 9 min sur Cloud Functions Gen 2. Au-delà, votre fonction est tuée même si elle n’a pas fini.
Cas typique : génération PDF d’un gros rapport, transcription audio, analyse vidéo — tâches qui dépassent souvent ces seuils.
Mitigation : passer en containers serverless (Cloud Run = 60 min, App Runner illimité), découper en sous-tâches via Step Functions / Durable Functions, basculer sur Batch managé pour les vraies tâches longues.
💸 Coût qui explose à l'échelle
Le piège : Lambda à 0,20 $/M req est attractif jusqu’à un seuil. À 100 M req/mois, c’est 20 $ ; à 10 milliards de req/mois, c’est 2 000 $/mois rien qu’en requêtes, plus le compute. Sur ce volume, une flotte de containers ECS Fargate ou de VMs reservées coûte 5 à 10 fois moins cher.
Cas typique : application qui scale au-delà du million d’utilisateurs actifs et garde une architecture FaaS par habitude. La facture devient ingérable à comparaison équivalente.
Mitigation : surveiller le break-even point (typiquement autour de 30 % d’usage continu), basculer sur ECS / Cloud Run / Kubernetes managé au-delà, utiliser le serverless pour les pics et les containers managés pour la baseline.
6. Quand choisir le serverless, quand l’éviter
Section intitulée « 6. Quand choisir le serverless, quand l’éviter »Le serverless est un outil tactique, pas un défaut stratégique. Voici les profils où il excelle et ceux où il échoue.
Choisir le serverless quand
Section intitulée « Choisir le serverless quand »- Charge très faible et sporadique : moins de 1 % d’utilisation continue, le coût zéro à charge nulle écrase tout autre modèle.
- Pipelines event-driven assumés : trigger S3 → traitement → écriture DB → notification. C’est exactement le scénario pour lequel Lambda a été conçu.
- Prototypes et MVP : vous voulez tester une idée sans gérer d’infrastructure, le serverless va plus vite que tout.
- Automation interne : cron jobs cloud, webhooks, réactions à événements infrastructure.
- API à très faible trafic ou très variable : où l’élasticité gratuite à zéro est l’argument décisif.
Éviter le serverless quand
Section intitulée « Éviter le serverless quand »- Latence prévisible exigée : le cold start tue les SLA stricts (par exemple < 200 ms p99 en permanence).
- Très haute volumétrie continue : au-delà du break-even point, les containers managés ou les VMs reserved sont moins chers.
- Workload long : tâches > 15 min, batch ML, vidéo, ETL volumineux — utilisez Batch managé ou des containers longs.
- Stack non standard : besoin de bibliothèques système particulières, dépendances binaires complexes, customisations OS — préférez containers ou IaaS.
- Souveraineté technologique : le FaaS pur (offres propriétaires des hyperscalers) reste lié à un SDK et à un format d’événement spécifiques. Pour un projet qui doit pouvoir migrer ailleurs, les containers serverless portables (image OCI standard, exécutable sur Knative on-prem ou tout CaaS compatible) offrent davantage d’options de sortie.
7. Quand le serverless est-il pertinent ?
Section intitulée « 7. Quand le serverless est-il pertinent ? »Le serverless est un outil ciblé, pas une architecture universelle. Comprendre ses forces et ses limites permet de l’utiliser au bon endroit, plutôt que de le déployer par défaut ou de l’écarter par principe.
Comprendre le coût réel. Le prix par requête affiché (de l’ordre de quelques centimes du million d’invocations) ne représente qu’une partie du coût final. À cela s’ajoutent : la concurrence provisionnée quand on veut éviter le cold start, les outils de tracing pour suivre les invocations, les logs pour la traçabilité, et le trafic sortant depuis un réseau privé. Un calcul TCO complet (sur le modèle de TCO cloud vs on-premise) est nécessaire avant de comparer le serverless à d’autres modèles.
Évaluer la portabilité attendue. Une fonction écrite pour un fournisseur FaaS spécifique dépend de son SDK, du format d’événement propre à ce fournisseur, et de ses intégrations IAM. Une image OCI standard exécutée dans un container serverless reste portable vers un autre environnement compatible OCI/Knative. Pour les projets qui veulent garder une stratégie de sortie, ce critère oriente souvent le choix vers les containers serverless plutôt que le FaaS pur (cf. Souveraineté technologique de la stack).
Choisir l’usage adapté. Le serverless excelle pour le glue code et l’event-driven : webhooks, automatisations, pipelines de données, réactions à des événements d’infrastructure. Construire une application transactionnelle complète en pur FaaS reste techniquement possible mais demande davantage d’efforts sur le tracing, le debugging, et la gestion d’état. Sur ces profils, les containers managés offrent un meilleur compromis simplicité / contrôle.
Profils où le serverless est un bon choix : tâches événementielles ponctuelles, automation autour de l’infrastructure, prototypes à faible trafic, traitements légers déclenchés par planification. Profils où il est moins adapté : APIs à latence stricte permanente, applications transactionnelles complexes, workloads continus à très haute volumétrie, traitements longs au-delà des limites d’exécution.
À retenir
Section intitulée « À retenir »- Le serverless signifie serveur invisible, pas sans serveur — toute la mécanique sous-jacente explique les comportements observés.
- Trois familles : FaaS event-driven, FaaS HTTP, containers serverless — cette dernière monte fortement depuis 2022.
- Le cycle de vie distingue cold start (100 ms–10 s) et warm start (10 ms), ce qui rend la latence imprévisible.
- Cinq pièges classiques : cold start, vendor lock-in, debugging difficile, durée max limitée, coût qui explose à l’échelle.
- Le serverless est un outil tactique : excellent pour event-driven et faible volume, inadapté pour latence prévisible et très haute volumétrie.
- Pour la portabilité entre environnements, les containers serverless (image OCI standard) offrent davantage d’options de sortie que le FaaS pur lié au SDK d’un fournisseur.