Cloud Act et RGPD : où vos données d'IA devraient-elles être stockées ?

Le Cloud Act et le RGPD sont rarement mentionnés dans la même phrase dans le cadre de projets d’IA, bien qu’ils puissent concerner le même ensemble de données dès lors qu’un modèle linguistique fonctionne dans un cloud américain. Le CLOUD Act américain autorise les autorités américaines, sous certaines conditions, à accéder aux données de fournisseurs américains, même si les serveurs sont situés dans l’UE. Quiconque prévoit de développer des applications d’IA utilisant des données à caractère personnel ou des données sensibles d’ordre commercial doit prendre en compte ces deux cadres juridiques dès le départ, et non pas attendre que le service juridique pose des questions après la mise en production.

Le Cloud Act et le RGPD : le cadre juridique régissant les données issues de l'IA

La loi américaine CLOUD Act de 2018 oblige les prestataires américains à communiquer des données sur ordre des autorités, même si ces données sont techniquement stockées sur des serveurs situés dans l’UE. Cela ne change rien à l'obligation proprement dite prévue par le RGPD. Un fournisseur de services cloud doit dans tous les cas disposer d'un contrat de sous-traitance qui définit les modalités de traitement des données à caractère personnel et identifie les sous-traitants impliqués.

En 2020, l'arrêt « Schrems II » a déclaré nul le « Privacy Shield » entre l'UE et les États-Unis, car la Cour de justice de l'Union européenne a jugé que l'accès des autorités américaines aux données européennes était disproportionné. Le « Data Privacy Framework » entre l'UE et les États-Unis succède à ce dispositif, mais, selon une évaluation de noyb à partir de juin 2026, l'accord est à nouveau remis en cause. Cette situation fait suite à des décisions concernant l'indépendance de l'autorité de régulation américaine FTC qui, selon cette analyse, affaiblissent les fondements de l'accord.

Classes de données et règles de routage

Dans la pratique, une classification simple s’avère plus utile qu’une distinction juridique au cas par cas. Les données à caractère personnel et les données sensibles sur le plan de la concurrence, telles que les données de conception ou les chiffres financiers non publiés, doivent être classées dans une catégorie distincte, assortie d’une règle claire précisant quels systèmes sont autorisés à les traiter. Selon cette règle, les données générales, déjà accessibles au public, peuvent être transférées vers une API cloud internationale, tandis que les données sensibles restent chez un fournisseur européen ou dans un environnement géré en interne. L'article explique comment un modèle linguistique peut fonctionner de manière entièrement autonome précisément pour ces données sensibles. LLM on-premise en entreprise : des modèles d'IA privés pour les données sensibles.

D'après une analyse de gosign D'ici février 2026, les entreprises traiteront, selon une répartition type, 60 à 70 % de leurs demandes d'IA via des fournisseurs de cloud internationaux, 25 à 35 % via des solutions IaaS allemandes et 5 à 10 % en local. Cette répartition dépend généralement de la catégorie des données, et non de la commodité technique pour l'équipe concernée.

Comment mettre en œuvre techniquement la règle de routage

Dans la plupart des architectures, la règle est centralisée à un seul endroit, une passerelle ou un petit middleware, par lequel transite chaque requête adressée à un modèle linguistique. C’est là qu’une balise associée à l’enregistrement, telle que „ public “ ou „ confidentiel “, détermine quel fournisseur reçoit la requête. Les équipes applicatives n’ont donc pas à faire cette distinction elles-mêmes ; il leur suffit de sélectionner la classe de données lors de la création d’un nouveau cas d’utilisation.

Ce système est également adapté à la journalisation. Si l'on doit ultérieurement déterminer quelle requête a été transmise à quel fournisseur, la réponse se trouve dans un seul fichier journal plutôt que dans plusieurs applications dispersées.

Le contrat de sous-traitance : un point à vérifier

