Serverless (FaaS)

Modèle d'exécution où le fournisseur cloud gère entièrement l'infrastructure et exécute des fonctions à la demande (FaaS), facturées selon l'usage réel.

En clair

Le serverless ne signifie pas « sans serveur » : les serveurs existent, mais leur gestion est entièrement déléguée au fournisseur cloud. Le développeur se concentre sur le code, sans se soucier du système d'exploitation, des correctifs ni du dimensionnement des machines. Dans sa forme la plus répandue, le « Function as a Service » (FaaS), on écrit des fonctions courtes déclenchées par un événement (un appel HTTP, un message déposé dans une file, un fichier ajouté à un stockage). La fonction s'exécute à la demande, traite l'événement, puis s'arrête. La facturation suit l'usage réel : on paie le temps d'exécution réellement consommé, pas une capacité réservée en permanence, et une fonction jamais appelée ne coûte rien.

Pourquoi c'est utilisé

Le serverless supprime la gestion des serveurs : ni provisionnement, ni mise à l'échelle manuelle, ni maintenance système. La montée en charge est automatique, le fournisseur lançant autant d'instances de la fonction que nécessaire pour absorber les requêtes simultanées, puis les arrêtant quand la charge retombe. Le modèle de coût à l'usage est avantageux pour des charges intermittentes ou imprévisibles, où réserver des serveurs en permanence serait du gaspillage. Pour de petites unités de traitement événementielles, on passe rapidement de l'idée à la production, sans investir dans une infrastructure à administrer. C'est un atout pour prototyper vite ou pour traiter des pics ponctuels sans surdimensionner en permanence.

En mission / dans la pratique

Le consultant utilise le serverless pour des traitements ponctuels, des tâches déclenchées par événement, des API légères ou de la glue entre services existants. Le quotidien consiste à écrire des fonctions ciblées, à gérer leurs déclencheurs, leurs droits d'accès et leurs variables d'environnement, et à instrumenter l'observabilité, plus délicate dans un contexte distribué et éphémère où aucune fonction ne reste en vie longtemps. Chez un grand compte, ces fonctions servent souvent à réagir à des événements internes (dépôt d'un fichier, message reçu) ou à automatiser des tâches d'exploitation, en complément des services principaux. Le consultant doit aussi composer avec les quotas et les limites du fournisseur, qui encadrent la taille, la durée et la mémoire de chaque exécution.

Pièges & bonnes pratiques

Attention au « cold start » : une fonction inactive depuis un moment peut subir une latence au premier appel, le temps que l'environnement d'exécution soit initialisé. Le serverless convient mal aux traitements longs ou très gourmands en état, car chaque fonction est plafonnée en durée et ne conserve rien d'une exécution à l'autre. L'adhérence à un fournisseur (vendor lock-in) est réelle, car les déclencheurs et les services associés sont souvent spécifiques à la plateforme. Gardez les fonctions petites et sans état, externalisez la persistance vers une base ou un stockage dédié, et soignez les délais d'attente, les reprises et la traçabilité. Pensez aussi à l'idempotence : un même événement pouvant déclencher plusieurs fois la fonction, le traitement doit tolérer les doublons.

À ne pas confondre

Le serverless est une alternative à l'exécution sur conteneurs orchestrés, pas son synonyme. Il s'intègre naturellement à une architecture événementielle et se déploie via la CI/CD et l'IaC.

ForTeam IT à vos côtés

Vous recherchez une mission ou un consultant expert sur ce sujet ? ForTeam IT met en relation des consultants IT freelance sélectionnés avec des grands comptes, ETI et scale-ups partout en France. Consultez aussi notre grille des TJM freelance IT et nos expertises par technologie.

Rejoindre la communauté