Les 3 modèles de service cloud, en une phrase chacun
Le cloud computing repose sur une idée simple : louer des ressources informatiques plutôt que les posséder. Mais « louer » peut vouloir dire des choses très différentes selon ce qui est inclus dans le contrat. IaaS, PaaS et SaaS décrivent trois niveaux d'abstraction, du plus proche du matériel (IaaS) au plus proche de l'usage final (SaaS).
Ces trois modèles ne sont pas concurrents : ils coexistent, et une même organisation utilise généralement les trois en parallèle, pour des besoins différents. Le point de référence pour les comparer reste le modèle historique : l'informatique « on-premises », où l'entreprise possède et exploite tout elle-même, du serveur physique jusqu'à l'application.
IaaS — Infrastructure as a Service
L'IaaS fournit des ressources de calcul, de stockage et de réseau virtualisées, facturées à l'usage. Le fournisseur possède et exploite les centres de données et le matériel physique ; vous gérez tout ce qui tourne au-dessus, à commencer par le système d'exploitation.
C'est le modèle qui offre le plus de contrôle et de flexibilité — et qui demande le plus de compétences d'exploitation en interne. Il reste néanmoins bien plus rapide à mettre en œuvre qu'un achat de serveurs physiques : une machine virtuelle se provisionne en quelques minutes, pas en plusieurs semaines.
- Exemples : Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine, IBM Cloud
PaaS — Platform as a Service
Le PaaS fournit une plateforme complète pour développer, déployer et exécuter des applications : serveurs, réseau, stockage, système d'exploitation, bases de données et outils de développement, le tout géré par le fournisseur.
Vous ne gérez plus de machines virtuelles ni de système d'exploitation : vous déployez du code, et la plateforme s'occupe du reste — mise à l'échelle, correctifs du système, disponibilité. C'est le modèle qui accélère le plus le cycle de développement, au prix d'une personnalisation technique plus limitée qu'en IaaS.
- Exemples : Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service
SaaS — Software as a Service
Le SaaS est une application complète, hébergée et gérée par le fournisseur, accessible directement depuis un navigateur ou une application cliente. Ni l'infrastructure, ni la plateforme, ni même l'application elle-même ne sont de votre ressort.
C'est le modèle le plus répandu aujourd'hui : la majorité des logiciels professionnels utilisés au quotidien sont désormais du SaaS. Vous ne payez pas pour de la capacité technique, mais pour un usage fonctionnel — un poste, une licence, un volume de données.
- Exemples : Salesforce, Dropbox, HubSpot, Google Workspace, Microsoft 365
L'analogie de la pizza, pour fixer les idées
Une métaphore largement reprise dans l'industrie, popularisée par Albert Barron (IBM) en 2014, compare les modèles cloud à différentes façons de manger une pizza.
En on-premises, vous faites tout vous-même : vous achetez les ingrédients, vous avez votre propre four, votre table et vos boissons. En IaaS, c'est une pizza à emporter à cuire chez vous : vous n'avez plus à gérer les ingrédients ni la recette, seulement le four et la cuisson. En PaaS, la pizza est livrée toute prête : vous n'avez plus qu'à dresser la table. En SaaS, vous allez au restaurant : tout est pris en charge, du four à la vaisselle — vous n'avez qu'à manger.
Cette image simplifie beaucoup, mais elle capture l'essentiel : à chaque étape, une couche de gestion supplémentaire est déléguée au fournisseur, en échange d'un contrôle plus limité.
Qui gère quoi : la pile technique, couche par couche
La notion clé pour distinguer les trois modèles n'est pas la technologie utilisée, mais la répartition des responsabilités entre vous et le fournisseur. Ce découpage porte un nom : le modèle de responsabilité partagée, central dans les guides Azure, AWS et Google Cloud de memia.
Règle générale : plus on monte dans la pile (IaaS → PaaS → SaaS), plus la responsabilité opérationnelle et sécuritaire bascule vers le fournisseur — et moins vous avez de levier technique pour intervenir.
Ce que le fournisseur gère toujours, quel que soit le modèle
Trois couches restent systématiquement sous la responsabilité du fournisseur cloud, y compris en IaaS :
- La sécurité physique des centres de données (accès, contrôles environnementaux)
- Le réseau physique (routeurs, switches, câblage)
- La couche de virtualisation (hyperviseur) qui permet de faire tourner les machines virtuelles
La couche système d'exploitation : le point de bascule IaaS → PaaS
En IaaS, vous êtes responsable du système d'exploitation installé sur votre machine virtuelle : mises à jour, correctifs de sécurité, configuration, durcissement. C'est un point souvent sous-estimé — beaucoup d'incidents de sécurité en environnement cloud viennent d'un OS mal patché, pas d'une faille chez le fournisseur.
En PaaS, cette responsabilité passe entièrement au fournisseur. Vous ne touchez plus à l'OS ni au runtime (le moteur d'exécution de votre langage de programmation) : vous gérez uniquement votre code applicatif et sa configuration.
La couche application : le point de bascule PaaS → SaaS
En PaaS, l'application elle-même — son code, sa logique métier, ses mises à jour fonctionnelles — reste de votre responsabilité. En SaaS, même cette couche bascule chez le fournisseur : c'est lui qui développe, teste et déploie les nouvelles fonctionnalités du logiciel que vous utilisez.
Ce que vous gérez toujours, quel que soit le modèle
À l'inverse, deux responsabilités restent les vôtres même en SaaS, le modèle le plus « géré » :
- Vos données (contenu, classification, conformité réglementaire)
- La configuration des accès à vos données (qui peut voir quoi, quels droits sont accordés)
IaaS : vous gérez le système d'exploitation. PaaS : vous gérez le code. SaaS : vous gérez la donnée et ses accès. Le reste appartient au fournisseur.
Comment choisir entre IaaS, PaaS et SaaS
Le choix ne se fait pas dans l'absolu, mais en fonction du besoin, des compétences disponibles en interne, et du niveau de contrôle réellement nécessaire. Un mauvais choix se paie soit en complexité opérationnelle inutile (trop de contrôle pour un besoin simple), soit en manque de flexibilité (pas assez de contrôle pour un besoin spécifique).
IaaS a du sens quand...
Vous avez des besoins spécifiques d'infrastructure (configuration matérielle particulière, logiciels legacy, contraintes réglementaires précises), une équipe capable de gérer des serveurs, ou un besoin de contrôle fin sur l'environnement d'exécution.
- Migration d'un système existant qui nécessite un contrôle proche du matériel
- Charges de travail avec des exigences de performance ou de configuration très spécifiques
- Équipes disposant déjà de compétences en administration système
PaaS a du sens quand...
Vous voulez que votre équipe se concentre sur le code plutôt que sur l'infrastructure, que vous développez une application avec un cycle de déploiement fréquent, ou que vous n'avez pas de compétences internes en administration système.
- Développement d'applications avec des déploiements fréquents (plusieurs fois par semaine ou par jour)
- Petites équipes de développement sans administrateur système dédié
- Besoin de scalabilité automatique sans gestion manuelle des serveurs
SaaS a du sens quand...
Vous avez besoin d'une fonction métier standard (CRM, messagerie, stockage de fichiers, comptabilité) sans particularité justifiant un développement sur mesure, et que la rapidité de mise en œuvre prime sur la personnalisation poussée.
- Fonctions métier communes à la plupart des organisations (RH, finance, communication)
- Besoin de démarrer immédiatement, sans phase de développement
- Pas de ressources internes pour maintenir un logiciel dans la durée
Les critères transverses à considérer
Au-delà du besoin technique, trois critères transversaux pèsent souvent plus lourd que la technologie elle-même dans la décision finale.
- Le modèle budgétaire (CapEx vs OpEx) : le cloud transforme un investissement en dépense opérationnelle récurrente, quel que soit le modèle choisi — mais la prévisibilité de cette dépense varie fortement entre un IaaS facturé à l'usage et un SaaS facturé au poste.
- La maturité des équipes internes : un PaaS ou un SaaS mal maîtrisé n'apporte pas les gains promis. Adopter un modèle plus abstrait sans former les équipes à son fonctionnement déplace le problème plutôt que de le résoudre.
- Les exigences de conformité : certains secteurs régulés (santé, finance, secteur public) imposent un niveau de contrôle ou de localisation des données qui oriente naturellement vers l'IaaS, voire l'on-premises, pour certains traitements spécifiques.
Il n'existe pas de modèle « par défaut » à privilégier systématiquement. Une organisation mature évalue chaque projet individuellement, en croisant le besoin technique et les trois critères transversaux ci-dessus, plutôt que d'appliquer une politique unique à l'ensemble de son informatique.
Une organisation utilise généralement les trois modèles en même temps
En pratique, les entreprises ne choisissent pas « un » modèle : elles combinent les trois selon les besoins, sans que ce soit un signe d'indécision — c'est la norme, pas l'exception.
Un exemple concret
Prenons une entreprise de taille moyenne, avec 200 salariés. Elle utilise Microsoft 365 ou Google Workspace pour la bureautique et la messagerie (SaaS), Salesforce pour son CRM (SaaS), une plateforme comme Azure App Service ou Heroku pour héberger l'application métier développée en interne (PaaS), et quelques machines virtuelles (IaaS) pour un logiciel legacy qui ne peut pas encore être migré vers une architecture plus moderne.
Cette même entreprise peut ajouter une fonction serverless (FaaS) pour traiter des exports de données déclenchés une fois par nuit — un besoin trop ponctuel pour justifier une machine virtuelle dédiée ou une application PaaS complète. Le choix se fait projet par projet, pas au niveau de l'organisation entière.
Aucun de ces choix n'est « meilleur » que l'autre dans l'absolu : chacun répond à un besoin différent, avec un niveau de contrôle adapté à ce besoin précis. Une erreur fréquente consiste à vouloir standardiser sur un seul modèle par souci de simplicité — au prix d'un mauvais compromis sur certains projets.
Le serverless (FaaS), une frontière de plus en plus floue
Le serverless (FaaS — Functions as a Service, comme AWS Lambda ou Azure Functions) se situe entre PaaS et une forme d'abstraction encore plus poussée : vous ne gérez même plus le concept de « serveur », seulement des fonctions déclenchées par des événements, facturées à l'exécution plutôt qu'à la capacité réservée. Certaines classifications le rangent dans le PaaS, d'autres en font une catégorie à part entière.
Le SaaS reste le modèle cloud public le plus utilisé : selon le rapport SaaS Management Index 2026 de Zylo, une organisation moyenne gère 305 applications SaaS, et les grandes entreprises en gèrent près de 700. De nouvelles couches émergent également, comme les plateformes exposant des capacités directement aux agents IA — une évolution à suivre plutôt qu'un modèle à maîtriser dès aujourd'hui.
Zylo, SaaS Management Index 2026Les confusions les plus courantes
Quatre erreurs reviennent régulièrement lorsqu'on découvre ces modèles :
Confondre PaaS et SaaS
Une plateforme de développement « as a service » n'est pas un logiciel prêt à l'emploi. Le PaaS demande toujours de développer et déployer du code ; le SaaS non. Beaucoup d'outils se présentent comme « SaaS » alors qu'ils exigent en réalité une configuration technique proche du PaaS — vérifier ce point avant de comparer des offres évite de mauvaises surprises.
Sous-estimer la responsabilité résiduelle en IaaS
Le cloud ne sécurise pas automatiquement votre système d'exploitation. En IaaS, les correctifs de sécurité de l'OS restent de votre ressort — une idée reçue fréquente consiste à croire que le fournisseur « gère la sécurité » dans son ensemble, alors qu'il ne gère que sa part du modèle de responsabilité partagée.
Oublier le risque de lock-in
Plus on monte vers le SaaS, plus il est structurellement difficile de changer de fournisseur (données, intégrations, formats propriétaires). C'est un critère à intégrer dès le choix initial, pas après coup — migrer un CRM SaaS après trois ans d'usage coûte largement plus cher que l'évaluer correctement en amont.
Croire qu'un modèle est objectivement « meilleur » qu'un autre
IaaS, PaaS et SaaS ne forment pas une hiérarchie de qualité, mais un éventail de compromis. Le SaaS n'est pas « plus avancé » que l'IaaS : c'est un choix différent, adapté à un besoin différent. Le bon modèle est celui qui correspond au niveau de contrôle réellement nécessaire, pas celui qui semble le plus moderne.
« Cloud » n'est pas synonyme de « sécurisé par défaut », quel que soit le modèle. Le modèle de responsabilité partagée signifie que vous conservez toujours une part de responsabilité — minimale en SaaS, mais jamais nulle (vos données et leurs accès restent les vôtres).
Où retrouver IaaS, PaaS et SaaS chez les grands fournisseurs
Les trois grands fournisseurs cloud proposent des services dans les trois catégories, avec des noms différents pour des logiques similaires.
Azure, AWS, Google Cloud
Chez Azure, l'IaaS correspond aux Azure Virtual Machines, le PaaS à Azure App Service (ou Azure Functions pour le serverless), et le SaaS à Microsoft 365 ou Dynamics 365. Chez AWS, l'IaaS s'appuie sur Amazon EC2, le PaaS sur AWS Elastic Beanstalk (ou Lambda pour le serverless), et le SaaS se retrouve principalement via l'AWS Marketplace, qui héberge des logiciels tiers packagés. Chez Google Cloud, l'IaaS correspond à Compute Engine, le PaaS à App Engine (ou Cloud Functions pour le serverless), et le SaaS à Google Workspace.
Et les fournisseurs cloud européens ?
Le même découpage IaaS/PaaS/SaaS s'applique aux fournisseurs cloud européens comme OVHcloud ou Scaleway, qui proposent des offres IaaS (instances de calcul) et des services managés proches du PaaS. La logique de responsabilité partagée reste identique : le modèle choisi détermine ce que vous gérez, indépendamment du fournisseur ou de sa localisation géographique.
Ce qui change, en revanche, ce sont les critères annexes : localisation des données, cadre juridique applicable, portabilité en cas de changement de fournisseur. Ce sujet — le choix entre grands fournisseurs américains et alternatives européennes — dépasse le cadre de cet article : il est traité en détail dans le guide memia dédié à la souveraineté cloud.
IaaS, PaaS, SaaS : un concept testé dans (presque) toutes les certifications d'entrée
Comprendre IaaS, PaaS et SaaS est un prérequis quasi universel des certifications cloud d'entrée, quel que soit le fournisseur. C'est généralement l'un des tout premiers concepts abordés, avant même les services spécifiques de chaque plateforme — parce qu'il structure toute la façon de penser le cloud : une fois ces trois modèles bien distingués, il devient beaucoup plus simple de comprendre pourquoi un service donné existe et à quel niveau il se situe.
Un concept transversal aux 3 grands fournisseurs
Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner consacrent chacun un domaine explicite aux concepts cloud fondamentaux, dont IaaS/PaaS/SaaS fait systématiquement partie, aux côtés des modèles de déploiement (public, privé, hybride) et des notions de CapEx/OpEx abordées plus haut.
Utile bien au-delà d'une certification
Ce concept dépasse largement le cadre d'un examen : il structure les échanges entre équipes techniques et métier, aide à lire une architecture existante, et guide les arbitrages lors du choix d'un nouvel outil ou service. C'est l'un des rares concepts cloud qui reste identique quel que soit le fournisseur — un investissement qui ne se périme pas.
Pour aller plus loin
Questions fréquentes
IaaS, PaaS, SaaS : quelle est la différence essentielle ?
La différence porte sur ce que vous gérez versus ce que le fournisseur gère. En IaaS, vous gérez l'OS et tout ce qui tourne dessus. En PaaS, vous gérez seulement votre code. En SaaS, vous gérez seulement vos données et leurs accès — l'application elle-même est entièrement prise en charge par le fournisseur.
Le serverless (FaaS), c'est du PaaS ou autre chose ?
Le serverless (Functions as a Service, comme AWS Lambda ou Azure Functions) est souvent présenté comme une évolution du PaaS : vous déployez des fonctions déclenchées par des événements, sans jamais gérer ni serveur ni runtime persistant. Certaines classifications le rangent dans le PaaS, d'autres en font une catégorie à part.
Quel modèle est le moins cher ?
Il n'y a pas de réponse universelle : cela dépend du volume d'usage, de la durée d'engagement et du coût du temps d'exploitation interne. L'IaaS peut sembler moins cher à l'unité mais demande du temps d'administration système. Le SaaS a un coût par utilisateur/mois prévisible mais peut devenir cher à grande échelle. Le bon calcul inclut le coût total, pas seulement la facture du fournisseur.
Peut-on changer de modèle après coup ?
Techniquement oui, mais le coût de migration augmente avec le niveau d'abstraction. Migrer d'un IaaS à un autre IaaS est relativement direct (ce sont des machines virtuelles). Migrer d'un SaaS vers un autre SaaS implique souvent une perte de données ou de fonctionnalités propriétaires. D'où l'intérêt d'anticiper le risque de lock-in dès le choix initial.
AWS, Azure et Google Cloud proposent-ils les 3 modèles ?
Oui, les trois grands fournisseurs couvrent l'ensemble du spectre : machines virtuelles (IaaS), plateformes applicatives managées (PaaS) et logiciels prêts à l'emploi comme les suites bureautiques (SaaS). Le choix du fournisseur et le choix du modèle sont deux décisions distinctes.
Le SaaS est-il toujours plus sécurisé que l'IaaS ?
Pas nécessairement plus sécurisé — mais le SaaS transfère davantage de responsabilité opérationnelle au fournisseur. Un IaaS mal configuré (OS non patché, accès mal restreints) peut être moins sûr qu'un SaaS correctement paramétré. La sécurité dépend autant du modèle que de la façon dont chaque partie assume sa part de responsabilité.
Qu'est-ce que le CapEx vs OpEx a à voir avec IaaS/PaaS/SaaS ?
Les trois modèles cloud transforment une dépense d'investissement (CapEx — acheter des serveurs) en dépense opérationnelle (OpEx — payer un abonnement ou un usage). C'est vrai pour l'IaaS comme pour le SaaS, mais le niveau d'abstraction supplémentaire du PaaS et du SaaS réduit aussi les coûts opérationnels internes (moins de temps d'administration système).
L'on-premises fait-il encore partie du paysage aujourd'hui ?
Oui. De nombreuses organisations conservent une partie de leur infrastructure on-premises, souvent pour des raisons réglementaires, de latence, ou parce qu'un système existant n'a pas encore été migré. On parle alors d'architecture hybride, combinant on-premises et un ou plusieurs modèles cloud.
Qu'est-ce que le XaaS (« Everything as a Service ») ?
XaaS est un terme générique qui regroupe tous les modèles « as a service » : IaaS, PaaS, SaaS, mais aussi FaaS (fonctions), DBaaS (bases de données), DaaS (postes de travail), et d'autres déclinaisons plus spécialisées. Le principe reste le même : déléguer une couche de gestion technique au fournisseur, en échange d'un abonnement ou d'une facturation à l'usage.
Faut-il connaître IaaS/PaaS/SaaS pour une certification cloud ?
Oui, c'est un concept fondamental présent dans la quasi-totalité des certifications d'entrée cloud (Azure Fundamentals, Google Cloud Digital Leader, AWS Cloud Practitioner). Les guides memia sur Azure, Google Cloud et AWS couvrent ce concept dans leurs premiers decks.