Limites de GCC High : Aperçus du Rapport 2026 de Kiteworks sur la souveraineté des données

Vous pouvez verrouiller la porte et tout de même remettre la clé à quelqu’un.

Voilà, en une phrase, le problème de considérer Microsoft GCC High comme une solution cloud souveraine. Les données sont stockées aux États-Unis. L’accès opérationnel est limité à des personnes américaines vérifiées. La solution répond aux exigences FedRAMP High et DoD SRG IL4/IL5. Mais rien de tout cela ne change le fait que Microsoft peut toujours accéder à vos clés de chiffrement — et peut y être contraint.

Points clés à retenir

1. La sensibilisation est généralisée. Les incidents touchent encore une organisation sur trois. Environ 44 % des répondants au Canada, au Moyen-Orient et en Europe se disent « très bien informés » sur les exigences de souveraineté — pourtant, 33 % ont signalé un incident lié à la souveraineté au cours des 12 derniers mois. Le problème n’est pas la connaissance. C’est le contrôle opérationnel.
2. GCC High garantit la souveraineté de la juridiction, pas des clés. La fonction Customer Key de Microsoft autorise explicitement Microsoft 365 à utiliser les clés de chiffrement des clients pour les opérations de service, et une « availability key » que Microsoft stocke et contrôle peut être utilisée si les clés du client ne sont pas disponibles. FedRAMP High et IL4/IL5 certifient la robustesse des processus, mais pas une architecture « zero knowledge » où le fournisseur serait techniquement incapable de déchiffrer les données.
3. Les demandes d’accès aux données par les gouvernements font déjà partie des incidents. Un répondant sur dix a cité une demande d’accès gouvernementale comme incident de souveraineté. La norme du CLOUD Act — les fournisseurs doivent fournir les données en leur « possession, garde ou contrôle » quel que soit l’emplacement de stockage — s’applique aux clients GCC High, et l’affaire BitLocker/FBI a prouvé que la détention des clés par le fournisseur transforme l’accès légal en question de processus, pas de chiffrement.
4. GCC High inverse l’équation de la souveraineté pour l’EMEA et le Canada. Quarante-quatre pour cent des répondants européens désignent les garanties de souveraineté du fournisseur comme principal obstacle à l’adoption du cloud, et 40 % des Canadiens citent les évolutions du partage de données Canada–États-Unis comme leur principale préoccupation réglementaire. Pour les organisations non américaines, migrer du contenu sensible dans une enclave exclusivement américaine accroît l’exposition juridictionnelle que les stratégies de souveraineté cherchent justement à réduire.
5. Le marché évolue vers le contrôle prouvable, pas vers les promesses des fournisseurs. L’automatisation de la conformité et le renforcement des contrôles techniques sont au cœur des stratégies à deux ans dans les trois régions interrogées. Les organisations investissent dans l’application au niveau architectural — gestion des clés de chiffrement, contrôle de la résidence des données, et reporting d’audit exportable — car elles ont compris que les documents de politique et les garanties des fournisseurs n’empêchent pas les incidents.

Nous avons passé six mois à élaborer le rapport >2026 Data Security and Compliance Risk: Data Sovereignty Report, en interrogeant 286 professionnels IT et sécurité au Canada, au Moyen-Orient et en Europe sur la réalité de la souveraineté dans la pratique. Les résultats ne remettent pas seulement en cause le positionnement de GCC High. Ils remettent en cause l’idée même que la seule juridiction équivaut à la souveraineté.

Voici ce que nous avons constaté, et pourquoi cela compte si votre organisation gère des CUI, opère à l’international ou doit rendre des comptes à des régulateurs qui n’acceptent plus « faites-nous confiance » comme posture de conformité.

Constat principal du rapport : tout le monde connaît les règles. Une organisation sur trois a tout de même été touchée.

Commençons par le chiffre qui devrait alerter tous les responsables sécurité.

Dans les trois régions interrogées, environ 44 % des répondants se disent « très bien informés » sur les exigences de souveraineté des données. Le Moyen-Orient atteint 45 %. Le Canada, 44 %. L’Europe, 44 %. La sensibilisation est désormais homogène.

Pourtant, 33 % des répondants ont signalé un incident lié à la souveraineté au cours des 12 derniers mois. 5 % supplémentaires ont préféré ne pas répondre — ce qui, selon notre expérience, signifie rarement « il ne s’est rien passé ».

La nature des incidents est instructive. Les violations de données à enjeu de souveraineté et les défaillances de conformité des tiers arrivent en tête, à 17 % chacune. Les enquêtes réglementaires suivent à 15 %. Les transferts transfrontaliers non autorisés atteignent 12 %. Et les demandes d’accès aux données par les gouvernements — scénario le plus directement lié à la promesse de GCC High — représentent 10,1 %.

