rgpd données souveraineté définitions

Le RGPD n'est pas un bouclier de souveraineté

On invoque le RGPD comme une preuve d'indépendance numérique. C'est confondre un droit des personnes avec une politique industrielle. Deux questions, deux réponses, et un nœud à défaire.

· 6 min de lecture

Dans les comités, le raisonnement revient comme un réflexe. On est conforme RGPD, donc on est souverain. La phrase rassure, et elle est fausse. Le RGPD protège des personnes contre les abus de traitement de leurs données. Il ne dit rien de votre dépendance à un fournisseur, rien de l’origine de votre infrastructure, rien du droit étranger qui peut s’appliquer par-dessus le sien. Ce sont deux questions distinctes. On les confond parce qu’elles partagent un mot, « données », et parce que le mot « souveraineté » s’est mis à servir d’emballage à tout ce qui touche au numérique européen.

Posons les deux objets côte à côte, sans en charger un pour sauver l’autre.

Ce que le RGPD fait, exactement

Le règlement (UE) 2016/679, entré en application en mai 2018, a un objet précis : protéger les personnes physiques à l’égard du traitement de leurs données à caractère personnel. Ce n’est ni un texte d’infrastructure ni une politique industrielle. C’est un droit des personnes, doublé d’obligations pour ceux qui traitent leurs données.

Du côté des personnes, il crée des droits opposables : accès, rectification, effacement, portabilité, opposition, limitation. Vous pouvez exiger qu’on vous dise ce qu’on détient sur vous, qu’on le corrige, qu’on l’efface, qu’on vous le rende dans un format réutilisable. Du côté des organisations, il impose des obligations au responsable de traitement, celui qui décide des finalités, et au sous-traitant, celui qui traite pour le compte du premier. Tout traitement doit reposer sur une base légale parmi six : le consentement, l’exécution d’un contrat, une obligation légale, la sauvegarde d’intérêts vitaux, une mission d’intérêt public, ou l’intérêt légitime. Hors de ces six cases, le traitement est illicite.

Deux principes structurent le reste. La minimisation : on ne collecte que les données nécessaires à la finalité déclarée, pas davantage, au cas où. La limitation des finalités : une donnée collectée pour un usage ne peut pas servir librement à un autre. À cela s’ajoutent l’obligation de sécurité, la notification des violations sous soixante-douze heures, et l’analyse d’impact pour les traitements à risque. Voilà le périmètre. Il est cohérent, exigeant, et entièrement tourné vers la protection de l’individu.

Ce qu’il ne fait pas

Rien dans ce périmètre ne touche à la souveraineté industrielle ou technologique. Le RGPD n’interdit pas AWS, Azure ou Google Cloud. Il encadre la manière dont on y traite des données personnelles, il exige des garanties, mais il ne dit pas de qui acheter son infrastructure. Une entreprise peut héberger l’intégralité de ses systèmes chez un hyperscaler américain et rester parfaitement conforme, pour peu qu’elle respecte les bases légales, la minimisation et les obligations de sécurité.

Le règlement ne crée aucune offre locale. Il ne finance pas de centre de données, ne fait pas émerger de fournisseur européen, ne réduit en rien la dépendance du continent à une poignée d’acteurs étrangers. Ce n’est pas son rôle, et lui en prêter l’intention, c’est se tromper de texte.

Il n’interdit pas davantage les transferts de données hors de l’Union. Il les encadre. Un transfert vers un pays tiers est licite s’il s’appuie sur une décision d’adéquation, sur des clauses contractuelles types, ou sur des règles d’entreprise contraignantes. Encadrer n’est pas empêcher. Les données européennes circulent, légalement, vers des juridictions où le droit local diverge du nôtre.

Et il ne résout pas la question du CLOUD Act. Ce texte américain de 2018 autorise les autorités des États-Unis à exiger les données détenues par une entreprise relevant de leur juridiction, où qu’elles soient stockées. Le RGPD oppose ses propres exigences à cette demande, mais il ne neutralise pas le rattachement juridique de l’opérateur. Le conflit de lois reste entier. La conformité au règlement ne fait pas disparaître la prise d’un droit étranger sur votre fournisseur.

D’où vient la confusion, et pourquoi elle dure

La confusion a une origine logique. Le RGPD est le texte numérique européen le plus connu, le plus médiatisé, le seul que les dirigeants citent de mémoire. Quand on cherche un symbole d’autonomie numérique du continent, c’est lui qui se présente, faute d’autre repère aussi visible. L’Europe a légiféré là où les autres se contentaient de conditions générales : on a pris cette avance normative pour une avance de puissance.

Le glissement s’est nourri du vocabulaire. À force d’appeler « souveraineté des données » la maîtrise de leur traitement, on a laissé entendre que protéger les données revenait à les soustraire à toute emprise étrangère. Le marketing a fait le reste. Afficher la conformité RGPD est devenu un argument de réassurance, et la réassurance s’est muée en promesse implicite d’indépendance. La confusion persiste parce qu’elle arrange : elle permet de cocher une case de souveraineté sans rien changer à son infrastructure.

Les deux questions à séparer

Il faut tenir deux fils distincts, et accepter qu’ils ne se recouvrent pas. La conformité RGPD est une question de protection des personnes : traite-t-on leurs données licitement, loyalement, avec les bonnes bases légales et les bonnes garanties. La dépendance à l’infrastructure est une question de souveraineté industrielle : de qui dépend-on pour faire tourner ses systèmes, sous quel droit tombe ce fournisseur, peut-on en changer sans tout réécrire.

Ces deux axes sont orthogonaux, et les quatre combinaisons existent dans le réel. On peut être conforme et dépendant : une PME parfaitement en règle, intégralement hébergée chez un hyperscaler soumis au CLOUD Act. On peut être non conforme et souverain : une administration qui héberge sur une infrastructure qualifiée SecNumCloud mais collecte sans base légale et néglige les droits des personnes. On peut être les deux, ou ni l’un ni l’autre. Le seul cas impossible est celui que le discours ambiant suppose acquis : que la conformité entraînerait la souveraineté. Elle ne l’entraîne pas.

L’affaire Schrems II l’a montré sans ambiguïté. En 2020, la Cour de justice de l’Union européenne a invalidé le Privacy Shield, l’accord qui couvrait les transferts vers les États-Unis, au motif que le droit américain de surveillance ne garantissait pas une protection équivalente. La conformité formelle ne suffisait plus, parce que le droit étranger pesait sur les données malgré toutes les garanties contractuelles. Le problème mis en lumière n’était pas un défaut de traitement : c’était une question de juridiction et de dépendance. Le RGPD a servi à révéler le problème de souveraineté. Il n’a jamais été l’instrument capable de le résoudre.

Pour le dirigeant, la conclusion est nette. La conformité au RGPD est nécessaire, et elle ne se négocie pas. Mais la cocher ne dit rien de votre dépendance à l’infrastructure, ni du droit qui peut s’imposer à votre fournisseur. Ce sont deux chantiers, deux budgets, deux décisions. Les confondre, c’est croire l’un réglé en ne traitant que l’autre.

Sources

  • Règlement (UE) 2016/679 (RGPD), texte officiel
  • CNIL, fiches sur les bases légales, la minimisation et les transferts hors UE, cnil.fr
  • CJUE, arrêt Schrems II, affaire C-311/18, 16 juillet 2020
  • CLOUD Act (États-Unis, 2018)
  • Comité européen de la protection des données (CEPD), recommandations sur les transferts internationaux