Modèle de Responsabilité Partagée Cloud GxP : rôles et matrice RACI
Modèle de Responsabilité Partagée en Cloud GxP : matrice des rôles et responsabilités pour IaaS, PaaS et SaaS
Dans un projet Cloud GxP, une question détermine le succès — ou un écart en audit :
« D’accord, mais qui fait quoi ? »
Le cloud transfère certaines activités opérationnelles (patching, infrastructure, durcissement de la sécurité, sauvegardes, supervision) vers le fournisseur. La responsabilité de la conformité, en revanche, reste la vôtre : vous pouvez déléguer des activités, pas la responsabilité finale.
Cette page vous aide à :
- comprendre les différences réelles entre IaaS, PaaS et SaaS (en termes de contrôles),
- construire une matrice de responsabilités robuste face à l’audit,
- transformer cette matrice en Quality Agreement + SOP + preuves.
Ce qu’est réellement le Modèle de Responsabilité Partagée en contexte GxP
Le principe est simple :
- le fournisseur gère une partie du stack et fournit des contrôles/garanties,
- vous gérez la partie restante et devez démontrer que l’ensemble du système est maîtrisé,
- en inspection, s’il existe une lacune, vous ne pouvez pas dire « c’était le fournisseur » : vous devez démontrer comment vous l’avez pilotée.
Les lignes directrices sont claires : dans le cloud, certaines responsabilités sont partagées, mais l’entreprise réglementée doit s’assurer, via des contrats, des audits et une gouvernance adéquate, que le fournisseur opère selon des standards appropriés.
IaaS vs PaaS vs SaaS : comment évolue le « poids » des responsabilités
Règle pratique (très utile pour QA et IT) :
- SaaS : de nombreuses responsabilités techniques relèvent du fournisseur → vous pilotez la configuration, les accès, les processus, la gouvernance des données, les changements/mises à jour, l’usage prévu et la formation.
- IaaS : davantage de responsabilités restent à la charge du client (OS, patching, hardening, sauvegardes, supervision, etc.) → l’effort de conformité est proche de l’on-premise.
En résumé : en SaaS, une grande partie du stack est gérée par le fournisseur ; en allant vers l’IaaS, les responsabilités et les contrôles côté client augmentent.
La matrice qui fonctionne : domaines de contrôle + ownership + preuves
Une matrice de responsabilités “audit-proof” n’est pas un tableau générique. Elle doit répondre à trois questions :
- Qui exécute l’activité ? (Fournisseur / Client / Partagé)
- Qui approuve ou décide ? (souvent QA / Métier)
- Quelle est la preuve ? (rapports, logs, SOP, tickets, rapports d’audit, rapports SOC, etc.)
Exemple de structure (adaptée à CMS/Excel) :
| Domaine | Exécution | Approbation | Preuves typiques |
|---|---|---|---|
| Accès & rôles (RBAC) | Client | QA / Process Owner | matrice des rôles, logs d’accès, SOP comptes |
| Audit trail | Fournisseur (fonction) + Client (revue) | QA | config. audit trail, SOP de revue, enregistrements |
| Sauvegarde/restauration | Fournisseur / Partagé | IT + QA | politique de sauvegarde, rapports, tests de restauration, tickets |
| Change/mise à jour | Fournisseur (release) + Client (évaluation) | QA | release notes, change records, tests de régression |
| Incident/RCA | Fournisseur + Client | QA | RCA, déviation/CAPA, communications |
| Export/rétention des données | Partagé | QA/RA | tests d’export, procédures, contrat |
Remarque : les domaines et les preuves doivent être adaptés au modèle cloud (SaaS/IaaS) et à la criticité du système.
Du workshop au document : les « bonnes » questions à poser au fournisseur
Une matrice de responsabilités solide naît d’un atelier réunissant fournisseur, QA, IT et métier.
Exemples de questions à forte valeur ajoutée (souvent négligées) :
- « Qui effectue la restauration si un utilisateur supprime des données par erreur : nous via l’interface ou vous sur demande ? »
- « Qui garantit le bon fonctionnement des sauvegardes et quels rapports recevons-nous ? »
- « Dispose-t-on d’un environnement sandbox/staging pour tester les nouvelles releases avant la production ? »
La guide recommande explicitement de clarifier ces points puis de les formaliser dans la matrice et le Quality Agreement.
Comment transformer la matrice en gouvernance réelle (et pas en “un PDF dans un tiroir”)
1) Quality Agreement (QA) / annexes contractuelles
C’est ici que les engagements sont formalisés :
- notification des changements (délais et contenu des release notes),
- gestion des incidents et RCA,
- propriété, restitution et stratégie de sortie des données,
- droits d’audit et accès aux preuves (ex. rapports SOC).
2) SOP internes
Sans SOP, la matrice ne vit pas :
- SOP de gestion des comptes et des privilèges,
- SOP de revue des audit trails,
- SOP de change control cloud (y compris mises à jour SaaS).
3) Preuves opérationnelles
En audit, dire « nous avons une SOP » ne suffit pas : il faut démontrer son application :
- registres de revue,
- change records clôturés avec tests,
- enregistrements de formation,
- revues périodiques.
Erreurs à éviter (celles qui déclenchent les questions de l’auditeur)
- Matrice existante mais non alignée avec le contrat/QA
- « Tout est à la charge du fournisseur » sans droits d’audit ni preuves
- Rôles et accès sans séparation adéquate des tâches
- Absence de règle claire pour les mises à jour SaaS (comment et quand elles sont acceptées)
Mini-checklist (prête à intégrer dans les SOP)
- Une matrice de responsabilités existe pour chaque fournisseur cloud GxP
- La matrice inclut exécution, approbation et preuves
- Les points critiques (sauvegardes, audit trail, change, RCA) sont couverts par le Quality Agreement
- Les SOP internes reflètent le modèle cloud (pas uniquement on-premise)
- Le dossier d’audit contient des preuves d’exécution (enregistrements, rapports, logs)
Souhaitez-vous une structure complète avec exemples, checklists et modèles pour définir les rôles et responsabilités et les présenter efficacement en audit ?
Achetez la guide « SaaS & Cloud Validation : guide d’implémentation GxP » sur guidegxp.com.