English
En 2026, la facture cloud des entreprises françaises a dépassé les 27 milliards d'euros selon les dernières estimations du cabinet Markess. Pourtant, une confusion persiste chez de nombreux décideurs techniques : serverless computing et cloud, quelle est réellement la différence ? Le serverless n'est-il pas, par définition, du cloud ? Techniquement, oui. Mais les deux termes recouvrent des philosophies, des modèles économiques et des responsabilités très différents. Confondre les deux revient à mettre dans le même panier un appartement en location longue durée et une chambre d'hôtel facturée à la nuit. Les deux vous offrent un toit, mais les engagements, les coûts et la flexibilité n'ont rien à voir. Cet article décortique les distinctions concrètes pour vous aider à choisir l'architecture la plus adaptée à vos projets.
Fondamentaux du Cloud Computing et du Serverless
Définition du Cloud traditionnel (IaaS, PaaS, SaaS)
Le cloud computing repose sur la mise à disposition de ressources informatiques via Internet, sans que l'utilisateur possède physiquement les serveurs. On distingue trois couches principales. L'IaaS (Infrastructure as a Service) fournit des machines virtuelles, du stockage et du réseau : c'est le cas d'OVHcloud, AWS EC2 ou Azure Virtual Machines. Vous louez l'infrastructure brute et vous gérez tout le reste, du système d'exploitation aux applications.
Le PaaS (Platform as a Service) monte d'un cran en abstraction. Des services comme Heroku, Google App Engine ou Scalingo prennent en charge le système d'exploitation et le middleware. Vous déployez votre code, la plateforme s'occupe du reste. Le SaaS (Software as a Service), lui, est le modèle le plus familier du grand public : Gmail, Salesforce, Microsoft 365. L'utilisateur consomme un logiciel prêt à l'emploi sans se soucier de l'infrastructure sous-jacente.
Ce qui caractérise le cloud classique, c'est que vous réservez des ressources, que vous les consommiez ou non. Vous provisionnez une instance avec 8 Go de RAM et 4 vCPU, vous payez pour cette capacité 24h/24, même si votre application dort à 3 heures du matin.
L'émergence du Serverless et du concept FaaS
Le serverless computing est apparu comme une réponse à ce gaspillage. Le terme est trompeur : il y a bien des serveurs, mais vous n'avez plus à vous en préoccuper. Le fournisseur cloud gère intégralement l'infrastructure, l'allocation des ressources et la mise à l'échelle. Votre seule responsabilité : écrire du code. Pour les organisations qui se demandent « Qu'est-ce que le calcul serverless ? », il s'agit d'un modèle d'exécution où les ressources sont automatiquement provisionnées et facturées uniquement lorsqu'elles sont utilisées.
Le concept central du serverless est le FaaS (Function as a Service). Vous découpez votre application en fonctions indépendantes qui s'exécutent en réponse à des événements : une requête HTTP, un message dans une file d'attente, un fichier déposé dans un bucket. AWS Lambda, lancé en 2014, a popularisé ce modèle. Depuis, Azure Functions, Google Cloud Functions et des alternatives open source comme OpenFaaS ou Knative ont enrichi l'écosystème.
Le serverless ne se limite pas au FaaS. Il englobe aussi les bases de données serverless (DynamoDB, Neon, PlanetScale), les API gateways managées et les services d'orchestration comme AWS Step Functions. Le point commun : zéro gestion de serveur, facturation à l'usage réel. La Technologie serverless : tout ce qu'il faut savoir repose justement sur cette capacité à abstraire l'infrastructure afin que les équipes se concentrent sur le développement applicatif plutôt que sur l'administration des ressources.
Gestion de l'infrastructure et abstraction
Le contrôle manuel des serveurs vs l'automatisation totale
Avec un cloud IaaS classique, votre équipe DevOps configure les machines virtuelles, installe les dépendances, gère les certificats SSL, paramètre les pare-feux et surveille les métriques système. Ce contrôle granulaire est un atout pour les architectures complexes qui nécessitent des configurations spécifiques : choix précis du noyau Linux, pilotes GPU pour du machine learning, ou contraintes réglementaires imposant un certain type de chiffrement.
Le serverless supprime cette couche. Vous ne choisissez ni le système d'exploitation, ni la quantité de RAM allouée à votre fonction (sauf un plafond maximal). Le fournisseur décide comment et où exécuter votre code. Pour une startup qui veut livrer vite, c'est libérateur. Pour une DSI habituée à contrôler chaque paramètre, c'est parfois déstabilisant.
Un exemple concret : une entreprise de e-commerce basée à Lyon qui traite 500 commandes par jour n'a probablement pas besoin de gérer ses propres serveurs. En revanche, un éditeur de logiciels médicaux soumis à la certification HDS (Hébergeur de Données de Santé) aura peut-être besoin du contrôle qu'offre un cloud IaaS pour prouver sa conformité aux auditeurs.
La responsabilité de la maintenance et des mises à jour
Sur un cloud traditionnel, les mises à jour de sécurité du système d'exploitation sont à votre charge. Quand une faille critique comme Log4Shell apparaît, c'est votre équipe qui doit patcher les serveurs, parfois en urgence un vendredi soir. Les correctifs applicatifs, les montées de version des runtimes, la rotation des certificats : tout cela mobilise du temps d'ingénierie.
En serverless, le fournisseur applique les correctifs de sécurité sur l'infrastructure sous-jacente de manière transparente. Vous restez responsable de votre code et de ses dépendances, mais la surface d'attaque liée à l'OS disparaît de votre périmètre. Pour les équipes réduites, c'est un argument de poids : moins de maintenance signifie plus de temps consacré au développement de fonctionnalités qui génèrent de la valeur métier.
Le revers de la médaille, c'est la dépendance au fournisseur pour les mises à jour de runtime. Quand AWS décide de déprécier le support de Node.js 16 sur Lambda, vous devez migrer selon son calendrier, pas le vôtre.
Comparaison des modèles de facturation
Paiement à la ressource allouée (Cloud classique)
Le modèle économique du cloud traditionnel repose sur la réservation de capacité. Vous louez une instance EC2 de type m6i.large, vous payez environ 0,096 dollar par heure, soit environ 70 dollars par mois, que votre CPU tourne à 2 % ou à 100 %. Les fournisseurs proposent des réductions via des instances réservées (engagement sur 1 ou 3 ans) ou des instances spot (capacité excédentaire à prix réduit mais interruptible).
Ce modèle est prévisible. Votre DAF peut budgéter les coûts cloud avec une marge d'erreur raisonnable. Mais il génère du gaspillage structurel. Selon une étude de Flexera publiée début 2026, les entreprises gaspillent en moyenne 28 % de leurs dépenses cloud en ressources sous-utilisées. Les serveurs de développement qui tournent le week-end, les environnements de staging oubliés, les instances surdimensionnées "par précaution" : autant de postes de dépense fantômes.
Pour les charges de travail stables et prévisibles, un serveur dédié ou une instance réservée reste souvent plus économique qu'une approche serverless. Un service qui consomme 100 % de CPU en permanence coûtera moins cher sur une VM bien dimensionnée.
Paiement à l'exécution et à la consommation réelle (Serverless)
Le serverless facture uniquement ce que vous consommez : le nombre d'invocations et la durée d'exécution de chaque fonction, mesurée en millisecondes. Sur AWS Lambda en 2026, le tarif est d'environ 0,20 dollar par million de requêtes et 0,0000166667 dollar par Go-seconde de calcul. Si votre fonction ne s'exécute pas, vous ne payez rien. Cette approche illustre parfaitement le serverless dans le cloud computing moderne, où les entreprises cherchent à optimiser leurs coûts tout en bénéficiant d'une infrastructure capable de s'adapter automatiquement aux variations de charge.
Ce modèle est redoutable pour les charges de travail irrégulières. Prenons un site de réservation de restaurants parisiens : le trafic explose entre 11h et 13h, puis entre 18h et 21h, et tombe à presque zéro la nuit. En serverless, la facture reflète exactement cette courbe. En cloud classique, vous payez pour des serveurs dimensionnés pour le pic, même pendant les heures creuses.
Le piège, c'est l'imprévisibilité des coûts à grande échelle. Une fonction mal codée qui s'appelle en boucle peut générer des millions d'invocations en quelques minutes. Sans alertes de facturation bien configurées, la note peut grimper très vite. Plusieurs entreprises françaises ont partagé des retours d'expérience sur ce sujet lors du dernier AWS Summit Paris, certaines évoquant des factures surprises dépassant les 10 000 euros sur un seul mois.
Évolutivité et performance opérationnelle
Auto-scaling natif vs configuration de l'élasticité
L'un des avantages les plus tangibles du serverless est sa capacité à monter en charge instantanément. Si votre fonction reçoit 10 requêtes par seconde puis soudainement 10 000, le fournisseur alloue automatiquement les ressources nécessaires. Vous n'avez rien à configurer. Cette élasticité native est particulièrement précieuse pour les événements imprévisibles : une mention dans un article de presse, un pic de trafic lié aux soldes ou une campagne marketing virale.
Sur un cloud classique, l'auto-scaling existe, mais il demande de la configuration. Vous définissez des règles : "Si le CPU dépasse 70 % pendant 5 minutes, ajouter une instance." Vous configurez un load balancer, des groupes d'auto-scaling, des seuils d'alarme. Ce paramétrage prend du temps et nécessite de l'expertise. Un mauvais réglage peut entraîner soit un sous-provisionnement (votre site tombe), soit un sur-provisionnement (votre facture explose).
La différence fondamentale : en serverless, la mise à l'échelle est un comportement par défaut. En cloud traditionnel, c'est une fonctionnalité que vous devez implémenter et tester.
Le défi du démarrage à froid (Cold Start)
Le cold start est le talon d'Achille du serverless. Quand une fonction n'a pas été appelée depuis un certain temps, le fournisseur doit initialiser un nouvel environnement d'exécution : charger le runtime, les dépendances, puis exécuter votre code. Ce délai peut aller de quelques dizaines de millisecondes (pour une fonction Python légère) à plusieurs secondes (pour une fonction Java avec un framework lourd).
Pour une API qui doit répondre en moins de 100 ms, ce temps de démarrage est problématique. Les fournisseurs ont développé des solutions : AWS propose le Provisioned Concurrency, qui maintient des instances "chaudes" en permanence, mais cela revient partiellement au modèle de facturation classique. Google Cloud Run, qui exécute des conteneurs en mode serverless, offre un compromis intéressant avec des cold starts généralement plus courts.
Sur un cloud traditionnel, ce problème n'existe pas. Votre serveur tourne en permanence, prêt à répondre. C'est un argument décisif pour les applications temps réel : trading haute fréquence, jeux en ligne, visioconférence.
Critères de choix pour votre architecture
Cas d'usage idéaux pour le Cloud traditionnel
Le cloud IaaS ou PaaS reste le choix pertinent dans plusieurs situations précises :
- Les applications monolithiques existantes qui fonctionnent bien et dont la réécriture en microservices ne se justifie pas économiquement
- Les charges de travail stables et prévisibles avec un taux d'utilisation CPU supérieur à 60 % en moyenne
- Les systèmes nécessitant un contrôle fin de l'infrastructure pour des raisons de conformité (HDS, SecNumCloud, RGPD avec localisation stricte)
- Les applications avec des connexions longues : WebSockets, streaming vidéo, bases de données relationnelles avec connection pooling complexe
- Les workloads de calcul intensif et continu : entraînement de modèles d'IA, rendu 3D, simulations scientifiques
Une PME industrielle qui fait tourner un ERP sur mesure depuis dix ans n'a aucun intérêt à migrer vers du serverless. Le coût de réécriture dépasserait largement les économies potentielles.
Quand privilégier une approche Serverless
Le serverless brille dans des contextes bien identifiés. Les applications événementielles en sont le cas d'école : traitement d'images après upload, envoi de notifications, synchronisation de données entre systèmes. Les API backends avec un trafic variable sont aussi d'excellents candidats, tout comme les tâches planifiées (cron jobs) qui s'exécutent quelques minutes par jour. Cette évolution confirme la place croissante du serverless dans le cloud computing moderne, notamment pour les organisations qui souhaitent accélérer leur transformation numérique sans alourdir leurs opérations d'infrastructure.
Les startups en phase de validation de concept tirent un bénéfice immédiat du serverless. Pas de coûts fixes, pas de serveurs à administrer, une mise en production rapide. Si le produit ne trouve pas son marché, les coûts d'infrastructure restent quasi nuls. Si le trafic décolle, la mise à l'échelle est automatique.
Les architectures hybrides sont d'ailleurs de plus en plus courantes en 2026. Le cœur applicatif tourne sur des conteneurs Kubernetes (cloud classique), tandis que les fonctions périphériques (traitement d'images, webhooks, tâches asynchrones) sont déployées en serverless. Cette approche combine la stabilité du cloud traditionnel avec la flexibilité du serverless là où elle apporte le plus de valeur. De nombreuses entreprises privilégient également des services open source afin de limiter leur dépendance aux fournisseurs propriétaires et de renforcer leur souveraineté numérique.
Synthèse des avantages et limites pour l'entreprise
Le choix entre cloud classique et serverless n'est pas binaire. Il dépend de votre contexte : taille de l'équipe, nature de la charge de travail, contraintes réglementaires, budget et compétences internes. Le cloud traditionnel offre contrôle, prévisibilité et maturité. Le serverless apporte agilité, réduction des coûts sur les charges variables et suppression de la gestion opérationnelle des serveurs.
La tendance observée chez les entreprises françaises va vers des architectures mixtes. Les DSI les plus efficaces ne choisissent pas un camp : elles placent chaque composant sur le modèle le plus adapté. Le vrai risque n'est pas de se tromper de modèle, mais de s'enfermer chez un seul fournisseur sans stratégie de réversibilité. Alors que les organisations cherchent à gagner en agilité et à optimiser leurs coûts, comprendre comment fonctionne le serverless computing ? devient essentiel pour faire les bons choix technologiques. Cette connaissance permet d'identifier les cas d'usage les plus pertinents et de tirer pleinement parti des avantages du cloud moderne tout en conservant une maîtrise efficace de son infrastructure.
Si vous cherchez un partenaire capable de vous accompagner dans ces choix d'architecture avec une approche open source qui préserve votre indépendance technologique, LINAGORA propose des solutions cloud et des outils libres pensés pour les entreprises françaises. Grâce à son expertise et à son support technique, l'entreprise aide les organisations à concevoir, déployer et exploiter des infrastructures performantes, évolutives et souveraines. Découvrir nos solutions peut être un bon point de départ pour construire une infrastructure adaptée aux enjeux actuels du cloud et du serverless.
