RGPD et stockage cloud : ce que la loi exige vraiment
Le RGPD fait 88 pages. Personne ne les lit. Tout le monde colle un bandeau de cookies sur son site et considere que c’est regle. C’est un peu comme mettre un extincteur dans le couloir et considerer qu’on a une politique de securite incendie. Si vous venez du guide sur la souverainete et le RGPD dans le cloud, vous savez que la conformite RGPD ne se resume pas a une case cochee – c’est un ensemble d’obligations contractuelles, techniques et organisationnelles qui s’appliquent a chaque donnee personnelle que vous confiez a un tiers. Le texte du Reglement General sur la Protection des Donnees est disponible en ligne, gratuitement, en francais. Mais comme personne ne le lit, voici ce qu’il dit concretement quand vous stockez des fichiers dans le cloud.
La reponse tient en trois articles. L’article 28 definit ce que votre contrat avec le fournisseur cloud doit contenir. L’article 32 fixe les mesures de securite techniques et organisationnelles. L’article 48 interdit les transferts vers des pays tiers sans garanties adequates. Si votre fournisseur actuel ne vous permet pas de cocher ces trois cases simultanement, vous avez un probleme de conformite.
Article 28 : le contrat qui protege (ou pas) vos donnees
L’article 28 du RGPD est le texte le plus sous-estime du reglement. Il ne parle pas de consentement ni de cookies – il parle de la relation contractuelle entre le responsable de traitement (vous) et le sous-traitant (votre fournisseur cloud). Et ce qu’il exige est precis : le contrat doit stipuler la nature et la finalite du traitement, la duree, le type de donnees, les categories de personnes concernees, et les obligations et droits du responsable du traitement.
En clair, le contrat standard « terms of service » que vous acceptez en cliquant « J’accepte » sans lire ne suffit pas. Il faut un accord de traitement des donnees (DPA – Data Processing Agreement) qui detaille exactement ce que le sous-traitant peut faire avec vos donnees, comment il les protege, et ce qu’il fait quand il recoit une demande d’acces d’une autorite etrangere. La CNIL a publie des guides detailles sur le contenu minimal de ces accords.
L’article 28 impose aussi que le sous-traitant n’engage pas un autre sous-traitant sans votre autorisation prealable ecrite. Chez les hyperscalers (AWS, Google Cloud, Azure), la chaine de sous-traitance peut compter une dizaine de niveaux. Savez-vous qui sont les sous-traitants de votre fournisseur cloud ? Et les sous-traitants de ses sous-traitants ?
Le Patriot Act complique tout : donnees europeennes, droit americain
C’est la que le cadre legal se complique. Vous pouvez avoir un DPA en beton, un contrat signe par les deux parties, des clauses contractuelles types (SCC) validees par la Commission europeenne. Si votre fournisseur est americain, le Patriot Act et le Cloud Act rendent toutes ces garanties inoperantes face a une injonction federale. L’article 48 du RGPD est explicite : aucune decision judiciaire ou administrative d’un pays tiers ne peut obliger un responsable de traitement a transferer des donnees sans passer par un accord d’entraide judiciaire international. Le Cloud Act contourne exactement ce mecanisme.
Le resultat pratique est absurde : un fournisseur americain qui respecte le RGPD viole le droit americain. Un fournisseur americain qui respecte le Cloud Act viole le RGPD. C’est un conflit de lois sans resolution – ce que l’arret Schrems II a confirme en invalidant le Privacy Shield.
Mesures techniques : chiffrement, localisation et controle d’acces
L’article 32 exige des mesures techniques « appropriees » au risque. Le terme est volontairement vague – le RGPD n’impose pas une technologie specifique. Mais les autorites de controle (la CNIL en France, l’APD en Belgique) ont precise ce que « appropriees » signifie en pratique : chiffrement en transit (TLS 1.2 minimum), chiffrement au repos (AES-256), controle d’acces base sur les roles, journalisation des acces, plan de continuite, et capacite a restaurer les donnees en cas d’incident.
Le chiffrement zero-knowledge (ou le fournisseur ne peut pas lire vos donnees) est le standard le plus protecteur. Tous les fournisseurs ne le proposent pas – et ceux qui le proposent ne l’activent pas forcement par defaut. Verifiez. Si votre fournisseur detient les cles de chiffrement, il peut theoriquement acceder a vos donnees. Ce n’est pas necessairement un probleme si le fournisseur est soumis a une juridiction alignee sur le RGPD (Suisse avec la nLPD, ou un Etat membre de l’UE). C’est un probleme majeur si le fournisseur est soumis au droit americain.
Le RGPD n’est pas un obstacle bureaucratique. C’est une checklist de securite. Si votre fournisseur cloud ne peut pas demontrer sa conformite a l’article 28, garantir les mesures de l’article 32, et respecter l’interdiction de l’article 48 – changez de fournisseur. La loi est claire meme si personne ne la lit.