La souveraineté des données : une question de contrôle

Demandez à la plupart des dirigeants où résident leurs données sensibles, ils sauront nommer une région. Demandez-leur qui peut les lire, les copier ou les désactiver, la réponse devient plus floue. Ce décalage constitue le véritable enjeu de la souveraineté des données, et les régulateurs commencent à l’affirmer clairement. Le 5 novembre 2026, l’autorité espagnole de protection des données, l’AEPD, et son homologue grecque ont publié un guide commun sur les environnements de traitement sécurisés, considérant le contrôle comme un fait technique plutôt qu’une simple clause contractuelle.

La même semaine, deux rappels ont illustré les conséquences d’un contrôle existant uniquement sur le papier. Une coalition de quatre procureurs généraux d’État a annoncé un accord avec une entreprise dont le logiciel de surveillance a enregistré l’intrusion d’un tiers sans en informer personne. Au Royaume-Uni, une affaire a montré comment un tableur publié de bonne foi a permis la fuite de données cachées concernant environ 8 000 employés.

Cet article défend l’idée que les échecs en matière de souveraineté, de confidentialité et de sécurité partagent une cause commune : quelqu’un a cru qu’un contrôle était en place, sans jamais vérifier s’il fonctionnait. Les sections ci-dessous expliquent ce que les régulateurs attendent désormais, pourquoi la localisation et le contrôle sont deux questions distinctes, comment la concentration des fournisseurs érode discrètement ces deux aspects, ce que révèlent les récents cas d’application et de divulgation, comment les assistants IA héritent de chacun de ces problèmes, et comment planifier des contrôles réguliers pour remplacer la croyance par la vérification.

Résumé des points clés

1. Les régulateurs définissent la souveraineté comme le contrôle.

Le guide de l’AEPD et de l’autorité hellénique précise que le fournisseur doit exercer un contrôle réel et effectif, même lorsqu’un tiers fournit l’infrastructure, faisant ainsi passer la question du contrat au terrain technique.

2. La localisation répond à la question « où », le contrôle à la question « qui ».

Un serveur situé dans le bon pays ne garantit pas pour autant qui détient les clés, qui administre le système et quels sous-traitants peuvent accéder aux données.

3. Des contrôles inactifs sont pires que l’absence de contrôle.

Un accord concernant 13,3 millions de personnes concernées a mis en lumière l’absence d’authentification multifactorielle, de chiffrement des fichiers et de configuration d’alerte sur un logiciel de surveillance.

4. Les données s’échappent par des canaux de confiance.

Une publication de documents administratifs a révélé des données cachées sur l’absentéisme maladie de près de 8 000 employés, faute d’avoir vérifié le contenu du tableur.

5. Les assistants IA héritent des mêmes failles.

Les nouvelles directives des régulateurs bancaires maintiennent la responsabilité des banques pour les IA tierces : les assistants doivent agir dans le cadre des droits de l’utilisateur et selon la même politique que les humains.

Un guide européen dit tout haut ce que beaucoup taisaient

L’AEPD et l’Autorité hellénique de protection des données ont élaboré leur guide avec la contribution d’Eurostat, de la Direction générale des données d’Espagne, du Garante italien et du Bureau du Commissaire à l’information du Royaume-Uni. Une liste de contributeurs notable pour un document sur l’infrastructure, qui montre l’accord des superviseurs de plusieurs juridictions sur ce point.

Le point central : une organisation responsable de données personnelles doit garder un contrôle réel et effectif sur l’environnement de traitement, même lorsqu’un tiers fournit l’infrastructure. Un certificat affiché sur le site d’un fournisseur ne suffit pas. Pas plus qu’une clause contractuelle. Le guide met aussi en garde contre la dépendance à un seul fournisseur et précise qu’une analyse d’impact relative à la protection des données sera généralement obligatoire pour ce type de traitement.

Il s’agit d’un changement de paradigme. Pendant des années, de nombreuses organisations ont géré la souveraineté en achetant des garanties : certifications, documents standards, attestations du fournisseur versées au programme de conformité. Le guide propose un autre test : pouvez-vous, en tant qu’organisation responsable, prouver que vous détenez les leviers ? Pouvez-vous décider qui accède aux données, modifier la configuration, déplacer ou supprimer les données sans demander l’autorisation d’un tiers ?

