Conforme au RGPD ne veut pas dire souverain : ce que l'IA change au contrôle

Votre hébergeur est européen. Votre contrat mentionne le RGPD. Votre DPO a validé. Et pourtant, si un gouvernement étranger décidait demain de couper, de retarifer ou de restreindre le service, rien de tout cela ne vous protégerait. La conformité et la souveraineté ne mesurent pas la même chose — et l'IA vient d'élargir l'écart entre les deux.

Ce n'est pas une question, c'en est trois

Le mot « souveraineté » recouvre en réalité trois questions distinctes, que les cadres d'analyse rangent depuis 2026 en trois niveaux hiérarchisés. Comme souvent avec l'IA, la difficulté n'est pas la technique : elle tient à ce que le vocabulaire courant donne une illusion de simplicité à une question qui n'en a pas.

Où sont mes données ? C'est la souveraineté des données : localisation, résidence, confidentialité, effacement. C'est la seule question que la conformité RGPD traite frontalement, et c'est celle que tout le monde sait poser.

Qui opère le système ? C'est la souveraineté opérationnelle : la capacité à surveiller, auditer et contrôler ce que fait le fournisseur — y compris son personnel d'exploitation et ses sous-traitants.

Puis-je continuer sans lui ? C'est la souveraineté technologique : le contrôle de la pile technique, jusqu'à la capacité d'opérer en configuration déconnectée avec du personnel local.

La propriété importante de ce modèle est qu'il ne fonctionne que dans un sens. Le niveau technologique inclut les deux autres, le niveau opérationnel inclut celui des données — mais l'inverse est faux. Satisfaire la résidence des données ne garantit rien au-dessus. C'est précisément l'écart le plus courant en 2026 : des offres irréprochables sur la localisation, muettes sur le reste.

Ce qu'un fournisseur a reconnu devant un juge

L'écart entre conformité et souveraineté n'est pas une hypothèse de consultant. Il a été formulé en audience.

En juillet 2025, dans le cadre d'un contentieux porté devant une juridiction française, Microsoft a reconnu ne pas pouvoir garantir la souveraineté des données de ses clients européens en cas d'injonction légalement fondée émanant des autorités américaines. La déclaration a été largement rapportée par la presse spécialisée et reprise depuis dans le débat européen sur les offres dites souveraines.

La raison est structurelle, pas technique. Le Clarifying Lawful Overseas Use of Data Act — le CLOUD Act, adopté aux États-Unis en 2018 — autorise les autorités fédérales à contraindre tout fournisseur de services numériques de droit américain à transmettre des données, quelle que soit la localisation géographique des serveurs. Le fournisseur se retrouve pris entre l'obligation de livrer et l'interdiction de transférer.

Ce que cela signifie concrètement pour un dirigeant : aucune clause contractuelle ne résout ce conflit. Un accord de service ne peut pas neutraliser les obligations légales qu'une partie doit à son propre gouvernement. La protection contractuelle déplace le risque, elle ne le supprime pas.

La seule réponse robuste identifiée est architecturale : le chiffrement contrôlé par le client, avec des clés conservées hors de l'infrastructure du fournisseur et hors de sa juridiction. Une réquisition ne produit alors que des données chiffrées. C'est aussi la mesure supplémentaire qu'attend la jurisprudence européenne depuis l'arrêt Schrems II.

Ce que Bruxelles a écrit noir sur blanc

Le 3 juin 2026, la Commission européenne a publié sa proposition de règlement sur le cloud et l'IA — le Cloud and AI Development Act, référencé COM(2026) 502 final. Son article 16 établit un cadre de souveraineté comprenant quatre niveaux d'assurance de l'Union, dont les critères figurent à l'annexe II.

Une précision utile, parce que beaucoup de synthèses circulent : nous avons lu le texte et ses annexes. Les acronymes « SEAL », les prétendus niveaux allant de 0 à 4 et les huit objectifs « SOV-1 à SOV-8 » que reprennent plusieurs analystes n'apparaissent nulle part dans la proposition. Il n'existe ni niveau 0, ni grille SOV. La terminologie officielle est « Union assurance level », de 1 à 4.

