Le triptyque historique IaaS / PaaS / SaaS ne suffit plus à décrire l'offre cloud en 2026. Entre l'IaaS « louez une VM, gérez tout au-dessus » et le SaaS « ouvrez un navigateur », deux modèles intermédiaires se sont imposés ces dernières années : CaaS (Containers as a Service) et FaaS (Functions as a Service). Le cinq forment ce qu'on appelle aujourd'hui la grille XaaS — Everything as a Service. Cette page pose les 5 modèles, étend l'analogie pizza pour les rendre intuitifs, détaille qui gère quoi dans chaque cas, et défend une opinion claire sur le modèle par défaut à choisir en 2026 pour un nouveau projet.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les 5 modèles XaaS (IaaS, CaaS, PaaS, FaaS, SaaS) et leurs frontières
- L'analogie pizza étendue qui rend les modèles intuitifs même pour un non-tech
- Le tableau de responsabilités : qui gère l'OS, le runtime, le scaling
- Comment choisir le bon modèle selon votre contexte
- Les pièges et le lock-in propres à chaque modèle
Prérequis : avoir compris la facturation cloud. Si besoin, démarrez par Pay-as-you-go : modèles tarifaires.
1. La grille XaaS : 5 modèles, 1 axe d'abstraction
Section intitulée « 1. La grille XaaS : 5 modèles, 1 axe d'abstraction »Tous les modèles cloud se rangent sur un seul axe : le niveau d'abstraction que le fournisseur gère pour vous. Plus l'abstraction monte, moins vous gérez de couches techniques, plus vous perdez en contrôle. Plus elle descend, plus vous touchez le matériel, plus vous portez la complexité opérationnelle.
| Modèle | Ce que vous gérez | Ce que vous ne gérez plus |
|---|---|---|
| On-premise | Tout : datacenter, électricité, matériel, réseau, OS, runtime, code | Rien |
| IaaS | OS, runtime, middlewares, code, données | Datacenter, hardware, virtualisation |
| CaaS | Image conteneur, code, données | + OS, patching, runtime container |
| PaaS | Code applicatif, données | + Runtime, middlewares, scaling |
| FaaS | Code de la fonction, événements | + Cycle de vie, scaling à zéro |
| SaaS | Configuration, données | + L'application elle-même |
L'expression XaaS (« Everything as a Service ») désigne cette grille élargie. Elle est utile parce qu'elle vous oblige à vous demander, pour chaque service que vous consommez : « à quel niveau d'abstraction suis-je en train de payer, et est-ce le bon ? » C'est la première grille mentale à ancrer avant de discuter d'un design ou d'un fournisseur.
2. L'analogie pizza étendue à 6 niveaux
Section intitulée « 2. L'analogie pizza étendue à 6 niveaux »Pour rendre les modèles intuitifs même à des collègues non-techniques, voici l'analogie pizza étendue. Chaque niveau correspond à un degré de service que vous achetez pour mettre une pizza dans votre estomac.
🏠 On-Premise
Tout faire vous-même
Vous cultivez les tomates, élevez les vaches pour le fromage, construisez le four, préparez la pâte, cuisez la pizza.
En cloud : vos serveurs dans votre datacenter. Vous gérez tout, du matériel à l'application.
Verdict : contrôle total, énormément de travail.
🛒 IaaS
Acheter les ingrédients
Vous achetez tomates, fromage et pâte au supermarché. Vous utilisez votre four et faites la pizza vous-même.
En cloud : le fournisseur livre l'infrastructure (VM, réseau, stockage). Vous installez l'OS, les middlewares, vos apps.
Verdict : moins de travail de base, mais vous cuisinez encore.
📦 CaaS
Pizza surgelée prête à enfourner
Pizza déjà préparée, vous la sortez de la boîte et l'enfournez. Vous contrôlez la cuisson, pas la recette.
En cloud : vous apportez un container (image OCI) avec votre application. Le fournisseur orchestre l'exécution.
Verdict : portable, prévisible, peu de travail système.
🏭 PaaS
Pizza à emporter non cuite
Pizza préparée par un pro, vous la mettez au four et la personnalisez (fromage, herbes).
En cloud : la plateforme est prête (OS, runtime, BDD managée). Vous déployez votre code via git push.
Verdict : focus produit, plateforme prise en charge.
⚡ FaaS
Pizza arrivée chaude par drone, déjà coupée
Vous demandez une part, elle arrive chaude en 2 minutes, vous mangez. Pas de four, pas de cuisson.
En cloud : vous écrivez une fonction, le fournisseur la lance à la demande, en facturant à la milliseconde.
Verdict : zéro infrastructure, scaling automatique, mais cold start et lock-in.
🍽️ SaaS
Manger au restaurant
Vous arrivez, on vous sert, vous mangez. Pas de cuisine, pas de vaisselle.
En cloud : Gmail, Salesforce, Slack, Notion. Vous utilisez, vous payez l'abonnement, point.
Verdict : service complet, aucun effort technique, configuration limitée.
L'analogie aide à visualiser un point souvent flou : CaaS et PaaS sont très proches, ils diffèrent surtout sur ce qui est imposé. Le PaaS choisit le runtime pour vous (Heroku « voici comment on déploie une app Python »), le CaaS vous laisse l'imposer dans votre image (votre Dockerfile, vos versions de bibliothèques). Sur le terrain, CaaS gagne du terrain depuis 2022 parce qu'il offre la simplicité d'un PaaS sans ses contraintes de stack.
3. Le tableau qui décide tout : qui gère quoi ?
Section intitulée « 3. Le tableau qui décide tout : qui gère quoi ? »
Ce tableau est la clé pour visualiser l'arbitrage. Chaque ligne est une couche technique, chaque colonne un modèle. Plus une case est « Vous », plus vous portez de travail et de responsabilité.
| Couche | On-prem | IaaS | CaaS | PaaS | FaaS | SaaS |
|---|---|---|---|---|---|---|
| Application | Vous | Vous | Vous | Vous | Vous | Fournisseur |
| Données | Vous | Vous | Vous | Vous | Vous | Partagé |
| Runtime | Vous | Vous | Image | Fournisseur | Fournisseur | Fournisseur |
| Container engine | Vous | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| OS | Vous | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Virtualisation | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Serveurs physiques | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Stockage physique | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
| Réseau physique | Vous | Fournisseur | Fournisseur | Fournisseur | Fournisseur | Fournisseur |
Lecture pratique. En passant d'IaaS à CaaS, vous abandonnez la gestion de l'OS et du moteur container — c'est typiquement 0,3 ETP économisé sur 50 instances. En passant de CaaS à PaaS, vous abandonnez en plus le choix du runtime, ce qui simplifie mais réduit votre liberté technique. Chaque saut vers le haut échange du temps humain contre du verrouillage sur le fournisseur.
4. IaaS — Infrastructure as a Service
Section intitulée « 4. IaaS — Infrastructure as a Service »L'IaaS est le modèle historique du cloud. Le fournisseur loue l'infrastructure de base (serveurs virtuels, stockage bloc, réseau virtuel), vous gérez tout ce qui est au-dessus : OS, middlewares, applications, données, sécurité.
Quand vous lancez une VM chez Outscale, AWS, Azure ou OVHcloud, vous obtenez l'équivalent d'un serveur physique virtualisé. Vous choisissez la puissance (CPU, RAM), le stockage, et vous installez ce que vous voulez — exactement comme si vous aviez un serveur dans votre datacenter, sans gérer le matériel ni l'électricité.
| Fournisseur | Service IaaS principal |
|---|---|
| Outscale | FCU (VM), Net, BSU (Block Storage) |
| OVHcloud | Public Cloud Instances, Block Storage |
| Scaleway | Instances, Block Storage, VPC |
| AWS | EC2, EBS, VPC |
| Azure | Virtual Machines, Managed Disks |
| GCP | Compute Engine, Persistent Disk |
Cas d'usage typiques : migration lift and shift d'applications existantes, besoin de contrôle total sur l'infrastructure (driver GPU spécifique, OS exotique, tuning kernel), environnements de R&D et de tests flexibles, workloads stateful complexes.
5. CaaS — Containers as a Service
Section intitulée « 5. CaaS — Containers as a Service »Le CaaS est le modèle qui a explosé entre 2020 et 2026. Vous apportez un container (image OCI standard, par exemple construite avec Docker ou Podman), le fournisseur l'exécute. Pas d'OS à patcher, pas de runtime à installer — le container porte sa propre stack applicative.
Le CaaS se décline en deux familles :
CaaS sans orchestrateur visible : ECS Fargate, Cloud Run, Azure Container Instances, App Runner. Vous donnez une image, le fournisseur la lance avec la mémoire et le CPU demandés. Pas besoin de connaître Kubernetes.
CaaS avec Kubernetes managé : EKS (AWS), AKS (Azure), GKE (GCP), OKS (Outscale). Le control plane Kubernetes est managé, vous gérez vos workloads via kubectl. Plus de complexité, plus de portabilité, écosystème CNCF complet.
| Fournisseur | CaaS sans orchestrateur | CaaS avec Kubernetes |
|---|---|---|
| AWS | ECS Fargate, App Runner | EKS |
| Azure | Container Instances, Container Apps | AKS |
| GCP | Cloud Run | GKE |
| Outscale | — | OKS |
| OVHcloud | — | Managed Kubernetes |
Cas d'usage typiques : applications conteneurisées modernes, microservices, batch courts, équipes DevOps avec expertise Docker/K8s, besoin de portabilité multi-cloud (le container tourne identique partout).
Le grand intérêt du CaaS est qu'il garde la portabilité au niveau de l'image OCI. Une image qui tourne sur Cloud Run peut tourner sans modification sur OKS Outscale, ECS Fargate ou Kubernetes on-prem. C'est un argument fort de réduction de lock-in, comparé à un PaaS propriétaire qui contraint le runtime et la structure du déploiement.
6. PaaS — Platform as a Service
Section intitulée « 6. PaaS — Platform as a Service »Le PaaS masque encore plus de couches : vous ne gérez plus le runtime ni les middlewares. Vous faites un git push et votre application est en ligne, scalée, patchée.
Une équipe qui passe d'IaaS à PaaS récupère typiquement 20 à 40 % de temps précédemment consacré à la maintenance infrastructure. Ce temps est réinvesti dans le développement produit, ce qui est très souvent le bon arbitrage en 2026.
| Fournisseur | Service PaaS |
|---|---|
| Scalingo | Plateforme française PaaS |
| Clever Cloud | Plateforme française PaaS |
| OVHcloud | Web PaaS (ex-Platform.sh) |
| Heroku | Heroku Platform |
| Vercel | Vercel Platform |
| AWS | Elastic Beanstalk, App Runner |
| Azure | App Service |
| GCP | App Engine |
Cas d'usage typiques : applications web et API modernes, équipes sans expertise infrastructure, déploiements rapides et fréquents, applications avec charge variable bénéficiant du scaling automatique.
7. FaaS — Functions as a Service
Section intitulée « 7. FaaS — Functions as a Service »Le FaaS pousse l'abstraction à son maximum. Vous écrivez une fonction (en Python, Node.js, Go, Java…), le fournisseur la lance à la demande quand un événement se produit (requête HTTP, message dans une queue, fichier déposé sur un bucket, horloge cron). Vous payez à la milliseconde d'exécution, et rien quand la fonction ne s'exécute pas.
| Fournisseur | Service FaaS |
|---|---|
| AWS | Lambda |
| Azure | Functions |
| GCP | Cloud Functions, Cloud Run (jobs) |
| Outscale | — (à venir) |
| Cloudflare | Workers |
Cas d'usage typiques : pipelines event-driven (S3 → trigger → traitement), API backend léger, automation interne (cron jobs cloud), webhooks, traitement asynchrone, cas IoT.
Les pièges spécifiques au FaaS sont nombreux et trop souvent ignorés. Le cold start ajoute 100 ms à 10 s de latence sur la première invocation après inactivité. Le vendor lock-in est élevé parce que chaque fournisseur impose son format d'event et son SDK. Le debugging est difficile : pas de SSH, pas de stack trace continue, juste des logs CloudWatch / App Insights. La durée maximale d'exécution est limitée (15 min Lambda, 60 min sur Cloud Run jobs).
Le FaaS mérite sa propre page de fondamentaux : voir Serverless et FaaS.
8. SaaS — Software as a Service
Section intitulée « 8. SaaS — Software as a Service »Le SaaS est le bout de la chaîne d'abstraction. Vous payez un abonnement, vous utilisez l'application via un navigateur ou une API. Pas d'infrastructure, pas de plateforme, pas de code — juste de la configuration et vos données.
Quand vous utilisez Gmail, Slack ou Salesforce, vous utilisez du SaaS. Vous ne savez pas (et n'avez pas besoin de savoir) sur quels serveurs tourne l'application, quelle stack, quelle architecture.
| Catégorie | Exemples SaaS |
|---|---|
| Gmail, Microsoft 365 | |
| CRM | Salesforce, HubSpot |
| Communication | Slack, Teams, Zoom |
| Monitoring | Datadog, New Relic |
| CI/CD | GitHub Actions, GitLab SaaS |
| Gestion de projet | Jira, Asana, Notion |
| Stockage / sync | Dropbox, Google Drive |
Le compromis : vous gagnez énormément en simplicité, vous perdez en personnalisation et en propriété des données. Avec SaaS, vous utilisez l'application telle qu'elle est conçue. Si elle ne couvre pas 100 % de vos besoins, vous vous adaptez ou changez d'outil.
9. Comment choisir le bon modèle ?
Section intitulée « 9. Comment choisir le bon modèle ? »Le choix dépend de plusieurs facteurs. Il n'y a pas de réponse universelle — le bon modèle dépend de votre contexte : compétences de l'équipe, type d'application, contraintes réglementaires, budget, profil de charge.
Voici un arbre de décision que je propose, simplifié pour tenir sur cette page.
Question 1 — Existe-t-il un SaaS standard qui couvre votre besoin ?
Section intitulée « Question 1 — Existe-t-il un SaaS standard qui couvre votre besoin ? »Oui → cherchez d'abord une solution SaaS. Email, CRM, monitoring, CI/CD, gestion de projet : ces besoins sont commoditisés depuis longtemps, redévelopper est rarement justifié.
Non → passez à la question 2.
Question 2 — Votre charge est-elle ponctuelle ou très variable ?
Section intitulée « Question 2 — Votre charge est-elle ponctuelle ou très variable ? »Oui (workflows événementiels, traitements batch, automation rare) → FaaS est probablement optimal financièrement.
Non → passez à la question 3.
Question 3 — Avez-vous des contraintes spécifiques de stack ou d'OS ?
Section intitulée « Question 3 — Avez-vous des contraintes spécifiques de stack ou d'OS ? »Oui (GPU spécifique, OS exotique, kernel custom, dépendances binaires complexes) → IaaS vous donne le contrôle nécessaire.
Non → passez à la question 4.
Question 4 — Avez-vous une équipe DevOps autonome avec Docker/K8s ?
Section intitulée « Question 4 — Avez-vous une équipe DevOps autonome avec Docker/K8s ? »Oui → CaaS est le défaut moderne. Vous gardez la portabilité de l'image, vous abandonnez la gestion OS.
Non, l'équipe est full-dev sans DevOps dédié → PaaS vous libère totalement de l'infrastructure.
Matrice de décision rapide
Section intitulée « Matrice de décision rapide »| Critère | IaaS | CaaS | PaaS | FaaS | SaaS |
|---|---|---|---|---|---|
| Contrôle maximum | ✅ | ⚠️ | ❌ | ❌ | ❌ |
| Déploiement rapide | ❌ | ✅ | ✅ | ✅ | ✅ |
| Pas d'expertise infra requise | ❌ | ⚠️ | ✅ | ✅ | ✅ |
| Personnalisation totale | ✅ | ✅ | ⚠️ | ❌ | ❌ |
| Portabilité multi-cloud | ⚠️ | ✅ | ❌ | ❌ | ❌ |
| Coût à charge nulle | ❌ | ❌ | ⚠️ | ✅ | ⚠️ |
| Éviter le lock-in | ✅ | ✅ | ⚠️ | ❌ | ❌ |
10. Comment choisir parmi les modèles XaaS
Section intitulée « 10. Comment choisir parmi les modèles XaaS »Le choix d'un modèle XaaS dépend de trois critères principaux : le niveau de contrôle technique dont l'équipe a besoin, le temps humain qu'elle peut consacrer à l'infrastructure, et la portabilité souhaitée vers d'autres environnements. Aucune réponse n'est universelle — chaque projet doit traduire ses contraintes en choix de modèle.
Quand SaaS convient. L'équipe a un besoin commoditisé (CRM, messagerie, partage de fichiers, suivi de tickets) et n'a aucune valeur ajoutée à le redévelopper. Elle accepte de payer par utilisateur, accepte la roadmap du fournisseur, et privilégie un démarrage rapide à la personnalisation profonde.
Quand FaaS convient. Le besoin est événementiel par nature (traitement d'images uploadées, déclenchement sur webhook, agrégation périodique). Le code est court, exécuté de manière intermittente, et l'équipe accepte les contraintes du modèle (cold start, durée maximale d'exécution, lock-in fournisseur).
Quand PaaS convient. L'équipe développe un service web classique (site, API, application métier) et n'a pas de DevOps dédié. Elle souhaite déployer en quelques minutes sans gérer kernel, runtime, ou load balancer. Elle accepte de pousser son code dans le format imposé par le fournisseur.
Quand CaaS convient. L'équipe a besoin de portabilité (image OCI qui tourne ailleurs sans réécriture), accepte de comprendre les bases des conteneurs, et veut industrialiser son cycle de déploiement. C'est un modèle très utilisé sur les nouveaux projets backend qui veulent garder une porte de sortie multi-cloud.
Quand IaaS reste pertinent. L'application a une dépendance forte au système (driver kernel spécifique, binaire propriétaire, contrainte de licence liée à la machine), ou l'équipe doit reproduire à l'identique un environnement existant pour des raisons de conformité ou d'audit.
Une équipe peut combiner plusieurs modèles : SaaS pour la messagerie, PaaS pour le site vitrine, CaaS pour l'API métier, FaaS pour les traitements événementiels, IaaS pour le composant legacy qui ne peut pas migrer. Cette combinaison est la norme, pas l'exception.
À retenir
Section intitulée « À retenir »- La grille XaaS (IaaS, CaaS, PaaS, FaaS, SaaS) range tous les modèles cloud sur un axe d'abstraction croissante ; chaque cran échange du temps humain contre du verrouillage.
- L'analogie pizza étendue à 6 niveaux rend les modèles intuitifs et facilite les conversations avec les non-techniques.
- Le tableau qui-gère-quoi est la grille de lecture unique : plus de cases « Vous », plus de travail et de contrôle.
- Le choix du modèle dépend du contrôle technique requis, du temps humain disponible, et de la portabilité souhaitée — aucune réponse n'est universelle.
- Le lock-in augmente du PaaS au FaaS au SaaS — toujours évaluer la sortie avant l'entrée.