Ce dernier chiffre mérite qu’on s’y attarde. Une organisation sur dix a signalé une demande d’accès gouvernementale comme incident de souveraineté. Ce n’est pas un risque théorique débattu par les équipes conformité lors de réunions stratégiques. Cela se produit. Aujourd’hui. Chez des organisations qui pensaient être protégées.

GCC High garantit la souveraineté de la juridiction, pas des clés.

Cette distinction change tout, et c’est celle que le marketing de Microsoft entretient dans la confusion.

GCC High fait exactement ce qu’il promet : il crée une frontière cloud opérée et hébergée aux États-Unis, pensée pour les charges de travail gouvernementales et de défense. Si votre exigence est « données stockées aux États-Unis, opérées par des Américains, derrière un périmètre FedRAMP High », GCC High répond à ce besoin. Point final.

Mais la souveraineté ne se limite plus à la géographie. Les régulateurs en Europe, au Canada et de plus en plus au Moyen-Orient posent d’autres questions. Le fournisseur peut-il accéder à vos données ? Peut-il être contraint de les déchiffrer ? Pouvez-vous prouver — preuves à l’appui, à la demande — que l’accès est resté dans les limites autorisées ?

GCC High ne répond pas à ces trois exigences.

Prenons la fonction « Customer Key » de Microsoft, souvent citée comme preuve que les clients contrôlent leur chiffrement. La documentation officielle de Microsoft est claire : « Vous autorisez explicitement Microsoft 365 à utiliser vos clés de chiffrement pour fournir des services à valeur ajoutée. » La plateforme utilise ces clés pour chiffrer les données au repos et les requiert pour les opérations de service.

Encore plus révélatrice, la « availability key » — un mécanisme de récupération que Microsoft « stocke et protège » et qui prend le relais si les clés du client ne sont pas disponibles. Les opérations internes telles que les analyses antimalware, l’eDiscovery, la DLP ou l’indexation de contenu peuvent toutes recourir à cette availability key. Microsoft la détient. Microsoft la contrôle. Microsoft peut l’utiliser.

Ce n’est pas une architecture « zero knowledge ». C’est une hiérarchie de chiffrement opérée par le fournisseur, conçue pour la continuité et la récupération. Ce compromis peut avoir du sens dans de nombreux environnements. Mais pour les organisations dont la souveraineté exige que « le fournisseur ne puisse pas déchiffrer », il s’agit d’une faille structurelle qu’aucune certification FedRAMP ne peut combler.

L’affaire BitLocker a rendu la faille visible

Si la différence entre « le fournisseur détient les clés » et « le fournisseur ne peut pas accéder aux clés » paraissait abstraite avant 2025, l’affaire BitLocker y a mis fin.

Plusieurs rapports ont confirmé que Microsoft a remis les clés de récupération BitLocker au FBI suite à un mandat dans le cadre d’une enquête à Guam. Les clés étaient en possession de Microsoft car c’est ainsi que fonctionne l’architecture de récupération. Un ordre légal valide est arrivé. Microsoft s’est exécuté. Les données ont été déchiffrées.

La leçon n’est pas que BitLocker est peu sûr. La leçon, c’est que lorsque le fournisseur détient les clés de récupération — ou peut exercer les clés pour des opérations de service — l’accès légal devient une question de procédure. Le chiffrement ne bloque pas la divulgation. Il l’encadre.

Microsoft publie chaque année un rapport Government Requests for Customer Data qui documente précisément ce processus. La norme du CLOUD Act américain est explicite : les fournisseurs peuvent être contraints de fournir les données en leur « possession, garde ou contrôle », quel que soit leur lieu de stockage. GCC High ne change pas cette réalité juridique fondamentale. Il modifie la frontière opérationnelle. Ce sont deux choses différentes.

Nos données rendent cela concret, et non hypothétique. Les demandes d’accès gouvernementales figurent déjà parmi les incidents de souveraineté. Un répondant sur dix les cite. Ce ne sont pas des cas marginaux. Ils font partie du quotidien.

Customer Lockbox : gouvernance, pas impossibilité

La fonction Customer Lockbox de Microsoft est souvent présentée comme la réponse aux inquiétudes sur l’accès du fournisseur. Et, pour être juste, c’est un bon contrôle de gouvernance. Elle permet aux clients d’approuver ou de refuser les demandes d’accès privilégié lorsqu’un ingénieur Microsoft doit intervenir sur des données dans le cadre du support.

Mais relisez bien cette phrase. Elle permet aux clients d’approuver ou de refuser les demandes d’accès. Le chemin d’accès existe par conception. Lockbox le gère. Lockbox ne le supprime pas.