Ce que les niveaux exigent réellement, en substance :

• Niveau 1 — le fournisseur est établi dans l'Union ; infrastructure et actifs y sont localisés ; les données client, métadonnées et télémétrie incluses, y restent exclusivement. Contrairement à ce qu'on lit souvent, ce n'est donc pas « du cloud standard avec des certifications » : les offres standard des grands fournisseurs américains n'y sont pas éligibles.
• Niveau 2 — s'y ajoutent la localisation du personnel, un certificat de cybersécurité de niveau substantiel, un inventaire logiciel complet (SBOM), des audits de code source sur les composants sensibles et un plan de migration documenté. Le contrôle par un pays tiers reste admis, mais sous conditions démontrées et vérifiées par un auditeur indépendant.
• Niveau 3 — personnel de nationalité européenne, support assuré depuis l'Union par des résidents. Le contrôle par un pays tiers est exclu par principe, sauf pour un « pays tiers associé » reconnu par la Commission — reconnaissance qui suppose notamment une décision d'adéquation au titre du RGPD.
• Niveau 4 — aucun contrôle de pays tiers, sans dérogation possible ; certificat de cybersécurité de niveau élevé ; démonstration qu'aucune entité étrangère n'exerce de contrôle effectif sur l'évolution technique et la maintenance des composants logiciels.

Le mécanisme qui rend tout cela opposable est l'article 30. Les organismes publics dont les activités ne touchent pas à l'ordre public devront acheter au minimum du niveau 1. Ceux dont les activités y contribuent — secteurs de la directive NIS2, sécurité nationale, défense, justice, police — ne pourront acheter que des niveaux 2, 3 ou 4.

Et c'est bien ainsi qu'il faut le lire, y compris si vous n'êtes pas un acheteur public. Le considérant 66 de la proposition l'annonce explicitement : les exigences imposées à la commande publique tendent à être reprises par les entités privées des secteurs régulés, avec un réalignement du marché dans la durée. L'article 31 va plus loin : les entités relevant de la directive NIS2 peuvent mener les mêmes évaluations, et la Commission pourra, par acte délégué, les y contraindre pour les secteurs hautement critiques.

L'IA déplace la frontière une seconde fois

Jusqu'ici, rien qui ne vaille aussi pour un ERP hébergé. L'IA introduit une rupture propre, et elle tient en une phrase : un système d'IA ne se contente pas de traiter vos données, il en fabrique de nouvelles.

Embeddings, inférences, journaux de raisonnement, sorties générées : ce sont des actifs informationnels neufs, produits en dehors du périmètre de gouvernance que vous aviez défini au départ. Le règlement européen sur l'IA impose d'ailleurs de documenter l'origine, la qualité et la représentativité des données d'entraînement, de validation et de test — prompts, sorties et journaux inclus.

Le texte du CADA confirme cette lecture d'une manière qui ne laisse pas de place au doute. À ses niveaux 2, 3 et 4, l'annexe II exige que les données générées par l'utilisation du service ne soient pas utilisées pour entraîner ou affiner un système d'IA exploité par un pays tiers, ni transférées hors de l'Union en aucun cas. Le régulateur protège explicitement la donnée produite, et pas seulement la donnée confiée.

Deuxième déplacement, plus discret : l'inférence est un transfert. Chaque appel à un modèle hébergé hors de l'Union avec des données personnelles européennes relève du chapitre V du RGPD. Pas une fois à la signature du contrat : à chaque requête. Et disposer d'un accord de traitement conforme au RGPD avec son fournisseur de modèle ne satisfait pas pour autant les obligations de gouvernance des données du règlement sur l'IA. Les deux régimes s'appliquent ensemble et ne se remplacent pas.

Qui répond de ce que votre agent décide

Reste la question que les trois niveaux de souveraineté ne posent pas. Ni « où est la donnée », ni « qui opère le système », mais : qui répond de ce que le système conclut et de ce qu'il fait ?

Sur ce point, les deux régulateurs disent la même chose, et ce n'est pas ce que beaucoup d'entreprises ont compris.

