Modèles de service et de déploiement
Comparer IaaS, PaaS et SaaS ainsi que les modèles de déploiement public, privé, communautaire et hybride.
À retenir
- IaaS, PaaS et SaaS correspondent à des niveaux d'abstraction croissants et à des responsabilités décroissantes côté client.
- Les quatre modèles de déploiement (public, privé, communautaire, hybride) répondent à des contraintes réglementaires et opérationnelles différentes.
- Un cloud hybride nécessite une interconnexion réseau et une fédération d'identités réelles pour tenir sa promesse.
- Le choix du modèle de service est un arbitrage entre autonomie technique et charge d'exploitation.
Trois modèles de service, trois niveaux d'abstraction
Le NIST distingue trois modèles de service qui correspondent à des niveaux d'abstraction croissants entre l'infrastructure physique et l'application finale.
| Modèle | Ce que gère le client | Ce que gère le fournisseur | Exemple |
|---|---|---|---|
| IaaS (Infrastructure as a Service) | OS, middleware, runtime, données, applications | Virtualisation, serveurs, stockage, réseau physique | AWS EC2, Azure VM, OpenStack |
| PaaS (Platform as a Service) | Applications et données | OS, middleware, runtime, infrastructure | AWS Elastic Beanstalk, Heroku, OpenShift |
| SaaS (Software as a Service) | Configuration et données d'usage | Tout, y compris l'application elle-même | Microsoft 365, Salesforce, Google Workspace |
Point clé
plus on monte vers le SaaS, moins le client a de contrôle technique, mais moins il porte de responsabilité opérationnelle. Le choix du modèle est un arbitrage entre autonomie et charge d'exploitation.
Les quatre modèles de déploiement
- Cloud public : infrastructure ouverte à plusieurs organisations, exploitée par un fournisseur tiers (AWS, Azure, GCP, OVHcloud).
- Cloud privé : infrastructure dédiée à une seule organisation, hébergée en interne ou chez un tiers, avec un contrôle renforcé sur la conformité et la localisation des données.
- Cloud communautaire : infrastructure partagée entre plusieurs organisations ayant des exigences communes (réglementaires, sectorielles), par exemple entre banques centrales régionales.
- Cloud hybride : combinaison de plusieurs infrastructures (privé + public) reliées par des mécanismes de portabilité des données et des applications.
Attention
un cloud hybride mal conçu, sans interconnexion réseau fiable et sans stratégie de portabilité des données, aboutit souvent à deux silos isolés plutôt qu'à une architecture unifiée. La promesse d'hybridation ne se réalise que si les flux de données et les identités sont réellement fédérés.
Illustration : déployer la même application sur trois modèles
# PaaS-like : déploiement Kubernetes (le client gère le manifeste,
# pas les nœuds ni le control plane si le cluster est managé)
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: registry.example.com/webapp:1.4.0
ports:
- containerPort: 8080
Sur un Kubernetes managé (EKS, AKS, GKE), le client se concentre sur ce manifeste : le fournisseur gère le control plane, les nœuds sous-jacents peuvent être encore gérés par le client (IaaS résiduel) ou totalement abstraits (modèle serverless de type Fargate, proche du PaaS).
Choisir un modèle selon le contexte
Sur le terrain
pour une PME ouest-africaine migrant sa messagerie et sa bureautique, le SaaS (Microsoft 365 ou Google Workspace) est presque toujours le bon choix : la charge de maintenance disparaît. À l'inverse, une banque avec des contraintes réglementaires strictes de résidence des données optera souvent pour un cloud privé ou une offre IaaS locale certifiée, en dépit d'une charge d'exploitation plus lourde.
Astuce
ne confondez pas « modèle de service » et « modèle de déploiement » dans un cahier des charges : on peut avoir du SaaS déployé en cloud privé (rare mais réel dans le secteur bancaire), ce qui surprend souvent les équipes juridiques lors de la rédaction des contrats.