Le modèle de responsabilité partagée, en une explication
Le modèle de responsabilité partagée définit qui, du fournisseur cloud ou du client, est responsable de la sécurité de chaque couche de la pile technique. AWS résume ce partage par une formule devenue une référence dans l'industrie : la « sécurité DU cloud » relève du fournisseur, la « sécurité DANS le cloud » relève du client.
Ce modèle n'est pas une simple précaution contractuelle : c'est la base sur laquelle repose toute stratégie de sécurité cloud cohérente. Ignorer sa part de responsabilité, ou la sous-estimer, est la cause la plus fréquente d'incident de sécurité en environnement cloud aujourd'hui.
Ce qui relève toujours du fournisseur
Quel que soit le modèle de service utilisé, le fournisseur reste responsable de la sécurité physique des centres de données, du réseau physique (routeurs, câblage, infrastructure backbone), et de la couche de virtualisation qui isole les clients entre eux.
Ce qui relève toujours du client
À l'inverse, quatre responsabilités restent les vôtres, quel que soit le modèle de service : vos données, la gestion des identités et des accès (IAM), la configuration de vos ressources, et la classification de la sensibilité de vos informations.
Ce qui varie : la zone intermédiaire
Entre ces deux extrêmes se trouve une zone dont la répartition dépend du modèle de service choisi : le système d'exploitation, le réseau virtuel, le runtime applicatif, et le chiffrement. C'est cette zone qui génère le plus de confusion — et donc le plus d'erreurs.
Le chiffrement illustre bien cette ambiguïté : le fournisseur propose presque toujours des mécanismes de chiffrement au repos et en transit, mais activer ces mécanismes, gérer les clés de chiffrement et s'assurer qu'ils couvrent bien toutes les ressources concernées reste, dans l'immense majorité des cas, une action que le client doit entreprendre explicitement — elle n'est pas automatique par défaut sur tous les services.
Comment Azure, AWS et Google Cloud présentent ce modèle
Les trois grands fournisseurs adhèrent au même principe général, mais le formulent différemment — une nuance qui a son importance dans la façon dont chacun accompagne (ou non) ses clients.
AWS : une ligne de partage nette
AWS formule le modèle de la façon la plus directe : « security of the cloud » (AWS) versus « security in the cloud » (le client). Cette formulation trace une frontière claire, mais laisse au client l'entière responsabilité de comprendre où elle se situe exactement pour chaque service utilisé.
Azure : un partage documenté par catégorie de responsabilité
Azure documente le modèle par catégorie explicite (identité, application, système d'exploitation, réseau, hôte, infrastructure physique) et par modèle de service, avec des tableaux détaillés indiquant qui gère quoi pour chaque catégorie, en IaaS, PaaS et SaaS.
Google Cloud : le modèle « shared fate »
Google Cloud va plus loin avec le concept de « shared fate » (destin partagé) : plutôt que de simplement délimiter une frontière de responsabilité, Google s'engage à fournir des garde-fous et des outils supplémentaires pour aider activement les clients à atteindre des résultats sécurisés, plutôt que de se contenter de dire « ceci est votre problème ».
« Responsabilité partagée » et « destin partagé » ne sont pas juste des choix marketing différents : le second implique un accompagnement plus actif du fournisseur (configurations sécurisées par défaut, outils intégrés), plutôt qu'une simple division théorique des tâches sur le papier.
La frontière varie selon IaaS, PaaS et SaaS
La répartition précise des responsabilités dépend directement du modèle de service utilisé — c'est le lien direct entre ce sujet et les modèles IaaS/PaaS/SaaS traités dans notre article dédié.
- En IaaS, vous gérez le système d'exploitation et tout ce qui tourne dessus — c'est la zone de responsabilité client la plus large.
- En PaaS, le fournisseur gère l'OS et le runtime — vous gérez votre code, sa configuration, et les données qui y transitent.
- En SaaS, le fournisseur gère l'application entière — il ne vous reste que vos données et la configuration des accès à ces données.
Notre article IaaS, PaaS, SaaS détaille cette répartition couche par couche, avec l'analogie de la pizza pour la visualiser simplement.
Pourquoi la plupart des failles cloud viennent du client, pas du fournisseur
Ce n'est pas une affirmation théorique : c'est une tendance mesurée de façon répétée par les analystes en sécurité cloud depuis plusieurs années, qui s'accentue plutôt qu'elle ne se résorbe.
L'essentiel des incidents vient d'erreurs de configuration
Gartner estime que, jusqu'en 2026, la quasi-totalité des défaillances de sécurité cloud seront imputables au client, principalement à cause d'erreurs de configuration — pas à une faille technique chez le fournisseur. Une étude Check Point va dans le même sens : 82 % des entreprises ont connu un incident de sécurité lié à une mauvaise configuration cloud.
Des failles qui restent invisibles longtemps
Le délai moyen de détection d'une faille dépasse 180 jours — une fenêtre largement suffisante pour qu'un attaquant opère sans être repéré. Une part significative des ressources cloud (environ un tiers) reste insuffisamment surveillée, chacune dissimulant en moyenne plus d'une centaine de vulnérabilités non traitées.
Gartner prévoit que la quasi-totalité des défaillances de sécurité cloud d'ici 2026 seront dues à des erreurs du client. Check Point rapporte que 82 % des entreprises ont subi un incident lié à une mauvaise configuration cloud. Le délai moyen de détection d'une faille dépasse 180 jours.
Gartner · Check Point Research, 2026Les erreurs de configuration les plus courantes côté client
Quatre familles d'erreurs reviennent systématiquement dans les analyses d'incidents cloud, toutes directement liées à des responsabilités qui incombent au client dans le modèle partagé.
Stockage exposé publiquement
Des espaces de stockage cloud (buckets, conteneurs) configurés par erreur en accès public restent l'une des causes les plus fréquentes de fuite de données — un exemple emblématique et récurrent de responsabilité client mal assumée : le fournisseur ne configure jamais un stockage en public à votre place.
Permissions IAM excessives
La gestion des identités et des accès est la cause la plus fréquente de faille de données côté client. Le principe du moindre privilège — n'accorder que les droits strictement nécessaires — est simple à énoncer mais rarement appliqué avec rigueur dans la durée, car les permissions ont tendance à s'accumuler à mesure que les projets évoluent, sans être révisées à la baisse.
- Utilisateurs et comptes de service disposant de droits plus larges que ce que leur usage réel nécessite
- Comptes inactifs jamais désactivés après le départ d'un salarié ou la fin d'un projet
- Une part significative des comptes IAM AWS, comptes de service Google Cloud et applications Microsoft Entra ID conservent une clé d'accès vieille de plus d'un an — une fenêtre de risque que le fournisseur ne peut pas fermer à votre place
Absence d'authentification multifacteur sur les comptes à privilèges
L'authentification multifacteur (MFA) reste l'une des mesures les plus efficaces pour limiter l'impact d'un mot de passe compromis, et elle est proposée nativement par les trois grands fournisseurs. Son absence sur les comptes disposant de privilèges élevés — administrateurs, comptes de service critiques — reste pourtant fréquente, généralement par simple oubli lors de la création du compte plutôt que par choix délibéré.
Clés et secrets jamais renouvelés
Les clés d'API, secrets applicatifs et clés de chiffrement partagées ou jamais renouvelées créent une fenêtre de risque qui s'élargit avec le temps. La rotation régulière des secrets est une responsabilité client dans les trois modèles de service, y compris en SaaS pour les intégrations tierces.
Aucune de ces erreurs n'est une défaillance du fournisseur cloud. Toutes relèvent directement de la part client du modèle de responsabilité partagée — ce qui signifie qu'elles sont toutes évitables avec les bons processus internes, indépendamment du fournisseur choisi.
Responsabilité partagée et conformité
Mal comprendre le modèle de responsabilité partagée n'est pas seulement un risque de sécurité : c'est aussi, de plus en plus, un risque de non-conformité réglementaire, avec des conséquences financières directes.
Un lien direct entre configuration et non-conformité
Une part importante des organisations déclare être en situation de non-conformité vis-à-vis d'au moins un référentiel réglementaire du fait de problématiques liées au cloud, et une proportion significative des échecs d'audit de conformité est directement liée à des problèmes de configuration relevant de la responsabilité du client — pas du fournisseur.
Le règlement DORA, un signal fort en Europe
Le règlement européen DORA (Digital Operational Resilience Act), pleinement applicable depuis janvier 2025, impose aux entités financières de démontrer leur capacité à résister, répondre et se rétablir face aux incidents liés aux technologies de l'information — y compris ceux résultant d'une mauvaise gestion de leur part de responsabilité cloud. C'est un exemple concret de réglementation qui rend ce sujet non négociable pour un secteur entier.
Un sujet qui dépasse un seul règlement
DORA n'est qu'un exemple parmi d'autres cadres qui rendent la responsabilité partagée explicite : le RGPD impose au responsable de traitement (souvent le client, pas le fournisseur) de garantir la protection des données personnelles, tandis que des référentiels de certification comme ISO 27001 ou SOC 2 exigent des preuves documentées que chaque partie assume effectivement son périmètre — pas seulement qu'il soit défini sur le papier.
Comment bien assumer sa part de responsabilité
Assumer correctement sa part du modèle ne demande pas une expertise de sécurité de très haut niveau : trois réflexes structurants couvrent l'essentiel du risque.
Cartographier précisément ce qui vous revient
Pour chaque service cloud utilisé, identifier explicitement ce qui relève de votre responsabilité (souvent documenté par le fournisseur lui-même) évite les angles morts qui apparaissent quand la responsabilité est supposée plutôt que vérifiée.
Automatiser les contrôles plutôt que les confier à la vigilance individuelle
Les outils de posture de sécurité cloud (souvent proposés nativement par les fournisseurs) détectent automatiquement les configurations à risque — stockage public, permissions excessives, absence de MFA — bien plus efficacement qu'une revue manuelle ponctuelle.
Former les équipes qui déploient, pas seulement l'équipe sécurité
La majorité des erreurs de configuration ne viennent pas d'une négligence délibérée, mais d'une méconnaissance du modèle chez les équipes qui déploient au quotidien. Une bonne compréhension du modèle de responsabilité partagée, diffusée au-delà de la seule équipe sécurité, réduit mécaniquement le risque — la sécurité cloud n'est pas qu'une affaire d'experts, c'est une compétence transverse.
Revoir périodiquement, pas seulement au moment du déploiement initial
Une configuration sécurisée au moment du déploiement ne le reste pas indéfiniment : de nouveaux services sont ajoutés, des permissions temporaires deviennent permanentes par oubli, des comptes changent de rôle sans que leurs accès soient ajustés en conséquence. Une revue périodique — trimestrielle a minima pour les environnements critiques — permet de détecter cette dérive avant qu'elle ne devienne un point d'entrée exploité.
Un domaine à part entière dans les certifications d'entrée
Le modèle de responsabilité partagée constitue généralement un domaine explicite des certifications cloud d'entrée — Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner l'abordent tous les trois en détail, aux côtés des concepts de sécurité, de conformité et de gouvernance.
Ce n'est pas un hasard : c'est l'un des rares concepts cloud directement actionnable au quotidien, indépendamment du niveau technique du poste occupé — comprendre sa part de responsabilité est utile à un développeur comme à un décideur métier qui valide un choix de fournisseur.
Pour aller plus loin
Questions fréquentes
Qu'est-ce que le modèle de responsabilité partagée en une phrase ?
C'est le cadre qui définit qui, du fournisseur cloud ou du client, est responsable de sécuriser chaque couche de la pile technique — le fournisseur sécurise toujours l'infrastructure physique, le client reste toujours responsable de ses données et de ses accès.
Le fournisseur cloud est-il responsable si mes données fuitent ?
Cela dépend de la cause. Si la fuite vient d'une faille dans l'infrastructure du fournisseur (rare), c'est sa responsabilité. Si elle vient d'une mauvaise configuration de votre part (stockage public, permissions excessives), c'est votre responsabilité, même si les données étaient hébergées chez un grand fournisseur reconnu pour sa sécurité.
Pourquoi le modèle diffère-t-il entre IaaS, PaaS et SaaS ?
Parce que le niveau d'abstraction technique change ce que le fournisseur gère à votre place. En IaaS, il ne gère que le matériel et la virtualisation ; en SaaS, il gère aussi l'application entière. Plus il gère de couches, plus votre périmètre de responsabilité se réduit.
Qu'est-ce que le modèle « shared fate » de Google Cloud ?
C'est une évolution du modèle de responsabilité partagée où le fournisseur ne se contente pas de définir une frontière théorique, mais s'engage activement à aider le client à atteindre un résultat sécurisé — via des configurations sécurisées par défaut et des outils intégrés, plutôt qu'une simple documentation de qui fait quoi.
La sécurité IAM est-elle vraiment toujours de mon ressort ?
Oui, dans les trois modèles de service (IaaS, PaaS, SaaS) sans exception. Le fournisseur peut proposer des outils IAM robustes, mais la configuration de ces outils — qui a accès à quoi, avec quelles permissions, avec ou sans MFA — reste entièrement de votre responsabilité.
Pourquoi la détection des failles cloud prend-elle autant de temps ?
Parce que de nombreuses ressources cloud restent insuffisamment surveillées, et que les erreurs de configuration ne génèrent pas toujours d'alerte immédiate — elles créent une exposition silencieuse qui n'est détectée qu'au moment d'un audit, d'un scan de sécurité, ou d'une exploitation active par un attaquant.
Le règlement DORA concerne-t-il toutes les entreprises ?
Non, DORA cible spécifiquement les entités financières opérant dans l'Union européenne (banques, assurances, gestionnaires d'actifs, etc.) et leurs fournisseurs de services informatiques critiques. Il illustre néanmoins une tendance réglementaire plus large : la responsabilité cloud mal assumée devient un risque de conformité, pas seulement un risque technique.
Un audit de sécurité cloud suffit-il à couvrir ma part de responsabilité ?
Un audit ponctuel identifie l'état à un instant T, mais la configuration cloud évolue en continu (nouveaux déploiements, nouveaux accès). La bonne pratique combine un audit initial avec des contrôles automatisés permanents, pas un audit isolé suivi d'aucun suivi.
Comment savoir précisément ce qui relève de ma responsabilité pour un service donné ?
Les trois grands fournisseurs publient une documentation dédiée au modèle de responsabilité partagée, généralement déclinée service par service. C'est le point de départ le plus fiable, à privilégier sur des suppositions génériques qui varient d'un service à l'autre.
Faut-il connaître ce modèle pour une certification cloud ?
Oui, c'est un concept central des certifications d'entrée Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner, généralement abordé dans le domaine consacré à la sécurité et à la gouvernance.