Pour les organisations soumises au RGPD, à la LPRPDE ou au PDPL — où l’exigence émergente est la séparation technique, pas la gestion des workflows — « nous approuvons ou refusons, puis auditons » ne suffit peut-être plus. Notre rapport révèle que 59 % des répondants citent la refonte de l’infrastructure technique comme principal poste de dépense. Ils investissent pour reconstruire des architectures, car les seuls contrôles de processus ne suffisent plus.

GCC High échoue par conception au test EMEA et Canada

C’est ici que la promesse de GCC High s’inverse totalement.

GCC High est explicitement hébergé, opéré et juridiquement rattaché aux États-Unis. C’est ce qui le rend adapté aux sous-traitants du DoD et aux charges de travail alignées CJIS. Mais c’est aussi ce qui le rend inadapté aux stratégies de souveraineté de l’EMEA et du Canada.

Les résultats de notre rapport pour le Canada sont parlants. Quarante pour cent des répondants canadiens identifient les évolutions du partage de données Canada–États-Unis comme leur principale préoccupation réglementaire. Vingt et un pour cent citent directement le CLOUD Act américain. Dans ce contexte, migrer du contenu canadien sensible dans une enclave exclusivement américaine n’est pas une stratégie de souveraineté — c’est une contradiction.

Les données européennes sont tout aussi claires. Quarante-quatre pour cent des répondants européens s’inquiètent des garanties de souveraineté du fournisseur, principal frein à l’adoption du cloud — le taux le plus élevé de toutes les régions interrogées. D’autres études le confirment : IDC identifie la « protection contre les demandes extraterritoriales » comme principal moteur du cloud souverain en Europe. Un sondage team.blue révèle que 57 % des PME européennes ignorent si leur fournisseur cloud garantit un stockage exclusivement européen.

Il y a aussi le problème concret de la collision juridique. Une ordonnance canadienne obligeant un fournisseur à produire des données stockées en Europe illustre comment les revendications de souveraineté peuvent s’effondrer face aux exigences de juridictions étrangères. Si votre stratégie de souveraineté repose sur la capacité du fournisseur à résister ou à gérer les procédures étrangères, vous pariez sur les avocats. Pas sur l’architecture. L’arrêt Schrems II a posé ce principe il y a des années : les contrats ne prévalent pas sur les lois d’accès des gouvernements étrangers. Pourtant, de nombreuses organisations continuent d’agir comme si les accords fournisseurs remplaçaient les contrôles structurels.

Conformité CMMC et la solution partielle coûteuse

Beaucoup de sous-traitants de la défense choisissent par défaut GCC High pour la conformité CMMC 2.0 car il répond aux bons référentiels et maintient les CUI dans une frontière américaine. Ce raisonnement n’est pas faux, mais il est incomplet.

CMMC et la souveraineté convergent vers la même attente : prouver que seuls les acteurs autorisés peuvent accéder aux CUI et que les contrôles empêchent toute divulgation inappropriée, notamment via des tiers.

Notre rapport montre que les défaillances de conformité des tiers sont à égalité avec les incidents de souveraineté les plus fréquents (17 %). Les équipes signalent que la complexité de la souveraineté se concentre dans la refonte de l’infrastructure et la conformité des fournisseurs — pas dans l’usage quotidien de l’e-mail et du partage de fichiers. Le plus difficile n’est pas de sécuriser son propre environnement. C’est de prouver que la supply chain ne peut pas divulguer ce que vous cherchez à protéger.

GCC High vous offre une enclave conforme. Mais les données qui s’y trouvent restent déchiffrables par Microsoft dans certaines conditions. Pour de nombreux scénarios CMMC, cela crée un écart entre l’exigence de contrôle (« seuls les membres autorisés de l’organisation peuvent accéder aux CUI ») et la réalité opérationnelle (« Microsoft peut exercer les clés pour les opérations de service, l’eDiscovery ou sur demande légale »).

Des analystes indépendants notent que GCC High est souvent présenté comme la voie par défaut pour la CMMC, mais il n’est pas exigé formellement par le référentiel et peut limiter fortement la flexibilité et la rentabilité. Les coûts de migration pour la conformité CMMC dépassent régulièrement 300 000 $ et peuvent aller jusqu’à plus d’un million de dollars pour des sous-traitants de taille moyenne — pour un environnement où Microsoft reste dans le périmètre d’accès légal.

La vraie question pour les sous-traitants de la défense n’est pas « GCC High coche-t-il les cases de conformité ? » — c’est souvent le cas. La question est de savoir si ces cases empêchent réellement les scénarios de divulgation que la souveraineté doit éviter.

