Choisir entre Infrastructure as a Service, Platform as a Service et Software as a Service est l’une des décisions structurantes de toute stratégie de transformation numérique. Pourtant, la confusion persiste entre ces trois modèles : des directions informatiques signent des contrats SaaS en croyant garder le contrôle de leur infrastructure, ou déploient de l’IaaS sans anticiper la charge opérationnelle que cela implique. Pour un DSI ou un RSSI, bien comprendre ces modèles et leurs implications en matière de sécurité, de conformité et de souveraineté est un prérequis à toute décision d’achat ou de migration.
Trois modèles de service, une seule définition de référence
Le cadre normatif de référence reste NIST SP 800-145 (2011), publié par le National Institute of Standards and Technology. Il définit le cloud computing comme un modèle permettant un accès réseau à la demande à un pool partagé de ressources configurables, et distingue trois modèles de service :
-
IaaS (Infrastructure as a Service) : le fournisseur met à disposition des ressources de calcul, de stockage et de réseau virtualisées. Le client contrôle les systèmes d’exploitation, les applications et dispose d’une capacité limitée sur les composants réseau. Le matériel physique et la couche de virtualisation restent sous la responsabilité du fournisseur.
-
PaaS (Platform as a Service) : le client déploie ses propres applications sur une infrastructure gérée par le fournisseur, en utilisant les langages, bibliothèques et outils supportés par ce dernier. Il ne contrôle pas l’infrastructure sous-jacente mais dispose d’un accès aux paramètres de configuration de l’environnement d’exécution.
-
SaaS (Software as a Service) : le client utilise les applications du fournisseur via un navigateur ou une interface légère. Il n’a aucun contrôle sur l’infrastructure, les systèmes d’exploitation ou les capacités applicatives au-delà des paramètres de configuration utilisateur.
Ces trois modèles ne sont pas des étapes d’une progression linéaire : ils répondent à des cas d’usage distincts, avec des compromis différents entre agilité, contrôle et responsabilité. Le choix du modèle adapté conditionne directement l’architecture cloud retenue, les compétences internes à maintenir et l’étendue des obligations de sécurité qui incombent à l’organisation.
Le modèle de responsabilité partagée : la frontière qui compte
La notion de responsabilité partagée est le concept central pour tout RSSI évaluant une offre cloud. Le principe est simple : le fournisseur est responsable de la sécurité de l’infrastructure cloud, le client est responsable de la sécurité dans l’infrastructure cloud. Cette formulation, popularisée par AWS, est reprise sous des formes proches par Microsoft Azure et GCP.
Ce qui change selon le modèle de service, c’est l’étendue de la responsabilité client.
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Matériel physique | Fournisseur | Fournisseur | Fournisseur |
| Virtualisation / hyperviseur | Fournisseur | Fournisseur | Fournisseur |
| Système d’exploitation | Client | Fournisseur | Fournisseur |
| Middleware / runtime | Client | Fournisseur | Fournisseur |
| Applications | Client | Client | Fournisseur |
| Configuration réseau | Client (partiel) | Client (partiel) | Fournisseur |
| Données | Client | Client | Client |
| Identités et accès | Client | Client | Client |
| Chiffrement des données | Client | Client | Client (partiel, BYOK possible) |
Un point critique, souvent sous-estimé : quelle que soit la couche de service, la gestion des identités, le contrôle d’accès et la classification des données restent systématiquement sous la responsabilité du client. Une compromission par des droits excessifs, un compte de service non rotationné ou un stockage exposé publiquement est toujours une faute côté client, jamais côté fournisseur. Gartner estimait que 99 % des incidents cloud résultent d’erreurs client (mauvaise configuration, droits excessifs, absence de chiffrement) et non de compromission de l’infrastructure fournisseur (Gartner, 2020).
La ligne “Chiffrement des données” mérite une précision en contexte SaaS : dans la majorité des offres, le chiffrement au repos et en transit est géré côté fournisseur. Certaines plateformes proposent une option BYOK (Bring Your Own Key) qui restitue partiellement le contrôle des clés au client. Cette distinction doit être vérifiée contrat par contrat, notamment pour les données soumises au secret médical ou au secret des affaires.
Critères de choix pour DSI et RSSI
Le choix d’un modèle de service ne se réduit pas à une question de coût ou de rapidité de déploiement. Plusieurs dimensions méritent une analyse structurée.
Criticité et souveraineté des données. Pour des données particulièrement sensibles (données de santé, données financières, informations classifiées, données à caractère personnel de grande échelle), la localisation physique et la protection contre les lois à portée extraterritoriale, notamment le Cloud Act américain, doivent être vérifiées contractuellement, quel que soit le modèle de service retenu. En France, l’ANSSI recommande pour ces usages des offres qualifiées SecNumCloud, disponibles en IaaS, PaaS et SaaS auprès d’une dizaine de prestataires.
Maturité opérationnelle des équipes. L’IaaS offre le contrôle maximal, mais exige la capacité de gérer des systèmes d’exploitation, d’appliquer les correctifs de sécurité, de configurer les pare-feu et de superviser les journaux système. Une organisation sans équipe SecOps dimensionnée pour ces tâches prend un risque opérationnel significatif en choisissant l’IaaS. Ce modèle suppose également une CMDB maintenue et des processus ITSM matures : sans inventaire fiable des assets virtuels, la surface d’attaque réelle reste opaque et les audits de conformité deviennent impossibles à conduire rigoureusement. Le PaaS transfère ces responsabilités au fournisseur tout en conservant le contrôle applicatif, un compromis pertinent pour les équipes DevOps qui souhaitent se concentrer sur le code métier.
Contraintes de conformité réglementaire. Les entités soumises à NIS2 (dont le délai de transposition nationale était fixé au 17 octobre 2024) ou à DORA (applicable depuis janvier 2025 pour les entités financières) doivent documenter leur gestion du risque tiers cloud, inclure des clauses contractuelles sur les droits d’audit, la portabilité des données et la notification d’incidents, et démontrer la résilience opérationnelle de leur chaîne de traitement. Ces obligations s’appliquent indépendamment du modèle IaaS, PaaS ou SaaS.
Portabilité et réversibilité. Un déploiement SaaS ou PaaS peut induire une dépendance technique forte envers le fournisseur (vendor lock-in). L’absence de portabilité des données ou des configurations applicatives est un risque stratégique à mesurer avant tout engagement pluriannuel. L’ENISA a publié des lignes directrices spécifiques sur ce sujet (ENISA Cloud Computing Risk Assessment, ENISA Guidelines on Cloud Computing Security for Critical Infrastructure) qui fournissent des grilles d’évaluation pratiques. Les travaux de la CNCF (Cloud Native Computing Foundation) sur l’interopérabilité des workloads conteneurisés complètent utilement cette approche pour les architectures PaaS natives cloud.
SecNumCloud et doctrine française : ce que le RSSI doit savoir
La doctrine “Cloud au centre” publiée par le gouvernement français en 2023 a formalisé l’usage du SecNumCloud comme exigence pour l’hébergement des données sensibles des administrations publiques. Le référentiel version 3.2 de l’ANSSI impose plus de 350 critères répartis en 14 thèmes couvrant les dimensions techniques, organisationnelles, opérationnelles et juridiques. Il a été étendu pour couvrir le CaaS (Container as a Service) en complément des trois modèles classiques.
Pour les organisations privées, la qualification SecNumCloud n’est pas légalement obligatoire, sauf dans le cadre de marchés publics sensibles ou pour les opérateurs d’importance vitale (OIV) et les opérateurs de services essentiels (OSE). Elle constitue néanmoins un marqueur de confiance utile pour objectiver le niveau de sécurité d’un fournisseur cloud, notamment sur les volets souveraineté et protection contre les réquisitions extrajudiciaires.
En 2026, les prestataires qualifiés incluent OVHcloud, Cloud Temple, NumSpot, S3NS (joint-venture Thales-Google) et 3DS Outscale (Dassault Systemes), couvrant les trois modèles de service. La qualification est valide trois ans, avec un audit de surveillance obligatoire tous les 18 mois.
Points de vigilance contractuels et opérationnels
Quel que soit le modèle retenu, plusieurs vérifications s’imposent avant signature :
- Sous-traitance et chaîne de confiance : vérifier si le fournisseur fait appel à des sous-traitants hébergeant des données hors de l’Union européenne, ce qui peut créer des risques au regard du RGPD et des réglementations sectorielles.
- Clauses de réversibilité : s’assurer que le contrat prévoit l’export des données dans un format standard, les délais et les coûts associés à une migration de sortie.
- Notification d’incidents : NIS2 impose une notification initiale sous 24 heures pour les incidents significatifs. Le SLA du fournisseur doit être compatible avec cette exigence, et les procédures de remontée d’incidents doivent être documentées contractuellement.
- Tests de résilience : DORA exige des entités financières la réalisation de tests de pénétration basés sur la menace (TLPT). Les contrats cloud doivent prévoir explicitement le droit d’effectuer ou de faire effectuer ces tests.
- Visibilité des journaux : en SaaS notamment, l’accès aux journaux d’événements de sécurité est souvent conditionné à des niveaux d’abonnement supérieurs. Ce point doit être négocié avant signature, pas après un incident.
Pour approfondir la sécurisation des infrastructures cloud et les stratégies de gouvernance associées, les publications de l’ANSSI sur la cybersécurité en entreprise constituent le point d’entrée recommandé pour les organisations soumises aux cadres réglementaires français et européens.