Serverless et FaaS : ce qui se cache derrière 'sans serveur'

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 donne des critères pour décider quand l'utiliser et quand l'éviter.

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

Périmètre : cette leçon porte sur le choix du serverless et sur ses pièges, du point de vue d'un fournisseur cloud. La mécanique côté Kubernetes (scale-to-zero, CloudEvents, Knative Serving, Eventing et Functions) est traitée dans Serverless : comprendre le modèle sans serveur, qui reste une page de référence.

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 »

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.

Serverless ≠ sans infrastructure

Le serveur existe toujours, il est juste géré par le fournisseur. Quand votre fonction Lambda répond à une requête, un environnement d'exécution isolé (une micro-VM, détaillée à l'étape 3 du cycle de vie plus bas) est lancé par AWS sur ses propres serveurs, votre code est chargé, exécuté, puis l'environnement est mis en pause ou détruit. Cette mécanique sous-jacente explique tous les comportements (le cold start, c'est-à-dire le délai de démarrage quand aucun environnement n'est prêt, la durée max, l'isolation) que nous allons détailler.

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

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

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

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

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), ECS Fargate (AWS, sans réveil automatique sur requête, voir la leçon CaaS) et Azure Container Apps (profil Consumption) entrent dans cette catégorie. AWS App Runner y figurait aussi, mais il est fermé aux nouveaux clients depuis le 30 avril 2026 (AWS recommande ECS Express Mode) et n'est plus à choisir pour un nouveau projet.

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 coût nul à charge nulle du FaaS, sans le lock-in des déclencheurs et des formats d'événement propres à chaque fournisseur.

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 par défaut, 10 min au plus (plan hérité)	200 ms–2 s	0,20 $/M req + 0,000016 $/Go-s
GCP Cloud Functions Gen 2 (Cloud Run functions)	FaaS event + HTTP	9 min pour les fonctions sur événement, 60 min pour HTTP	200 ms–1 s	0,40 $/M req + 0,0000025 $/Gio-s, plus le CPU facturé à part
AWS Fargate Spot	Container serverless	pas de durée maximale documentée, interruption possible avec 2 min de préavis	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	2 M req gratuites/mois (facturation à la requête) puis 0,40 $/M
Cloudflare Workers	FaaS Edge	30 s de temps CPU par défaut, 5 min au plus	< 5 ms	0,30 $/M req au-delà de 10 M incluses

Glissez pour voir

Dates de référence du tableau. Les tarifs datent d'avril 2026, sauf la ligne Cloud Run, qui suit la page de tarification de Google Cloud au 9 octobre 2026. Les durées maximales suivent les documentations d'AWS, de Microsoft, de Google Cloud et de Cloudflare au 12 octobre 2026 ; le plan Azure Functions Consumption y est qualifié d'hérité (le plan Flex Consumption est recommandé pour un nouveau projet). Ces valeurs changent plusieurs fois par an, et les paliers gratuits encore plus souvent. Servez-vous de ce tableau pour comparer des ordres de grandeur et le rapport entre plateformes, jamais pour bâtir un budget : pour cela, la grille tarifaire du fournisseur fait seule autorité, et un simulateur officiel vaut mieux qu'une multiplication à la main.

Cette diversité permet de choisir la plateforme adaptée au profil, mais elle a aussi son revers : chaque plateforme a ses déclencheurs, son format d'événement et ses intégrations (souvent via son SDK), ce qui crée le lock-in dont on parle plus loin.

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.

Le cycle complet tient en une chaîne : événement, initialisation d'un conteneur si aucun n'est disponible, exécution, retour de la réponse, attente du conteneur en veille (quelques minutes, durée non garantie), puis destruction. Les étapes ci-dessous détaillent cette séquence.

É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 environnement d'exécution isolé, que ce texte appelle « container » par commodité mais qui est en réalité une micro-VM Firecracker, 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 en veille 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 » (la provisioned concurrency, qui consiste à payer pour garder des environnements prêts), et le coût caché de stocker du contexte dans une variable globale persistant entre invocations.

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 nul à charge nulle. C'est le bénéfice le plus évident, et le seul qu'une machine virtuelle ne pourra jamais offrir : une fonction qui n'est pas appelée ne coûte rien, là où une machine allumée se facture à l'heure qu'elle travaille ou non.

La mécanique compte plus que le multiplicateur. Un point d'entrée d'administration appelé quelques dizaines de fois par jour représente quelques milliers d'invocations par mois : à 0,20 $ par million de requêtes (tarif Lambda, hors durée de calcul), la ligne est inférieure au centime, tandis que la machine équivalente se facture en dizaines d'euros. L'écart n'est donc pas d'un facteur connu à l'avance, il dépend entièrement du nombre d'appels et de la durée d'exécution de chacun : ce sont les deux seules variables à mesurer.

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 à mesure que les appels arrivent, dans la limite des quotas de concurrence (le nombre maximal d'exécutions simultanées autorisées sur votre compte et votre région, que l'on peut demander à relever) : la montée en charge n'est ni infinie ni instantanée. Chez AWS Lambda, la documentation fixe par défaut 1 000 exécutions simultanées par région et par compte, et une montée de 1 000 environnements d'exécution toutes les 10 secondes pour chaque fonction (valeurs relevées le 12/10/2026 dans la documentation Lambda, à revérifier avant dimensionnement). 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 et pas de CVE à suivre sur la couche système : le fournisseur opère ces couches. Le runtime (Node.js, Python, Java) reste à votre charge sur ce point : les versions finissent par être retirées du support, et il faut migrer la fonction vers une version supportée. Vous gérez en outre le code et les dépendances embarquées. 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

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, initialisation paresseuse (lazy) des dépendances.

Vendor lock-in fort

Le piège : chaque plateforme a ses déclencheurs, son format d'événement, son IAM et ses limites propres. 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, Azure Container Apps) 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 par défaut sur Functions Consumption (10 min au plus ; le plan Flex Consumption impose 30 min par défaut, sans maximum), 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 jusqu'à 60 min par requête (5 min par défaut), ECS Fargate sans durée maximale documentée par tâche, AWS pouvant toutefois la retirer pour la patcher), 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 finit par coûter moins cher à charge continue. L'écart dépend de la mémoire allouée, de la durée des exécutions et du taux d'utilisation : calculez-le avec les grilles tarifaires du moment plutôt que de retenir un coefficient.

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, le seuil d'usage à partir duquel le serverless coûte plus cher qu'un conteneur ou une VM (il n'existe pas de valeur universelle : plus la charge est continue et prévisible, plus ce seuil est vite atteint), 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

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

Cette liste réunit les situations favorables au serverless. Si votre projet en coche plusieurs, notamment une charge faible ou sporadique ou un traitement event-driven, le serverless est un candidat sérieux.

• 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

Cette liste réunit à l'inverse les situations défavorables au serverless. Un seul critère bloquant, comme une latence prévisible exigée ou un workload long, suffit pour préférer des containers managés ou des VMs.

• Latence prévisible exigée : le cold start tue les SLA stricts (par exemple moins de 200 ms au p99, c'est-à-dire pour 99 % des requêtes, 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. Que vérifier avant de trancher : coût, portabilité, usage ?

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é (0,20 $ le million d'invocations chez AWS Lambda, hors durée de calcul) 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.

À 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é aux déclencheurs et formats d'événement d'un fournisseur.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →