Serverless : définition, fonctionnement et cas d'usage

Serverless : la définition en clair

Le serverless (« sans serveur ») est un modèle de cloud computing dans lequel un fournisseur exécute votre code à la demande, sans que vous ayez à louer, configurer ou surveiller un serveur. Les serveurs existent toujours, bien sûr. Ils ne sont simplement plus votre affaire : le fournisseur les démarre, les met à jour et les éteint à votre place.

Concrètement, on découpe l'application en petites fonctions. Chacune se déclenche quand un événement survient : une visite, un formulaire envoyé, un fichier déposé, une heure précise. La fonction s'exécute, renvoie son résultat, puis s'arrête. Vous payez le temps de calcul réellement consommé, pas une machine allumée jour et nuit.

D'où vient le terme

Le mot s'est imposé avec AWS Lambda, lancé par Amazon en 2014. Google Cloud Functions, Azure Functions et Cloudflare Workers ont ensuite repris le principe. On parle aussi de FaaS, pour Function as a Service. Aujourd'hui, le serverless désigne plus largement tout service cloud qui s'adapte seul à la charge et se facture à l'usage : bases de données, files de messages, stockage.

Ce que le serverless change pour une PME

Pour un dirigeant, l'intérêt tient en une idée : on paie ce qui sert. Un site peu visité la nuit ne coûte presque rien la nuit. Un pic soudain, provoqué par une campagne ou un passage dans les médias, est absorbé automatiquement, sans qu'un technicien doive agrandir un serveur dans l'urgence. En contrepartie, l'équipe de développement doit concevoir l'application autrement.

À quoi sert le serverless : les cas d'usage concrets

Le serverless excelle sur les tâches courtes, déclenchées par un événement et irrégulières dans le temps. Voici les usages qu'on retrouve le plus souvent dans les projets de TPE et de PME.

• Traiter un formulaire de contact ou de devis : vérifier les champs, enregistrer la demande, envoyer un email de confirmation.
• Recevoir un webhook d'un service de paiement et mettre à jour la commande dans la base.
• Redimensionner ou compresser une image dès qu'elle est déposée dans un espace de stockage.
• Exposer une petite API qui alimente une application mobile ou un site.
• Lancer des tâches planifiées, comme un export nocturne, à la place d'un cron job installé sur un serveur.
• Appeler un modèle d'IA pour résumer un document ou trier des demandes, puis renvoyer le résultat au site.

Ces usages ont un point commun : entre deux appels, rien ne tourne et rien n'est facturé. C'est ce qui rend le modèle si adapté aux services d'appoint qui gravitent autour d'un site principal.

Le serverless au-delà des fonctions

Le modèle s'étend aujourd'hui à d'autres briques. Les conteneurs serverless, comme AWS Fargate ou Google Cloud Run, exécutent une image Docker sans qu'il faille gérer de cluster. Aurora Serverless, chez AWS, propose une base de données relationnelle dont la capacité varie selon la demande. Databricks serverless applique la même logique au traitement de données : les ressources se lancent pour une requête et se libèrent ensuite.

Mises bout à bout, ces briques forment une architecture serverless : une application entière construite à partir de services managés qui communiquent par événements. On peut tout bâtir ainsi ou n'en adopter qu'une partie, selon les besoins.

Comment fonctionne une architecture serverless

Le fonctionnement repose sur trois éléments : un déclencheur, une fonction et des services managés autour. Le déclencheur peut être une requête HTTP, un message posé dans une file d'attente, un fichier ajouté au stockage ou une horloge. La fonction contient le code métier. Les services managés s'occupent du reste : base de données, authentification, envoi d'emails.

Le cycle de vie d'une fonction AWS Lambda

Prenons AWS Lambda, la référence du marché. Vous envoyez votre code et choisissez un langage, par exemple Node.js, Python, Java ou Go. Quand un événement arrive, AWS prépare un environnement d'exécution isolé, y charge le code et lance la fonction. Si d'autres appels arrivent en même temps, la plateforme crée d'autres environnements en parallèle, sans aucun réglage de votre part.

Une fois l'appel terminé, l'environnement peut rester disponible un moment pour l'appel suivant. S'il a été libéré, le prochain appel subit un démarrage à froid, le fameux cold start : un peu de latence en plus, le temps de tout réinstaller. Une fonction Lambda est aussi limitée en durée, avec un maximum de quinze minutes par exécution.

Des fonctions sans mémoire

Une fonction serverless est dite sans état : elle ne garde rien d'un appel à l'autre. Tout ce qui doit durer, comme une commande, un panier ou un compte client, est rangé dans une base de données ou un stockage externe. Cette règle surprend parfois les développeurs habitués aux serveurs classiques. C'est pourtant elle qui permet de multiplier les copies d'une fonction sans risque de mélange.

Déployer avec un framework

Écrire une fonction isolée est simple. La relier à ses déclencheurs, gérer les droits d'accès et reproduire le tout à l'identique entre préproduction et production l'est beaucoup moins. C'est le rôle des frameworks. Le plus connu s'appelle justement Serverless Framework : on décrit ses fonctions et leurs événements dans un fichier de configuration, puis une commande comme « serverless deploy » envoie l'ensemble dans le cloud.

D'autres outils suivent la même idée, comme AWS SAM, proposé par Amazon, ou SST, apprécié des équipes qui travaillent en TypeScript. Tous transforment une description de l'infrastructure en ressources réelles. Le déploiement devient reproductible et se versionne avec le code, ce qui limite les mauvaises surprises au moment de la mise en ligne.

Serverless, VPS, microservices, services managés : bien comparer

On compare souvent le serverless à d'autres approches, parfois à tort, parce qu'elles ne répondent pas à la même question. Voici comment les situer les unes par rapport aux autres.

Face à un serveur privé virtuel

Un VPS est une machine virtuelle louée en continu. Vous y installez ce que vous voulez, vous en assurez la sécurité et les mises à jour, et elle coûte la même chose qu'elle travaille ou non. Le serverless inverse cette logique : pas de maintenance système, une montée en charge automatique, une facture qui suit l'usage. Pour un trafic stable et élevé, ou un logiciel qui doit tourner en permanence, le VPS reste souvent plus simple et plus prévisible. Notre comparatif VPS ou mutualisé détaille les autres options d'hébergement classique.

Microservices et serverless ne s'opposent pas

Les microservices sont une façon de découper une application en petits services indépendants, chacun chargé d'une mission. Le serverless, lui, est une façon de les héberger. On peut donc faire des microservices sur des serveurs, dans des conteneurs ou sous forme de fonctions. Le serverless pousse simplement le découpage plus loin, parfois jusqu'à une fonction par action. Attention à ne pas trop morceler : cent fonctions minuscules deviennent vite difficiles à suivre.

Service managé et serverless : une question de degré

Avec un service managé, c'est le fournisseur qui gère l'exploitation : sauvegardes, correctifs, haute disponibilité. Une base de données managée classique vous fait pourtant choisir une taille de machine, payée en continu. Un service serverless va un cran plus loin : plus de taille à choisir, la capacité s'ajuste seule et peut parfois descendre à zéro. Tout service serverless est managé, mais tout service managé n'est pas serverless.

SST ou Serverless Framework, un choix d'outil

Ici, on compare deux outils, pas deux modèles. Serverless Framework est le plus ancien, il vise plusieurs fournisseurs et repose sur un fichier de configuration déclaratif. SST, historiquement centré sur AWS, se configure en TypeScript et propose un mode de développement local branché sur les vraies ressources du cloud. Le choix dépend surtout du langage de l'équipe et du fournisseur visé : les deux produisent des applications serverless comparables.

Un exemple concret et les erreurs courantes

Les erreurs que l'on voit souvent

• Tout migrer d'un coup : réécrire un site entier en fonctions coûte cher et rapporte peu si le site actuel fonctionne.
• Ignorer le démarrage à froid sur une page où chaque instant compte, comme un tunnel de commande.
• Oublier la limite de durée : un traitement long doit être découpé ou confié à un conteneur.
• Écrire les clés et mots de passe dans le code au lieu de les ranger dans des variables d'environnement ou un gestionnaire de secrets.
• Donner des droits trop larges : chaque fonction ne devrait accéder qu'aux ressources dont elle a besoin.
• Ne pas fixer d'alerte budgétaire : la facturation à l'usage évite les coûts fixes, mais pas une boucle mal écrite qui s'emballe.
• Se lier sans le savoir à un fournisseur : plus on utilise de services propriétaires, plus un changement de cloud devient lourd.

La sécurité mérite une attention particulière. Le fournisseur protège l'infrastructure, mais votre code, vos permissions et vos données restent sous votre responsabilité. Surveillez les journaux d'exécution et testez chaque fonction comme n'importe quelle autre partie du logiciel.

Quand vaut-il mieux s'en passer ?

Mieux vaut l'éviter pour une application qui tourne en continu sous une charge forte et stable, pour des calculs très longs, ou quand l'équipe n'a pas le temps d'apprendre une nouvelle façon de travailler. Dans ces cas, un serveur ou des conteneurs classiques restent plus économiques et plus simples à maintenir. Pour un projet sur mesure, le mieux est de trancher dès la conception, comme nous le faisons en création de logiciel.

Questions fréquentes