La plupart des organisations ne peuvent pas répondre oui à ces trois questions. Les leviers sont généralement entre les mains des administrateurs du fournisseur cloud, des ingénieurs du prestataire de services managés ou d’un sous-traitant situé à plusieurs niveaux dans la chaîne. Ce n’est pas un manque de volonté, mais la conséquence logique de l’achat d’une infrastructure en tant que service, puis de la considérer comme un contrôle effectif.

Une mise en garde s’impose. Le guide est une publication de supervision sur les environnements de traitement sécurisés, il ne crée pas de nouvelle loi en soi. Mais les superviseurs publient des guides pour expliquer leur lecture du droit existant, et la direction est claire : la partie responsable doit pouvoir démontrer le contrôle, et la promesse d’un fournisseur ne suffit pas.

La localisation répond à « où », le contrôle à « qui »

Trois notions sont souvent confondues dans les comités de direction. La résidence des données désigne l’endroit où les données sont stockées. La localisation des données concerne les lois imposant le stockage des données dans un territoire. La souveraineté décrit qui détient l’autorité sur les données, y compris qui peut en exiger l’accès. Un système peut remplir les deux premiers critères et échouer sur le troisième.

Prenons l’exemple d’une organisation qui stocke les dossiers clients dans un centre de données situé dans son pays, exploité par une filiale d’un fournisseur étranger. La résidence est assurée, la règle de localisation respectée. Mais si le gouvernement du pays d’origine du fournisseur peut exiger la remise des données détenues par ses filiales, le contrôle de l’organisation reste conditionnel. C’est la source du débat sur le US CLOUD Act, et la raison pour laquelle un code postal sur un contrat ne prouve pas grand-chose.

Trois questions permettent de passer d’une simple affirmation de localisation à une affirmation de contrôle. Qui détient les clés de chiffrement ? Si c’est le fournisseur, alors son personnel ou une décision de justice peut déverrouiller les données, quelle que soit la géographie. Les clés de chiffrement contrôlées par le client redonnent ce pouvoir à l’organisation, et la double couche de chiffrement ajoute une barrière supplémentaire pour qu’aucun acteur unique ne puisse tout déverrouiller.

Qui administre l’environnement ? Les administrateurs peuvent tout voir et tout modifier, donc leur localisation compte autant que celle des disques. Une organisation qui conserve ses données dans la région mais autorise une administration à distance déplace le problème sans le résoudre.

Quels sous-traitants manipulent les données ? Les garanties du fournisseur ne couvrent que rarement ses propres fournisseurs. C’est dans la chaîne que la souveraineté s’érode discrètement, et un vrai programme de gestion des risques tiers doit cartographier la chaîne jusqu’au dernier maillon.

Rien de tout cela ne rend les transferts transfrontaliers impossibles. Les mécanismes comme les clauses contractuelles types restent un outil légitime pour la conformité RGPD. Mais une clause n’a de valeur que si l’organisation peut vérifier que les conditions sont respectées, ce qui ramène la discussion au contrôle effectif.

Un fournisseur unique, un point de défaillance unique

Le guide de l’AEPD met en garde contre la dépendance à un seul fournisseur, et les recherches de Kiteworks dans la région où la pression sur la souveraineté s’accentue le plus rapidement montrent que cet avertissement est concret. Dans le rapport Kiteworks 2026 Data Security and Compliance Risk: Data Sovereignty in the Middle East, 44 % des répondants du Moyen-Orient ont signalé un incident lié à la souveraineté, contre 32 % en Europe et 23 % au Canada.

La répartition des incidents est instructive. Les enquêtes réglementaires représentent 22 %, les violations liées à la souveraineté 20 %, les défaillances de tiers 19 %, les demandes d’accès gouvernementales 15 % et les transferts non autorisés 13 %. La sensibilisation est élevée (74 %) et 93 % affirment que les cadres de souveraineté impactent leurs opérations. Connaître le problème n’a pas suffi à l’éviter.

Observez combien de ces catégories ramènent au fournisseur. Les défaillances de tiers sont évidentes, mais les demandes d’accès gouvernementales, les transferts non autorisés et même certaines violations dépendent de ce que le fournisseur peut atteindre et de qui peut le contraindre. La concentration aggrave le phénomène. Si un fournisseur détient les données, les clés et l’administration, une seule défaillance, une décision de justice ou une panne affecte tout.

