Déployer “en Europe” ou “sur site”, est ce vraiment être souverain? Pour la plupart des entreprises, le vrai choix est plus concret : où héberger le modèle et les données pour garder un contrôle réel (juridiction, accès, dépendances). En pratique, beaucoup d’organisations confondent encore résidence et maîtrise : déployer “en Europe” ou “sur site” ne dit rien, à lui seul, de qui opère l’infrastructure, de quel droit peut s’appliquer, ni de qui a la main sur les clés, les accès et les couches matérielles.
Depuis deux ans, l’expression “sovereign compute” s’est imposée dans les annonces et les offres commerciales. Mais que vaut-elle réellement, quand une partie décisive du contrôle dépend de l’opérateur cloud, des chaînes de sous-traitance, et des puces qui font tourner les modèles ?
Dans cet article, je m’appuie sur plusieurs travaux récents pour clarifier ce que les données disent vraiment de la souveraineté du compute IA, et en tirer des implications opérationnelles : comment raisonner en niveaux de souveraineté, où se situent les angles morts, et quelles décisions d’architecture permettent de réduire le risque sans tomber dans des promesses irréalistes.
Key takeaways
Les études empiriques — Richardson et al. (2025), Hawkins, Lehdonvirta & Wu (2025) — établissent un fait difficile à contester : construire localement ne garantit pas de contrôler localement, et la souveraineté d’un data center dépend autant de qui le construit, qui l’opère, et avec quelles puces, que de l’adresse à laquelle il se trouve. Le cadre analytique de Mügge (2024) et de Lehr, Stocker & Whalley (2025) y ajoute une dimension politique : les réponses purement protectionnistes ou autarciques sont non seulement infaisables, mais contre-productives. Le “sovereignty washing” (Lehr et al.) et la confusion entre souveraineté juridictionnelle et citoyenne (Mügge) sont déjà à l’œuvre dans les discours institutionnels comme dans les offres commerciales. Angelier (2026) et McKinsey (2025) proposent la sortie opérationnelle : la souveraineté réelle se construit au niveau de la donnée, pas de l’infrastructure. Elle n’exige pas de tout rapatrier — elle exige de savoir précisément ce qu’on ne contrôle pas, et de s’en assurer là où ça compte. Pour les entreprises qui passent à l’échelle, une stratégie de souveraineté d’infrastructure IA sérieuse doit intégrer la dimension juridictionnelle dès la conception — pas comme une contrainte légale de dernière minute, mais comme un paramètre d’architecture à part entière.
1. L’illusion du data center souverain
La notion de souveraineté numérique repose historiquement sur le principe de territorialité : un État exerce son autorité sur tout ce qui se passe dans ses frontières. Appliqué aux data centers, cela signifie que si votre infrastructure est physiquement sur le territoire français, belge ou japonais, l’État concerné a juridiction dessus.
Le problème : les data centers ne sont pas seulement définis par leur emplacement physique. Ils sont opérés par des entreprises, qui ont une nationalité. Or, en droit international, le principe de nationalité permet à un État d’exercer sa juridiction sur ses entreprises nationales, même quand elles opèrent à l’étranger.
Un data center construit en Allemagne mais opéré par AWS reste potentiellement sous juridiction américaine via le Cloud Act de 2018, qui contraint les entreprises américaines à fournir des données sur demande des autorités, quel que soit le pays où ces données sont stockées.
L’étude “How Sovereign Is Sovereign Compute?” (Richardson et al., 2025) essaye de quantifier la proportion de datacenters tombant sous la gouvernance du droit local à leur emplacement physique sur 775 projets hors Etats-Unis.Hawkins, Lehdonvirta & Wu (2025), dans un travail parallèle mené depuis Oxford, posent la même question avec un prisme différent : en cartographiant 225 régions cloud de 9 hyperscalers majeurs sur 43 pays, ils montrent que la réponse dépend entièrement du niveau d’analyse retenu: les résultats changent radicalement selon si l’on mesure la localisation des serveurs, la nationalité de l’opérateur. Quelques données clés à retenir:
48% des projets de datacenter non-US sont opérés par des entreprises américaines (en valeur d’investissement)
56% de des investissements des projets IA spécifiquement opérée par des entreprises US
76% de la capacité compute mondiale pourrait relever de la juridiction américaine (estimation)
Pour les projets dédiés à l’IA en particulier, la concentration est encore plus marquée. Les entreprises américaines — AWS, Microsoft Azure, Google Cloud, Oracle — opèrent plus de la moitié de la valeur d’investissement mondiale en infrastructures IA hors États-Unis.
Hawkins et al. (2025) ajoutent une couche à ce tableau : même parmi les pays qui hébergent du compute IA sur leur territoire, la souveraineté au niveau des puces est quasi universellement américaine — NVIDIA représentant la quasi-totalité des accélérateurs dans les régions cloud publiques. Ce que les auteurs appellent la souveraineté “territoriale” (serveurs sur le sol national) peut donc coexister avec une dépendance totale aux couches hardware et opérationnelles.
En comparaison, les opérateurs chinois représentent 8% des projets et seulement 5% de la valeur d’investissement totale — avec une présence quasi nulle sur les projets IA hors de Chine.
2. La souveraineté compute est un spectre, pas un état binaire
L’erreur classique est de traiter la souveraineté numérique comme un interrupteur on/off. En réalité, c’est un continuum qui se joue sur plusieurs dimensions simultanément :
- Où sont physiquement les serveurs ?
- Qui les opère, et sous quelle juridiction ?
- Quelles législations encadrent les échanges de données transfrontaliers ?
- Qui détient les clés de chiffrement ?
Hawkins et al. (2025) formalisent cela en trois niveaux d’analyse distincts — territorial, cloud ownership, et accelerator vendor — et montrent qu’un pays peut scorer “souverain” sur le premier niveau tout en étant totalement dépendant sur les deux autres. C’est précisément ce qu’une lecture naïve des annonces gouvernementales manque.
Une entreprise qui optimise uniquement sur la première dimension — la localisation physique — peut se retrouver dans impression de souveraineté. Il est important de savoir à quel niveau de souveraineté on se situe réellement dans sa stratégie.
La vraie question n’est pas “où est mon data center ?” mais “qui peut légalement accéder à mes données et systèmes, et dans quelles conditions ?”
La notion de souveraineté dans le cadre européen
Une compréhension du spectre de la souveraineté compute en France passe nécessairement par une analyse du contexte européen. Mügge (2024), dans une étude des textes de la Commission depuis 2018 et des négociations de l’AI Act, distingue deux conceptions de la souveraineté numérique qui ne se recoupent pas :
- La souveraineté juridictionnelle — l’indépendance de l’UE face aux grandes puissances américaine et chinoise. C’est la posture dominante dans les textes officiels, avec une logique de “course à l’IA” où les champions européens et les autorités publiques s’allient pour contrer les rivaux géopolitiques.
- La souveraineté citoyenne — la protection des individus face aux grandes plateformes tech, qu’elles soient américaines ou européennes. C’est le parent pauvre de la stratégie réelle, malgré les déclarations sur l'”IA centrée sur l’humain”.
Ce que Mügge révèle est inconfortable : quand l’UE parle de “souveraineté numérique”, elle parle surtout de compétitivité géopolitique, pas de contrôle des citoyens sur leurs données ou leurs systèmes. Pour les entreprises, cela signifie que la conformité aux textes européens ne protège pas nécessairement contre les dépendances opérationnelles — elle sécurise surtout une position dans une compétition entre blocs.
Lehr, Stocker & Whalley (2025) poussent cette tension plus loin encore : une solution développée en France ou en Allemagne présentée comme “européenne” peut être vécue par d’autres États membres comme une dépendance subie plutôt que choisie. Même européenne, une technologie imposée ne garantit ni choix ni contrôle. Le risque de concentration ne s’arrête pas aux frontières de l’UE.
Le “sovereignty washing” : une dérive déjà à l’œuvre
Les chercheurs ont nommé le phénomène : par analogie avec le greenwashing, le “sovereignty washing” désigne les offres commercialisées comme “souveraines” ou “made in EU” tout en reposant critiquement sur des inputs non européens. Lehr et al. (2025) citent le cas du partenariat SAP/OpenAI présenté comme “OpenAI souverain pour l’Allemagne” — un modèle américain, des GPU américains, une infrastructure cloud américaine, sous une étiquette allemande.
Pour les entreprises, cela transforme les due diligences fournisseurs. Interroger l’origine des GPU, la nationalité de l’opérateur du cloud sous-jacent, la provenance du modèle de fondation, et la localisation du traitement des données d’entraînement n’est plus une formalité juridique : c’est le cœur de l’évaluation de risque.
Repenser l’objet de la souveraineté : des infrastructures aux données
Le dernier glissement conceptuel est peut-être le plus utile opérationnellement. Angelier (2026) formule une critique directe des approches centrées autour de l’infrastructure uniquement: elles font erreur sur l’objet même de cette dite souveraineté. Selon Angelier, concentrer les efforts sur la localisation des serveurs ou la nationalité de l’opérateur revient à traiter le symptôme plutôt que la cause.
Sa proposition : déplacer le locus de contrôle vers la donnée elle-même. Ce qui compte n’est pas où tourne le compute, mais qui détient la maîtrise exclusive des clés de chiffrement, qui peut révoquer ou accorder l’accès indépendamment du prestataire, et qui contrôle les mécanismes de prévention de fuite de données. Un opérateur américain hébergeant vos données en Irlande avec des clés que vous contrôlez exclusivement vous confère plus de souveraineté effective qu’un opérateur européen avec accès partagé aux clés.
McKinsey (2025) rejoint cette logique dans un registre plus pragmatique avec ce qu’ils appellent la “minimum sufficient sovereignty” : classifier les workloads selon leur sensibilité réglementaire et leur exposition aux tiers, puis assigner un niveau de souveraineté avec des exigences explicites sur la résidence des données, la propriété des clés et les contrôles d’accès. L’objectif n’est pas la souveraineté totale (— ce qui serait à la fois coûteux et contre-productif), — mais la souveraineté ciblée aux points de contrôle qui comptent vraiment.
3. Recommendations pour les entreprises qui scalent
Cartographiez votre exposition avant de choisir votre stack. La question n’est pas “où hébergeons-nous ?” mais “qui contrôle l’infrastructure et sous quelle loi ?” Avant tout déploiement, établissez une matrice opérateur, juridiction, type de donnée. C’est le seul point de départ sérieux pour une stratégie cloud en contexte réglementaire contraint.
Concevez pour la portabilité dès le premier jour. Les lock-ins technologiques se construisent vite et se défont lentement. Privilégiez des architectures découplées des APIs propriétaires, des formats ouverts, et des couches d’abstraction qui permettent de changer de provider ou d’environnement d’inférence sans tout reconstruire. Ce n’est pas une contrainte de développement : c’est une assurance contre l’évolution des politiques commerciales et réglementaires de vos fournisseurs.
Traitez le chiffrement comme un levier de souveraineté, pas comme une case à cocher. La maîtrise exclusive des clés de chiffrement et des mécanismes d’accès révocables vous confère plus de contrôle effectif sur vos données que n’importe quelle promesse de localisation. C’est actionnable aujourd’hui, avec n’importe quel opérateur.
Évaluez les fournisseurs européens indépendants pour vos données sensibles. OVHcloud, Hetzner, T-Systems — ces opérateurs impliquent parfois un compromis sur la performance ou le catalogue de services, mais ils sortent du périmètre du Cloud Act. Pour certaines catégories de données, ce compromis mérite d’être formellement évalué plutôt que systématiquement écarté.
Sources
“How Sovereign Is Sovereign Compute?”, Richardson et al. (2025)
