Google Cloud et RGPD : vérifier le périmètre réel

Google Cloud peut être utilisé pour traiter des données personnelles, mais une région européenne et un contrat ne valident pas toute l’architecture. Il faut décider quels services, accès, copies et transferts sont autorisés pour votre traitement précis. La première étape est de rapprocher les engagements du fournisseur des ressources réellement déployées, y compris les anciens projets et les exports.

Commencer par les traitements et les rôles

Recensez les applications, jeux de données, catégories de personnes et finalités. Un prestataire qui exploite Google Cloud pour ses clients doit aussi vérifier leurs instructions et l’autorisation de recourir à un sous-traitant ultérieur. À l’inverse, une entreprise qui héberge son propre fichier clients reste responsable de ses choix de traitement.

La qualification peut varier pour les traitements de service, de sécurité ou d’amélioration. La CNIL demande d’examiner les rôles des acteurs du cloud par opération, ce qui interdit de déduire tous les rôles d’un simple schéma commercial.

Vérifiez l’entité contractante et le service souscrit. Le Cloud Data Processing Addendum couvre les contrats concernés Google Cloud et Workspace ; cela ne rend pas leurs services ni leurs garanties techniques interchangeables. Ses clauses 4–5 envisagent le client comme responsable ou sous-traitant. La clause 7.5.2 prévoit des audits, y compris des inspections lorsque le droit l’exige, avec les modalités de la clause 7.5.3. Il serait inexact de dire que seuls les certificats sont toujours disponibles.

Pour les nouveaux sous-traitants, la clause 11.4 prévoit une information anticipée de trente jours et un mécanisme d’objection par résiliation dans les quatre-vingt-dix jours de l’information. Archivez le dispositif applicable et organisez sa surveillance. Reliez cette veille à votre cartographie de la chaîne de sous-traitance.

Distinguer région, politique technique et engagement contractuel

Pour chaque service, identifiez la localisation du contenu, des sauvegardes, des copies de travail et des traitements complémentaires. Une base régionale et un service global n’offrent pas nécessairement les mêmes choix.

La politique gcp.resourceLocations aide à restreindre la création de certaines ressources. Google précise explicitement qu’elle ne constitue pas un engagement de résidence des données et qu’elle ne corrige pas les ressources existantes. Certains services ou traitements ne relèvent pas de son périmètre. Documentation sur la restriction des localisations.

Une décision renseignée pour un portail de réparation

Considérons un dossier fictif de migration : une PME veut héberger son portail de réparation d’appareils. Les données prévues sont les coordonnées du demandeur, la référence de l’appareil, le statut de réparation et les pièces utiles au dossier. La fonction ne nécessite ni copie de pièce d’identité ni dossier médical. L’entreprise reste responsable de ce traitement ; l’intégrateur exploite le portail pour son compte.

L’exigence interne est un stockage des dossiers et de leurs sauvegardes dans l’EEE, avec des accès limités aux équipes autorisées. C’est une exigence du projet, pas une affirmation selon laquelle le RGPD interdirait tout autre emplacement. La fiche suivante décrit l’état des pièces dans l’hypothèse ; elle ne rapporte aucun examen d’un compte Google réel.

La conclusion n’est pas « Google Cloud non conforme » ni « fournisseur approuvé ». Le stockage principal est documenté sur un point ; la mise en production reste conditionnée à la sauvegarde et à la fermeture des circuits excessifs. Le travail de configuration peut continuer avec des données fictives sans prétendre que cet environnement est dépourvu de toute donnée personnelle : les comptes des développeurs et leurs traces restent à gérer.

Pour lever la réserve sur la sauvegarde, le responsable technique remet l’identifiant de la ressource, son réglage de destination, le périmètre contractuel applicable et la règle de suppression. Le référent RGPD rapproche ces pièces de l’exigence EEE. Une affirmation commerciale générale n’est pas substituée à la pièce manquante.

Cette méthode sépare trois états : démontré pour un critère, à corriger, non renseigné. « Non renseigné » n’est ni zéro transfert ni absence de risque. La décision finale vise la version corrigée de l’architecture, pas la capture d’une règle créée au niveau de l’organisation.

Examiner les transferts réellement possibles

Le choix d’une localisation doit être rapproché des engagements propres au service et des opérations d’accès. La clause 10.1 du CDPA Google prévoit des traitements dans les pays où existent des installations, sous réserve des engagements applicables de localisation et de transfert. Elle ne peut pas être résumée par « Paris garantit que tout reste en France ».

Les Art. 44–46 exigent un mécanisme pertinent pour les transferts concernés. Une décision d’adéquation et des clauses contractuelles types répondent à des cadres différents ; vérifiez notamment l’entité destinataire, son périmètre et les éventuels transferts ultérieurs. RGPD, chapitre V.

Lorsque vous devez évaluer les garanties d’un transfert, documentez les données accessibles, les destinataires, les risques et les mesures supplémentaires nécessaires. Le guide CNIL AITD aide à construire cette analyse. Notre modèle d’analyse d’impact du transfert fournit une trame pratique. Évitez de confondre Union européenne, Espace économique européen et autres pays bénéficiant d’une décision d’adéquation.

Comprendre ce que les clés externes protègent

