IaaS, PaaS, SaaS

Le problème #

Toutes les entreprises n’ont pas besoin du même niveau de contrôle sur leur infrastructure. Une startup qui veut mettre en ligne une API le plus vite possible n’a pas envie de configurer un système d’exploitation, un pare-feu et un load balancer à la main. À l’inverse, une entreprise avec des contraintes réglementaires strictes ou une architecture réseau très spécifique a besoin de maîtriser chaque couche, jusqu’au système d’exploitation.

Sans vocabulaire commun pour désigner ces différents niveaux d’abstraction, les discussions entre équipes techniques et décideurs deviennent confuses : “on migre vers le cloud” ne veut rien dire tant qu’on n’a pas précisé quel type de cloud, et donc qui est responsable de quoi.

L’idée générale #

IaaS, PaaS et SaaS désignent trois niveaux d’abstraction dans la consommation du cloud, qui se distinguent par la frontière entre ce que le fournisseur gère et ce que vous gérez.

• IaaS (Infrastructure as a Service) : le fournisseur donne accès à des ressources brutes — machines virtuelles, stockage, réseau. Vous installez et configurez tout, à partir du système d’exploitation. Exemples : AWS EC2, Azure Virtual Machines, Google Compute Engine.
• PaaS (Platform as a Service) : le fournisseur gère le système d’exploitation, le runtime et l’infrastructure de déploiement. Vous vous concentrez sur votre code applicatif. Exemples : Heroku, AWS Elastic Beanstalk, Render, Vercel.
• SaaS (Software as a Service) : le fournisseur gère tout, y compris l’application elle-même. Vous utilisez le logiciel fini via un navigateur ou une API. Exemples : Gmail, Salesforce, Notion.

Une image classique aide à retenir la répartition des responsabilités : dans un tableau où chaque ligne est une couche technique (application, données, runtime, middleware, OS, virtualisation, serveur, stockage, réseau), le nombre de lignes gérées “par vous” diminue à mesure qu’on avance de IaaS vers SaaS.

Analogie du quotidien #

C’est comme se loger. Le IaaS, c’est louer un terrain nu : vous devez construire la maison, l’électricité, la plomberie, tout vous-même — mais vous avez une liberté totale sur l’architecture. Le PaaS, c’est louer un appartement meublé : les fondations, la structure et les équipements de base sont déjà là, vous n’avez qu’à emménager et vivre votre vie, avec quelques contraintes sur ce que vous pouvez modifier (pas question d’abattre un mur porteur). Le SaaS, c’est réserver une chambre d’hôtel : vous n’avez rien à gérer, ni le ménage ni la maintenance, vous utilisez le service tel quel, avec très peu de personnalisation possible.

Diagramme #

Exemple de code #

Le même objectif — déployer une API Node.js — illustre bien la différence de responsabilité entre IaaS et PaaS.

# --- IaaS : vous configurez tout, à partir de zéro, sur une VM louée ---
sudo apt update && sudo apt install -y nodejs npm nginx
git clone https://github.com/moncompte/mon-api.git
cd mon-api && npm install
# Configuration manuelle de nginx en reverse proxy, du service systemd,
# des certificats TLS, du firewall...
sudo systemctl enable --now mon-api

# --- PaaS : vous décrivez juste votre besoin, la plateforme fait le reste ---
# app.yaml (exemple simplifié pour un PaaS type Elastic Beanstalk / Render)
name: mon-api
runtime: nodejs20
build:
  command: npm install
start:
  command: npm start
instances:
  min: 1
  max: 5   # le PaaS gère lui-même le scaling automatique

Quand utiliser IaaS, PaaS ou SaaS ? #

• IaaS : quand vous avez des besoins précis de configuration réseau, de conformité, ou une stack technique non standard qu’aucune plateforme ne supporte nativement.
• PaaS : quand l’objectif est de livrer vite un produit sans réinventer l’infrastructure de déploiement, et que les contraintes du PaaS (runtimes supportés, scaling automatique standard) sont acceptables.
• SaaS : quand le besoin est générique (messagerie, CRM, suivi de projet) et qu’il n’y a aucune valeur ajoutée à développer sa propre solution.
• Une même entreprise combine généralement les trois selon le besoin : impossible de tout faire en SaaS quand on développe un produit sur-mesure, et rarement pertinent de tout faire en IaaS quand des solutions PaaS ou SaaS existent déjà pour des besoins standards.

Points importants #

• La frontière entre les modèles n’est pas toujours nette : Kubernetes managé, par exemple, se situe entre IaaS et PaaS, parfois appelé CaaS (Container as a Service).
• Monter en abstraction (vers le PaaS ou le SaaS) réduit la charge opérationnelle mais augmente la dépendance au fournisseur (vendor lock-in) : migrer hors d’un PaaS propriétaire peut être coûteux.
• Le choix du modèle a un impact direct sur le profil de l’équipe nécessaire : plus on descend vers IaaS, plus il faut des compétences systèmes et réseau en interne.
• En entretien, ce sujet est souvent utilisé pour vérifier que le candidat comprend que “le cloud” n’est pas un bloc monolithique, mais un ensemble de niveaux de responsabilité partagée entre client et fournisseur.