Responsabilité partagée cloud : qui sécurise quoi sur les 5 modèles

Quand une fuite de données survient dans le cloud, qui est responsable — vous ou le fournisseur ? La réponse honnête : ça dépend du modèle de service. Le cloud fonctionne sur un principe de responsabilité partagée où chacun sécurise une partie de la pile, et la frontière se déplace selon que vous utilisez IaaS, CaaS, PaaS, FaaS ou SaaS. Cette page clarifie exactement ce que le fournisseur gère et ce qui vous incombe sur chacun des cinq modèles, liste les erreurs de configuration récurrentes, et défend une opinion claire sur le piège classique du « le cloud est sécurisé par défaut ».

Ce que vous allez apprendre

Le principe de responsabilité partagée et la distinction sécurité « du » vs « dans » le cloud
Les 5 modèles XaaS et leurs frontières de responsabilité (IaaS, CaaS, PaaS, FaaS, SaaS)
Le tableau récapitulatif universel à garder en référence
Les 4 erreurs de configuration les plus courantes en 2026
Une checklist actionnable pour auditer votre posture de sécurité cloud

Prérequis : avoir compris la grille XaaS. Si besoin, lisez d'abord IaaS, PaaS, SaaS, FaaS, CaaS.

1. L'analogie de la location d'appartement

Pour comprendre la responsabilité partagée, imaginez que vous louez un appartement dans un immeuble. Le partage des responsabilités y est intuitif et il transpose exactement à ce qui se passe dans le cloud.

Ce que le propriétaire gère : la structure du bâtiment (murs, toit, fondations), les parties communes (hall, escaliers, ascenseur), la sécurité de l'immeuble (porte d'entrée, interphone, vidéosurveillance), les réseaux jusqu'au compteur (électricité, eau, gaz).

Ce que vous gérez : la serrure de votre porte (et à qui vous donnez les clés), le contenu de l'appartement (vos meubles, vos affaires), vos installations intérieures (vous branchez un appareil défectueux, c'est votre problème), vos visiteurs (vous laissez entrer un cambrioleur, c'est votre responsabilité).

Le cloud fonctionne exactement pareil : le fournisseur sécurise l'immeuble (l'infrastructure), vous sécurisez votre appartement (vos données et configurations). La nuance qu'on ajoute dans le cloud, c'est que plus vous montez dans la pile (de IaaS vers SaaS), plus le fournisseur prend en charge — comme si l'immeuble incluait progressivement les meubles et les services dans le bail.

2. Le modèle de responsabilité partagée

Le modèle définit une frontière claire entre ce que le fournisseur cloud sécurise et ce qui reste sous votre contrôle. Cette frontière se déplace selon le niveau d'abstraction du service utilisé. Voici comment cela fonctionne visuellement :

Modèle de responsabilité partagée : comparaison On-Premise, IaaS, PaaS et SaaS avec zones client et fournisseur

Le schéma montre la responsabilité qui migre progressivement vers le fournisseur au fur et à mesure qu'on monte en abstraction. En on-premise, tout vous incombe. En IaaS, le fournisseur prend en charge l'infrastructure physique. En PaaS, il gère aussi le système et le runtime. En SaaS, il ne vous reste que la configuration et les accès.

Principe fondamental — sécurité « du » vs « dans » le cloud

Le fournisseur cloud est responsable de la sécurité DU cloud (of the cloud). Vous êtes responsable de la sécurité DANS le cloud (in the cloud).

Cette distinction n'est pas une nuance sémantique, c'est la clé du modèle :

Périmètre	Ce que ça couvre	Qui
Sécurité DU cloud	Infrastructure physique, hyperviseurs, réseau backbone, isolation entre clients	Fournisseur
Sécurité DANS le cloud	Données, configurations, accès, applications, conformité de votre périmètre	Vous

Ce que le fournisseur sécurise (toujours, sur tous les modèles)

Quel que soit le modèle XaaS, le fournisseur gère trois piliers communs.

Infrastructure physique : datacenters (accès physique, vidéosurveillance, gardes), alimentation électrique et refroidissement, protection contre les catastrophes (incendie, inondation, séisme).

Infrastructure réseau : réseau backbone entre datacenters, protection DDoS au niveau infrastructure, isolation réseau entre clients (au niveau hyperviseur).

Conformité de base : certifications du fournisseur (ISO 27001, SOC 2, HDS, SecNumCloud selon les acteurs), audits réguliers, conformité réglementaire de leur périmètre opérationnel.

Ce qui vous incombe (toujours, sur tous les modèles)

Quel que soit le modèle XaaS, vous restez responsable de trois domaines.

