IaaS, PaaS, SaaS : choisir son modèle de service cloud

Les notions d'IaaS, PaaS et SaaS sont souvent présentées comme un simple classement de services cloud. En pratique, ce sont surtout trois niveaux de responsabilité technique. Chacun change la façon dont une équipe construit, opère, sécurise et fait évoluer une application.

Le bon choix ne dépend pas de la définition marketing du service. Il dépend de ce que votre équipe veut contrôler et de ce qu'elle est capable d'assumer durablement.

Une lecture plus utile que la définition classique

La présentation la plus connue dit :

• IaaS : Infrastructure as a Service ;
• PaaS : Platform as a Service ;
• SaaS : Software as a Service.

Cette classification est correcte, mais elle est trop abstraite pour guider une décision d'architecture. Une lecture plus utile consiste à poser une autre question : qui porte quelle part de la complexité ?

Selon le modèle choisi, vous contrôlez plus ou moins le réseau, le système d'exploitation, le runtime, le déploiement, la sécurité, la maintenance et l'évolution de la plateforme. Une seule ligne ne change jamais de propriétaire : la gouvernance des données et des droits d'accès. Même avec un SaaS, une fuite causée par un partage public mal configuré reste votre incident.

IaaS : maximum de contrôle, maximum de responsabilité

Avec l'IaaS, vous disposez principalement de briques d'infrastructure : machines virtuelles, disques, réseaux, load balancers et pare-feu. Vous gardez donc la main sur une grande partie de la pile technique.

Ce que cela apporte

L'IaaS est pertinent quand vous voulez :

• contrôler finement le système et le runtime ;
• gérer vous-même le déploiement ;
• configurer des environnements spécifiques (pilotes, logiciels propriétaires, réseau particulier) ;
• optimiser les coûts d'infrastructure à bas niveau ;
• maintenir des applications avec des contraintes de conformité particulières.

Ce que cela coûte

Ce contrôle a un prix :

• correctifs système et mises à jour de sécurité ;
• durcissement des hôtes ;
• supervision et alerting ;
• sauvegardes et tests de restauration ;
• gestion de la capacité ;
• automatisation du provisioning.

L'IaaS est rarement « moins cher » si l'on oublie le temps humain nécessaire pour opérer correctement la plateforme. Ce temps se réduit avec de l'infrastructure as code et une automatisation qui échoue franchement quand elle ne fait rien : voir Ansible : workflow vert malgré un inventaire introuvable.

Exemple

Une API .NET déployée sur une VM Linux avec reverse proxy, certificats, monitoring et base de données installée sur une autre VM reste un usage typique de l'IaaS.

PaaS : réduire la charge opérationnelle

Le PaaS retire une partie du poids d'exploitation. Vous fournissez l'application, la plateforme prend en charge le reste : runtime, déploiement, montée en charge de base, configuration d'environnement et souvent une observabilité minimale.

Pourquoi le PaaS est attractif

Pour beaucoup d'équipes produit, le PaaS est un excellent compromis :

• mise sur le marché plus rapide ;
• moins de travail d'infrastructure ;
• déploiements simplifiés ;
• bonne expérience développeur.

Il permet de concentrer l'effort sur la logique métier.

Les limites du PaaS

Le PaaS impose aussi des contraintes :

• moins de contrôle sur le runtime exact ;
• limites sur certaines configurations réseau ;
• comportement de plateforme parfois opaque ;
• coût potentiellement élevé à grande échelle ;
• dépendance plus forte au fournisseur.

Le PaaS est intéressant quand la réduction de friction opérationnelle vaut plus que la perte de contrôle fin.

Exemple

Une API ASP.NET Core déployée sur Azure App Service, Google App Engine ou un équivalent managé entre clairement dans cette catégorie.

Entre les deux : conteneurs managés et serverless

Le découpage historique en trois cases ne décrit plus toute l'offre. Deux familles intermédiaires dominent aujourd'hui les nouveaux projets :

• les conteneurs managés (Azure Container Apps, Google Cloud Run, AWS App Runner) : vous livrez une image OCI, la plateforme gère l'exécution et la mise à l'échelle. Vous gardez la maîtrise de l'image et de son contenu, sans gérer de VM ni de cluster. Une image .NET peut d'ailleurs être produite sans Dockerfile, directement par le SDK ;
• le serverless à fonctions (Azure Functions, AWS Lambda) : vous livrez du code déclenché par des événements, facturé à l'exécution. Très efficace pour des traitements courts et irréguliers, moins adapté aux processus longs ou aux latences strictes à froid.

