English
Quand une requête HTTP arrive sur un endpoint, que se passe-t-il si aucun serveur ne l'attend ? C'est précisément la question que pose le serverless computing, un modèle d'exécution où l'infrastructure se matérialise à la demande, traite la requête, puis disparaît. Comprendre comment fonctionne le serverless computing suppose de dépasser le terme marketing pour examiner les mécanismes réels : allocation de ressources, cycle de vie des fonctions, déclencheurs événementiels et facturation à la milliseconde. En 2026, les trois grands fournisseurs cloud (AWS Lambda, Azure Functions, Google Cloud Functions) traitent collectivement des milliards d'invocations quotidiennes, et des acteurs comme Cloudflare Workers ou Vercel ont élargi le périmètre du modèle aux edge functions. Ce paradigme ne supprime pas les serveurs : il les rend invisibles pour les équipes de développement. Le serverless dans le cloud computing moderne s'impose désormais comme une approche incontournable pour concevoir des applications évolutives. Voici ce qui se passe concrètement.
Définition et principes fondamentaux du serverless
Le serverless computing désigne un modèle d'exécution dans lequel le fournisseur cloud provisionne, dimensionne et gère l'infrastructure de manière dynamique. Le développeur déploie du code sous forme de fonctions ou de conteneurs événementiels, sans jamais configurer de machine virtuelle, de système d'exploitation ou de runtime serveur. Le terme "sans serveur" est trompeur : des serveurs physiques existent bel et bien dans les datacenters du fournisseur. La différence fondamentale réside dans la responsabilité opérationnelle : patching, scaling, haute disponibilité et allocation mémoire sont entièrement délégués. Cette définition permet de répondre simplement à la question : Qu'est-ce que le calcul serverless ? Il s'agit d'un modèle où l'infrastructure est entièrement abstraite pour les équipes de développement. Dans cette approche, le recours à un cloud open source peut également permettre aux organisations de bénéficier d'une plus grande maîtrise de leur environnement technologique.
L'abstraction totale de la gestion d'infrastructure
Dans un déploiement classique sur EC2 ou sur un cluster Kubernetes, l'équipe d'exploitation choisit le type d'instance, configure les groupes d'auto-scaling, gère les mises à jour du noyau Linux et surveille l'utilisation CPU. Avec le serverless, ces couches disparaissent du périmètre de l'équipe. Le développeur fournit un artefact de code (un fichier ZIP, une image conteneur OCI depuis le support Lambda des images en 2020, ou un bundle edge), définit la quantité de mémoire allouée (de 128 Mo à 10 Go sur AWS Lambda en 2026) et spécifie un handler d'entrée. Le fournisseur se charge du reste : placement sur un hôte physique, isolation via microVM (Firecracker chez AWS) ou isolats V8 (chez Cloudflare), et recyclage de l'environnement après inactivité. Cette logique s'inscrit dans l'évolution des modèles de Service open source proposés par de nombreux acteurs du numérique et illustre parfaitement le fonctionnement de la technologie severless.
Le modèle de facturation à l'usage réel
La facturation serverless repose sur deux métriques : le nombre d'invocations et la durée d'exécution multipliée par la mémoire allouée. AWS Lambda facture par tranche de 1 ms depuis 2020, avec un tarif de 0,0000166667 USD par Go-seconde en 2026. Concrètement, une fonction configurée avec 512 Mo de mémoire qui s'exécute pendant 200 ms coûte environ 0,0000016 USD par invocation. Ce modèle élimine le coût des serveurs inactifs : une application qui reçoit 100 requêtes par jour paie uniquement ces 100 exécutions, contrairement à une instance EC2 t3.micro facturée 24h/24 même à 0 % de charge. Le revers : une application à trafic constant et prévisible peut revenir plus cher en serverless qu'avec des instances réservées. Cette comparaison soulève souvent la question : Serverless computing et cloud : quelle différence ? Le cloud fournit l'infrastructure et les services, tandis que le serverless constitue un modèle d'exécution spécifique reposant sur cette infrastructure cloud.
Le fonctionnement technique : de l'événement à l'exécution
Le serverless est fondamentalement un modèle événementiel. Aucune fonction ne tourne en permanence en attente de requêtes. Chaque exécution est déclenchée par un événement externe, traité par le runtime du fournisseur, puis terminée. Ce flux événement-exécution-terminaison constitue le cœur du fonctionnement technique.
Le rôle des déclencheurs et du Function-as-a-Service (FaaS)
Un déclencheur est un événement qui provoque l'invocation d'une fonction. Les sources sont variées :
- Une requête HTTP via une passerelle API (API Gateway, Cloud Endpoints)
- Un message déposé dans une file d'attente (SQS, Pub/Sub, EventBridge)
- Une modification dans un bucket de stockage (upload de fichier sur S3)
- Un événement de base de données (DynamoDB Streams, Firestore triggers)
- Un timer cron (exécution planifiée toutes les 5 minutes)
Le composant FaaS reçoit l'événement sous forme de payload JSON, instancie un environnement d'exécution si aucun n'est disponible, puis appelle la fonction handler avec le contexte d'invocation. Le développeur n'a aucune visibilité sur le serveur hôte : il reçoit l'événement, retourne une réponse, et l'environnement est libéré ou mis en veille.
La gestion automatique de la mise à l'échelle
L'un des mécanismes les plus distinctifs du serverless est le scaling horizontal automatique et granulaire. Chaque invocation peut théoriquement s'exécuter dans son propre conteneur isolé. Si 1 000 requêtes arrivent simultanément, le fournisseur provisionne jusqu'à 1 000 environnements d'exécution en parallèle. AWS Lambda impose une limite de concurrence par défaut de 1 000 exécutions simultanées par compte et par région, extensible sur demande à plusieurs dizaines de milliers. Google Cloud Functions v2 s'appuie sur Cloud Run et permet jusqu'à 1 000 requêtes concurrentes par instance, réduisant le nombre total d'instances nécessaires. Ce scaling se fait sans configuration : pas de règle d'auto-scaling, pas de seuil CPU à définir. Le retour à zéro instance est tout aussi automatique quand le trafic cesse.
Le cycle de vie d'une fonction éphémère
Une fonction serverless passe par trois phases. La phase d'initialisation (cold start) inclut le téléchargement du code, le démarrage du runtime (Node.js, Python, Java, .NET, Rust) et l'exécution du code d'initialisation global. Sur AWS Lambda, un cold start typique dure entre 100 ms (Python, Node.js) et 1-2 secondes (Java avec Spring). La phase d'invocation correspond à l'exécution du handler proprement dit. La phase de gel (freeze) intervient après l'exécution : l'environnement reste en mémoire pendant quelques minutes, prêt à traiter une nouvelle requête sans repasser par l'initialisation. C'est le warm start, qui réduit la latence à quelques millisecondes. Après une période d'inactivité variable (non documentée officiellement, mais observée entre 5 et 45 minutes selon le fournisseur), l'environnement est détruit.
Les composants clés de l'écosystème serverless
Une architecture serverless ne se limite pas aux fonctions FaaS. Elle s'appuie sur un ensemble de services managés qui remplacent chaque composant traditionnel de l'infrastructure : stockage, base de données, routage réseau et orchestration.
Services de stockage et bases de données managées
Les fonctions étant éphémères et sans état, toute persistance doit être externalisée. DynamoDB (AWS), Firestore (Google Cloud) et Cosmos DB (Azure) sont les bases de données les plus couramment associées aux architectures serverless, car elles offrent une facturation à la requête et un scaling automatique. Pour le stockage d'objets, S3, Cloud Storage et Azure Blob Storage servent à la fois de dépôt de fichiers et de source d'événements déclencheurs. Les bases relationnelles posent un défi spécifique : chaque invocation ouvre potentiellement une nouvelle connexion, ce qui sature rapidement le pool de connexions d'un PostgreSQL ou MySQL classique. AWS a introduit RDS Proxy pour résoudre ce problème, et PlanetScale ou Neon proposent en 2026 des bases serverless-native avec connection pooling intégré. Cette approche peut être complétée par un support de logiciels libres afin d'assurer une meilleure interopérabilité des composants.
Passerelles API et routage des requêtes
La passerelle API est le point d'entrée principal pour les fonctions déclenchées par HTTP. Amazon API Gateway, Google API Gateway et Azure API Management reçoivent les requêtes, gèrent l'authentification (JWT, clés API, OAuth2), appliquent des quotas de débit (rate limiting) et routent vers la fonction appropriée. API Gateway sur AWS propose deux modes : REST API (plus riche en fonctionnalités, plus cher) et HTTP API (latence réduite, coût divisé par trois). La passerelle transforme la requête HTTP en événement JSON transmis à la fonction Lambda, puis convertit la réponse de la fonction en réponse HTTP standard. Ce composant ajoute typiquement 5 à 15 ms de latence, un coût acceptable pour la plupart des cas d'usage.
Avantages et défis de l'architecture sans serveur
Adopter le serverless modifie profondément les pratiques de développement et d'exploitation. Les gains sont réels, mais les contraintes techniques méritent une analyse lucide.
Agilité du développement et réduction du Time-to-Market
Sans infrastructure à provisionner, un développeur peut déployer une API fonctionnelle en quelques heures. Les frameworks comme Serverless Framework, AWS SAM ou SST (Solid Start Toolkit, très populaire en 2026) permettent de définir l'infrastructure en code (IaC) et de déployer fonctions, bases de données et passerelles API en une seule commande. Le cycle de feedback se raccourcit : un correctif peut être déployé en production en moins de 60 secondes. Les équipes réduites y trouvent un avantage considérable, car elles n'ont pas besoin d'un ingénieur DevOps dédié pour gérer des clusters. Les coûts opérationnels chutent pour les applications à trafic variable ou imprévisible : un side project, un webhook de traitement, un pipeline de données déclenché ponctuellement.
Les contraintes techniques : démarrage à froid et verrouillage fournisseur
Le cold start reste le principal irritant. Pour les applications sensibles à la latence (API temps réel, interfaces utilisateur), un délai de 1 à 2 secondes à la première requête est problématique. AWS propose Provisioned Concurrency pour maintenir des environnements chauds en permanence, mais cela revient à payer pour des ressources réservées, ce qui annule partiellement l'avantage économique du modèle. Le verrouillage fournisseur (vendor lock-in) est l'autre défi majeur. Une fonction Lambda utilisant DynamoDB, SQS et API Gateway est profondément liée à l'écosystème AWS. Migrer vers Google Cloud nécessite une réécriture significative. Des projets comme Knative ou OpenFaaS proposent une couche d'abstraction portable, mais leur adoption en production reste limitée comparée aux services natifs des hyperscalers. Les initiatives portées par la communaute open source contribuent toutefois à réduire cette dépendance grâce à des solutions plus ouvertes et interopérables.
Cas d'usage concrets et avenir de la technologie
Le serverless excelle dans des scénarios précis : traitement d'images à l'upload (redimensionnement automatique via S3 + Lambda), backends d'applications mobiles avec trafic sporadique, pipelines ETL déclenchés par des événements, chatbots et intégrations webhook. En 2026, l'essor des edge functions (Cloudflare Workers, Vercel Edge Functions, Deno Deploy) étend le modèle serverless aux points de présence géographiques, réduisant la latence à moins de 50 ms pour les utilisateurs finaux. Les architectures serverless-first deviennent la norme pour les startups et les équipes produit qui privilégient la vitesse d'itération.
Les limites persistent pour les workloads de longue durée (traitement vidéo, entraînement ML) et les applications nécessitant un contrôle fin sur le réseau ou le système de fichiers. AWS Lambda autorise désormais des exécutions de 15 minutes maximum, mais ce plafond reste contraignant pour certains cas. L'avenir du modèle passe par la convergence entre conteneurs et serverless : AWS Fargate, Google Cloud Run et Azure Container Apps proposent déjà des conteneurs facturés à l'usage avec scaling à zéro, brouillant la frontière entre les deux approches. Pour les équipes qui évaluent cette architecture, la recommandation est pragmatique : commencez par un cas d'usage événementiel isolé (un webhook, un traitement asynchrone), mesurez les coûts et la latence réels, puis élargissez progressivement le périmètre en fonction des résultats observés.
