Architecture serverless pour applications web : avantages, limites et mise en œuvre

Serverless : une révolution dans la façon de déployer du code

Le terme « serverless » est trompeur — il y a toujours des serveurs. Ce qui disparaît, c’est la responsabilité de les gérer. Dans une architecture serverless (ou FaaS, Function as a Service), vous déployez des fonctions individuelles qui s’exécutent à la demande, à la milliseconde, sans avoir à provisionner, configurer ou maintenir des serveurs. Le fournisseur cloud gère tout : l’infrastructure, la scalabilité, la disponibilité et la sécurité système.

AWS Lambda a popularisé le concept en 2014. Depuis, tous les grands fournisseurs cloud ont leur offre : Google Cloud Functions, Azure Functions, Cloudflare Workers, Vercel Edge Functions, Netlify Functions. Le marché serverless dépasse les 20 milliards de dollars et continue de croître solidement.

Comment fonctionne une fonction serverless

Une fonction serverless est un bloc de code qui :

1. S’exécute en réponse à un événement (requête HTTP, message dans une queue, modification en base de données, timer programmé)
2. Démarre en quelques millisecondes à quelques secondes (cold start)
3. S’exécute pendant quelques ms à quelques minutes maximum
4. Se termine et libère ses ressources
5. Se facture à la milliseconde d’exécution et au nombre d’invocations

Chaque invocation est indépendante et sans état (stateless). Si vous avez besoin de persister de l’état, vous utilisez un service externe : base de données, cache Redis, stockage objet.

Les avantages du serverless

Scalabilité automatique et illimitée

C’est l’avantage le plus souvent cité. Une fonction serverless peut passer de 0 à 100 000 invocations simultanées en quelques secondes, automatiquement, sans configuration. Un pic de trafic inattendu ne fait pas tomber votre application. Pour les applications à trafic variable, c’est une propriété extraordinairement précieuse.

Modèle de coût à l’usage

Vous ne payez que pour ce que vous consommez. AWS Lambda offre 1 million d’invocations gratuites et 400 000 GB-secondes par mois, puis facture environ 0,20 $ par million d’invocations supplémentaires. Pour les applications à faible trafic ou à trafic intermittent, le serverless peut être 10 à 100 fois moins cher qu’un serveur dédié.

Réduction de la charge opérationnelle

Pas de patches de sécurité à appliquer, pas de mise à jour du système d’exploitation, pas de monitoring d’infrastructure. L’équipe se concentre sur le code applicatif. Le time-to-market est aussi considérablement réduit : déployer une API serverless sur Vercel ou Netlify prend littéralement cinq minutes.

Les limites à connaître avant de se lancer

Cold starts

Une fonction qui n’a pas été invoquée récemment doit être « démarrée » — c’est le cold start. Selon le fournisseur, le runtime et la taille de la fonction, ce délai varie de quelques dizaines de millisecondes (Cloudflare Workers) à plusieurs secondes (AWS Lambda avec des runtimes lourds comme Java). Pour les APIs avec des SLA de latence stricts, les cold starts peuvent être problématiques. Les solutions : Provisioned Concurrency sur Lambda, ou le passage aux edge functions (Cloudflare Workers, Vercel Edge).

Durée d’exécution limitée

Les fonctions serverless ont des timeouts stricts : 15 minutes maximum sur AWS Lambda, 30 secondes sur Vercel, 50 ms sur Cloudflare Workers. Les traitements longs (génération de vidéo, exports massifs de données) ne sont pas adaptés au serverless standard.

État distribué et debugging complexe

Les fonctions étant stateless et distribuées, le debugging et le tracing de bout en bout sont plus complexes. Les outils comme AWS X-Ray, Datadog ou Sentry s’adaptent au contexte serverless, mais la courbe d’apprentissage est réelle. Les tests en local sont aussi moins représentatifs de l’environnement de production.

Vendor lock-in

Chaque fournisseur a ses spécificités d’API, de configuration et de limites. Migrer d’AWS Lambda vers Google Cloud Functions nécessite des adaptations. Les frameworks comme SST (Serverless Stack) ou le Serverless Framework abstraient une partie de cette dépendance.

Cas d’usage idéaux pour le serverless

• APIs REST et GraphQL à trafic variable ou imprévisible
• Traitement d’événements : webhook handlers, traitement de formulaires, intégrations Stripe ou Twilio
• Tâches programmées : cron jobs dans le cloud sans serveur dédié
• Traitement de fichiers : resize d’images à l’upload, conversion de documents, génération de PDF
• Fonctions backend pour applications Jamstack
• APIs de MVP et prototypes : déploiement rapide, coût minimal pendant la phase de validation

Exemple concret : API de traitement d’image avec Vercel Functions

// api/resize.js (Vercel Serverless Function)
import sharp from 'sharp';

export default async function handler(req, res) {
  const { url, width = 800 } = req.query;
  const response = await fetch(url);
  const buffer = Buffer.from(await response.arrayBuffer());

  const resized = await sharp(buffer)
    .resize(parseInt(width))
    .webp({ quality: 80 })
    .toBuffer();

  res.setHeader('Content-Type', 'image/webp');
  res.setHeader('Cache-Control', 's-maxage=86400');
  res.send(resized);
}

Ce handler transforme n’importe quelle image en WebP redimensionné, à la demande, sans serveur permanent. La fonction se déclenche uniquement lors des requêtes, se scale automatiquement et ne coûte rien quand personne ne l’utilise.

Erreurs fréquentes à éviter

• Fonctions trop larges : une fonction serverless doit avoir une responsabilité unique. Une fonction « fourre-tout » de 500 lignes trahit une mauvaise décomposition
• Connexions base de données mal gérées : chaque invocation qui ouvre une connexion peut saturer le pool. Utilisez PgBouncer, RDS Proxy ou Supabase Connection Pooler
• Ignorer les coûts à grande échelle : le serverless est économique à faible volume mais peut devenir coûteux à très haute fréquence d’invocations
• Ne pas monitorer les erreurs : les erreurs dans les fonctions serverless sont silencieuses sans alerting configuré. Sentry ou Datadog doivent être intégrés dès le début
• Secrets mal gérés : ne jamais hardcoder des clés API dans le code. Utilisez les variables d’environnement de votre plateforme

Conclusion

L’architecture serverless représente une évolution majeure dans le déploiement d’applications web. Elle n’est pas adaptée à tous les cas, mais pour les APIs à trafic variable, les traitements événementiels et les projets où la vélocité de déploiement est critique, elle offre un rapport productivité/coût difficile à égaler. Commencez par une fonction simple — un webhook handler ou une API CRUD basique — pour maîtriser l’approche avant de l’étendre.