Comment les agences gouvernementales européennes peuvent répondre aux exigences d’achat en matière de souveraineté numérique

Les agences gouvernementales européennes passent de la souveraineté numérique comme objectif à des spécifications d’achat contraignantes. En octobre 2025, la Commission européenne a publié le Cloud Sovereignty Framework (version 1.2.1), qui introduit huit objectifs de souveraineté et une méthodologie de notation permettant à toutes les agences gouvernementales d’évaluer les fournisseurs de cloud. La Commission a soutenu ce cadre par un appel d’offres de 180 millions d’euros pour des services cloud souverains via le Cloud III Dynamic Purchasing System, posant ainsi le premier jalon opérationnel sur la façon dont la souveraineté des données s’applique concrètement aux achats cloud du secteur public.

Ce changement reflète une réalité structurelle à laquelle sont confrontés les acheteurs publics, directeurs IT et responsables de la protection des données dans les administrations européennes. Selon le rapport 2025 du Parlement européen sur la souveraineté technologique, l’UE dépend de pays non membres pour plus de 80 % de ses produits, services, infrastructures numériques et propriété intellectuelle. Les fournisseurs cloud européens ne détiennent qu’environ 15 % du marché de l’UE. Lorsque les données des citoyens, le partage de fichiers entre agences et les échanges réglementaires transitent par des plateformes contrôlées par des fournisseurs non européens soumis au CLOUD Act et à la Section 702 du FISA, l’écart entre l’intention d’achat et la réalité opérationnelle en matière de souveraineté est considérable.

Ce guide explique comment les agences gouvernementales européennes peuvent rédiger des cahiers des charges qui traduisent les exigences de souveraineté en critères techniques évaluables, en s’appuyant sur le Cloud Sovereignty Framework de l’UE et en l’appliquant aux choix concrets lors de la sélection de plateformes pour l’échange de données sensibles.

Résumé Exécutif

À retenir : Les agences gouvernementales européennes disposent désormais d’un cadre standardisé pour évaluer la souveraineté cloud lors des achats publics. Les huit objectifs de souveraineté et le système de notation SEAL (Sovereignty Effective Assurance Level) du Cloud Sovereignty Framework de l’UE offrent des critères évaluables couvrant les dimensions stratégiques, juridiques, opérationnelles et technologiques. Ce cadre permet de rédiger des cahiers des charges qui distinguent la véritable souveraineté des arguments marketing, en exigeant des preuves architecturales plutôt que de simples garanties contractuelles.

Pourquoi c’est important : Le Cloud Sovereignty Framework n’est pas théorique. La Commission européenne l’utilise pour son propre appel d’offres de 180 millions d’euros, dont l’attribution est attendue entre décembre 2025 et février 2026. Toute offre ne respectant pas les niveaux d’assurance minimum sur les huit objectifs est automatiquement rejetée. Les gouvernements nationaux devraient adopter des critères similaires. La certification SecNumCloud en France impose déjà des exigences de souveraineté pour le cloud du secteur public. En Allemagne, les Cloud Platform Requirements fixent des attentes comparables via le partenariat Delos Cloud. Les agences qui n’actualisent pas leurs cahiers des charges risquent de choisir des fournisseurs incapables de répondre aux nouveaux standards nationaux et européens en matière de souveraineté.

5 points clés à retenir

1. Le Cloud Sovereignty Framework de l’UE définit huit objectifs évaluables pour les achats publics. SOV-1 à SOV-8 couvrent la souveraineté stratégique, juridique, des données, opérationnelle, de la supply chain, technologique, de sécurité et environnementale. Chacun est noté selon les niveaux SEAL, de 0 (aucune souveraineté) à 4 (pleine souveraineté numérique). Les agences peuvent fixer des seuils SEAL minimums comme critères d’éligibilité.
2. La souveraineté juridique et de juridiction (SOV-2) exige une évaluation honnête de l’exposition aux lois extraterritoriales. Le cadre évalue explicitement si des autorités non européennes peuvent exiger l’accès aux données ou aux systèmes par des moyens juridiques, contractuels ou techniques. Les fournisseurs soumis au CLOUD Act obtiennent une note plus faible, quel que soit l’emplacement du data center dans l’UE.
3. Les stratégies nationales de souveraineté cloud convergent vers les standards européens. La certification SecNumCloud en France, le programme Souveräner Cloud en Allemagne et le Cloud Sovereignty Framework de l’UE partagent des exigences clés sur le contrôle des clés de chiffrement, la localisation des données et l’indépendance opérationnelle vis-à-vis d’entités non européennes.
4. Le chiffrement contrôlé par le client est un critère fondamental d’achat. La souveraineté des données et de l’IA (SOV-3) évalue si l’agence garde le contrôle des clés de chiffrement et si le fournisseur peut accéder au contenu déchiffré. Ce critère distingue la véritable souveraineté des arguments marketing sur la localisation des données.
5. Le Cloud and AI Development Act va inscrire ces exigences dans la loi. La Commission européenne a annoncé une législation visant à créer une politique cloud harmonisée à l’échelle de l’UE pour les administrations publiques, rendant obligatoires les standards de souveraineté. Adopter dès maintenant des cahiers des charges alignés sur ce cadre permet aux agences de devancer les futures obligations réglementaires.

