Modèles cloud : IaaS, PaaS, SaaS — comprendre et choisir

Vous entendez parler d’IaaS, PaaS, SaaS sans vraiment comprendre ce qui les distingue ? Ces trois acronymes représentent les trois façons fondamentales de consommer des services cloud. La différence ? Le niveau de responsabilité que vous conservez.

Ce guide clarifie ces trois modèles de services cloud en expliquant ce que vous gérez et ce que le fournisseur gère dans chaque cas. À la fin, vous saurez choisir le modèle adapté à votre projet — et surtout, vous comprendrez pourquoi ce choix est important.

Ce que vous allez apprendre

Ce guide pose les bases pour comprendre l’offre cloud :

Compétence	Ce que vous saurez faire
Distinguer les modèles	Expliquer IaaS, PaaS, SaaS avec des exemples concrets
Comprendre les responsabilités	Identifier qui gère quoi (vous vs le fournisseur)
Choisir le bon modèle	Sélectionner le modèle adapté à votre contexte
Éviter les pièges	Reconnaître les erreurs courantes de choix

L’analogie : la pizza as a Service

Pour comprendre les modèles cloud, imaginons que vous voulez manger une pizza. Vous avez plusieurs options, de la plus laborieuse à la plus simple :

🏠 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 et cuisez la pizza.

En cloud : Vos propres serveurs dans votre datacenter. Vous gérez tout, du matériel à l’application.

Verdict : Contrôle total, mais énormément de travail.

🛒 IaaS

Acheter les ingrédients

Vous achetez les ingrédients au supermarché (tomates, fromage, pâte). Vous utilisez votre four et faites la pizza vous-même.

En cloud : Le fournisseur vous donne l’infrastructure (serveurs, réseau, stockage). Vous installez l’OS, les middlewares et vos apps.

Verdict : Moins de travail de base, mais vous cuisinez encore.

📦 PaaS

Pizza à emporter non cuite

Vous commandez une pizza préparée mais pas cuite. Vous la mettez au four et la personnalisez (fromage, herbes).

En cloud : Le fournisseur vous donne une plateforme prête (OS, runtime, BDD managée). Vous déployez uniquement votre code.

Verdict : La préparation est faite, vous gérez la cuisson finale.

🍽️ SaaS

Manger au restaurant

Vous allez au restaurant, commandez une pizza et la mangez. Pas de cuisine, pas de vaisselle.

En cloud : Le fournisseur vous donne une application prête à l’emploi (Gmail, Salesforce, Slack). Vous l’utilisez, point.

Verdict : Service complet, aucun effort technique.

Les trois modèles en détail

IaaS — Infrastructure as a Service

Définition : Le fournisseur vous loue l’infrastructure de base (serveurs virtuels, stockage, réseau). Vous gérez tout ce qui est au-dessus : système d’exploitation, middlewares, applications, données.

En pratique : Quand vous lancez une VM (machine virtuelle) sur AWS EC2 ou Outscale, vous obtenez l’équivalent d’un serveur physique, mais virtualisé. Vous choisissez la puissance (CPU, RAM), le stockage, et vous installez ce que vous voulez dessus — exactement comme si vous aviez un serveur dans votre datacenter, mais sans gérer le matériel physique.

Ce que le fournisseur gère :

Datacenters physiques (bâtiments, électricité, refroidissement)
Serveurs physiques et hyperviseurs
Réseau physique et virtualisation réseau
Stockage physique

Ce que vous gérez :

Systèmes d’exploitation (installation, mises à jour, patches)
Configuration réseau virtuel (firewall, load balancer)
Middlewares (serveurs web, bases de données)
Applications et données
Sécurité de vos workloads

Exemples concrets :

Fournisseur	Service IaaS
AWS	EC2, EBS, VPC
Azure	Virtual Machines, Managed Disks
GCP	Compute Engine, Persistent Disk
OUTSCALE	VM, Net, Block Storage

Cas d’usage typiques :

Migration “lift and shift” d’applications existantes
Besoin de contrôle total sur l’infrastructure
Applications avec des exigences spécifiques (GPU, configurations particulières)
Environnements de développement/test flexibles

PaaS — Platform as a Service

Définition : Le fournisseur gère l’infrastructure ET la plateforme d’exécution. Vous déployez uniquement votre code. Plus besoin de gérer les serveurs, les mises à jour système ou les middlewares.

En pratique : Imaginez que vous développez une application Python. Avec PaaS, vous faites un git push et votre application est en ligne. Pas de serveur à configurer, pas d’OS à mettre à jour, pas de certificat SSL à gérer. Le fournisseur s’occupe de tout ça. Vous vous concentrez sur ce qui compte : votre code métier.

