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

Le serverless (littéralement “sans serveur”) est un modèle d’exécution dans le cloud où le développeur déploie du code — généralement sous forme de fonctions — sans avoir à gérer l’infrastructure sous-jacente. Il n’y a pas de serveur à configurer, pas de système d’exploitation à mettre à jour, pas de capacité à dimensionner manuellement. Le fournisseur cloud — AWS, Google Cloud, Azure — s’occupe de tout : le déploiement, la mise à l’échelle, la disponibilité. Le développeur écrit une fonction, la déploie, et elle s’exécute à chaque fois qu’elle est appelée.

Le nom est trompeur — il y a bien des serveurs quelque part. Mais du point de vue du développeur, ils sont invisibles. C’est un changement de paradigme : au lieu de penser en termes de machines, on pense en termes de fonctions et d’événements. On parle aussi de FaaS (Function as a Service) pour désigner ce modèle.

Comment fonctionne le serverless

Dans un modèle serveur classique, une application tourne en permanence sur une machine — qu’il y ait des requêtes à traiter ou non. Le serveur consomme des ressources et coûte de l’argent vingt-quatre heures sur vingt-quatre, même à trois heures du matin quand personne ne l’utilise.

En serverless, le fonctionnement est radicalement différent. Le code ne tourne pas en permanence — il est déclenché par un événement : une requête HTTP, un fichier déposé dans un espace de stockage, un message dans une file d’attente, une tâche planifiée. Le fournisseur cloud alloue les ressources nécessaires à l’exécution, exécute la fonction, puis libère les ressources. La facturation se fait au temps d’exécution réel — à la milliseconde — et au nombre d’invocations. Si la fonction n’est jamais appelée, le coût est nul.

Cette facturation à l’usage est l’un des avantages les plus immédiats pour une startup en phase de lancement. Un produit SaaS qui reçoit quelques centaines de requêtes par jour peut fonctionner pour quelques euros par mois en serverless, là où un serveur classique coûterait plusieurs dizaines d’euros par mois — même inactif.

Les principales plateformes serverless

Chaque grand fournisseur cloud propose sa propre plateforme serverless :

• AWS Lambda — le pionnier du marché, lancé en 2014. Le plus mature et le plus utilisé, avec un écosystème complet de services complémentaires (API Gateway, DynamoDB, S3, SQS). C’est souvent la référence quand on parle de serverless.
• Google Cloud Functions — l’équivalent chez Google Cloud, bien intégré avec Firebase, ce qui en fait un choix populaire pour les applications mobiles et les projets frontend avec un backend léger.
• Azure Functions — la solution Microsoft, particulièrement adoptée par les entreprises déjà dans l’écosystème Azure et .NET.
• Vercel Functions et Cloudflare Workers — des alternatives orientées edge computing, qui exécutent les fonctions au plus près des utilisateurs pour minimiser la latence. Vercel est particulièrement populaire dans l’écosystème Next.js et React.

Le choix de la plateforme dépend souvent de l’écosystème déjà en place et du framework utilisé côté application.

Les avantages du serverless

La mise à l’échelle automatique

C’est l’argument le plus puissant. Quand le nombre de requêtes augmente, le fournisseur cloud lance automatiquement de nouvelles instances de la fonction pour absorber la charge. S’il y a mille requêtes simultanées, mille instances s’exécutent en parallèle. Quand la charge redescend, les instances sont libérées. Le développeur n’a rien à configurer — la scalabilité est native.

Pour une startup en phase de growth hacking, cette élasticité est précieuse : un pic de trafic après un article viral ou une campagne de content marketing ne provoque pas de crash serveur.

L’absence de gestion d’infrastructure

Pas de serveur à maintenir signifie pas de mises à jour de sécurité à appliquer, pas de disques à surveiller, pas de processus à relancer quand ils tombent. L’équipe de développement peut se concentrer entièrement sur le code métier au lieu de consacrer du temps à l’administration système. Pour une petite équipe — un CTO seul ou un développeur full-stack — c’est un avantage considérable qui accélère le time-to-market.

Le coût optimisé pour les faibles trafics

La facturation à l’usage signifie qu’un MVP en phase de validation ne coûte quasiment rien tant qu’il n’a pas de trafic significatif. AWS Lambda offre un million d’invocations gratuites par mois dans son offre gratuite. Pour une startup en bootstrapping qui surveille son burn rate, cette économie sur l’infrastructure est un levier direct sur le runway.

Le déploiement rapide

Déployer une fonction serverless prend quelques secondes — le code est envoyé au fournisseur cloud et il est immédiatement disponible. Couplé à un pipeline de CI/CD, le déploiement peut être entièrement automatisé. Il n’y a pas de conteneur à construire, pas de serveur à redémarrer. Cette rapidité raccourcit le cycle de développement et permet d’itérer plus vite.

La haute disponibilité

Les fournisseurs cloud exécutent les fonctions serverless dans plusieurs centres de données simultanément. Si l’un tombe en panne, les requêtes sont automatiquement redirigées vers un autre. Cette résilience est incluse par défaut, sans configuration supplémentaire.

Les limites du serverless

Le démarrage à froid (cold start)

Quand une fonction n’a pas été appelée depuis un certain temps, le fournisseur cloud a libéré les ressources qui lui étaient allouées. La première requête qui arrive doit attendre que l’environnement d’exécution soit recréé — c’est le démarrage à froid (cold start). Cette latence — entre 100 millisecondes et plusieurs secondes selon le langage et la configuration — est invisible pour les traitements en arrière-plan, mais problématique pour les API temps réel où chaque milliseconde compte.