Le Cloud Sovereignty Framework de l’UE : Guide pratique pour les acheteurs publics

Huit objectifs de souveraineté comme critères d’évaluation

Le Cloud Sovereignty Framework, publié par la Commission européenne le 20 octobre 2025, propose une méthodologie d’évaluation structurée que les acheteurs peuvent intégrer directement dans leurs appels d’offres. Ce cadre s’inspire du programme Cloud de Confiance français, de l’initiative Souveräner Cloud allemande, et de réglementations européennes comme NIS2 et DORA pour définir la souveraineté de façon mesurable.

Les huit objectifs de souveraineté (SOV-1 à SOV-8) offrent une structure d’évaluation complète. SOV-1 : Souveraineté stratégique évalue la gouvernance, la propriété et la structure capitalistique du fournisseur, sous contrôle de l’UE ou exposées à des dépendances extérieures. SOV-2 : Souveraineté juridique et de juridiction mesure l’exposition aux systèmes juridiques non européens, y compris la possibilité pour des autorités étrangères d’exiger l’accès aux données par des moyens juridiques, contractuels ou techniques. Cet objectif cible directement le CLOUD Act et les lois extraterritoriales similaires. SOV-3 : Souveraineté des données et de l’IA porte sur le contrôle du traitement, du stockage des données et de la gestion des clés de chiffrement. SOV-4 : Souveraineté opérationnelle examine si l’exploitation, le support et la maintenance des services sont réalisés sous juridiction européenne.

SOV-5 : Souveraineté de la supply chain analyse l’origine et le contrôle des composants matériels, des dépendances logicielles et des sous-traitants. SOV-6 : Souveraineté technologique évalue le degré d’indépendance technologique, notamment si la stack technique repose sur des systèmes propriétaires non européens pouvant être suspendus. SOV-7 : Souveraineté sécurité et conformité mesure l’alignement avec les cadres de certification cybersécurité européens (ENISA, NIS2, DORA). SOV-8 : Durabilité environnementale concerne l’efficacité énergétique, l’utilisation d’énergies renouvelables et le reporting sur la durabilité.

Niveaux SEAL : de l’absence à la pleine souveraineté numérique

Chaque objectif de souveraineté est noté selon les Sovereignty Effective Assurance Levels (SEAL), de SEAL-0 (aucune souveraineté) à SEAL-4 (pleine souveraineté numérique). Le cadre fixe des niveaux SEAL minimums à atteindre pour chaque objectif afin de pouvoir candidater aux marchés publics européens. Toute offre ne respectant pas le seuil minimum sur un seul objectif est automatiquement rejetée.

Pour les acheteurs publics, le système SEAL fournit le langage et la structure nécessaires pour dépasser les exigences vagues de souveraineté dans les appels d’offres. Plutôt que d’exiger que le fournisseur « garantisse la souveraineté des données », les agences peuvent imposer des niveaux SEAL précis pour chaque objectif. Par exemple, un appel d’offres pour le traitement des données citoyennes peut exiger SEAL-3 ou plus pour SOV-2 (souveraineté juridique) et SOV-3 (souveraineté des données), tout en acceptant SEAL-2 pour SOV-8 (durabilité environnementale).

Traduire le cadre en spécifications d’achat

Critères essentiels pour les plateformes de données sensibles

Les agences publiques qui achètent des plateformes pour le partage sécurisé de fichiers, les communications inter-agences et le traitement des données citoyennes doivent prioriser quatre des huit objectifs de souveraineté dans leurs cahiers des charges.

Souveraineté juridique et de juridiction (SOV-2) est le critère le plus déterminant. Les spécifications doivent exiger que le fournisseur divulgue toutes les juridictions dont les lois s’appliquent à sa structure, ses opérations, son personnel et ses activités de traitement des données. Il faut demander explicitement si une autorité non européenne peut exiger la production, la divulgation ou l’accès aux données de l’agence par tout moyen légal, y compris les injonctions de sécurité nationale, les réquisitions judiciaires ou les pouvoirs de collecte de renseignements. Les fournisseurs soumis au CLOUD Act doivent répondre par l’affirmative, quel que soit l’emplacement physique des données.

Souveraineté des données (SOV-3) : les spécifications doivent exiger une documentation détaillée de l’architecture de chiffrement. Les questions clés sont : l’agence génère-t-elle et conserve-t-elle ses propres clés de chiffrement ? Le fournisseur peut-il accéder au contenu déchiffré, même dans certains cas ? La gestion des clés est-elle techniquement séparée de l’environnement de traitement des données ? La différence entre clés gérées par le fournisseur (qui peut déchiffrer) et clés contrôlées par le client (qui ne le peut pas) marque la frontière entre simple localisation et véritable souveraineté des données.

Souveraineté opérationnelle (SOV-4) : les spécifications doivent préciser si l’exploitation, la maintenance et le support sont assurés exclusivement par du personnel basé dans l’UE et sous juridiction européenne. Les agences doivent exiger la divulgation de toute capacité d’accès à distance depuis l’extérieur de l’UE et de toute situation où du personnel non européen pourrait accéder aux environnements de l’agence.

Souveraineté de la supply chain (SOV-5) : les spécifications doivent exiger la transparence sur la chaîne de sous-traitance, notamment si l’infrastructure repose sur des plateformes cloud non européennes qui réintroduisent l’exposition juridique que la souveraineté vise à éliminer.

Rédiger des spécifications évaluables : approche pratique

Des spécifications efficaces traduisent les exigences de souveraineté en questions techniques fermées (oui/non) et en exigences de preuves documentées. Pour chaque objectif prioritaire, le cahier des charges doit inclure une obligation de divulgation (ce que le fournisseur doit révéler), un critère d’évaluation (comment les réponses sont notées) et un standard de preuve (quels documents prouvent la conformité).

Pour la gestion des clés de chiffrement, la spécification pourrait indiquer : « Le fournisseur doit documenter l’intégralité du cycle de vie des clés de chiffrement, y compris leur génération, stockage, rotation et destruction. L’agence conserve le contrôle exclusif des clés dans son propre module de sécurité matériel (HSM) ou un système équivalent. Le fournisseur doit démontrer, par une documentation architecturale et une vérification indépendante, qu’il ne peut en aucun cas accéder aux données déchiffrées de l’agence, même sous contrainte légale de n’importe quelle juridiction. »

Pour la localisation des données, la spécification pourrait exiger : « Toutes les données de l’agence, y compris le stockage principal, les sauvegardes, les réplicas et les métadonnées, doivent résider exclusivement dans [État(s) membre(s) de l’UE spécifié(s)]. Le fournisseur doit mettre en place des contrôles techniques empêchant toute sortie de données hors des frontières désignées et fournir un audit continu de la localisation des données. L’agence doit pouvoir vérifier de façon indépendante la résidence des données. »

Pour l’indépendance vis-à-vis du fournisseur, la spécification doit indiquer : « Le fournisseur doit démontrer que l’agence peut mettre fin au contrat sans perte de données ni interruption de service. Toutes les données de l’agence doivent être exportables dans des formats standards et non propriétaires. Le fournisseur doit documenter un plan de transition testé, incluant le calendrier, les ressources nécessaires et les procédures de migration des données. »

Stratégies nationales de souveraineté à suivre pour les agences

France : SecNumCloud et Cloud de Confiance

La France adopte l’approche la plus prescriptive d’Europe. La certification SecNumCloud de l’ANSSI (v3.2) impose la localisation de toutes les données clients et techniques dans l’UE, un support assuré dans l’UE par du personnel européen, et des restrictions de propriété limitant les actionnaires non européens à moins de 25 % individuellement et 39 % collectivement. La certification SecNumCloud est obligatoire pour les achats cloud du secteur public français et de plus en plus influente pour les opérateurs d’infrastructures critiques (santé, énergie, finance, transport). Le partenariat de Microsoft avec Bleu (coentreprise Orange/Capgemini) et celui de Google avec S3NS (Thales) illustrent le poids opérationnel de ces exigences.

