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, situe chacun sur son niveau d'abstraction, 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
- Le niveau d'abstraction de chaque modèle, et ce qu'il vous retire de charge
- 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. Le tableau qui décide tout : qui gère quoi ?
Section intitulée « 2. 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.
3. IaaS, Infrastructure as a Service
Section intitulée « 3. 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.
4. CaaS, Containers as a Service
Section intitulée « 4. 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 | aucune offre | OKS |
| OVHcloud | aucune offre | 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.
5. PaaS, Platform as a Service
Section intitulée « 5. 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.
6. FaaS, Functions as a Service
Section intitulée « 6. 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 | aucune offre à ce jour |
| 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.
7. SaaS, Software as a Service
Section intitulée « 7. 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.
8. Comment choisir le bon modèle ?
Section intitulée « 8. Comment choisir le bon modèle ? »Le choix se ramène à trois critères : 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. Il n'y a pas de réponse universelle : compétences de l'équipe, type d'application, contraintes réglementaires, budget et profil de charge pèsent différemment d'un projet à l'autre.
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 | ✅ | ✅ | ⚠️ | ❌ | ❌ |
Le profil type de chaque modèle
Section intitulée « Le profil type de chaque modèle »L'arbre de décision donne une orientation rapide ; les descriptions ci-dessous permettent de la confirmer, en vérifiant que votre contexte correspond bien au profil du modèle retenu.
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.
- Chaque cran d'abstraction supprime une couche à gérer, et ajoute une dépendance au fournisseur.
- 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.