Les solutions existent : réserver des instances chaudes en permanence (provisioned concurrency sur AWS Lambda), utiliser des runtimes plus légers comme Node.js plutôt que Java, ou architecturer l’application pour que les chemins critiques ne passent pas par des fonctions froides. Mais ces optimisations ajoutent du coût et de la complexité, ce qui réduit partiellement l’avantage du modèle.

La durée d’exécution limitée

Les fonctions serverless ont une durée d’exécution maximale — quinze minutes sur AWS Lambda, par exemple. Les traitements longs — migration de données, génération de rapports complexes, entraînement de modèles de machine learning — ne peuvent pas s’exécuter en une seule invocation et doivent être découpés en étapes via des services d’orchestration (comme AWS Step Functions), ce qui ajoute de la complexité architecturale.

L’absence d’état

Chaque invocation d’une fonction serverless est indépendante — elle ne conserve rien en mémoire entre deux appels. Il n’y a pas de cache local, pas de variables partagées, pas de connexion persistante à une base de données. Toute donnée qui doit persister entre les invocations doit être stockée dans un service externe (base de données, cache distribué comme Redis), ce qui ajoute de la latence et de la complexité.

La dépendance au fournisseur (vendor lock-in)

Les fonctions serverless utilisent les services spécifiques de chaque fournisseur cloud — les files d’attente, le stockage, les bases de données, les déclencheurs. Cette intégration profonde crée une dépendance (vendor lock-in) : migrer d’un fournisseur à un autre implique de réécrire une partie significative du code et de l’architecture. Pour une startup qui construit un produit durable, cette dépendance est un facteur à évaluer lors de la due diligence technique.

Des frameworks comme Serverless Framework ou SST permettent d’abstraire une partie de cette dépendance, mais l’abstraction reste partielle dès qu’on utilise des services managés spécifiques.

Le debugging et l’observabilité

Débugger une fonction serverless est plus complexe qu’une application classique. L’exécution est éphémère, distribuée et déclenchée par des événements — reproduire un bug localement demande des outils spécifiques. Le monitoring et le suivi des erreurs nécessitent des solutions dédiées (AWS CloudWatch, Datadog, Sentry) et une approche structurée du logging pour suivre une requête à travers plusieurs fonctions.

Quand utiliser le serverless

Le serverless excelle dans certains cas d’usage et est mal adapté à d’autres. Choisir le bon outil pour le bon problème est plus important que de suivre la tendance.

Le serverless est adapté pour :

• Les traitements déclenchés par des événements — traitement d’images après un envoi, envoi d’e-mails transactionnels, notifications, webhooks
• Les intégrations avec des services tiers — paiement, signature électronique, synchronisation de CRM
• Les tâches planifiées — nettoyage de données, génération de rapports, synchronisation de systèmes
• Les API à faible ou moyen trafic, notamment les API REST ou GraphQL d’un MVP
• Les backends légers pour des applications frontend — formulaires, authentification, logique métier simple

Le serverless est moins adapté pour :

• Les API à fort trafic et faible latence, où le démarrage à froid est pénalisant
• Les traitements longs (plus de quelques minutes)
• Les applications qui nécessitent des connexions persistantes — comme le temps réel via WebSocket
• Les architectures qui demandent un contrôle fin sur l’environnement d’exécution

Serverless et conteneurs : deux approches complémentaires

Le serverless et les conteneurs (Docker, Kubernetes) ne sont pas en concurrence — ils répondent à des besoins différents et coexistent souvent dans la même architecture.

Les conteneurs offrent un contrôle total sur l’environnement d’exécution, pas de limite de durée, pas de démarrage à froid, et la possibilité de maintenir des connexions persistantes. En contrepartie, ils demandent une gestion d’infrastructure — dimensionnement, mise à jour, surveillance — que le serverless élimine.

En pratique, beaucoup de produits SaaS utilisent une approche hybride : les conteneurs pour l’API principale et les traitements critiques en termes de latence, le serverless pour les traitements asynchrones, les tâches planifiées et les intégrations événementielles. Cette combinaison permet de bénéficier des avantages de chaque modèle sans subir tous les inconvénients.

Le choix entre serverless et conteneurs dépend aussi de la maturité de l’équipe. Une équipe qui maîtrise Docker et Kubernetes peut préférer la prévisibilité des conteneurs. Un développeur solo ou une petite équipe sans expertise DevOps tirera davantage profit du serverless pour sa simplicité opérationnelle.

Serverless et architecture microservices

Le serverless s’intègre naturellement dans une architecture microservices. Chaque fonction serverless peut correspondre à un service isolé avec une responsabilité unique — créer un utilisateur, envoyer une notification, traiter un paiement. Cette granularité facilite le développement indépendant et le déploiement découplé.

Cependant, une architecture serverless avec des centaines de fonctions peut devenir difficile à maintenir si elle n’est pas structurée. Le risque de dette technique est réel si les conventions de nommage, la gestion des dépendances et la documentation ne sont pas rigoureuses dès le départ.

Comment Polara Studio utilise le serverless

Chez Polara Studio, le serverless fait partie de notre boîte à outils — mais il n’est pas la réponse à tous les problèmes.

Notre architecture type combine un backend principal en Node.js et TypeScript — conteneurisé et déployé sur une infrastructure maîtrisée — avec des fonctions serverless pour les cas où elles apportent un avantage réel : traitements d’images après envoi, tâches planifiées de nettoyage ou de reporting, intégrations avec des services tiers comme les plateformes de paiement. Le choix est guidé par le besoin technique, pas par la tendance — et chaque décision d’architecture est évaluée en fonction de son impact sur le coût, la performance et la maintenabilité du produit.