Vos données : classification (sensible, confidentielle, publique), chiffrement (au repos et en transit), sauvegarde et rétention, suppression sécurisée en fin de vie.

Vos accès : gestion des identités (qui a accès), permissions (à quoi ils ont accès), authentification (MFA, SSO), revue régulière des accès.

Vos configurations : paramètres de sécurité des services activés, règles firewall et groupes de sécurité, logs et monitoring, conformité de votre périmètre.

3. Responsabilités par modèle de service

La frontière de responsabilité varie selon le modèle. Plus vous montez dans la pile XaaS, plus le fournisseur prend en charge — mais vous ne disparaissez jamais complètement, même en SaaS.

IaaS — vous gérez presque tout

En IaaS (EC2, Azure VMs, Compute Engine, Outscale FCU, OVH Public Cloud Instances), le fournisseur ne gère que l'infrastructure de base. Vous portez le poids opérationnel le plus lourd en sécurité, parce que vous avez le contrôle le plus large.

Ce que le fournisseur sécurise : hyperviseur et isolation des VMs, réseau physique et virtuel de base, stockage physique.

Ce que vous sécurisez : système d'exploitation (patches, hardening), configuration réseau (security groups, firewall, NACL), middlewares et runtime, applications, données.

CaaS — l'OS disparaît, l'image OCI reste

En CaaS (Cloud Run, ECS Fargate, App Runner, Container Apps, Kubernetes managé), le fournisseur gère l'OS et le moteur de containers. Vous gérez le container lui-même : ce qui est dans l'image OCI, comment elle est buildée, ce qu'elle expose.

Ce que le fournisseur sécurise : tout ce qu'il gère en IaaS, plus l'OS hôte et le container engine (containerd, CRI-O), l'orchestrateur (Kubernetes managé) ou la plateforme d'exécution (Cloud Run, ECS).

Ce que vous sécurisez : le contenu de l'image OCI (OS de base de l'image, paquets système installés, runtime applicatif), les dépendances applicatives (bibliothèques, frameworks), les secrets dans l'image (à ne jamais y mettre), votre code applicatif, les configurations Kubernetes (RBAC, NetworkPolicy, PodSecurity), vos données.

Le CaaS introduit une nouveauté importante par rapport à l'IaaS : la responsabilité de la chaîne d'approvisionnement de l'image. Une image basée sur ubuntu:latest non patchée embarque toutes les CVE non corrigées d'Ubuntu. Vous devez scanner les images, choisir des bases minimales (distroless, Alpine), signer les images, et tracer les vulnérabilités.

PaaS — vous gérez le code, le fournisseur gère la plateforme

En PaaS (App Service, Cloud Run en mode plateforme, Elastic Beanstalk, Scalingo, Clever Cloud), le fournisseur gère la plateforme complète d'exécution. Vous déployez votre code, le fournisseur l'exécute.

Ce que le fournisseur sécurise : tout ce qu'il gère en CaaS, plus le runtime applicatif (Java, Python, Node.js et leurs CVE), les middlewares (serveur web, base de données managée), le scaling et la haute disponibilité.

Ce que vous sécurisez : votre code applicatif (vulnérabilités SAST/DAST), vos dépendances (CVE des bibliothèques que vous importez), la configuration applicative (gestion de session, CSRF, en-têtes de sécurité), l'authentification et l'autorisation, vos données.

Avantage sécurité : moins de surface d'attaque à votre charge, le fournisseur patche l'OS et le runtime sans intervention de votre part. Attention : vous restez responsable des vulnérabilités dans votre code et vos dépendances applicatives.

FaaS — la fonction est le seul périmètre que vous gérez

En FaaS (AWS Lambda, Azure Functions, Cloud Functions), le fournisseur gère absolument tout autour de votre fonction. Vous écrivez du code, il l'exécute.

Ce que le fournisseur sécurise : tout ce qu'il gère en PaaS, plus le cycle de vie complet du container d'exécution (création, init, exécution, idle, destruction), l'isolation entre invocations, la gestion des permissions IAM associées au runtime.

