Le serverless est un modèle de développement cloud qui permet aux développeurs de créer et d’exécuter des applications sans avoir à gérer l’infrastructure sous-jacente (serveurs, OS, etc.). Le fournisseur de cloud se charge de tout, y compris la mise à l’échelle, la gestion des serveurs, et la haute disponibilité. Mais par où commencer ? Quelle plateforme cloud choisir ? Pour quels usages ? Découvrez les bonnes pratiques, les pièges à éviter, et suivez pas à pas notre feuille de route…
Le serverless s’impose aujourd’hui comme une tendance majeure du cloud computing. De plus en plus d’organisations adoptent ce modèle pour gagner en agilité et réduire leurs coûts d’infrastructure.
Le marché du serverless pèse environ 25 milliards de dollars en 2025, porté par la demande d’agilité et de réduction des coûts. Pour les DSI, il s’agit d’un levier stratégique, mais aussi d’un défi à maîtriser.
Selon un rapport Datadog de 2023, la majorité des entreprises utilisant AWS ou Google Cloud ont déjà au moins un déploiement serverless, et près de la moitié des utilisateurs d’Azure en font de même.
Mais qu’est-ce que le serverless exactement, d’où vient-il et que change-t-il pour les professionnels de l’IT ?
Le serverless : qu’est-ce que c’est ?
Le serverless est un modèle de développement cloud-native qui permet de créer et d’exécuter des applications sans avoir à gérer de serveurs physiques ou virtuels.
Contrairement à ce que le terme suggère, il ne s’agit pas d’une absence totale de serveurs, mais plutôt d’une abstraction complète de leur gestion : le fournisseur cloud prend en charge le provisionnement (préparation et configuration des ressources matérielles et logicielles nécessaires), la maintenance, la mise à l’échelle et la disponibilité de l’infrastructure sous-jacente.
Le développeur se concentre exclusivement sur le code et la logique métier, qu’il empaquette souvent sous forme de fonctions ou de conteneurs. L’application s’exécute à la demande, en réponse à des événements, et la facturation s’effectue à l’usage réel, ce qui optimise les coûts, notamment pour les charges de travail irrégulières ou imprévisibles.
Différence avec le cloud computing standard
Dans un modèle standard de cloud computing comme l’IaaS (Infrastructure-as-a-Service), les utilisateurs achètent à l’avance des unités de capacité. Ils paient un fournisseur de cloud public pour des composants de serveur actifs en permanence pour l’exécution de leurs applications. Il leur incombe d’utiliser et d’augmenter la capacité du serveur pendant les périodes de forte demande et de la réduire lorsque cette capacité n’est plus nécessaire. L’infrastructure cloud reste active même lorsque l’application n’est pas utilisée, ce qui peut entraîner des coûts.
Le serverless, en revanche, est un modèle d’exécution orienté événements. Les applications répondent à la demande et s’adaptent automatiquement en fonction des besoins. Lorsqu’une fonction serverless est inactive, elle ne coûte rien. Le fournisseur de cloud gère l’infrastructure, y compris la mise à l’échelle et la maintenance. L’objectif principal est de permettre aux développeurs de se concentrer sur le code de leurs applications tandis que le fournisseur gère l’infrastructure sous-jacente.
Les applications serverless sont déployées dans des conteneurs qui démarrent automatiquement sur simple demande.
Les différents types d’informatique serverless
Le serverless se décline principalement en deux catégories :
Le Function as a Service (FaaS) est souvent considéré comme le cœur du serverless – il s’agit de déployer des fonctions applicatives déclenchées par des événements, exécutées de façon éphémère et stateless (sans état) dans des conteneurs temporaires. Le code côté serveur reste à la charge du développeur, mais son exécution est gérée par la plateforme cloud dans des conteneurs qui ne conservent aucune donnée entre deux appels. Cela signifie qu’à chaque invocation, la fonction démarre dans un environnement vierge, ce qui impose de penser des tâches courtes ne dépendant pas de données en mémoire locale persistante.
Le Backend-as-a-Service (BaaS) quant à lui, désigne les services backend prêts à l’emploi fournis par un tiers. Par exemple, des services gérés de base de données, d’authentification, de stockage de fichiers, de messagerie en temps réel, etc., où le développeur consomme une API sans avoir à déployer lui-même ces composants.
Quelles sont les origines du serverless ?
Le concept de serverless est le fruit d’une évolution progressive dans le monde du cloud. Bien avant que le terme ne devienne populaire, l’idée de délester les développeurs de la gestion serveur existait déjà sous d’autres formes.
Platform as a Service (PaaS), par exemple, offrait dès la fin des années 2000 un avant-goût du serverless en proposant de déployer des applications sans gérer l’infrastructure (Google App Engine dès 2008, ou Heroku). Cependant, le terme “serverless” lui-même n’apparaît que plus tard pour désigner une approche encore plus granulaire et événementielle du cloud computing.
Le tournant décisif survient en 2014 lorsque Amazon Web Services lance AWS Lambda. Pour beaucoup, c’est le point de départ concret du serverless tel qu’on le conçoit aujourd’hui. AWS Lambda introduit un modèle d’exécution de fonctions à la demande, déclenchées par des événements, avec une facturation à l’invocation et un autoscaling complètement transparent. Plus besoin de démarrer ni d’arrêter des VM – le code tourne dans un conteneur éphémère géré par AWS et passe à l’échelle automatiquement.
Depuis, l’écosystème serverless n’a cessé de se développer. De nouveaux services ont émergé pour compléter l’exécution de fonctions : par exemple, des bases de données serverless (AWS DynamoDB en mode on-demand, Azure Cosmos DB serverless), du traitement de flux (AWS Kinesis, Google Cloud Pub/Sub + Functions) ou encore des orchestrateurs sans serveur (AWS Step Functions, Azure Logic Apps).
Des solutions open source ont également vu le jour (OpenFaaS, Apache OpenWhisk utilisé par IBM Cloud) pour permettre le serverless hors des grands clouds.
Quels sont les avantages du serverless ?
Si le serverless connaît un tel succès, c’est qu’il apporte de nombreux avantages aux équipes de développement et aux entreprises. En voici les principaux bénéfices :
– Aucune gestion de serveur, plus de focus sur l’application. Le premier avantage, évident, est de libérer les développeurs des tâches d’administration système. Plus besoin de configurer ni maintenir des machines, des correctifs OS ou des middleware – le cloud s’en charge. L’équipe peut ainsi se concentrer sur la logique applicative, les fonctionnalités et l’expérience utilisateur, ce qui accélère le développement.
– Scalabilité automatique et élasticité. Les fonctions et services serverless s’adaptent automatiquement à la charge. Qu’il y ait 10 requêtes par jour ou 10 millions, la plateforme alloue dynamiquement les instances nécessaires pour traiter les demandes en parallèle. Cette élasticité instantanée est un atout majeur pour absorber les pics de trafic imprévus sans intervention manuelle. Par exemple, un site web e-commerce hébergé via une API Gateway + fonctions Lambda pourra encaisser un pic de visites lors du Black Friday sans que les développeurs aient à prévoir du surcapacitaire – les fonctions se multiplient à la demande. Inversement, en période creuse, aucune ressource ne tourne inutilement. Le dimensionnement est toujours “juste ce qu’il faut”, ce qui améliore la disponibilité du service sans effort particulier en architecture.
– Paiement à l’usage, optimisation des coûts. Le modèle économique du serverless est généralement le pay-per-use, c’est-à-dire facturé à la demande, à la consommation réelle. Contrairement à un serveur classique facturé à l’heure (même s’il ne fait rien), une fonction serverless ne coûte quelque chose que lorsqu’elle s’exécute. Ainsi, “les ressources ne sont jamais inactives, elles ne s’activent qu’à la demande”. Le client ne paye que pour les ressources réellement utilisées (temps CPU, mémoire, nombre d’appels), et non pour du temps d’inactivité. Ce modèle peut engendrer des économies substantielles, en particulier pour les charges de travail intermittentes ou imprévisibles. Par exemple, une application dont l’activité est très variable dans le temps coûte beaucoup moins cher en serverless qu’avec un serveur alloué en permanence.
– Performance et rapidité de mise en œuvre. Les plateformes serverless tirent parti des capacités des clouds pour offrir des temps de réponse très courts. La mise en route d’une fonction est quasi instantanée (quelques millisecondes pour un conteneur “chaud”), et même en cas de démarrage à froid d’une nouvelle instance, le délai reste très faible dans la plupart des environnements (notamment avec des langages interprétés). Par ailleurs, comme de nombreux composants sont déjà pris en charge par le fournisseur (équilibrage de charge, CDN, authentification, etc. via des services managés), le temps nécessaire pour développer et déployer une nouvelle application est réduit. On peut passer de l’idée à un prototype fonctionnel en quelques heures. Par exemple, un développeur peut coder et déployer en quelques minutes une API REST complète en utilisant AWS Lambda et API Gateway, là où configurer une stack serveur traditionnelle aurait pris des jours. La rapidité de provisioning du serverless (pas de délai de commande de serveur ou de démarrage de VM) permet une grande vélocité en développement.
En outre, le serverless encourage de bonnes pratiques DevOps : infrastructure as code (IaaS), déploiements fréquents, et une étroite collaboration entre dev et ops. Les développeurs sont incités à adopter une approche “DevOps sans serveur”, où ils intègrent l’infrastructure (bien que gérée par le cloud) directement dans leur cycle de développement via des frameworks (Serverless Framework, AWS SAM, Terraform, etc.). La barrière à l’entrée opérationnelle étant plus faible, on observe souvent une culture DevOps renforcée et une démocratisation de la mise en production. Par exemple, un développeur peut facilement inclure la configuration d’une fonction et de ses déclencheurs dans le même dépôt de code que l’application, favorisant l’autonomie et la responsabilité sur l’ensemble du cycle de vie.
– Haute disponibilité et tolérance aux pannes. Par construction, les services serverless sont distribués sur l’infrastructure du fournisseur cloud, qui assure la redondance. Une fonction déployée est généralement répliquée sur plusieurs zones pour être tolérante aux pannes matérielles. Les fournisseurs garantissent souvent une disponibilité élevée (par exemple AWS Lambda est déployé sur plusieurs zones de disponibilité par défaut). Le développeur n’a pas d’effort supplémentaire à fournir pour bénéficier de cette robustesse. De plus, la nature stateless facilite le basculement en cas de problème : une instance de fonction qui échoue n’affecte pas les autres appels, et les systèmes d’orchestration peuvent automatiquement relancer des exécutions en échec. En couplant avec d’autres services managés (base de données répliquée, stockage objet durable, etc.), on obtient une architecture intrinsèquement résiliente aux pannes régionales ou matérielles, sans avoir à configurer du failover manuellement.
– Efficacité et écoconception. Le fait de n’utiliser que les ressources strictement nécessaires a un bénéfice écologique et technique. Sur le plan technique, cela élimine les ressources oisives : l’infrastructure est mutualisée au maximum entre clients et allouée à la volée, ce qui améliore l’efficacité globale des data centers. Du point de vue d’une démarche d’écoconception logicielle, le serverless évite de faire tourner en continu des serveurs peu utilisés, donc contribue à réduire le gaspillage d’énergie. Les grands fournisseurs optimisent fortement leurs installations pour la consommation énergétique, si bien que déléguer son calcul à ces plateformes peut diminuer l’empreinte carbone de son application. C’est un argument de plus en plus prisé : une application serverless bien conçue minimise l’utilisation de CPU et de mémoire, ce qui, multiplié à l’échelle, a un impact environnemental moindre.
Naturellement, ces avantages s’accompagnent de contreparties et limites (détaillées plus loin dans les pièges à éviter). Mais dans de nombreux scénarios, les gains en productivité, en coût et en flexibilité font du serverless un choix attractif par rapport aux architectures traditionnelles sur serveurs dédiés ou même aux conteneurs managés.
Par où commencer ?
Devant les promesses du serverless, on peut être tenté de l’adopter immédiatement. Cependant, il est important de démarrer de manière réfléchie. Par où commencer lorsqu’on veut se lancer dans le serverless ? La première étape consiste à bien comprendre le concept et ses cas d’usage. Il est recommandé de se documenter sur le fonctionnement des fonctions serverless, leurs modèles d’événements, et de parcourir les exemples fournis par les grands fournisseurs (AWS, Azure, GCP) pour cerner en quoi cette architecture diffère d’une approche classique. En d’autres termes, il faut adopter le “state of mind” serverless : penser événementiel, stateless, et appréhender que l’on ne dispose plus d’un serveur permanent pour stocker des sessions ou des fichiers temporaires, par exemple.
Ensuite, il convient d’identifier un premier cas d’utilisation simple et approprié pour faire ses armes. Plutôt que de basculer directement toute une application critique en serverless, il est judicieux de choisir un projet pilote à petite échelle. Par exemple, cela peut être le développement d’une petite API interne, d’un script d’automatisation planifié ou d’un traitement de données isolé. L’objectif est de se familiariser avec le cycle développement-déploiement et les spécificités (gestion des logs, surveillance, gestion des permissions) sans risque majeur. Idéalement, ce premier projet doit avoir des caractéristiques propices au serverless : une charge variable ou rare (pour bénéficier du pay-per-use), pas de besoin de conserver un état en mémoire entre deux exécutions, et des performances non critiques à la milliseconde près (afin de tolérer d’éventuels démarrages à froid). Un exemple courant est la création d’un petit service de génération de rapports PDF déclenché à la demande, ou d’une fonction qui s’exécute chaque nuit pour nettoyer une base de données – des tâches bien circonscrites et adaptées au modèle sans serveur.
Enfin, par où commencer implique aussi de préparer son environnement de développement. Cela signifie généralement : ouvrir un compte chez un fournisseur cloud (ou réutiliser celui de son entreprise), installer les outils en ligne de commande appropriés (par exemple AWS CLI, Azure CLI, Google Cloud SDK) et éventuellement un framework de déploiement. La plupart des plateformes offrent des paliers gratuits ou de très faibles coûts pour débuter, ce qui permet d’expérimenter sans contrainte budgétaire. Par exemple, AWS Lambda propose un million d’invocations gratuites par mois, ce qui est largement suffisant pour les tests initiaux. Il est donc recommandé de tirer profit de ces free tiers. En résumé, on commence par se former, choisir un petit projet, se doter des outils et comptes nécessaires, puis on peut passer à l’action concrète.
Comment débuter avec le serverless : feuille de route en plusieurs étapes
Une fois les bases posées et un cas d’usage cible identifié, il est temps de passer à la pratique. Pour guider vos premiers pas, voici une feuille de route étape par étape afin de débuter efficacement en serverless. Ce parcours progressif vous aidera à monter en compétence et à éviter les écueils courants :
Étape 1 : Choisir son fournisseur et son environnement
Commencez par sélectionner la plateforme serverless la plus pertinente pour vous. Le choix dépend souvent de votre contexte : si votre entreprise est déjà très présente sur AWS, AWS Lambda sera un choix naturel; si vous travaillez dans un environnement Microsoft, Azure Functions s’intègre bien; pour des besoins spécifiques ou un attachement à Google Cloud, Google Cloud Functions ou Cloud Run seront appropriés. Chaque grand cloud a ses atouts, mais pour débuter, ils offrent tous des documentations riches et des exemples prêts à l’emploi. Après ce choix, assurez-vous d’installer les outils de développement correspondants (CLI, SDK) et de configurer vos identifiants d’accès (clés API, etc.). Préparez aussi votre environnement local avec le langage que vous allez utiliser (Python, Node.js, C#, etc. – choisissez un langage supporté que vous maîtrisez déjà, afin de ne pas cumuler l’apprentissage du serverless avec celui d’un nouveau langage).
Étape 2 : Déployer une première fonction “Hello World”
Lancez-vous avec un exemple minimal pour valider votre chaîne de développement et comprendre le cycle complet. Par exemple, créez une petite fonction qui retourne simplement un message “Hello World” ou la date du jour. Utilisez la console web du fournisseur ou les outils en ligne de commande pour déployer cette fonction. Sur AWS Lambda, cela peut se faire directement via la console en quelques clics, ou via la commande aws lambda create-function. Sur Azure, vous pouvez utiliser VS Code avec l’extension Azure Functions pour initier un projet de fonction local et le publier. Le but de cette étape est de vérifier que vous savez packager votre code, le déployer et l’exécuter dans le cloud. Testez l’invocation de votre fonction : par exemple, si c’est une fonction HTTP, appelez son URL publique; si c’est une fonction déclenchée par événement, utilisez un mécanisme de test (AWS Lambda offre un outil de test dans la console). Une fois que “Hello World” fonctionne, vous avez déjà franchi un cap psychologique important : votre code s’exécute “quelque part dans le cloud” sans que vous ayez configuré de serveur !
Étape 3 : Ajouter un déclencheur et intégrer un service
Enrichissez votre exemple en lui adjoignant un événement déclencheur réel et éventuellement une intégration à un service cloud. Par exemple, connectez votre fonction à une API Gateway pour la déclencher par une requête HTTP REST (cas typique pour créer une API serverless). Ou bien configurez un déclencheur temporel (un cron) si votre fonction doit tourner de façon planifiée – sur Azure Functions, c’est un Timer Trigger facile à configurer, sur AWS vous utilisez EventBridge (anciennement CloudWatch Events) pour programmer l’exécution. Vous pourriez également lier votre fonction à un événement de stockage : par exemple, une image déposée dans un bucket S3 qui déclenche automatiquement une fonction Lambda de traitement d’image. Profitez de cette étape pour appeler depuis la fonction un service managé, comme une base de données ou une API externe, afin de comprendre comment gérer les appels sortants et les permissions. Par exemple, votre fonction pourrait écrire un enregistrement dans DynamoDB (base NoSQL AWS) ou dans Firestore sur GCP, ou envoyer un message dans une file d’attente (Azure Service Bus, AWS SQS). Vous apprendrez ainsi à configurer les rôles de sécurité (IAM sur AWS, Identity/Access Management équivalent sur GCP/Azure) pour donner à votre fonction les droits nécessaires, sans ouvrir plus que de raison. Cette étape consolide votre maîtrise des interactions entre la fonction et l’écosystème.
Étape 4 : Structurer et déployer via un framework
Une bonne pratique dès que l’on dépasse une simple fonction est d’automatiser le déploiement via du code descriptif (Infrastructure as Code). Appropriez-vous un outil comme Serverless Framework, AWS SAM (Serverless Application Model), Terraform, ou l’outil natif de votre cloud (Azure ARM/Bicep, Google Cloud Deployment Manager). Reprenez votre projet et transformez-le pour que la configuration (déclencheurs, ressources liées) soit décrite dans un fichier (YAML, JSON ou HCL selon l’outil) et que le déploiement complet puisse être fait par une seule commande. Par exemple, avec Serverless Framework, vous écrivez un fichier serverless.yml qui définit la fonction, son runtime, et l’événement qui la déclenche, puis la commande serverless deploy crée tout automatiquement. Cette étape peut sembler un effort supplémentaire, mais elle vous habitue à gérer proprement votre code + configuration de manière versionnée, et facilitera énormément l’évolution vers plusieurs fonctions et environnements (staging, production). C’est aussi le moment d’organiser votre code en modules, de gérer les dépendances (par exemple, utiliser un requirements.txt en Python ou un package.json en Node.js pour embarquer les librairies nécessaires à la fonction).
Étape 5 : Tester, monitorer et optimiser
Une fois votre fonction (ou petit ensemble de fonctions) déployée via un framework, assurez-vous de mettre en place les outils de test et de monitoring adéquats. Testez localement si possible : la plupart des frameworks offrent des émulateurs ou des outils de test locaux pour simuler l’exécution (par exemple, la commande serverless invoke local permet de tester une Lambda localement). Mettez en place des tests unitaires sur la logique de vos fonctions, et des tests d’intégration qui invoquent réellement la fonction déployée dans le cloud pour vérifier son comportement. Côté monitoring, familiarisez-vous avec les consoles de logs et de métriques : CloudWatch Logs pour AWS Lambda, Application Insights pour Azure Functions, etc. Vérifiez que votre fonction écrit bien des logs utiles (par exemple via console.log ou print) et que vous pouvez consulter ces logs en cas de problème. Surveillez également les métriques de base : nombre d’invocations, durée moyenne, éventuelles erreurs ou timeouts. Cette étape vous apprend à débugger dans un environnement serverless, ce qui est un peu différent du debug traditionnel sur un serveur (on ne peut pas simplement se connecter sur une machine distante). Profitez-en pour optimiser la configuration : par exemple, ajustez la mémoire allouée à la fonction (plus de mémoire peut accélérer l’exécution CPU au prix d’un coût unitaire plus élevé – il y a souvent un point optimal à trouver). Observez les cold starts (démarrages à froid) : si vous constatez un délai notable sur la première invocation après une période d’inactivité, envisagez des solutions pour les mitiger (garder une fonction “au chaud” via des appels réguliers, ou sur AWS Lambda, activer Provisioned Concurrency pour pré-allouer une instance active en permanence si vraiment nécessaire).
Étape 6 : Étendre l’architecture et industrialiser
Après avoir réussi un premier projet pilote, vous pouvez progressivement étendre l’utilisation du serverless à d’autres composants de votre système. Identifiez d’autres fonctionnalités ou microservices dans votre application qui pourraient bénéficier d’une migration en serverless. Par exemple, après une API simple, peut-être migrer le traitement d’images, ou mettre en place un système de notifications asynchrone via des fonctions. Construisez ainsi petit à petit une architecture plus complète, en veillant à la cohérence globale. À ce stade, pensez aussi à industrialiser vos pipelines CI/CD pour vos fonctions : intégrez le déploiement dans vos workflows (par exemple, déployer automatiquement la fonction sur la plateforme de test à chaque commit sur la branche correspondante). Assurez-vous que la stratégie de gestion de configuration (variables d’environnement par exemple) et de sécurité (chiffrement de secrets, rotation de clés) est en place pour un usage plus avancé en production. Enfin, documentez les bonnes pratiques dans votre contexte d’entreprise, formez vos collègues, et partagez les retours d’expérience. L’adoption du serverless peut impliquer un changement culturel (infrastructure gérée par le code, plus forte dépendance à un fournisseur), il est donc important d’accompagner l’équipe dans cette transition.
En suivant cette feuille de route, vous passerez progressivement du statut de novice à celui de praticien averti du serverless. Chaque étape consolide vos compétences et vous évite de brûler les étapes, réduisant ainsi les risques d’erreur lors de l’adoption de cette nouvelle approche.
Quelle plateforme serverless choisir ?
Le choix de la plateforme est une question incontournable quand on aborde le serverless. Il existe aujourd’hui de nombreuses offres serverless et le choix dépendra de critères techniques, stratégiques et parfois de préférences personnelles. Les trois grands fournisseurs de cloud – Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) – dominent largement le paysage avec des solutions matures et intégrées à leurs écosystèmes respectifs. Mais il ne faut pas oublier l’existence d’autres acteurs et plateformes spécialisées, qui peuvent convenir à certains cas d’usage.
Voici un tour d’horizon des principales plateformes serverless et des éléments de choix :
- AWS Lambda (AWS) : c’est le pionnier et l’offre la plus utilisée du marché. AWS Lambda bénéficie d’un très large écosystème de services intégrés (API Gateway pour en faire une API web, S3 pour déclencher sur ajout de fichier, DynamoDB Streams, CloudWatch Events, etc.). La communauté autour d’AWS Lambda est massive, ce qui signifie de nombreux exemples, tutoriels et outils tiers (Serverless Framework est d’ailleurs né avec AWS Lambda comme première cible). AWS propose également des services complémentaires comme AWS Step Functions pour orchestrer plusieurs Lambdas en workflow, ou Amazon EventBridge pour la gestion des événements à l’échelle inter-applications. Si vous cherchez la polyvalence et la maturité, Lambda est un excellent choix. Côté limites, AWS Lambda impose un temps d’exécution maximal (15 minutes par invocation) et a historiquement souffert de cold starts un peu plus longs pour certaines runtimes (ex : Java ou .NET). Mais AWS a introduit des optimisations (Provisioned Concurrency) et même la possibilité de packager des fonctions en images Docker pour plus de flexibilité.
- Azure Functions (Microsoft Azure) : très bien intégrée à l’écosystème Microsoft, Azure Functions est un choix naturel pour les entreprises déjà utilisatrices d’Azure ou d’outils Microsoft (.NET, Visual Studio). Elle supporte de nombreux langages (C#, JavaScript/TypeScript, Python, Java, PowerShell, etc.) et s’intègre aisément avec les autres services Azure (Azure Event Grid pour les événements, Azure Cosmos DB en sortie/entrée, Azure DevOps pour le CI/CD, etc.). Azure Functions a la particularité de pouvoir être hébergée non seulement en mode 100 % serverless (plan de consommation à la demande) mais aussi en mode dedicated ou premium permettant d’avoir des instances pré-allouées, ce qui peut réduire la latence à froid. Pour un développeur .NET ou un contexte Microsoft 365, c’est souvent la plateforme idéale. L’interface de développement, notamment via Visual Studio Code, est très conviviale pour créer et déployer des Functions. Azure a également mis l’accent sur la productivité développeur : possibilité de déboguer en local, de tester avec Azure Functions Core Tools, etc.
- Google Cloud Functions et Cloud Run (Google Cloud) : Google propose deux approches. Cloud Functions est l’équivalent direct de Lambda/Azure Functions – une fonction event-driven gérée. Cloud Run est quant à lui un service serverless pour conteneurs : on lui déploie une image Docker (contenant par exemple un petit serveur web ou une application), et Google la fait tourner de manière serverless (autoscaling et pay-per-use également). Cloud Run est devenu très populaire car il combine la facilité du serverless avec la flexibilité des conteneurs (choix du langage sans restriction, possibilité d’inclure ses binaires, etc.).
- Autres plateformes : au-delà du “Big Three” du cloud, il y a des offres serverless à considérer. Par exemple, IBM Cloud Functions repose sur Apache OpenWhisk et propose également un FaaS multi-langages. Oracle Cloud a un service Functions (basé sur Fn Project). Alibaba Cloud en Chine a Function Compute. À noter aussi Cloudflare Workers qui propose une approche originale du serverless en l’exécutant en périphérie (edge computing) directement au plus près des utilisateurs, ce qui excelle pour des besoins à très faible latence sur du contenu distribué. Cloudflare Workers utilise un modèle différent (isolation par V8 isolates) et supporte notamment JavaScript/Workers syntax. C’est un bon choix pour par exemple générer des pages web dynamiquement au bord du réseau, ou implémenter des APIs globalement réparties géographiquement. Dans un autre registre, des PaaS modernes comme Netlify Functions ou Vercel Functions offrent du serverless intégré pour les développeurs web, couplé au déploiement de sites statiques.
Comment choisir alors ?
Le principal critère sera souvent la connaissance existante et l’écosystème. Si votre équipe est déjà formée à AWS et utilise massivement ses services, il y a fort à parier que AWS Lambda conviendra parfaitement (d’autant que beaucoup d’outils tiers sont d’abord compatibles AWS). De même, ne sous-estimez pas l’aspect vendor lock-in : si vous craignez l’enfermement propriétaire, sachez que migrer une application serverless d’un fournisseur à un autre n’est pas anodin. Il peut être plus simple de rester cohérent avec votre cloud principal.
Chaque plateforme a ses spécificités (limites de temps, de mémoire, formats supportés, modes de configuration). Il vaut mieux les étudier en amont pour voir laquelle correspond à vos besoins. Par exemple, AWS Lambda impose 15 minutes max par exécution, GCP Cloud Functions 9 minutes, Azure Functions 10 minutes (en consommation) – si vous prévoyez des traitements plus longs, Cloud Run ou Azure Functions Premium seraient plus adaptés. Autre exemple, en termes de performances au démarrage : les fonctions AWS sur runtime Node.js ou Python démarrent très vite, tandis qu’une fonction Java peut prendre plus de temps; Azure Functions offre un runtime .NET très efficace si vous codez en C# car la plateforme est optimisée pour .NET.
Coût et modèle de facturation peuvent aussi jouer : les trois grands sont sensiblement similaires en pay-per-use (quelques dizaines de centimes de dollar par million d’invocations, plus le temps CPU/mémoire). Néanmoins, il peut y avoir des différences sur les options : Google Cloud Functions inclut les appels réseau sortant dans la facturation ou non, AWS facture séparément le trafic via API Gateway, etc. Selon votre cas d’utilisation (par exemple une API fortement sollicitée où le coût principal peut devenir l’API Gateway), cela peut influencer le choix.
En résumé, pour choisir la plateforme serverless : prenez en compte votre environnement technologique (affinité avec AWS/Azure/GCP), les cas d’usage ciblés (simples fonctions vs conteneurs plus complexes, besoins temps réel global, etc.), les caractéristiques techniques (langages supportés, limites, performances) et éventuellement les coûts. La bonne nouvelle est qu’il est tout à fait possible de réussir avec n’importe laquelle des plateformes majeures – elles ont toutes fait leurs preuves. Certains adoptent même une stratégie multi-cloud, en exploitant chaque plateforme pour ce qu’elle a de meilleur (par exemple Cloudflare Workers pour l’edge + AWS Lambda pour le backend interne). En tant que débutant, il est cependant conseillé de se concentrer sur une plateforme au départ, pour monter en compétence dessus, avant éventuellement d’en explorer une autre.
Le serverless s’est imposé en quelques années comme un pilier de l’informatique moderne. En libérant les développeurs de la gestion des serveurs, il leur permet d’innover plus vite et à moindre coût. Le serverless s’applique aujourd’hui à un large éventail de cas d’usage : du web à la data, de l’automatisation à l’IoT, en passant par le machine learning. Naturellement, il n’y a pas de solution universelle et le serverless comporte ses limites, mais maîtrisé correctement, il offre un levier puissant de transformation pour les systèmes d’information. Ainsi, que vous soyez développeur, architecte ou responsable technique, il est fort probable qu’au présent – et plus encore dans le futur – vous croisiez le chemin d’une architecture sans serveur.