Cloud EKM permet d’utiliser des clés conservées chez un gestionnaire externe pour les services compatibles. Google décrit la protection des données au repos, l’autorisation des opérations cryptographiques et les conséquences d’une perte d’accès aux clés. Le matériau de clé externe reste dans le système externe. Documentation Cloud EKM.

Cette architecture doit être analysée avec le fonctionnement applicatif : qui autorise une opération, où le contenu est-il déchiffré et à qui devient-il accessible ? Une clé externe ne prouve pas que les données ne sont jamais traitées en clair dans le service. Il faut également prévoir la continuité d’activité et la réversibilité en cas de problème chez le gestionnaire de clés.

Consignez les rôles d’administration, les droits de déclenchement, la procédure de révocation et un scénario de restauration. L’Art. 32(1) inclut notamment confidentialité, intégrité, disponibilité et capacité de rétablissement ; il ne se réduit pas au choix d’un algorithme. RGPD, chapitre IV.

HDS : examiner l’offre, pas seulement le nom du fournisseur

L’affirmation selon laquelle Google Cloud n’aurait aucune offre certifiée HDS est dépassée. Google publie un périmètre HDS v2.0 et les certificats correspondants, avec des produits, activités et conditions précis, y compris certains services Workspace. La page actuelle distingue les activités 1–2 et 3–5 et exclut l’activité 6 du périmètre présenté. Elle prévoit également des conditions contractuelles, dont un avenant HDS. Ne reprenez donc pas une ancienne présentation des six activités comme si elle décrivait nécessairement l’offre actuelle.

Pour un traitement entrant dans le champ de l’Art. L1111-8 CSP, vérifiez le certificat en vigueur, les activités couvertes, les produits autorisés, les localisations et les engagements complémentaires à souscrire. La présence d’un service sur une liste ne démontre pas à elle seule la conformité de votre application. Les accès d’un intégrateur et les exports doivent aussi être examinés.

Préparer une décision et son suivi

La fiche de validation doit être attachée à une architecture datée. Enregistrez le responsable métier, les finalités, les données, le contrat, les services, les régions, les accès privilégiés, les transferts, les sous-traitants et les règles de suppression. Indiquez les points ouverts et l’autorité qui décide de la mise en service.

Les traitements susceptibles d’engendrer un risque élevé nécessitent une AIPD préalable, conformément à l’Art. 35(1). La simple utilisation d’un cloud ne suffit pas à conclure dans un sens ou dans l’autre. Ajoutez une revue lors de l’activation d’un service d’IA, d’un connecteur ou d’un nouveau mode de support ; leurs conditions doivent être vérifiées spécifiquement.

Pour la sortie, rapprochez les suppressions applicatives des versions, sauvegardes et copies externes. Une preuve d’exécution de l’effacement doit exposer les exceptions justifiées et leur terme. Si le projet concerne surtout des documents collaboratifs, utilisez plutôt les contrôles spécifiques de Google Drive.

Remettre un dossier exploitable à l’équipe suivante

La validation doit pouvoir survivre au départ du développeur qui connaît l’installation. Remettez un inventaire daté des ressources, une carte des accès, les décisions sur les copies et les points qui imposent une nouvelle revue. Le responsable métier approuve les données nécessaires ; l’exploitation tient les paramètres à jour ; le DPO conseille et contrôle dans son rôle, sans devenir automatiquement l’exploitant du service.

Dans le portail fictif, la réception comprend une recherche d’un dossier témoin dans la base, les pièces, les journaux et les exports autorisés. L’équipe doit également pouvoir expliquer comment une correction ou un effacement atteint les copies concernées et ce qui reste temporairement dans une sauvegarde. Ce sont des opérations de contrôle à organiser, pas des essais présentés comme déjà réalisés.

Si l’intégrateur ne peut produire l’inventaire ou expliquer un flux sortant, la direction n’approuve pas ce flux par défaut. Elle demande une réponse précise, réduit le périmètre ou diffère l’ouverture concernée. Un changement d’agence, l’ajout d’un outil d’IA ou une nouvelle méthode de sauvegarde doit être rapproché de cette décision documentée. L’objectif est de savoir exactement ce qui a été accepté et sur quelles preuves.

Ce qu’il faut retenir

• La validation concerne une architecture et un usage définis.
• Une politique de création des ressources n’est pas une garantie contractuelle de résidence.
• Les clés externes renforcent certains contrôles sans supprimer toute question d’accès au contenu.
• HDS, audit et transferts nécessitent une lecture du périmètre réellement applicable.

FAQ

Les conditions Google Cloud et Workspace sont-elles identiques ?

Le CDPA est un texte commun aux contrats concernés, mais les services, paramètres, engagements de localisation et conditions spécifiques diffèrent. Vérifiez le dossier de l’offre effectivement souscrite.

Une clé externe empêche-t-elle tout accès de Google aux données ?

Elle permet de maîtriser le matériau de clé externe et certaines autorisations. Il faut encore examiner les opérations de déchiffrement et le traitement du contenu dans l’application.

Faut-il refaire la revue à chaque nouveau service ?

Il faut au moins vérifier si le changement modifie les données, destinataires, accès ou garanties. Un ajout apparemment mineur peut créer un export ou un traitement nouveau.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.