La même enquête indique que 48 % prévoient d’augmenter leur recours au cloud régional, et 33 % citent l’instabilité géopolitique comme facteur. Migrer vers un fournisseur régional peut réduire certains risques, mais crée aussi une nouvelle concentration si l’organisation ne fait que remplacer une dépendance par une autre. L’hébergement régional change l’adresse du risque, il ne supprime pas l’exigence de contrôle effectif.

La résilience doit aussi entrer en ligne de compte. Un plan de sortie jamais testé n’est qu’un vœu pieux. Le vrai test consiste à vérifier si l’organisation pourrait migrer ses données, ses clés et ses politiques vers un autre environnement dans un délai acceptable, et si elle l’a déjà fait. Les superviseurs qui questionnent la dépendance à un fournisseur unique s’intéressent à cette capacité de bascule.

Un contrôle présent mais inactif

Si la première faille consiste à faire confiance aux garanties du fournisseur, la seconde est de croire en ses propres outils sans les tester. Le 6 novembre 2026, la procureure générale de New York a annoncé un accord conclu avec une coalition incluant le Connecticut, le Michigan et le New Jersey, avec Perry Johnson & Associates et quatre sociétés affiliées. Le montant annoncé atteint jusqu’à 10 millions de dollars, dont au moins 300 000 garantis et 9,7 millions conditionnés. L’incident a concerné environ 13,3 millions de personnes, dont 4,2 millions de New-Yorkais.

Les faits sont clairs. En mars 2023, un intrus a accédé au système avec les identifiants d’un employé. L’accès à distance n’était pas protégé par une authentification multifactorielle. Les fichiers contenant des informations médicales protégées n’étaient pas chiffrés. Un logiciel a enregistré l’activité de l’intrus, mais sans alerter personne, et l’intrusion n’a été découverte qu’environ deux mois plus tard, lorsque les pirates ont pris contact.

Chaque contrôle existait sous une forme ou une autre. L’entreprise disposait d’un logiciel de journalisation, d’un accès à distance, de fichiers. Ce qui manquait, c’était la configuration qui aurait permis à chaque contrôle de jouer son rôle. L’authentification multifactorielle était absente de la porte d’entrée utilisée par l’intrus. Le chiffrement manquait sur les fichiers consultés. Et aucune alerte n’était configurée sur l’outil de surveillance.

Ce type de défaillance n’apparaît que rarement dans une checklist de conformité, car celle-ci se limite à vérifier la présence d’un contrôle. Les termes de l’accord pointent une autre question : chaque contrôle est-il configuré pour agir ? Les réformes imposées incluent un programme de sécurité et un protocole de réponse aux incidents, l’authentification multifactorielle, la gestion des mots de passe, le chiffrement et la gestion des actifs, des évaluations annuelles des risques HIPAA, ainsi que des politiques de collecte, d’utilisation, de conservation et de suppression des données. Plusieurs de ces mesures concernent l’exploitation, pas la propriété. Elles exigent de vérifier régulièrement que les dispositifs fonctionnent toujours.

Pour les données réglementées, l’enjeu se trouve dans la règle de sécurité HIPAA et son exigence d’analyse continue des risques. Mais la leçon vaut au-delà de la santé. Un journal d’audit qui enregistre tout sans alerter personne n’est qu’un journal intime. Un outil de surveillance n’est un contrôle que lorsqu’une personne nommée reçoit ses alertes et doit agir.

Les données peuvent fuir par une porte non surveillée

Toute perte ne vient pas d’une attaque. Une analyse de Jackson Lewis du 9 décembre 2025 décrit comment Royal Cornwall a publié un tableur en réponse à une demande d’accès à l’information en 2023. Le fichier contenait des données cachées sur l’absentéisme maladie de près de 8 000 employés actuels et anciens. Après la découverte du problème, le fichier a été retiré, le registre des divulgations suspendu, et une règle imposant la désactivation complète des tableurs avant publication a été adoptée.

Le détail à retenir est la banalité du canal utilisé. Une publication de documents administratifs est une voie approuvée et de confiance pour la sortie de données. Personne ne cherchait à voler quoi que ce soit. L’organisation ignorait simplement le contenu réel de son propre fichier, car les informations sensibles se trouvaient dans des feuilles cachées non vues par la personne chargée de la publication.