Allemagne : Cloud Platform Requirements et Delos Cloud

L’approche allemande repose sur les Cloud Platform Requirements définis par le gouvernement, mis en œuvre via le partenariat Delos Cloud (filiale SAP exploitant des technologies Microsoft sous contrôle allemand). L’IT-Planungsrat coordonne les standards IT du secteur public au niveau fédéral et régional. Pour les agences allemandes, les attentes de la BaFin sur l’externalisation cloud et les recommandations techniques du BSI complètent les exigences européennes. Les agences achetant pour l’État fédéral ou les Länder doivent combiner les critères du Cloud Sovereignty Framework de l’UE et les exigences spécifiques à l’Allemagne.

Convergence vers les standards européens

La Commission européenne a annoncé le Cloud and AI Development Act (CAIDA), qui doit instaurer une politique cloud unique à l’échelle de l’UE pour les administrations publiques, avec des standards d’achat harmonisés. Cette législation s’appuiera largement sur les huit objectifs et la méthodologie SEAL du Cloud Sovereignty Framework. Les agences qui alignent dès maintenant leurs cahiers des charges sur ce cadre seront prêtes à répondre aux exigences du CAIDA dès leur entrée en vigueur, sans devoir relancer ou renégocier leurs contrats existants.

L’écart de souveraineté dans la pratique actuelle des achats publics

Pourquoi « data center UE » n’est pas un critère suffisant

De nombreuses spécifications d’achat public exigent la « localisation des données dans l’UE » ou un « data center situé dans l’UE » comme critère de souveraineté. Le Cloud Sovereignty Framework montre pourquoi cela ne suffit pas. L’emplacement du data center répond à la géographie physique mais pas à la juridiction légale, au contrôle des clés de chiffrement, à l’accès opérationnel ou aux dépendances de la supply chain. Un fournisseur basé aux États-Unis exploitant un data center dans l’UE obtient SEAL-0 ou SEAL-1 sur SOV-2 (souveraineté juridique), car la loi américaine s’applique indépendamment de l’emplacement des serveurs.

Le choix de la Commission européenne d’utiliser huit objectifs distincts plutôt qu’une simple case « souveraineté » reflète la complexité multidimensionnelle du sujet. Se baser uniquement sur la localisation du data center permet aux fournisseurs de revendiquer la conformité souveraine tout en restant soumis aux exigences d’accès des gouvernements non européens.

Pourquoi les partenariats « cloud souverain » doivent être examinés de près

Face à la pression européenne, les hyperscalers américains ont noué des partenariats locaux. Bleu (Microsoft, France), Delos Cloud (Allemagne), S3NS (Google, France) et le European Sovereign Cloud d’AWS se présentent comme des alternatives souveraines. Mais le niveau réel de souveraineté varie fortement, et les cahiers des charges doivent les évaluer selon les mêmes critères que tout autre fournisseur.

Les questions clés pour évaluer ces partenariats sont : le partenaire européen a-t-il un contrôle technique total sur la stack ou dépend-il de la maison mère américaine pour le code, les mises à jour et la maintenance ? L’arrangement a-t-il été testé en cas de demande au titre du CLOUD Act ou du FISA, et quel en serait le résultat documenté ? L’entité européenne peut-elle fonctionner de façon autonome si le partenaire américain se retire ? L’architecture repose-t-elle sur une infrastructure dédiée ou sur une infrastructure mutualisée avec des charges de travail non souveraines ?

Mise en œuvre : intégrer la souveraineté dans votre processus d’achat

Phase 1 : évaluer les solutions existantes avec le cadre

Cartographiez tous les services cloud et SaaS traitant des données citoyennes, des communications inter-agences, des échanges réglementaires et des documents internes. Pour chaque service, évaluez le fournisseur actuel selon les huit objectifs de souveraineté, en notant les niveaux SEAL atteints si possible. Identifiez les solutions dont la souveraineté juridique (SOV-2) ou des données (SOV-3) est inférieure aux seuils acceptables. Cette évaluation permet de prioriser les migrations.

