Pendant longtemps, les décisions technologiques ont été évaluées à l’aune d’un ensemble de questions bien connues : est-ce plus rapide ? Est-ce moins cher ? Est-ce que cela peut passer à l’échelle ? Est-ce que cela rendra l’équipe plus productive ?
Ces questions restent importantes. Elles ne suffisent plus.
Lorsqu’une organisation dépend d’infrastructures, de plateformes et, de plus en plus, de modèles d’IA externes, une question plus difficile s’impose d’abord : que se passe-t-il lorsque les conditions changent ? Que se passe-t-il lorsque l’accès devient plus coûteux, plus restreint, politiquement sensible, ou difficile à justifier auprès d’un régulateur, d’un conseil d’administration ou d’un client ?
C’est cela, la question de la souveraineté en informatique et en IA.
Il ne s’agit pas seulement de l’endroit où se trouvent les données. Il s’agit du contrôle au sens large : qui peut inspecter le système, l’interrompre, imposer un accès, changer les règles ou rendre la sortie difficile. Il s’agit aussi de responsabilité. Quand quelque chose tourne mal, qui reste responsable ?
Il n’existe pas de définition mondiale unique de la souveraineté numérique. Les différentes juridictions mettent l’accent sur des aspects différents : portée juridique, dépendance à l’infrastructure, contrôle des données, résilience opérationnelle, concentration des fournisseurs et, de plus en plus, contrôle de la couche des modèles d’IA. Le fil conducteur est pratique plutôt qu’idéologique.
La souveraineté est la capacité de conserver un contrôle réel sur les capacités numériques dont une organisation dépend le plus.
Cela ne signifie pas que chaque pays ou chaque entreprise doive tout construire lui-même. Cela signifie savoir où la dépendance est acceptable, où elle est dangereuse, et quel contrôle doit rester en interne ou être garanti par contrat.
La souveraineté n’est pas l’autosuffisance
La souveraineté est souvent confondue avec l’autosuffisance ou la localisation des données. Aucune de ces notions ne couvre l’ensemble du problème.
Une entreprise peut stocker ses données dans la bonne juridiction et rester malgré tout exposée si la plateforme environnante est difficile à quitter, si le fournisseur reste soumis à des exigences juridiques étrangères, ou si les systèmes d’IA intégrés à des flux de travail critiques ne peuvent pas être audités ni influencés par le client.
L’IA rend cette distinction plus urgente. Un modèle n’est pas simplement un composant logiciel de plus. Il peut façonner la manière dont une organisation rédige, recherche, classe, accompagne ses clients, analyse l’information et prend des décisions. Une fois ce seuil franchi, la dépendance remonte dans la pile. La question n’est plus seulement de savoir où une machine fonctionne. Elle devient : qui façonne l’intelligence au cœur du travail ?
La plupart des organisations en font l’expérience dans des situations opérationnelles tout à fait ordinaires. Un fournisseur modifie sa tarification, et un cas d’usage viable devient soudain coûteux. Une mise à jour de modèle change les résultats, et les workflows internes doivent être recalibrés. Les équipes juridiques ou conformité posent des questions simples sur le traitement des données et reçoivent des réponses vagues. Les achats découvrent qu’une architecture présentée comme flexible serait coûteuse et lente à remplacer.
Une crise géopolitique n’est pas nécessaire. Une dépendance ordinaire suffit.
Un débat mondial, avec des langages juridiques différents
La question est mondiale, même lorsque la terminologie diffère.
Aux États-Unis, la préoccupation s’exprime souvent à travers l’autorisation fédérale et les contrôles de sécurité nationale plutôt qu’à travers l’expression souveraineté numérique. FedRAMP fournit une approche standardisée pour évaluer, autoriser et surveiller en continu les services cloud utilisés par les agences fédérales. Les agences restent responsables de leurs charges de travail après leur migration vers le cloud, et les environnements de défense ajoutent des exigences supplémentaires.
Au Royaume-Uni, la question est généralement abordée sous l’angle de la résilience opérationnelle et de la dépendance systémique. La Bank of England, la PRA et la FCA ont mis en place un régime applicable aux Critical Third Parties, car une perturbation majeure chez un prestataire externe peut créer un risque non seulement pour une entreprise, mais aussi pour l’ensemble du système financier.
Le profil de contrôle cloud du Canada pour les informations Protected B rend explicite le principe de responsabilité : des responsabilités peuvent être déléguées à des fournisseurs cloud, mais la responsabilité ne disparaît pas avec ce transfert.
L’Inde associe des exigences de localisation des données pour les données des systèmes de paiement à l’attente que les entités réglementées restent responsables des dispositifs d’externalisation IT et cloud. Singapour encourage l’adoption du cloud tout en le traitant comme une externalisation qui doit être gouvernée. L’Australie, le Brésil et l’Afrique du Sud abordent eux aussi la question sous l’angle de la résilience opérationnelle, du risque lié aux prestataires de services, de l’accès des superviseurs, de la gouvernance des données et des infrastructures stratégiques.
Le constat est clair. La souveraineté n’est pas une préoccupation européenne de niche. C’est une réponse large au fait que la dépendance numérique est devenue stratégique.
Pourquoi l’approche européenne compte
L’Europe a poussé le concept plus loin que la plupart des juridictions en le transformant en cadre d’évaluation et de passation des marchés.
Le Cloud Sovereignty Framework de la Commission européenne évalue les fournisseurs de cloud souverain selon huit objectifs : considérations stratégiques, juridiques et juridictionnelles, données et IA, opérationnelles, chaîne d’approvisionnement, technologiques, sécurité et conformité, et environnementales. Il s’appuie sur deux mécanismes complémentaires :
- Sovereignty Effectiveness Assurance Level (SEAL) : un niveau d’assurance minimal pour chaque objectif.
- Overall sovereignty score : une comparaison pondérée des offres qui atteignent le seuil SEAL requis.
La distinction est importante. Le SEAL global est déterminé par le niveau pertinent le plus faible atteint parmi les objectifs. Une faiblesse sérieuse dans un domaine critique peut donc limiter le niveau global du fournisseur, quelle que soit sa solidité ailleurs. Le score remplit une autre fonction : il permet de distinguer les offres qui ont déjà franchi le seuil minimal.
Le niveau relève d’une logique de seuil ; le score relève d’une logique comparative.
Les orientations de la Commission laissent à l’autorité contractante la possibilité de fixer le SEAL minimal requis pour un marché, puis de comparer les offres qualifiées à l’aide du score. Son marché public de cloud souverain de 2026 exigeait des fournisseurs qu’ils atteignent au moins le niveau SEAL-2. Le cadre reconnaît aussi des degrés de souveraineté : SEAL-2 est associé à la souveraineté des données, SEAL-3 à la résilience numérique, et SEAL-4 à une souveraineté numérique complète.
Le niveau le plus élevé est délibérément exigeant. La Commission note qu’une souveraineté complète reste difficile dans le contexte européen actuel en raison de dépendances persistantes dans les chaînes d’approvisionnement, en particulier pour le matériel et les puces. C’est un correctif utile à une pensée binaire. Un service peut améliorer la posture de souveraineté d’une organisation sans satisfaire à la définition la plus exigeante que l’on puisse imaginer de la souveraineté.
C’est pourquoi ce cadre est plus qu’une checklist. Il oblige le concept à résister à l’épreuve des achats, de l’ingénierie, de l’examen juridique et de la responsabilité institutionnelle.
Pourquoi cela compte au-delà des secteurs réglementés
Les banques, les opérateurs télécoms, les organisations de défense, les systèmes de santé et les autorités publiques ressentent généralement ces pressions en premier, parce que la réglementation rend les enjeux visibles. Mais la vulnérabilité sous-jacente est bien plus large.
Un fabricant qui dépend d’une seule région d’un hyperscaler pour ses analyses de production, une entreprise logicielle qui a bâti des fonctionnalités essentielles autour d’un seul fournisseur de modèles, un distributeur qui s’appuie sur une infrastructure d’identité externe, ou une université qui intègre des outils d’IA tiers dans la recherche et l’administration sont tous confrontés, sous des formes différentes, au même problème.
Une partie du risque est géopolitique. Les contrôles à l’exportation, les sanctions, les interventions au nom de la sécurité nationale et les exigences juridiques transfrontalières peuvent pénétrer plus profondément dans la pile technologique que beaucoup d’organisations ne l’avaient supposé. Une autre partie est structurelle : un petit nombre d’entreprises sous-tend une large part des capacités mondiales en matière de cloud, de plateformes, d’identité et d’IA. Leurs capacités sont souvent excellentes. C’est précisément pour cela que la dépendance peut devenir profonde.
L’IA accentue le problème parce que des services externes deviennent des capacités internes. Lorsqu’un modèle est intégré aux workflows de support, à la rédaction, à la recherche, à la revue de conformité ou à l’expérience produit, il devient une composante de la manière dont l’organisation pense et fonctionne. Si cette couche est difficile à auditer, à gouverner ou à remplacer, la dépendance n’est plus seulement technique. Elle devient managériale et stratégique.
Ce que la grille de lecture de la souveraineté permet de voir
La souveraineté se comprend mieux comme une discipline du jugement, et non comme une exigence d’indépendance totale.
La question utile n’est pas de savoir si une organisation contrôle tout. Presque aucune ne le peut. La meilleure question est : quel objectif de souveraineté est le plus faible, et pourquoi ?
Le facteur limitant est-il la propriété et la gouvernance ? L’exposition juridique ? Le contrôle des données ? La dépendance opérationnelle ? La fragilité de la chaîne d’approvisionnement ? Le verrouillage technologique ? Ou la couche d’IA elle-même ?
Une fois cela rendu visible, la réponse devient concrète. Certaines organisations ont besoin de droits d’audit et de sortie plus solides. D’autres ont besoin de limites juridictionnelles plus strictes pour certaines données ou certaines charges de travail. Certaines peuvent choisir de conserver la portabilité de fonctions sélectionnées entre fournisseurs de cloud ou de modèles, même si cela augmente les coûts. D’autres peuvent accepter une dépendance gérée dans des domaines moins critiques tout en conservant un contrôle plus fort sur les systèmes qui déterminent la résilience, la responsabilité ou l’avantage concurrentiel.
C’est là toute la valeur de la grille de lecture de la souveraineté. Elle n’impose pas une conclusion politique unique et n’exige pas une autosuffisance technologique spectaculaire. Elle donne aux organisations une méthode rigoureuse pour identifier leur objectif pertinent le plus faible, comprendre pourquoi il est faible et décider si cette exposition est acceptable.
Cette question s’applique désormais à l’infrastructure, aux données et, de plus en plus, à l’IA.
Sources
- Commission européenne : le cadre de cloud souverain expliqué (2026)
- Commission européenne : cadre de souveraineté du cloud — guide de mise en œuvre (2026)
- Commission européenne : la Commission fait progresser la souveraineté du cloud grâce aux achats stratégiques (2026)
- APRA : CPG 230 Operational Risk Management
- U.S. General Services Administration : Cloud Security
- Bank of England, PRA, and FCA : Critical Third Parties to the UK financial sector
- Gouvernement du Canada : profil des contrôles de sécurité pour les services GC basés sur le cloud
- Reserve Bank of India : FAQ sur le stockage des données des systèmes de paiement
- Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025
- Monetary Authority of Singapore : Cloud
- Banco Central do Brasil : Resolução CMN nº 4.893
- Gouvernement d’Afrique du Sud : politique nationale sur les données et le cloud (2024)