C’est un problème de souveraineté autant que de confidentialité. Une organisation incapable de dire ce que contient un fichier ne peut pas savoir où sont parties les données, qui peut les lire ou quelle loi s’applique. La classification des données permet de répondre à ces questions, et la prévention des pertes de données fait appliquer la classification au moment où un fichier s’apprête à sortir. Ces contrôles paraissent secondaires jusqu’au jour où ils font défaut.

Dans ce cas, la solution a été un changement de processus, ce qui est positif. Mais la vraie question est pourquoi une règle sur les tableurs cachés n’a été adoptée qu’après un incident. Toute organisation qui publie des documents, partage des fichiers avec des partenaires ou transmet des données à des régulateurs court le même risque. Le test est simple à énoncer et rarement réalisé : prenez un échantillon de fichiers sortants et demandez ce que chacun contient que l’expéditeur n’avait pas prévu de partager.

Pour les données personnelles et de santé, la réponse a un poids au regard des règles sur les informations personnelles identifiables (PII) et les informations médicales protégées (PHI). Un contrôle qui ne fonctionne que si la personne qui publie le fichier pense à vérifier relève de l’habitude, et les habitudes échouent les jours de forte charge.

Les assistants IA héritent de toutes ces failles

Tous les points ci-dessus s’appliquent aux assistants IA, et les superviseurs bancaires l’ont bien compris. Le 5 novembre 2026, American Banker a rapporté que l’OCC a publié des recommandations non contraignantes sur la délégation de tâches à des agents IA, structurées autour de six piliers : objectif, risques potentiels, contrôles, supervision humaine, résilience et tests. Les banques doivent documenter l’objectif de chaque système IA, les utilisateurs autorisés, les droits sur les données et les pouvoirs délégués. Elles restent responsables des IA tierces, et l’intensité des contrôles augmente avec l’autonomie accordée au système.

Transposé à la souveraineté : un assistant qui lit des documents et agit constitue un nouveau canal de circulation des données, héritant des failles de contrôle de tout ce qu’il touche. S’il fonctionne sur l’infrastructure d’un fournisseur, la question du fournisseur s’applique. S’il accède à des fichiers jamais classifiés, la faille de classification s’applique. Si son activité est consignée par un outil non surveillé, la faille d’alerte s’applique.

La réponse, c’est la parité, pas un programme distinct. Les assistants doivent agir dans le cadre des droits de la personne qu’ils servent, être soumis à la même politique et figurer dans le même journal que les humains. Une organisation qui crée un jeu de règles séparé pour l’IA verra les deux ensembles diverger, et c’est dans cet écart que les questions des régulateurs s’invitent. Les banques restent responsables des IA tierces : la vraie question est de savoir si la banque peut imposer sa propre politique à un assistant qu’elle n’a pas développé.

C’est aussi pourquoi l’approche Zero trust data exchange est pertinente. La vérification s’effectue au point de circulation des données, pour chaque acteur — employé, partenaire ou assistant — et l’organisation détient la politique au lieu de la louer. Le même principe répond à la question de contrôle de l’AEPD et à celle de délégation de l’OCC.

Deux mauvaises réponses à la souveraineté

La première consiste à tout rapatrier en interne. Cela semble offrir le contrôle le plus fort, et pour quelques usages c’est pertinent. Mais pour la plupart des organisations, cela remplace une faiblesse par une autre, car construire et gérer chaque environnement exige des compétences et des budgets rarement disponibles, et des opérations faibles produisent exactement les alertes manquantes et les fichiers non chiffrés évoqués plus haut. Contrôler ne signifie pas posséder chaque serveur.

La seconde consiste à se contenter de garanties contractuelles. Certifications, attestations et clauses ont leur utilité, mais le guide de l’AEPD est clair : elles ne remplacent pas un contrôle réel et effectif. Une organisation qui s’arrête à la paperasse n’a qu’une trace d’intention, et le régulateur en demandera plus.

La variable clé est de savoir si l’organisation détient les leviers essentiels, quelle que soit l’infrastructure. Cela signifie détenir les clés, définir la politique, consulter les journaux et pouvoir déplacer les données. Une organisation peut remplir ces quatre critères sur l’infrastructure d’un fournisseur… et échouer sur la sienne.