Le gain réel : Une équipe qui passe de IaaS à PaaS récupère souvent 20-40% de temps précédemment consacré à la maintenance infrastructure. Ce temps peut être réinvesti dans le développement produit.

Ce que le fournisseur gère :

Tout ce que gère IaaS, plus :
Système d’exploitation (patches, mises à jour)
Runtime (Java, Python, Node.js…)
Middlewares et bases de données managées
Scaling automatique
Haute disponibilité de la plateforme

Ce que vous gérez :

Votre code applicatif
La configuration de l’application
Les données
La sécurité applicative (authentification, autorisation)

Exemples concrets :

Fournisseur	Service PaaS
AWS	Elastic Beanstalk, App Runner, Lambda
Azure	App Service, Azure Functions
GCP	App Engine, Cloud Run, Cloud Functions
Heroku	Heroku Platform
Vercel	Vercel Platform
Scalingo	Scalingo Platform

Cas d’usage typiques :

Développement d’applications web/API modernes
Équipes sans expertise infrastructure
Besoin de déploiements rapides et fréquents
Applications avec charge variable (scaling automatique)

SaaS — Software as a Service

Définition : Le fournisseur gère tout, de l’infrastructure à l’application. Vous utilisez un logiciel prêt à l’emploi via un navigateur ou une API.

En pratique : 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, quel OS est utilisé, ni comment le scaling est géré. Vous payez un abonnement, vous utilisez le service.

Le compromis : Vous gagnez énormément en simplicité, mais vous perdez en personnalisation. Avec SaaS, vous utilisez l’application telle qu’elle est conçue. Si elle ne correspond pas à 100% à vos besoins, vous devez vous adapter ou chercher une alternative.

Ce que le fournisseur gère :

Infrastructure complète
Plateforme et runtime
Application elle-même
Mises à jour fonctionnelles
Support et maintenance

Ce que vous gérez :

Configuration utilisateur (préférences, paramètres)
Vos données dans l’application
Gestion des accès utilisateurs
Intégrations avec d’autres outils

Exemples concrets :

Catégorie	Exemples SaaS
Email	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

Cas d’usage typiques :

Besoins standards couverts par des solutions existantes
Pas de compétences ou de volonté de gérer l’infrastructure
Démarrage rapide sans investissement initial
Fonctionnalités complexes difficiles à développer soi-même

Tableau comparatif : qui gère quoi ?

Ce tableau est la clé pour comprendre les modèles cloud. Il résume les responsabilités selon le modèle. Plus une case est “Vous”, plus vous avez de travail (et de contrôle).

Comment lire ce tableau : Prenez la colonne IaaS. Vous voyez que vous gérez les Applications, Données, Runtime, Middleware et OS. C’est beaucoup ! Maintenant regardez PaaS : vous ne gérez plus que Applications et Données. Le fournisseur a pris en charge 3 couches supplémentaires.

Couche	On-Premise	IaaS	PaaS	SaaS
Applications	Vous	Vous	Vous	Fournisseur
Données	Vous	Vous	Vous	Partagé
Runtime	Vous	Vous	Fournisseur	Fournisseur
Middleware	Vous	Vous	Fournisseur	Fournisseur
OS	Vous	Vous	Fournisseur	Fournisseur
Virtualisation	Vous	Fournisseur	Fournisseur	Fournisseur
Serveurs	Vous	Fournisseur	Fournisseur	Fournisseur
Stockage	Vous	Fournisseur	Fournisseur	Fournisseur
Réseau	Vous	Fournisseur	Fournisseur	Fournisseur

Lecture : “Vous” = vous êtes responsable. “Fournisseur” = le cloud provider gère. “Partagé” = responsabilité partagée selon le contexte.

Comment choisir le bon modèle ?

Le choix dépend de plusieurs facteurs. Il n’y a pas de réponse universelle — le meilleur modèle dépend de votre contexte : compétences de l’équipe, type d’application, contraintes réglementaires, budget.

Voici un arbre de décision simplifié pour vous guider :

Question 1 : Avez-vous besoin d’un logiciel standard ?

Oui → Cherchez d’abord une solution SaaS. Exemples : monitoring (Datadog), CI/CD (GitHub Actions), email (Gmail).

Non → Passez à la question 2.

Question 2 : Avez-vous des contraintes d’infrastructure spécifiques ?

Oui (GPU, configuration réseau particulière, OS exotique) → IaaS vous donne le contrôle nécessaire.

Non → Passez à la question 3.

Question 3 : Avez-vous une équipe ops/infrastructure ?

