Serverless
Définition
Modèle d'hébergement où les fonctions sont exécutées à la demande sans gérer de serveur. Facturation à l'usage, scalabilité automatique. Exemples : Vercel Functions, AWS Lambda.
Comment ça marche
Serverless est un modèle d'hébergement où les fonctions sont exécutées à la demande, sans gérer de serveur persistant. Vous écrivez une fonction (HTTP handler, traitement d'événement, webhook), vous la déployez, et le fournisseur s'occupe de tout : provisioning, scaling automatique, mises à jour OS, monitoring de base. Lorsqu'une requête arrive, l'infrastructure démarre un container léger en quelques centaines de millisecondes (cold start) ou réutilise un container existant (warm). La fonction tourne, renvoie sa réponse, puis le container reste disponible quelques minutes avant d'être recyclé. Vous payez à la requête et à la durée d'exécution, pas pour l'idle.
À quoi ça sert
Le serverless brille sur les charges irrégulières. Pic lié à un lancement marketing ? L'infrastructure scale automatiquement de 1 à 1000 instances en quelques secondes, puis revient à 0 quand le pic retombe. Traitement de fichiers utilisateurs déclenché par upload S3. Webhooks Stripe ou GitHub avec volume imprévisible. APIs publiques avec trafic irrégulier selon les heures. Tâches asynchrones (envoi d'email, traitement d'image) déclenchées par une file de messages. Pour un MVP ou un produit qui n'a pas encore de trafic constant, c'est imbattable : on ne paye que ce qu'on consomme réellement.
Les acteurs
AWS Lambda reste la référence historique, avec l'écosystème le plus mature mais aussi le plus complexe à prendre en main. Vercel Functions et Netlify Functions enveloppent Lambda dans une expérience développeur simplifiée, intégrée au framework (Next.js, SvelteKit). Cloudflare Workers utilise une architecture V8 isolates qui démarre en quelques millisecondes, idéale pour le edge. Google Cloud Functions et Azure Functions ciblent les équipes déjà dans ces écosystèmes. Pour Python et data science, Modal et Beam offrent du serverless GPU. Le choix dépend du langage, du cas d'usage et de l'écosystème existant.
Le cold start
Le cold start est le délai entre l'arrivée d'une requête sur un container froid et l'exécution effective de la fonction. Sur Lambda Node, ça varie de 100 ms (fonction simple) à 2 secondes (gros bundle avec dépendances lourdes). Sur Cloudflare Workers, c'est 5 ms (V8 isolates), pratiquement invisible. Sur Python avec Lambda, on monte facilement à 3-5 secondes. C'est problématique pour les API critiques avec trafic faible (le premier utilisateur attend longtemps). On l'atténue avec provisioned concurrency (containers pré-chauffés, à un coût supplémentaire), un bundle léger, ou un runtime edge qui contourne le problème.
Quand l'utiliser
On choisit serverless pour : MVP et POC où le trafic est inconnu, webhooks et événements ponctuels, traitements asynchrones déclenchés à la demande, API à trafic irrégulier, fonctions très isolées avec peu de dépendances. Le scaling automatique gère les pics sans intervention, on ne paie rien pendant les périodes creuses. Combiné à un framework moderne (Next.js sur Vercel, Hono sur Cloudflare), l'expérience développeur est excellente : déploiement en quelques secondes par push Git. Pour 80% des SaaS B2B en phase MVP à scale-up, c'est le choix par défaut.
Quand ne pas l'utiliser
On évite serverless pour les charges constantes et soutenues (un site avec 100 requêtes/seconde 24/7) où un serveur classique sera 5 à 10 fois moins cher. Pour les jobs longs au-delà de 15 minutes (Lambda max), c'est éliminatoire. Pour les connexions persistantes (WebSocket serveur stateful, long polling) le modèle ne tient pas. Pour les apps avec base de données accédée massivement, le nombre élevé de connexions concurrentes sature le pool : il faut un pooler (PgBouncer, Supavisor, Data Proxy Prisma). Pour les calculs lourds (ML inference, traitement vidéo), le coût grimpe vite, on préfère un GPU dédié ou un service spécialisé.
Les pièges à éviter
Le coût explose quand on a un trafic constant : à 10 000 requêtes/heure 24/7, on peut payer 10 fois plus qu'un VPS équivalent. On surveille la facture mensuelle. Les bundles trop gros ralentissent les cold starts : on évite les libs inutiles, on tree-shake agressivement. La gestion des connexions DB nécessite un pooler côté base, sinon on sature. Les variables d'environnement contenant des secrets doivent passer par un vault (AWS Secrets Manager, Vercel Encrypted), pas en clair. Et on teste systématiquement le comportement sous charge avant la production : un cold start mal anticipé peut faire planter un service le jour du lancement.