À quoi ressemble vraiment le « contrôle prouvable »

Notre rapport ne plaide pas pour une « souveraineté de façade ». Il défend la maturité opérationnelle.

Les répondants estiment que la conformité à la souveraineté des données apporte une vraie valeur métier — amélioration de la sécurité et renforcement de la confiance client en tête. Mais ils soulignent aussi le coût réel. Les changements d’infrastructure technique (59 %) et l’expertise juridique (53 %) sont les principaux postes de dépense. Les investissements annuels sont conséquents, la plupart des organisations y consacrant plus d’un million de dollars par an.

Le signal prospectif est clair. L’automatisation de la conformité et le renforcement des contrôles techniques guident les stratégies à deux ans dans les trois régions. Le marché exprime ses besoins : moins d’outils dispersés, plus d’application unifiée, et des preuves à la demande.

C’est précisément la faille que Kiteworks vient combler. Le Réseau de données privé consolide les canaux où la souveraineté échoue le plus souvent — la messagerie électronique, le partage et le transfert de fichiers, Kiteworks SFTP et les formulaires de données sécurisés Kiteworks — sur une plateforme unique avec propriété exclusive des clés de chiffrement, journaux d’audit immuables et reporting automatisé de conformité. Le fournisseur ne peut pas déchiffrer vos données. Il ne peut pas remettre vos clés aux autorités. Et quand un auditeur demande une preuve, vous la produisez à partir d’un seul système, sans devoir rassembler des éléments issus de six outils différents.

Une voie pragmatique : éliminer d’abord les points de vulnérabilité

Si vous souhaitez traduire les conclusions du rapport en actions sans bouleverser tout votre environnement Microsoft, commencez par la couche d’échange. C’est là que les incidents surviennent.

Commencez par consolider les échanges externes. Les transferts de fichiers fournisseurs, le partage avec des partenaires et la collecte de données côté client sont les points où apparaissent les défaillances de tiers et les transferts transfrontaliers non autorisés. Migrez ces flux vers une plateforme qui impose la résidence et restreint les accès par conception.

Ensuite, standardisez vos preuves. Traçabilité immuable, règles d’accès cohérentes, reporting exportable. Quand le régulateur appelle — ou qu’un client demande — vous ne devez pas avoir besoin d’une enquête de trois semaines pour répondre.

Puis, sécurisez vos clés et limitez l’exposition juridictionnelle. Passez de « nous approuvons les demandes d’accès et auditons ensuite » à « la plateforme ne peut fournir l’accès sans notre contrôle explicite ». C’est la différence entre une souveraineté de workflow et une souveraineté d’architecture.

Enfin, testez vos plans de réponse avant l’incident. Notre rapport montre que les incidents sont fréquents et variés — violations, transferts non autorisés, enquêtes réglementaires, demandes gouvernementales. Si votre premier test du plan intervient lors de l’incident réel, vous partez déjà avec un retard.

Cette approche est aussi plus facile à expliquer à un conseil d’administration. Vous ne remplacez pas Microsoft. Vous encapsulez la couche d’échange critique pour la souveraineté dans un système pensé pour le contrôle prouvable — tout en conservant les outils de productivité là où ils sont utiles.

Une définition moderne de la souveraineté

GCC High constitue une enclave solide pour des exigences spécifiques du gouvernement et de la défense américains. Ce n’est pas une solution de souveraineté pour les organisations qui doivent prouver — aux régulateurs, aux clients, à leur direction — que leur fournisseur ne peut pas accéder, déchiffrer ou être contraint de produire du contenu sensible.

Notre rapport 2026 sur la souveraineté des données illustre clairement les enjeux : une organisation sur trois a connu un incident de souveraineté l’an dernier. Le panel d’incidents recoupe précisément les scénarios que l’architecture GCC High laisse ouverts — défaillances de tiers, transferts non autorisés, enquêtes réglementaires, demandes d’accès gouvernementales. Et le marché se tourne résolument vers l’automatisation, les contrôles techniques et la preuve — pas vers les documents de politique ou les promesses des fournisseurs.

La souveraineté signifiait autrefois la géographie. Aujourd’hui, elle implique la détention des clés, la portée juridictionnelle et la capacité à fournir des preuves. Si votre architecture ne garantit pas ces trois éléments, vous n’avez pas la souveraineté. Vous avez un data center très coûteux avec une étiquette conformité sur la porte.

Si votre stratégie de souveraineté repose encore sur la confiance dans votre fournisseur pour dire non à votre place, il est temps de vous demander si la confiance est le bon fondement — ou si l’architecture ne devrait pas remplir ce rôle à la place.

Téléchargez le rapport complet 2026 Data Security and Compliance Risk: Data Sovereignty Report.