Oui, et elle a du temps → IaaS peut être pertinent si vous voulez le contrôle.

Non, ou elle est surchargée → PaaS vous libère de la gestion infrastructure.

Matrice de décision rapide

Critère	IaaS	PaaS	SaaS
Contrôle maximum	✅	❌	❌
Déploiement rapide	❌	✅	✅
Pas d’expertise infra requise	❌	✅	✅
Personnalisation totale	✅	⚠️	❌
Coût prévisible	⚠️	✅	✅
Éviter le lock-in	✅	⚠️	❌

Légende : ✅ = avantage fort, ⚠️ = dépend du cas, ❌ = pas l’objectif de ce modèle.

Pièges courants à éviter

Après des années à accompagner des équipes dans leur adoption du cloud, voici les erreurs les plus fréquentes que je constate. Les connaître vous évitera de perdre du temps et de l’argent.

Piège 1 : Choisir IaaS “par défaut”

Le problème : Beaucoup d’équipes choisissent IaaS par habitude (on a toujours géré des serveurs) alors que PaaS suffirait.

Conséquence : Temps perdu à gérer l’OS, les patches, le scaling manuel. L’équipe devient “ops” au lieu de développer.

Solution : Posez-vous la question : “Qu’est-ce qui m’empêche d’utiliser PaaS ?” Si la réponse est “rien de concret”, essayez PaaS.

Piège 2 : Sous-estimer le travail IaaS

Le problème : IaaS semble moins cher (on paie juste des VMs). Mais le coût caché est le temps de votre équipe pour tout gérer : patches de sécurité, mises à jour, monitoring, gestion des certificats, scaling manuel…

Conséquence : Une VM à 50€/mois + 2 jours/mois d’un ingénieur pour la maintenir = bien plus cher qu’un PaaS à 150€/mois. C’est ce qu’on appelle le TCO (Total Cost of Ownership).

Solution : Calculez le coût total incluant le temps humain, pas juste le coût infrastructure. Multipliez les heures de maintenance par le taux journalier de vos ingénieurs.

Piège 3 : Ignorer le lock-in SaaS

Le problème : On adopte un SaaS, on y met toutes ses données, puis on réalise qu’on ne peut plus partir (ou que ça coûte très cher).

Conséquence : Dépendance à un fournisseur, augmentation des prix subie, fonctionnalités imposées.

Solution : Avant d’adopter un SaaS, vérifiez : export des données, API ouverte, alternatives existantes, coût de migration.

Piège 4 : Mélanger les modèles sans cohérence

Le problème : Avoir du IaaS, du PaaS et du SaaS sans stratégie claire. Chaque équipe choisit ce qu’elle veut.

Conséquence : Complexité de gestion, compétences dispersées, coûts incontrôlés.

Solution : Définissez une stratégie cloud avec des modèles par défaut et des exceptions justifiées.

Exemples concrets par type de projet

Contexte : Une startup développe une application web SaaS pour ses clients.

Choix recommandé : PaaS (ex: Heroku, Vercel, AWS App Runner)

Pourquoi :

L’équipe doit se concentrer sur le produit, pas l’infrastructure
Le scaling automatique gère les pics de charge
Déploiements rapides via git push
Pas besoin d’expertise ops

Checklist de décision

Avant de choisir un modèle, prenez 10 minutes pour répondre à ces questions. Ne sautez pas cette étape — un mauvais choix initial coûte cher à corriger.

Existe-t-il un SaaS qui répond à mon besoin ? (Si oui, l’évaluer en premier)
Ai-je des contraintes techniques qui imposent IaaS ? (GPU, OS spécifique, configuration réseau particulière)
Mon équipe a-t-elle les compétences ops pour gérer IaaS ? (Linux, sécurité, réseau)
Ai-je calculé le coût total (infra + temps humain) ?
Ai-je vérifié les options d’export/migration ? (Portabilité des données)
Ma stratégie cloud est-elle documentée ? (Pour éviter le chaos multi-modèles)

À retenir

Concept	Point clé
IaaS	Vous louez l’infrastructure, vous gérez tout le reste (OS, apps, données)
PaaS	Vous déployez votre code, le fournisseur gère la plateforme
SaaS	Vous utilisez une application prête, le fournisseur gère tout
Choix par défaut	PaaS pour les nouvelles apps, sauf contrainte spécifique
Coût réel	Inclure le temps humain, pas juste le coût infrastructure
Lock-in	Toujours vérifier les options d’export avant d’adopter un SaaS

Prochaines étapes

Maintenant que vous comprenez les modèles cloud, explorez les concepts liés :

Responsabilité partagée Comprendre qui est responsable de quoi en sécurité cloud