Le sans serveur vous permet de vous concentrer sur le code et non sur l'infrastructure.
L'informatique sans serveur (souvent appelée Function-as-a-Service ou FaaS) vous permet d'exécuter du code sans provisionner ni gérer de serveurs. Vous téléchargez votre code et le fournisseur de cloud s'occupe de tout : configuration du serveur, mise à l'échelle, maintenance et planification de la capacité. Selon un rapport Datadog de 2025, l'adoption du sans serveur a augmenté de 150 % depuis 2022, AWS Lambda traitant des milliards d'exécutions chaque mois.
Sans serveur ne signifie pas qu’il n’y a pas de serveurs, cela signifie que vous ne les gérez pas. Chez x13apps, nous utilisons le sans serveur pour des cas d'utilisation spécifiques où ses avantages dépassent ses limites. Voici ce que vous devez savoir.
Comment fonctionne le sans serveur
Vous écrivez une fonction (une unité de code qui exécute une seule tâche), configurez le moment où elle doit s'exécuter (déclenchée par une requête HTTP, un téléchargement de fichier, une modification de base de données ou une planification) et la déployez sur une plate-forme sans serveur. La plate-forme maintient la fonction prête à être exécutée, la fait évoluer automatiquement en fonction de la demande et ne facture que le temps de calcul utilisé, mesuré en millisecondes. Lorsque la fonction ne fonctionne pas, vous ne payez rien.
Les principales plates-formes sans serveur incluent AWS Lambda, Google Cloud Functions, Azure Functions et Cloudflare Workers. Chacun prend en charge plusieurs langages de programmation et s'intègre à d'autres services cloud. Les fonctions sans serveur ont généralement des limites de temps d'exécution (15 minutes sur AWS Lambda) et une exécution sans état, ce qui signifie que chaque appel recommence sans mémoire des appels précédents.
Quand utiliser le sans serveur
Le sans serveur excelle pour les charges de travail basées sur des événements : traitement des téléchargements de fichiers (redimensionnement des images, génération de vignettes), gestion des webhooks de services tiers, exécution de tâches planifiées (génération de rapports quotidiens, nettoyage des données), création d'API légères et gestion du trafic variable ou imprévisible. Le sans serveur est également excellent pour les prototypes et les MVP : vous pouvez créer et déployer rapidement sans configuration d'infrastructure.
Le sans serveur est moins adapté aux processus de longue durée, aux applications nécessitant des connexions persistantes (WebSockets), aux charges de travail avec un trafic élevé prévisible où la capacité réservée est moins chère et aux applications avec une sensibilité au démarrage à froid (le premier appel après une inactivité a un délai de 100 ms à plusieurs secondes).
Modèle de coût et mise à l’échelle
La tarification sans serveur est basée sur le nombre d'exécutions, la durée d'exécution (en millisecondes) et la mémoire allouée. Pour un trafic faible à modéré, le sans serveur est souvent moins cher que l’hébergement traditionnel. Pour un trafic très élevé et constant, un serveur provisionné peut être plus rentable. Le sans serveur évolue automatiquement de zéro à des milliers d'exécutions simultanées, gérant ainsi les pics de trafic sans aucune configuration.
Le défi réside dans les coûts imprévisibles. Un bug qui déclenche des tentatives infinies ou un pic de trafic provenant d'une publication virale peut générer des factures inattendues. Configurez des alertes budgétaires et demandez des limites de limitation. Utilisez des outils d'observabilité (AWS X-Ray, Datadog) pour surveiller les performances et les coûts des fonctions. Le sans serveur est un outil puissant dans le bon contexte : chez x13apps, nous aidons les clients à déterminer sa place dans leur architecture. Pour en savoir plus sur l'infrastructure cloud, lisez notrecomparaison d'hébergement cloud.