Conformément à l’article 28 du RGPD, un contrat de sous-traitance est obligatoire dans tous les cas, quel que soit le lieu d’implantation du prestataire. Dans le cas d’un prestataire américain, il est important de vérifier quels sous-traitants sont mentionnés dans le contrat et si, parmi eux, certaines sociétés sont elles-mêmes soumises au CLOUD Act américain. Un partenaire contractuel européen dont la société mère est américaine n'offre généralement pas de protection contre cet accès. Un deuxième ou un troisième sous-traitant dans la chaîne entre également en ligne de compte, par exemple un exploitant de centres de données ou un prestataire de services d'assistance ayant accès aux données de production.

Dans nos propres projets, nous vérifions systématiquement cette chaîne avant de choisir le système, et non après. Dans la pratique, changer de sous-traitant en cours de projet prend plus de temps qu’une vérification approfondie dès le début, surtout lorsque des données d’entraînement ou des embeddings se trouvent déjà sur le système concerné.

De la classe de données à l'architecture

Une classification claire des données constitue la base de l'architecture technique qui en découle. Notre article sur l'architecture IA hybride montre comment combiner, dans la pratique, le traitement dans le cloud et le traitement local sans avoir à prendre une nouvelle décision pour chaque requête. Ceux qui souhaitent classer leurs propres données d'un point de vue à la fois juridique et technique trouveront pour cela, dans un Premier entretien de conseil en IA une introduction structurée.

Foire aux questions

Un centre de données européen suffit-il ?

Un centre de données situé dans l'UE répond aux exigences du RGPD concernant le lieu de traitement, mais n'empêche pas automatiquement l'accès en vertu du CLOUD Act américain. Ce sont la nationalité et la structure du groupe du prestataire qui importent, et non pas uniquement l'emplacement du serveur. Une entreprise américaine disposant d'un centre de données à Francfort reste soumise au CLOUD Act américain, même si les données ne quittent jamais l'UE.

Quelles données ne doivent en aucun cas être transmises à l'API cloud ?

Il n’existe pas de réponse universelle, mais la plus grande prudence s’impose pour les brevets non publiés, les données de conception présentant un intérêt concurrentiel et les données à caractère personnel particulièrement sensibles au sens de l’article 9 du RGPD, telles que les données relatives à la santé. Pour ces catégories, un traitement local ou européen s’avère justifié, indépendamment de la charge technique supplémentaire que cela implique. En cas de doute, il est utile de se demander si la perte de ces données porterait gravement préjudice à l’entreprise. Pour une telle catégorie, le niveau de protection le plus élevé prime sur le confort de l’équipe de développement.

Quels changements cela entraînera-t-il si le cadre s'effondre ?

Si le cadre de protection des données UE-États-Unis venait à échouer, à l’instar du Privacy Shield auparavant, les entreprises perdraient la base juridique la plus simple pour les transferts de données vers les États-Unis et devraient se rabattre sur des clauses contractuelles types assorties de garanties supplémentaires. Celles qui procèdent dès à présent à une séparation par catégories de données n’auront alors qu’à adapter la règle de routage pour une catégorie donnée, sans avoir à reconstruire toute l’architecture. C’est précisément pour cela que ce travail préparatoire en vaut la peine, même s’il peut sembler, dans un projet en cours, constituer dans un premier temps une charge de travail supplémentaire.

Pourquoi torck ?

torck développe et exploite des systèmes d’IA avec ses propres équipes à Maxhütte-Haidhof, Vienne et Rabat, et définit la classe de données pour chaque projet avant même que la première ligne de code ne soit écrite. Le partenaire contractuel est la société allemande torck GmbH : un contrat unique remplace une chaîne de sous-traitants, ce qui simplifie considérablement la vérification des sous-traitants chargés du traitement des données évoquée dans cet article. Cette approche évite des modifications coûteuses si la situation juridique relative aux transferts transatlantiques de données venait à changer. Quiconque souhaite sécuriser son architecture sur les plans juridique et technique peut le faire dans un Premier entretien de conseil en IA en discuter.

Prendre rendez-vous