Nommer l’échec aide à le combattre. Appelez la stratégie « tout sur le papier » du théâtre de l’assurance, un programme qui accumule les preuves de confort au lieu de tester le contrôle. Appelez le contrôle non testé un contrôle dormant, présent mais silencieux. Ces deux situations sont courantes et ne ressortent pas dans un audit basé sur la présence.

Comment Kiteworks place le contrôle là où résident les données

Le Kiteworks Control Plane s’appuie sur les quatre critères évoqués. Il fonctionne en mode locataire unique, pour éviter tout mélange de données et de clés entre clients. Il applique la double couche de chiffrement, inclut le géorepérage et des contrôles de souveraineté permettant à l’organisation de décider où le contenu peut être consulté et échangé. Un moteur de politique unique et un journal d’audit couvrent tous les mouvements de contenu sensible, que l’acteur soit un employé, un partenaire ou un agent IA.

Ce dernier point répond à la question de parité. Le serveur Kiteworks Secure MCP permet aux assistants IA comme Claude et Copilot de travailler sur les contenus d’entreprise tout en héritant des autorisations de l’utilisateur, avec des contrôles par rôle et par attribut appliqués à chaque opération IA. Les identifiants sont stockés dans le trousseau du système d’exploitation, jamais exposés au modèle, et le journal d’audit alimente le SIEM de l’organisation. Kiteworks Compliant AI applique cette gouvernance pour les organisations devant prouver aux régulateurs comment l’IA traite les données réglementées.

Pour les organisations confrontées aux exigences de souveraineté, les fonctions de conformité à la souveraineté des données et un moteur de politique unique offrent à la partie responsable un élément concret à présenter au superviseur. Humains et agents relèvent d’un même plan de contrôle : toute modification de règle s’applique à tous les acteurs et figure dans un seul registre.

Aucun produit ne dispense de la revue évoquée ci-après. Mais une plateforme qui place les clés, la politique et le journal sous l’autorité du client rend la revue pertinente.

Contrôlez chaque trimestre

Une revue trimestrielle peut se faire en une demi-journée et répond aux questions récurrentes des régulateurs et des accords. Commencez par les clés : listez chaque système contenant des données sensibles et notez qui détient les clés de chiffrement. Toute réponse du type « le fournisseur » constitue un point d’alerte.

Poursuivez avec les alertes : sélectionnez trois contrôles que vos outils revendiquent (échec d’authentification multifactorielle, téléchargement massif, connexion depuis un nouveau pays, etc.), et déclenchez-les en environnement de test. Vérifiez qu’une personne nommée reçoit la notification et dans quel délai. Un contrôle qui envoie une alerte dans une boîte non surveillée n’a pas fonctionné.

Puis échantillonnez les fichiers sortants : prenez vingt documents ayant quitté l’organisation le trimestre précédent (e-mail, partage de fichiers, publication administrative ou portail partenaire) et vérifiez la présence de feuilles cachées, de métadonnées et de données personnelles non prévues à l’envoi.

Cartographiez la chaîne pour vos deux fournisseurs critiques, jusqu’aux sous-traitants et administrateurs, et notez qui a accès à quoi. Demandez-vous si vous pourriez migrer dans le délai prévu et, si la réponse est inconnue, planifiez un test.

Enfin, passez en revue les assistants IA : pour chacun, notez les autorisations utilisées, les systèmes accessibles et l’emplacement du journal d’activité. Si les réponses diffèrent de ce que vous diriez pour un utilisateur humain au même poste, comblez l’écart.

Consignez les résultats sur une page et transmettez-les aux responsables de la confidentialité, de la sécurité et des achats. Recommencez dans 90 jours et comparez. Une anomalie récurrente indique que l’organisation documente un problème sans le résoudre.

Pour découvrir comment la maîtrise des clés, des politiques et des journaux peut rendre la souveraineté démontrable, réservez une démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog  
  Souveraineté des données : bonne pratique ou exigence réglementaire ?
• eBook  
  Souveraineté des données et RGPD
• Article de blog  
  Évitez ces pièges de la souveraineté des données
• Article de blog  
  Bonnes pratiques pour la souveraineté des données
• Article de blog  
  Souveraineté des données et RGPD [Comprendre la sécurité des données]