Phase 2 : rédiger des appels d’offres alignés sur le cadre

Rédigez des cahiers des charges intégrant les huit objectifs de souveraineté comme critères d’évaluation, avec des niveaux SEAL minimums définis pour chacun. Pondérez les critères selon la sensibilité des données et des fonctions concernées. Exigez la divulgation obligatoire de l’architecture de chiffrement, de l’exposition aux juridictions, de l’accès opérationnel et de la composition de la supply chain. Précisez les standards de preuve attendus : documentation architecturale, et non supports marketing. Définissez les exigences de sortie alignées sur les attentes du cadre pour la souveraineté opérationnelle.

Phase 3 : évaluer les réponses avec la méthodologie du cadre

Notez les réponses des fournisseurs pour chaque objectif de souveraineté selon la méthode SEAL. Rejetez toute réponse ne respectant pas les seuils minimums sur les objectifs prioritaires. Pour les offres qualifiées, appliquez la pondération du cadre pour comparer la posture globale de souveraineté. Demandez une vérification indépendante des affirmations du fournisseur, notamment sur la gestion des clés de chiffrement et l’indépendance juridictionnelle.

Phase 4 : valider et suivre après attribution

Après attribution, vérifiez que l’architecture déployée correspond au cahier des charges grâce à un audit indépendant. Mettez en place un suivi continu, avec réévaluation périodique des objectifs de souveraineté, notamment en cas d’évolution de la structure du fournisseur, de la sous-traitance ou du contexte juridique. Prévoyez contractuellement la possibilité de résilier si la posture de souveraineté descend sous les seuils fixés.

Des achats souverains pour préserver la confiance des citoyens

Les citoyens européens confient à leurs gouvernements des données personnelles : dossiers fiscaux, informations médicales, données sociales, documents d’identité, communications inter-agences… Il s’agit des informations les plus sensibles d’une société. Lorsque ces données transitent par des plateformes soumises à des exigences d’accès de gouvernements étrangers, la promesse implicite de protection des données citoyennes est rompue, quels que soient les contrats signés.

Le Cloud Sovereignty Framework de l’UE donne aux agences publiques les outils pour prendre des décisions d’achat respectant cette confiance. En traduisant les principes de souveraineté en critères techniques évaluables, les agences peuvent choisir des plateformes qui offrent une véritable protection, et non de simples garanties contractuelles qui ne résistent pas à la contrainte légale étrangère.

Kiteworks aide les agences gouvernementales européennes à répondre aux exigences d’achats souverains

Le Réseau de données privé Kiteworks propose une architecture souveraine alignée sur les exigences du Cloud Sovereignty Framework de l’UE sur tous les objectifs prioritaires. Sur SOV-2 (souveraineté juridique), le modèle de chiffrement contrôlé par le client de Kiteworks garantit que la plateforme ne peut pas répondre à des demandes de déchiffrement émanant de gouvernements étrangers, car elle ne détient pas les clés. Sur SOV-3 (souveraineté des données), les agences génèrent et conservent les clés dans leur propre HSM, rendant tout accès non autorisé techniquement impossible.

Kiteworks se déploie en instance à locataire unique sur une infrastructure européenne dédiée, répondant à SOV-4 (souveraineté opérationnelle) grâce à des environnements isolés, non partagés avec d’autres clients ou juridictions. Le géorepérage intégré impose la résidence des données au niveau de la plateforme, fournissant l’audit continu exigé par les cahiers des charges alignés sur le cadre. Kiteworks contribue à la conformité RGPD, à l’alignement NIS2 et à la résilience opérationnelle DORA sur tous les canaux de communication de contenu sensible.

La plateforme unifie le partage sécurisé de fichiers, la protection des e-mails, le transfert de fichiers géré et les formulaires web sous un même cadre de gouvernance, permettant aux agences de répondre aux exigences de souveraineté sur tous les canaux d’échange de données avec une seule architecture, une seule évaluation et un seul dossier de preuves.

Pour en savoir plus sur la conformité aux exigences d’achats souverains, réservez votre démo personnalisée dès aujourd’hui.

Ressources complémentaires 

• Article de blog  
  Souveraineté des données : bonne pratique ou obligation réglementaire ?
• eBook  
  Souveraineté des données et RGPD
• Article de blog  
  Les pièges à éviter en matière de 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]