Ce que vous sécurisez : le code de la fonction (ses CVE, ses logiques métier, ses traitements de données), les dépendances embarquées (paquets npm, pip, Maven utilisés dans le bundle), les permissions IAM attribuées à la fonction (le moindre privilège est critique parce qu'une fonction compromise hérite de tous ses droits), les événements en entrée (validation, sanitisation, anti-injection), les variables d'environnement et secrets (à externaliser dans Secrets Manager / Key Vault).

Le piège classique du FaaS est la prolifération de fonctions sur-privilégiées. Une équipe pressée donne souvent AdministratorAccess à toutes ses Lambdas pour aller vite, et n'audite jamais. Sur 200 fonctions en production, c'est 200 vecteurs d'élévation de privilèges en cas de compromission d'une seule.

SaaS — responsabilité minimale, mais jamais nulle

En SaaS (Gmail, Salesforce, Slack, Datadog, Notion), le fournisseur gère l'application complète. Mais vous restez responsable de plusieurs périmètres essentiels.

Ce que le fournisseur sécurise : toute la pile technique, application et ses mises à jour, infrastructure de l'application, conformité de la plateforme.

Ce que vous sécurisez : la configuration du service (paramètres de sécurité activés, niveaux de partage par défaut, audit logs activés), la gestion des accès utilisateurs (SSO/SAML, MFA obligatoire, désactivation à temps des comptes anciens), vos données dans l'application (classification, exports réguliers, droit à l'oubli RGPD), les intégrations avec d'autres systèmes (clés API, webhooks, OAuth), la conformité réglementaire des données stockées (RGPD, HDS, etc.).

4. Tableau récapitulatif universel — les 5 modèles

Ce tableau synthétise les responsabilités sur les 5 modèles XaaS. C'est la référence que vous gardez sous la main quand vous évaluez votre posture de sécurité.

Couche	IaaS	CaaS	PaaS	FaaS	SaaS
Données	Vous	Vous	Vous	Vous	Partagé
Application / fonction	Vous	Vous	Vous	Vous	Fournisseur
Dépendances applicatives	Vous	Vous	Vous	Vous	Fournisseur
Image OCI / packaging	Vous (si conteneurisé)	Vous	Fournisseur	Fournisseur	Fournisseur
Runtime	Vous	Image	Fournisseur	Fournisseur	Fournisseur
OS	Vous	Fournisseur	Fournisseur	Fournisseur	Fournisseur
Container engine	Vous	Fournisseur	Fournisseur	Fournisseur	Fournisseur
Virtualisation	Fournisseur	Fournisseur	Fournisseur	Fournisseur	Fournisseur
Serveurs / stockage / réseau	Fournisseur	Fournisseur	Fournisseur	Fournisseur	Fournisseur
Accès / IAM	Vous	Vous	Vous	Vous	Vous
Configuration sécurité	Vous	Vous	Vous	Vous	Vous

Lecture : « Vous » = votre responsabilité. « Fournisseur » = sa responsabilité. « Partagé » = dépend du contexte (typiquement : le fournisseur garantit la durabilité, vous gérez le contenu et la classification).

5. Les 4 erreurs de configuration les plus fréquentes en 2026

Dans la pratique courante, ces quatre erreurs représentent à elles seules plus de 80 % des incidents de sécurité côté client. Aucune n'est due au fournisseur — toutes sont des manques de gouvernance interne.