La CNIL est explicite : si vous utilisez un modèle tiers avec des données personnelles de vos clients ou de vos salariés, vous êtes responsable de traitement — pas le fournisseur du modèle. Le règlement européen sur l'IA dit l'équivalent pour les systèmes à haut risque : l'obligation de gouvernance des données incombe au fournisseur du système et n'est pas délégable au prestataire de modèle. Autrement dit, celui qui assemble porte la charge, et il ne peut pas la sous-traiter avec la brique technique.

Ces obligations ne sont pas à venir. Elles sont applicables depuis le 2 août 2026, soit un peu plus d'un mois au moment où nous publions.

La conséquence est plus lourde encore pour les architectures agentiques. Dans une chaîne d'agents, la frontière de conformité s'étend à chaque agent exécutant une fonction à haut risque. Et un système dont la dérive comportementale n'est pas traçable ne peut structurellement pas satisfaire les exigences essentielles du règlement. La journalisation de provenance n'est pas une fonctionnalité qu'on ajoute en fin de projet : c'est une condition d'existence du système.

Nous avons détaillé ailleurs le socle minimal à poser avant de laisser un agent agir en production : voir gouvernance et sécurité des agents IA en entreprise. Le présent article en donne la raison juridique ; celui-là en donne les briques.

Cinq vérifications avant de signer

Aucune de ces cinq questions ne demande une expertise juridique. Toutes se posent à un fournisseur avant la signature, et l'embarras d'une réponse vous en apprendra souvent plus que la réponse elle-même.

Un dernier repère, propre au contexte français : la qualification SecNumCloud délivrée par l'ANSSI vise explicitement la protection contre l'application des lois extraterritoriales. Elle est exigeante, la liste des offres qualifiées est publique et tenue par l'agence, et elle constitue aujourd'hui le repère le plus solide dont dispose une entreprise française — en attendant que le cadre européen se stabilise.

Reste que ces cinq questions ne se posent utilement que si quelqu'un, dans l'entreprise, sait interpréter les réponses. C'est l'objet de nos formations à l'IA en entreprise : rendre une direction capable d'arbitrer elle-même, plutôt que de déléguer l'arbitrage à celui qui vend la solution. La question du coût entre aussi dans la balance — nous l'avons traitée sous un autre angle à propos de ce que l'IA fait à l'assiette sociale française.

Pour aller plus loin : sept sources publiques

Toutes les affirmations de cet article sont traçables aux documents ci-dessous. La proposition européenne et ses annexes ont été lues directement, et non reprises de synthèses secondaires.

• Commission européenne — Proposition de règlement Cloud and AI Development Act, COM(2026) 502 final (3 juin 2026) : texte de la proposition et annexes 1 à 3. L'article 16 pose les quatre niveaux d'assurance, l'annexe II en fixe les critères, l'article 30 les obligations de commande publique.
• Règlement (UE) 2024/1689 — règlement européen sur l'intelligence artificielle : gouvernance des données des systèmes à haut risque (art. 10), documentation technique (art. 11), journalisation (art. 12), évaluation de conformité (art. 43).
• Règlement (UE) 2023/2854 — règlement européen sur les données : mesures contre l'accès gouvernemental non européen, obligations de transparence et suppression des frais de migration.
• CNIL — Développement des systèmes d'IA : les recommandations pour respecter le RGPD : qualification des rôles entre responsable de traitement et sous-traitant, base légale, minimisation.
• CNIL — Les fiches pratiques IA : risques propres aux systèmes d'IA, dont l'extraction de données depuis un modèle et l'injection de prompts.
• ANSSI — Cloud de confiance et qualification SecNumCloud : doctrine française, portée de la qualification et catalogue des offres qualifiées.
• ANSSI — FAQ avant de se lancer dans la qualification SecNumCloud : exigences du référentiel et déroulé du processus de qualification.

À propos de l'auteur

Frédéric Michel dirige Oppchain, cabinet et organisme de formation certifié Qualiopi spécialisé en IA agentique. Il anime régulièrement des ateliers de cadrage IA en comité de direction, auprès de dirigeants de PME et d'ETI.