Un cluster Kubernetes managé se situe, lui, plus près de l'IaaS : le plan de contrôle est géré, mais les nœuds, les mises à jour de version, le réseau du cluster et la sécurité des charges restent largement à votre charge.

SaaS : externaliser complètement une capacité

Le SaaS ne consiste pas à déployer votre application. Il consiste à consommer un produit déjà exploité par un fournisseur : CRM, suite collaborative, ticketing, e-mailing, observabilité managée ou API d'IA générative.

Ce que le SaaS change

Avec le SaaS, vous ne construisez pas la plateforme. Vous intégrez un service externe dans votre système. Le sujet devient alors :

• la gestion des contrats d'API et de leurs versions ;
• la dépendance fournisseur et la réversibilité ;
• la gouvernance des données ;
• la sécurité des accès ;
• la robustesse des intégrations.

Le SaaS transfère massivement la charge d'exploitation, mais pas la responsabilité de l'intégration. Les modèles d'IA consommés par API en sont un bon exemple : le fournisseur opère le modèle, mais le routage, le repli et les tests restent chez vous, comme dans résilience IA .NET : routage et failover testés.

Le bon modèle dépend du contexte d'équipe

La meilleure option ne dépend pas uniquement du système. Elle dépend aussi de l'organisation.

Une petite équipe produit cherchera souvent moins d'opérations manuelles, plus de vitesse et moins de risque d'infrastructure. Elle bénéficiera d'une approche proche du PaaS, des conteneurs managés ou du SaaS.

Une équipe plateforme mature peut, au contraire, tirer plus de valeur d'un modèle IaaS ou hybride, si elle a les compétences et les besoins correspondants.

Un bon critère de choix : que voulez-vous vraiment maîtriser ?

Avant de choisir un modèle cloud, posez ces questions :

• avons-nous besoin d'un contrôle fort sur l'infrastructure ?
• l'équipe sait-elle opérer ce niveau de complexité, y compris la nuit et le week-end ?
• la plateforme doit-elle supporter des contraintes très spécifiques ?
• cherchons-nous à accélérer la livraison ou à optimiser le contrôle ?
• quelle dépendance au fournisseur est acceptable, et comment en sortir si nécessaire ?
• quelle est la criticité opérationnelle du système ?

Ces questions valent plus que n'importe quel tableau comparatif générique.

Impact sur l'architecture applicative

Le choix IaaS, PaaS ou SaaS influence directement la façon de déployer les services, la conception des intégrations, la gestion de la configuration, la supervision, la sécurité et la capacité à changer de fournisseur.

Une architecture fortement orientée SaaS impose une excellente maîtrise des contrats d'intégration, des nouvelles tentatives, des délais d'attente, de l'idempotence et du traitement des erreurs extérieures. Les clients HTTP typés présentés dans Refit en .NET et le pattern Inbox/Outbox répondent précisément à ces besoins.

Une architecture plus orientée IaaS impose davantage d'automatisation de l'infrastructure, de standardisation opérationnelle, de gestion des correctifs et de documentation d'exploitation.

Le piège classique : choisir par imitation

Beaucoup d'organisations copient le modèle d'une autre entreprise sans reprendre son contexte : même fournisseur, même pile d'infrastructure, même niveau de contrôle. Cela produit souvent de mauvaises décisions, comme adopter Kubernetes et des microservices pour une équipe de quatre personnes. Les conséquences de ce choix sont détaillées dans pourquoi les architectures microservices échouent.

Un système n'a pas besoin d'être plus complexe que la valeur qu'il doit délivrer.

Une approche pragmatique

Dans beaucoup de contextes, la bonne trajectoire ressemble à ceci :

1. partir d'un niveau de complexité opérationnelle faible (PaaS ou conteneurs managés) ;
2. automatiser ce qui est répétitif ;
3. identifier les vrais points de blocage par la mesure ;
4. reprendre du contrôle seulement là où cela apporte une valeur concrète.

Cette approche évite de payer trop tôt les coûts d'une infrastructure entièrement gérée par l'équipe, tout en gardant une trajectoire d'évolution.

Conclusion

IaaS, PaaS et SaaS ne sont pas seulement des catégories cloud. Ce sont des choix de répartition de responsabilité. Le bon choix dépend de ce que votre système exige, de ce que votre équipe sait opérer et de la vitesse à laquelle vous devez livrer.

Le critère central n'est pas « quel modèle est le plus moderne ? ». Le vrai critère est : « quel niveau de contrôle sommes-nous prêts à assumer sans fragiliser le système ? » D'autres articles sur ces arbitrages sont regroupés dans le parcours cloud et systèmes distribués.