English
Le cloud computing a profondément changé la manière dont on conçoit et déploie des applications. Parmi les modèles qui se sont imposés ces dernières années, le Function as a Service (FaaS) représente une approche radicalement différente : au lieu de gérer des serveurs, des conteneurs ou même des plateformes complètes, les développeurs écrivent simplement des fonctions. Ces fonctions s'exécutent à la demande, ne consomment des ressources que pendant leur exécution, et disparaissent ensuite. Simple en apparence, ce modèle soulève pourtant des questions techniques, économiques et architecturales qu'il faut bien comprendre avant de l'adopter. Voici ce qu'il faut réellement savoir sur le FaaS, au-delà du discours marketing des fournisseurs cloud.
Définition et principes fondamentaux du FaaS
Le FaaS est un modèle d'exécution du cloud computing dans lequel un fournisseur prend en charge l'intégralité de l'infrastructure serveur. Le développeur déploie uniquement des fonctions : des blocs de code autonomes, chacun conçu pour accomplir une tâche précise. Ces fonctions ne tournent pas en permanence. Elles sont déclenchées par un événement spécifique (une requête HTTP, l'ajout d'un fichier dans un stockage, un message dans une file d'attente), s'exécutent, puis s'arrêtent.
Ce qui distingue le FaaS d'autres modèles comme le PaaS (Platform as a Service), c'est le niveau de granularité. On ne déploie pas une application entière, mais des unités fonctionnelles indépendantes. Chaque fonction peut avoir son propre langage, ses propres dépendances, et évoluer indépendamment des autres. Le fournisseur gère l'allocation des ressources, la mise à l'échelle et la disponibilité sans aucune intervention manuelle.
L'exécution de code basée sur les événements
Le FaaS repose sur un paradigme événementiel. Concrètement, une fonction ne fait rien tant qu'aucun événement ne la sollicite. Un utilisateur soumet un formulaire ? Une fonction traite les données. Un capteur IoT envoie une mesure ? Une fonction l'enregistre en base. Un fichier est déposé dans un bucket S3 ? Une fonction le redimensionne ou le convertit.
Ce modèle événementiel s'oppose au modèle traditionnel où un serveur tourne en continu, attendant des requêtes. Avec le FaaS, il n'y a aucun processus en attente. Le déclencheur peut être une requête API, un événement de base de données, un message dans un système de messagerie comme Kafka ou RabbitMQ, ou même un cron planifié. La diversité des sources d'événements rend le FaaS extrêmement flexible pour des architectures distribuées.
Le concept de Serverless et l'abstraction de l'infrastructure
Le FaaS est souvent présenté comme la forme la plus pure du Serverless. Bien sûr, des serveurs existent quelque part : le terme signifie simplement que le développeur n'a jamais à s'en soucier. Pas de provisionnement de machines virtuelles, pas de configuration de systèmes d'exploitation, pas de gestion de patchs de sécurité au niveau de l'OS.
L'abstraction va plus loin que le PaaS. Avec un PaaS comme Heroku ou Google App Engine, on déploie une application qui tourne en continu sur une plateforme gérée. Avec le FaaS, l'unité de déploiement est la fonction elle-même, et son cycle de vie est entièrement éphémère. Le fournisseur cloud s'occupe de tout ce qui se trouve sous la couche applicative : réseau, stockage temporaire, orchestration des conteneurs sous-jacents, répartition de charge. Le développeur se concentre exclusivement sur la logique métier.
Fonctionnement technique d'une architecture FaaS
Pour comprendre comment le FaaS fonctionne en pratique, il faut s'intéresser à ce qui se passe entre le moment où un événement survient et celui où la réponse est renvoyée. Ce mécanisme, invisible pour l'utilisateur final, implique plusieurs étapes gérées automatiquement par la plateforme.
Le cycle de vie d'une fonction : du déclenchement à l'arrêt
Lorsqu'un événement déclenche une fonction, la plateforme FaaS suit un processus en plusieurs phases. D'abord, elle identifie la fonction associée à l'événement. Si aucune instance de cette fonction n'est déjà chargée en mémoire, la plateforme en crée une : c'est l'initialisation, qui inclut le chargement du runtime (Node.js, Python, Java, Go, etc.), des dépendances et du code.
Ensuite, la fonction s'exécute. Elle reçoit l'événement en entrée, effectue son traitement, et renvoie un résultat ou déclenche une action. La durée d'exécution est limitée : la plupart des fournisseurs imposent un timeout maximal, généralement entre 5 et 15 minutes selon la plateforme. Une fois l'exécution terminée, l'instance peut rester "chaude" pendant quelques minutes pour traiter d'éventuelles requêtes suivantes, ou être supprimée si aucun nouvel appel ne survient.
Ce cycle crée un fonctionnement fondamentalement différent d'un serveur classique. Il n'y a pas de processus persistant. Chaque invocation est potentiellement indépendante, même si les plateformes réutilisent parfois les instances pour des raisons de performance.
La gestion de l'état et le modèle Stateless
Les fonctions FaaS sont conçues pour être sans état (stateless). Cela signifie qu'une fonction ne conserve aucune donnée entre deux invocations. Chaque appel repart de zéro : pas de variable globale persistante, pas de session en mémoire, pas de fichier temporaire garanti.
Cette contrainte a des implications architecturales majeures. Toute donnée qui doit persister entre deux appels doit être stockée dans un service externe : une base de données (DynamoDB, Firestore, PostgreSQL managé), un cache distribué (Redis, Memcached) ou un système de fichiers partagé. Les développeurs habitués à des frameworks web classiques comme Django ou Express doivent repenser leur approche. On ne peut pas stocker un panier d'achat dans la mémoire du serveur : il faut le placer dans un datastore externe.
Cette architecture stateless est aussi ce qui permet la mise à l'échelle horizontale. Puisque chaque instance de fonction est interchangeable, la plateforme peut en lancer des dizaines, des centaines ou des milliers en parallèle sans conflit d'état.
Avantages majeurs pour les développeurs et les entreprises
Le FaaS n'est pas qu'un concept technique élégant. Il apporte des bénéfices concrets qui expliquent son adoption croissante, aussi bien par des startups que par des grands groupes.
Scalabilité automatique et haute disponibilité
L'un des atouts les plus immédiats du FaaS est la mise à l'échelle automatique. Quand le trafic augmente, la plateforme lance automatiquement de nouvelles instances de la fonction pour absorber la charge. Quand le trafic diminue, les instances sont supprimées. Il n'y a aucune configuration de règles d'auto-scaling, aucun seuil à définir, aucune alarme à paramétrer.
Pour une entreprise qui gère des pics de trafic imprévisibles (un site e-commerce pendant les soldes, une application média lors d'un événement viral), cette élasticité est précieuse. Un service classique nécessiterait de provisionner des serveurs supplémentaires à l'avance ou de risquer une surcharge. Avec le FaaS, la plateforme s'adapte en temps réel. La haute disponibilité est aussi gérée par le fournisseur : les fonctions sont répliquées sur plusieurs zones de disponibilité, ce qui réduit les risques de panne.
Optimisation des coûts : le modèle de paiement à l'usage
Le modèle économique du FaaS est radicalement différent de l'hébergement traditionnel. On ne paie pas pour un serveur qui tourne 24 heures sur 24. On paie uniquement pour le temps d'exécution réel des fonctions, mesuré à la milliseconde, et pour le nombre d'invocations.
Prenons un exemple concret : une API qui traite 100 000 requêtes par mois avec un temps d'exécution moyen de 200 ms par requête. Sur AWS Lambda en 2026, cela coûte quelques euros par mois. Un serveur EC2 équivalent, même le plus petit, tournerait en continu et coûterait entre 15 et 30 euros mensuels. Pour des charges de travail intermittentes ou faibles, l'économie est significative. En revanche, pour des charges constantes et élevées, le calcul peut s'inverser : une fonction invoquée des millions de fois par jour peut finir par coûter plus cher qu'un serveur dédié.
Défis et limites à prendre en compte
Le FaaS n'est pas une solution miracle. Plusieurs contraintes techniques et organisationnelles méritent une attention sérieuse avant de migrer une architecture existante ou de construire un nouveau projet sur ce modèle.
Le problème du démarrage à froid (Cold Start)
Le cold start est le talon d'Achille du FaaS. Quand une fonction n'a pas été invoquée depuis un certain temps, la plateforme doit recréer une instance complète : charger le runtime, les bibliothèques, le code. Ce processus ajoute une latence qui peut aller de quelques dizaines de millisecondes (pour une fonction Python légère) à plusieurs secondes (pour une fonction Java avec de nombreuses dépendances).
En 2026, les fournisseurs ont fait des progrès considérables. AWS propose les "SnapStart" pour Java et les "Provisioned Concurrency" qui maintiennent des instances préchauffées. Google Cloud Functions et Azure Functions offrent des mécanismes similaires. Mais ces solutions ont un coût, et elles réduisent l'un des avantages principaux du FaaS : ne payer que pour l'exécution réelle. Pour des applications nécessitant des temps de réponse inférieurs à 50 ms de manière constante, le cold start reste un sujet de vigilance.
Complexité du débogage et dépendance au fournisseur
Déboguer une application FaaS est nettement plus complexe que déboguer une application monolithique. Les fonctions s'exécutent dans un environnement distant et éphémère. On ne peut pas attacher un débogueur classique, poser des breakpoints ou inspecter l'état de la mémoire en temps réel. Le débogage repose principalement sur les logs (CloudWatch, Stackdriver) et sur des outils de tracing distribué comme AWS X-Ray ou Jaeger.
La dépendance au fournisseur (vendor lock-in) est un autre point sensible. Chaque plateforme FaaS a ses propres formats d'événements, ses propres APIs de configuration, ses propres intégrations avec d'autres services. Une fonction écrite pour AWS Lambda ne se déploie pas directement sur Google Cloud Functions sans modifications. Des frameworks comme Serverless Framework ou le projet open source Knative tentent d'atténuer ce problème en proposant une couche d'abstraction, mais la portabilité totale reste un idéal difficile à atteindre en pratique.
L'observabilité pose aussi des difficultés. Avec des dizaines ou des centaines de fonctions qui s'appellent mutuellement, comprendre le flux d'une requête à travers le système demande des outils spécialisés et une discipline rigoureuse dans la structuration des logs.
Cas d'usage courants et applications pratiques
Le FaaS brille dans certains scénarios et s'avère moins pertinent dans d'autres. Identifier les bons cas d'usage est la clé pour tirer profit de ce modèle.
Traitement de données en temps réel et ETL
Le traitement événementiel de données est probablement le cas d'usage le plus naturel du FaaS. Un fichier CSV est déposé dans un bucket de stockage : une fonction le parse, le transforme et l'insère dans une base de données. Un flux de logs arrive via Kafka : des fonctions filtrent, enrichissent et routent les messages vers les bons systèmes.
Les pipelines ETL (Extract, Transform, Load) bénéficient particulièrement du modèle. Chaque étape du pipeline peut être une fonction indépendante, ce qui permet de les faire évoluer séparément et de les mettre à l'échelle en fonction du volume de données. Une entreprise française de retail qui traite les données de ventes de ses 200 magasins peut déclencher des fonctions à chaque transaction, agréger les résultats en quasi temps réel, et alimenter des tableaux de bord sans maintenir un cluster Spark en permanence.
Le traitement d'images et de vidéos est un autre cas classique : redimensionnement automatique de photos uploadées, génération de miniatures, extraction de métadonnées, application de filtres. Ces tâches sont ponctuelles, parallélisables et parfaitement adaptées au modèle FaaS.
Backends d'applications web et APIs mobiles
Le FaaS s'est aussi imposé comme une option viable pour construire des backends d'API. Couplé à un service de passerelle API (API Gateway), chaque endpoint peut être servi par une fonction distincte. L'endpoint /users/login est géré par une fonction d'authentification, /orders/create par une fonction de commande, etc.
Cette approche fonctionne bien pour des applications avec un trafic variable ou des APIs qui ne sont pas sollicitées en permanence. Une application mobile B2B utilisée principalement pendant les heures de bureau, par exemple, ne génère quasiment aucun trafic la nuit et le week-end. Avec le FaaS, le coût pendant ces périodes creuses tombe à zéro.
Les chatbots, les webhooks et les intégrations tierces (Slack, Stripe, Twilio) sont aussi des candidats naturels. Ces systèmes reçoivent des événements de manière imprévisible et doivent répondre rapidement sans nécessiter un serveur dédié. Plusieurs entreprises françaises du secteur fintech utilisent le FaaS pour gérer les notifications de paiement et les callbacks de leurs partenaires bancaires.
Panorama des principaux fournisseurs de solutions FaaS
Le marché du FaaS est dominé par les trois grands fournisseurs cloud, mais des alternatives existent pour ceux qui cherchent plus de flexibilité.
- AWS Lambda : le pionnier, lancé en 2014, reste le leader en parts de marché. Il supporte une dizaine de langages, s'intègre avec la quasi-totalité des services AWS, et offre les fonctionnalités les plus matures (Lambda@Edge pour le CDN, SnapStart pour Java, support des conteneurs). Son écosystème est le plus riche, mais c'est aussi là que le risque de vendor lock-in est le plus élevé.
- Google Cloud Functions : bien intégré avec Firebase, BigQuery et les services Google, il se distingue par sa simplicité de prise en main et ses performances sur les fonctions légères. La deuxième génération (Gen 2), basée sur Cloud Run, offre plus de flexibilité sur les durées d'exécution et les ressources allouées.
- Azure Functions : le choix naturel pour les entreprises déjà investies dans l'écosystème Microsoft. Il offre un mode "Durable Functions" pour orchestrer des workflows complexes avec gestion d'état, ce qui étend le FaaS au-delà de son modèle stateless habituel.
- Cloudflare Workers : une approche différente, basée sur des isolates V8 plutôt que sur des conteneurs. Les temps de démarrage à froid sont quasi inexistants (moins de 5 ms), ce qui en fait une option intéressante pour des fonctions edge à très faible latence.
- Knative et OpenFaaS : des solutions open source qui permettent de déployer du FaaS sur son propre cluster Kubernetes. Elles offrent une portabilité totale mais demandent de gérer l'infrastructure sous-jacente, ce qui annule une partie de la promesse serverless.
Le choix du fournisseur dépend de l'écosystème existant, des compétences de l'équipe et des contraintes de souveraineté des données. Pour les entreprises françaises soumises à des exigences réglementaires strictes, les offres de cloud souverain comme OVHcloud ou Scaleway commencent à proposer des fonctionnalités FaaS, même si elles restent en retrait par rapport aux hyperscalers américains en termes de maturité fonctionnelle.
Le Function as a Service a profondément modifié la manière dont les équipes techniques conçoivent leurs architectures. En supprimant la gestion de l'infrastructure et en introduisant un modèle de facturation à la milliseconde, il a rendu le cloud accessible à des projets qui n'auraient jamais justifié un serveur dédié. Mais le FaaS n'est pas adapté à tous les contextes : les applications à forte charge constante, les traitements de longue durée ou les systèmes nécessitant une latence ultra-faible trouveront parfois mieux ailleurs.
La bonne approche consiste à évaluer chaque composant de votre architecture indépendamment. Certaines parties gagneront à être déployées en FaaS, d'autres resteront mieux servies par des conteneurs ou des machines virtuelles. L'architecture hybride, où le FaaS cohabite avec d'autres modèles de déploiement, est souvent la plus pragmatique. Commencez par un cas d'usage simple (un webhook, un traitement d'image, une API peu sollicitée), mesurez les résultats, et élargissez progressivement si le modèle vous convient.
