La pile cloud compte sept niveaux maintenant, pas seulement IaaS, PaaS, SaaS
Tous les cours enseignent encore trois cases : IaaS, PaaS, SaaS. Le marché a cessé de ressembler à ce dessin il y a environ dix-huit mois.
L'ancien schéma était bon. Il répondait bien à une question : quelle part du serveur est mon problème ? Vous louez une machine, tout est à vous. Vous poussez du code sur une plateforme, l'essentiel est à eux. Vous achetez un logiciel fini, rien n'est à vous.
Puis trois choses sont arrivées. Le milieu de la pile s'est replié sur lui-même. La base de données est devenue un marché à part, où circulent des milliards de dollars. Et un nouveau niveau est apparu, qui n'existe que parce que les agents IA écrivent désormais du code qui doit bien tourner quelque part.
Voici le dessin que je ferais à la place. Deux piles, pas une, et le SaaS dans aucune des deux.
Remarquez que le SaaS n'est dans aucune des deux piles. Il a toujours été l'intrus. Le SaaS, c'est un logiciel que vous achetez. Les autres sont des endroits où faire tourner le logiciel que vous avez écrit. Les mettre dans le même schéma a embrouillé une génération d'étudiants.
Changement un : le PaaS et les fonctions se sont rejoints
L'ancienne règle était simple, et pendant des années elle a été vraie.
Une application PaaS est un programme qui reste allumé. Il est là, il attend. Vous payez à l'heure, toute la journée, y compris à 3 h du matin quand personne n'est réveillé. Pensez à une boutique qui laisse la lumière allumée.
Une fonction n'est pas un programme qui reste allumé. Elle se réveille quand une requête arrive, fait le travail, et se rendort. Vous payez à la requête. Pensez à un distributeur automatique.
Donc : chaud veut dire payer à l'heure, froid veut dire payer à la requête. Deux options bien nettes.
Les deux ont bougé depuis, et chacune vers l'autre.
Fluid compute de Vercel laisse une instance traiter plusieurs requêtes en même temps, et ne facture le CPU que pendant que votre code s'exécute vraiment. Si votre code attend la réponse d'une base de données ou d'un modèle d'IA, le compteur CPU se met en pause. Entre deux requêtes, rien n'est facturé du tout. Les tarifs sont de $0.128 par heure de CPU et $0.0106 par Go-heure de mémoire. C'est un processus chaud, à longue durée de vie, facturé comme une fonction.
En sens inverse, Google Cloud Run prend un conteneur Docker ordinaire, lui donne un Linux complet, le langage que vous voulez, jusqu'à 32 Go de mémoire et un timeout de 60 minutes, et le ramène quand même à zéro. C'est une facture en forme de fonction posée autour d'un vrai serveur.
Les mêmes trois requêtes, facturées de trois façons. "Est-ce que c'est chaud ?" et "comment suis-je facturé ?" ne formaient qu'une seule question. Elles en font deux aujourd'hui, et toutes les combinaisons existent.
Changement deux : "serverless" veut dire quatre choses différentes
C'est là que la plupart des discussions dérapent. Quelqu'un annonce que l'équipe passe au serverless, tout le monde acquiesce, et trois mois plus tard on découvre que ce qui a été choisi ne sait pas lancer une tâche cron.
- Exécute
- Un court traitement de requête à la fois
- Descend à zéro
- Oui, complètement
- Le piège
- Les limites varient ; une instance chaude peut conserver sa mémoire et ses fichiers temporaires, sans garantie de persistance
- Exécute
- Des images de conteneur compatibles. Services Cloud Run : jusqu'à 32 Gio et 60 minutes de délai par requête. Fargate a d'autres limites et accepte des tâches de longue durée.
- Descend à zéro
- Cloud Run peut le faire automatiquement. Les services Fargate exigent une politique de mise à l'échelle explicite et un mécanisme pour relancer les tâches.
- Le piège
- Toujours une seule région, sauf à en monter d'autres vous-même
- Exécute
- Du JavaScript ou du WebAssembly, dans toutes les villes à la fois
- Descend à zéro
- Oui, et démarre en moins d'une milliseconde
- Le piège
- Pas de runtime Node complet, et un budget de temps CPU serré
- Exécute
- Postgres, avec le calcul séparé du stockage
- Descend à zéro
- Le calcul oui, le stockage jamais
- Le piège
- Le réveil prend du temps, et les octets sont facturés pendant le sommeil
Les quatre ne sont pas de proches parents. Les limites des fonctions dépendent du fournisseur. La limite d'une heure de Cloud Run concerne les requêtes de ses services, pas tous les conteneurs serverless ni les tâches de fond. Un isolate en edge démarre en moins d'une milliseconde mais ne sait pas exécuter du code Node normal. Une base de données serverless endort son calcul et continue de vous facturer les octets sur le disque.
La prochaine fois qu'on vous parle de serverless, demandez lequel des quatre. Ce sont les limites qui feront votre quotidien.
Changement trois : l'argent est passé à la base de données
Pendant qu'internet se disputait sur Kubernetes, les capitaux, eux, sont allés ailleurs.
Databricks a payé environ 1 milliard de dollars pour Neon, une entreprise qui vend du Postgres serverless, sur à peu près 25 millions de dollars de revenus annuels. Snowflake a pris Crunchy Data pour 250 millions, selon la presse. Supabase est passé d'une valorisation de 2 milliards à 5 milliards en quatre mois. Postgres a atteint 55,6% d'utilisation dans l'enquête Stack Overflow 2025, base de données la plus utilisée deux années de suite.
Les prix ont chuté dans la foulée. Le stockage de Neon est passé de $1.75 à $0.35 par Go-mois, soit 80% de baisse, et le calcul a suivi.
La raison tient dans le dernier chiffre. Plus de 80% des nouvelles bases de Neon ont été créées par des agents IA, pas par des humains, contre 30% un an plus tôt. Un agent qui monte une base jetable à chaque tâche n'est pas du tout le même client qu'une personne qui clique dans une console une fois par trimestre. Le Postgres qui descend à zéro existe parce que ce client existe.
Et c'est bien une deuxième pile, pas un niveau de la première. Où tourne votre code et où vivent vos données sont deux achats distincts. L'ancien schéma n'avait pas de case pour une base de données, personne n'a donc appris à le voir comme ça.
Le piège quand on mélange les deux piles
Prenez du calcul serverless et une base de données managée ordinaire, et vous tomberez dessus dès votre première journée chargée.
Postgres est à 100 connexions par défaut, et aucun code astucieux ne rattrape cette arithmétique. Soit vous mettez un pooler au milieu, soit vous prenez une panne.
Deux autres choses à savoir avant de faire confiance au "scale to zero" d'une base de données. Le stockage ne dort jamais : seul le calcul s'endort, et une base en pause facture toujours chaque octet qu'elle garde. Le réveil prend du temps : une base endormie a besoin d'un moment pour revenir, et ce moment s'ajoute au démarrage à froid que votre fonction avait déjà.
Reste l'asymétrie qui décide du niveau de paranoïa. Quitter votre plateforme d'hébergement, c'est à peu près une semaine de travail. Quitter votre base de données, c'est déplacer des téraoctets, payer pour les sortir, et réécrire les requêtes pour un autre moteur. Soyez détendu sur le verrouillage côté calcul. Soyez prudent sur le verrouillage côté données.
Le nouveau niveau : des sandboxes pour le code écrit par l'IA
C'est la catégorie vraiment nouvelle, et elle n'existait pas quand on a dessiné le schéma d'origine.
Un agent IA écrit du code. Ce code doit s'exécuter. Pas sur votre propre serveur : vous ne l'avez pas écrit et vous ne savez pas ce qu'il fait. Il vous faut un ordinateur jetable, pour une tâche, complètement cloisonné, jeté juste après.
C'est devenu une catégorie de produits avec une vraie concurrence. En avril 2026, le SDK Agents d'OpenAI a livré la prise en charge des sandboxes avec sept fournisseurs hébergés intégrés : Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop et Vercel. Docker a sorti sa propre fonctionnalité de sandbox, en version expérimentale.
| Fournisseur | Type d'isolement | Session la plus longue | GPU | Démarrage à froid |
|---|---|---|---|---|
| E2B | microVM Firecracker | jusqu'à 24 heures | non | environ 90 à 200 ms |
| Modal | conteneur gVisor | pas de limite fixée | oui, du T4 au B200 | non publié |
| Daytona | conteneur Sysbox | pas de limite fixée | oui | environ 90 ms |
| Vercel Sandbox | microVM Firecracker | 45 min gratuit, 24 h payant | non | non publié |
| Cloudflare Sandboxes | conteneur en edge | 30 minutes | non | non publié |
| Blaxel | microVM | pas de limite fixée | non | environ 25 ms |
Chiffres annoncés par les fournisseurs, et ils bougent vite.
Les écarts ne sont pas cosmétiques. Les limites de session vont de 30 minutes à aucune limite du tout. Les démarrages à froid vont d'environ 25 millisecondes à deux ou trois cents. Certains donnent accès à un GPU, la plupart non. Le modèle d'isolement change aussi : des microVM au niveau matériel comme Firecracker d'un côté, un isolement par conteneur de l'autre. Si vous exécutez du code auquel vous ne faites vraiment pas confiance, c'est la colonne à lire en premier.
Pourquoi s'y intéresser si vous ne construisez pas d'agents ? À cause de ce 80% de Neon. Le consommateur d'infrastructure cloud qui grandit le plus vite en ce moment n'est pas une personne. Tous les fournisseurs se réorganisent autour d'un client qui arrive par rafales, travaille quatre-vingt-dix secondes et disparaît. Ça change les produits qu'on vous propose, qui que vous soyez.
Comment choisir : accorder le niveau à la forme du travail
Deux questions au lieu d'une. D'abord, quelle forme a le travail ? Ensuite, et séparément, où vivent les données ?
La plupart des équipes répondent à peu près juste à la première question, par instinct, et se trompent sur la seconde par défaut, parce que l'ancien schéma ne leur a jamais dit qu'il y en avait une seconde.
Ce qui n'a pas bougé d'un pouce
Deux choses restent entièrement votre affaire, à tous les niveaux, du bare metal à la sandbox la plus récente.
Votre schéma et vos requêtes. Aucun fournisseur, dans l'une ou l'autre pile, ne corrigera un index manquant. Une base managée qui fait un parcours séquentiel sur quarante millions de lignes est une base lente. La plupart des tickets "notre base managée est lente" sont en réalité une requête que personne n'a regardée.
Votre facture. Chacun de ces modèles a sa manière de vous surprendre. Les serveurs toujours allumés vous facturent pendant votre sommeil. Les fonctions facturent à la requête, et les requêtes s'additionnent plus vite que prévu. Kubernetes facture $73 par mois et par cluster EKS avant qu'un seul conteneur ne démarre, et passe à environ $438 si vous laissez le cluster prendre du retard sur les versions. Les bases de données serverless facturent les octets au repos. Personne ne vous envoie d'e-mail d'avertissement.
Le schéma de votre présentation n'est pas faux. Il vient juste d'un marché plus petit. Redessinez-le avec deux piles et sept niveaux, et les débats dans votre équipe raccourciront nettement.
Choisir le bon niveau, et quitter le mauvais, c'est l'essentiel de mon travail : migrations AWS, passages de Lambda aux conteneurs et audits de coûts pour les équipes qui ont parié tôt et qui le paient aujourd'hui. Si vous êtes face à cette décision, écrivez-moi.
Les pages tarifaires et les articles liés étayent les chiffres cités. Vérifiez séparément les limites de Cloud Run et de Fargate. Pour les limites actuelles des sandboxes, consultez E2B, Modal, Daytona, Vercel Sandbox, Cloudflare Sandboxes et Blaxel. Le tableau est un instantané, pas un benchmark que j'ai exécuté ni une garantie du temps de démarrage. Vérifié en septembre 2026, et ce marché bouge vite, alors vérifiez avant de vous engager.