Erreur 1 — « Le cloud est sécurisé par défaut ». Le mythe : « Mon fournisseur cloud est certifié, donc mes données sont en sécurité. » La réalité : le fournisseur sécurise son infrastructure. Vos configurations par défaut sont souvent permissives (bucket de stockage public, ports SSH ouverts à 0.0.0.0/0, pas de chiffrement at-rest). Les fuites de données cloud les plus médiatisées de la décennie sont rarement dues au fournisseur — ce sont des buckets S3 publics ou des security groups trop ouverts. Mitigation : activer les guardrails dès le J1 (chiffrement par défaut, blocage de l'accès public, IAM Access Analyzer, logs activés).

Erreur 2 — « Le fournisseur gère les backups ». Le mythe : « Mes données sont dans le cloud, elles sont sauvegardées. » La réalité : le fournisseur assure la durabilité du stockage (vos données ne disparaissent pas à cause d'un disque défaillant), mais il ne fait pas de backup applicatif. Vous supprimez accidentellement une base RDS, sans snapshot configuré par vous, les données sont perdues. Mitigation : configurer explicitement les backups (snapshots automatisés, réplication cross-région, tests de restauration trimestriels).

Erreur 3 — « Les logs sont automatiques ». Le mythe : « Le cloud trace tout, je pourrai investiguer si besoin. » La réalité : les logs d'audit (CloudTrail AWS, Activity Log Azure, Cloud Audit Logs GCP) sont souvent désactivés par défaut sur les nouveaux comptes ou ont une rétention courte (90 jours par défaut). Mitigation : activer les logs dès le premier jour, rétention adaptée (1 an minimum pour audit, 5 ans pour conformité bancaire), centralisation dans un SIEM.

Erreur 4 — « L'isolation entre clients est parfaite ». Le mythe : « Je suis dans mon propre environnement, personne ne peut accéder à mes données. » La réalité : l'isolation technique est gérée par le fournisseur (et généralement excellente), mais les erreurs de configuration peuvent exposer vos ressources à Internet ou à d'autres comptes. Un bucket avec une policy trop permissive est accessible par n'importe qui. Une fonction Lambda exposée publiquement avec AdministratorAccess est un trou béant. Mitigation : audit régulier des configurations (Trusted Advisor, Defender for Cloud, Security Command Center), Infrastructure as Code avec scan SAST (Checkov, tfsec), IAM Access Analyzer.

6. Spécificités par fournisseur souverain européen

Documentation : docs.outscale.com (sécurité)

Outils pour vérifier vos responsabilités :

Cockpit : console web pour visualiser et gérer vos ressources.
API OAPI : automatiser les audits de configuration via CLI ou Terraform.
Logs d'audit : traçabilité des actions sur votre compte.

Points d'attention :

OOS (Object Storage) : vérifier les policies de bucket, jamais de bucket public par défaut.
IAM : utiliser des Access Keys avec rotation régulière, MFA sur le compte admin.
Security Groups : règles en allowlist (pas de 0.0.0.0/0 sur SSH).
Nets (VPC) : isoler les environnements sensibles dans des Nets séparés.

Certification : Outscale est qualifié SecNumCloud 3.2 par l'ANSSI sur sa région cloudgouv-eu-west-1.

7. Les zones de responsabilité souvent sous-estimées

Le modèle de responsabilité partagée s'enseigne souvent sur trois colonnes (IaaS, PaaS, SaaS). L'arrivée du CaaS et la généralisation du FaaS introduisent deux zones de responsabilité que les équipes découvrent parfois après-coup.

La chaîne d'approvisionnement de l'image OCI (CaaS). En CaaS, le fournisseur prend en charge l'OS hôte et l'orchestrateur, mais l'image OCI reste de la responsabilité de l'équipe. Une image basée sur une distribution non maintenue depuis plusieurs années embarque automatiquement les CVE accumulées sur cette période. Le fournisseur de plateforme ne corrige pas le contenu de l'image. Trois bonnes pratiques permettent de tenir cette responsabilité :

Scanner les images systématiquement en CI (par exemple avec un scanner SCA reconnu) avant publication.
Mettre à jour les images de base régulièrement, en automatisant la reconstruction.
Signer les images publiées pour tracer leur origine et bloquer les images non signées au déploiement.

L'IAM granulaire des fonctions FaaS. En FaaS, la sécurité repose largement sur la qualité des rôles IAM attachés à chaque fonction. Une fonction qui dispose d'un rôle trop permissif et qui traite une entrée utilisateur insuffisamment validée expose, en cas de vulnérabilité applicative, l'ensemble des ressources accessibles via ce rôle. Le principe du moindre privilège prend ici une importance particulière : c'est souvent la seule barrière entre une vulnérabilité applicative et une compromission plus large.

Bonnes pratiques transverses :

Connaître le tableau de responsabilité pour chaque service utilisé et le partager dans la documentation interne.
Activer les guardrails du fournisseur dès l'ouverture du compte (chiffrement par défaut, blocage des ressources publiques par défaut, audit logs, MFA obligatoire pour les comptes humains).
Auditer les permissions IAM régulièrement, en particulier celles des fonctions FaaS et des rôles techniques.
Tester la restauration des sauvegardes au moins annuellement — un backup non testé ne peut pas être considéré comme valide.

À retenir

Sécurité DU cloud = fournisseur ; sécurité DANS le cloud = vous.
Sur les 5 modèles XaaS, plus on monte, plus le fournisseur prend en charge — mais vous ne disparaissez jamais (accès, configuration, données restent vôtres).
CaaS introduit la responsabilité de la chaîne d'approvisionnement de l'image OCI.
FaaS transfère le poids principal sur la qualité des rôles IAM des fonctions.
4 erreurs récurrentes : « cloud sécurisé par défaut », « backups automatiques », « logs automatiques », « isolation parfaite ».
Activer les guardrails dès le J1 est plus efficace que d'auditer après coup.

Prochaines étapes

IaaS, PaaS, SaaS, FaaS, CaaS La grille XaaS qui structure les 5 modèles de responsabilité partagée.

Modèles de déploiement Public, privé, hybride, sovereign : où vivent les données et qui en a la garde juridique.

IAM : gestion des identités et accès La couche transverse de la sécurité cloud, qui reste toujours votre responsabilité.

Souveraineté technologique de la stack Comprendre comment la conformité du fournisseur s'articule avec sa propre conformité.