IaaS, PaaS, SaaS et serverless
Résumé : ces sigles décrivent jusqu'où va la responsabilité du fournisseur et où commence la vôtre. Plus vous montez dans l'abstraction — de IaaS vers SaaS — moins vous gérez de choses, mais moins vous contrôlez. Cette leçon clarifie chaque niveau, présente le modèle de responsabilité partagée et donne une règle claire pour choisir.
1. L'analogie de la pizza
C'est l'analogie classique, et elle fonctionne remarquablement bien.
Ce que l'analogie enseigne : il n'existe pas de niveau « meilleur ». On choisit selon le contrôle dont on a réellement besoin et le temps qu'on veut consacrer à l'exploitation.
2. Qui gère quoi — la pile complète
Voici la répartition précise des responsabilités, couche par couche.
Notez la constante essentielle : vos données restent votre responsabilité à tous les niveaux, y compris en SaaS. Le fournisseur assure la disponibilité et le chiffrement de l'infrastructure, mais qui accède à quoi et ce que contiennent vos données relève toujours de vous.
3. IaaS — Infrastructure as a Service
4. CaaS — le niveau intermédiaire souvent oublié
Ce niveau n'apparaît pas dans la définition NIST d'origine, mais il est devenu central depuis 2016.
Recommandation concrète pour 2026 : pour une application web moderne conteneurisée, un service comme Google Cloud Run, AWS Fargate ou Azure Container Apps offre souvent le meilleur rapport simplicité / contrôle / portabilité. Vous fournissez une image Docker, le fournisseur gère tout le reste, et votre image reste déplaçable ailleurs.
5. PaaS — Platform as a Service
Erreur très fréquente à éviter : choisir de l'IaaS « parce qu'on veut garder le contrôle », puis passer les six mois suivants à reconstruire à la main ce que le PaaS offrait immédiatement — mise à l'échelle, certificats, déploiements sans interruption, journaux centralisés. Demandez-vous honnêtement : de quel contrôle avez-vous réellement besoin ?
6. Serverless et FaaS
Précision sur le nom : le terme serverless est trompeur. Il y a évidemment des serveurs — vous ne les gérez simplement pas et ne payez pas pour leur temps d'inactivité. Une formulation plus juste serait « sans gestion de serveur ».
Le calcul économique à connaître : le serverless est très économique en trafic faible ou irrégulier, et peut devenir plus cher qu'un conteneur permanent au-delà d'un certain volume constant. Le point de basculement dépend du cas, mais l'ordre de grandeur se situe souvent autour de quelques millions d'invocations mensuelles.
7. SaaS — Software as a Service
Règle d'arbitrage utile : construisez ce qui différencie votre entreprise, achetez en SaaS tout le reste. Personne ne gagne de marché grâce à son serveur de messagerie interne.
8. Le tableau de synthèse
| Modèle | Vous fournissez | Fournisseur gère | Contrôle | Charge d'exploitation | Dépendance |
|---|---|---|---|---|---|
| Serveur possédé | Tout | Rien | Maximal | Maximale | Aucune |
| IaaS | OS + app + données | Matériel, virtualisation | Élevé | Élevée | Faible |
| CaaS | Image + données | Machines, orchestration | Moyen-élevé | Moyenne | Faible |
| PaaS | Code + données | OS, runtime, mise à l'échelle | Moyen | Faible | Moyenne |
| Serverless | Fonction + données | Absolument tout le reste | Faible | Très faible | Élevée |
| SaaS | Données + configuration | Tout | Minimal | Nulle | Élevée |
Les deux colonnes à regarder ensemble : charge d'exploitation et dépendance. Le CaaS occupe une position particulièrement intéressante — charge d'exploitation moyenne et dépendance faible, grâce à la portabilité des images de conteneur.
9. Le modèle de responsabilité partagée
C'est la notion de sécurité la plus importante du cloud, et la plus mal comprise.
Le constat empirique le plus important de cette leçon : la très grande majorité des fuites de données dans le cloud ne proviennent pas d'une faille du fournisseur. Elles proviennent d'erreurs de configuration côté client :
- Un espace de stockage laissé accessible publiquement — la cause la plus fréquente et la plus documentée.
- Une clé d'accès commise dans un dépôt Git public.
- Un rôle avec des droits d'administrateur accordé à un service qui n'en a pas besoin.
- Une base de données exposée sur internet sans mot de passe.
- Une machine virtuelle non mise à jour pendant deux ans.
La ligne de responsabilité se déplace selon le modèle : plus vous montez vers le SaaS, plus le fournisseur en assume. En IaaS, les mises à jour de l'OS sont entièrement votre problème. En PaaS, elles ne le sont plus.
10. Comment choisir — arbre de décision
La question 4 est celle où l'on se trompe le plus. Beaucoup répondent « oui » par habitude et se retrouvent avec une charge d'administration système qu'ils n'avaient pas anticipée. Demandez-vous : « ai-je réellement besoin de compiler un module noyau, ou est-ce que je réponds oui par réflexe ? »
Retenir en 30 secondes
- Les sigles décrivent jusqu'où va la responsabilité du fournisseur.
- IaaS = machine virtuelle nue, vous gérez l'OS. PaaS = vous ne fournissez que le code. SaaS = application prête.
- CaaS (conteneurs managés) est le niveau intermédiaire souvent le meilleur choix : peu d'exploitation, faible dépendance.
- Serverless = vous payez à l'invocation. Excellent en trafic irrégulier, coûteux en trafic constant élevé.
- Vos données restent votre responsabilité à tous les niveaux, y compris en SaaS.
- Responsabilité partagée : le fournisseur sécurise le cloud, vous sécurisez ce qui est dans le cloud.
- La plupart des fuites viennent d'erreurs de configuration client : stockage public, clé dans Git, droits trop larges.
- Règle d'arbitrage : construisez ce qui vous différencie, achetez le reste en SaaS.
Suivant : Régions, zones de disponibilité et haute disponibilité →