La dépendance numérique de l’Europe ne se joue pas d’abord à l’endroit où les serveurs sont installés.
Elle se joue à l’endroit où le contrôle se déplace lorsque les systèmes sont sous tension.
En temps normal, une infrastructure cloud étrangère peut sembler neutre. Les contrats sont respectés. Les services fonctionnent. La performance est mesurable. Les coûts sont optimisés. La dépendance ressemble alors à une décision d’achat.
En situation anormale, cette hypothèse se fragilise.
Escalade juridique, sanctions, arguments de sécurité nationale, pouvoirs d’urgence, demandes de divulgation et pression politique peuvent déplacer l’autorité de décision hors du périmètre du client. L’infrastructure peut rester techniquement disponible pendant que le contrôle de l’accès, de la reprise, de la divulgation et de l’escalade se déplace ailleurs.
C’est la vraie question de souveraineté.
Pas la localisation seule.
Pas l’image de marque.
Pas l’autonomie symbolique.
La souveraineté numérique est fondamentalement une question de risque à budgéter.
Les données de marché récentes montrent l’ampleur de la dépendance. Synergy Research Group indique qu’Amazon, Microsoft et Google représentent environ 70 % du marché européen du cloud, tandis que les fournisseurs européens restent autour de 15 %. InCyber, citant une étude commandée par le Cigref et Numeum, rapporte que les entreprises américaines captent environ 80 % des dépenses européennes de cloud professionnel, soit près de 265 milliards d’euros par an.
Ces chiffres sont souvent présentés comme des données de politique industrielle. Ils doivent aussi être lus comme des données de risque.
Ils montrent où l’Europe achète de la capacité, où elle dépend d’une marge de manœuvre empruntée, et où elle a externalisé le contrôle de certains modes de défaillance critiques.
La réalité structurelle de la domination cloud
Le contrôle suit toujours la juridiction.
Le marché européen du cloud est dominé par des hyperscalers non européens soumis à des cadres juridiques situés en dehors du périmètre institutionnel de l’Union européenne.
Cela ne rend pas ces fournisseurs peu fiables. Au contraire, ils sont souvent supérieurs sur le plan opérationnel. Leur échelle, leur profondeur d’ingénierie, leurs besoins en capitaux, leurs outils de sécurité, leur disponibilité mondiale et leur intégration dans les écosystèmes expliquent précisément leur domination.
Le problème stratégique n’est pas de savoir s’ils fonctionnent.
Le problème stratégique est de savoir qui décide lorsque la contrainte juridique ou politique modifie l’environnement opérationnel.
L’infrastructure cloud n’est pas une utilité neutre. Elle intègre de l’autorité juridique, des droits d’escalade, des obligations d’exécution, des contrôles discrétionnaires, des canaux de support, des systèmes d’identité, des pistes d’audit et des dépendances de reprise.
Une institution financière européenne peut exécuter une charge critique très résiliente sur une plateforme cloud contrôlée par un acteur américain. L’architecture peut être techniquement solide. Les engagements de niveau de service peuvent être robustes. Les données peuvent être stockées en Europe.
Pourtant, dans certaines conditions juridiques, l’autorité de décision peut encore se déplacer hors de la juridiction du client.
C’est le problème de la priorité juridictionnelle.
Le CLOUD Act en est l’exemple le plus visible, mais le sujet dépasse ce seul texte. Dès qu’un fournisseur est soumis à des obligations juridiques externes, les engagements contractuels ne suppriment pas l’exposition souveraine. Ils définissent seulement l’état normal de fonctionnement.
La souveraineté ne se teste pas dans l’état normal.
Elle se teste lorsque l’autorité juridique et la dépendance opérationnelle entrent en collision.
Quand la souveraineté est sous contrainte
La dépendance numérique n’est pas irrationnelle en soi.
En temps normal, le cloud améliore la productivité, accélère les déploiements, réduit les besoins en capitaux et donne accès à des capacités que la plupart des organisations ne pourraient pas construire seules de manière efficiente.
Le problème commence lorsque la dépendance est budgétée comme une source d’efficacité, mais se comporte comme un transfert de contrôle.
Un système peut rester techniquement disponible pendant que la marge de manœuvre de gouvernance change de mains.
La disponibilité physique signifie que l’infrastructure et les réseaux continuent de fonctionner.
La disponibilité logique signifie que les applications et les données restent utilisables.
La disponibilité juridique signifie que l’organisation conserve encore l’autorité sur l’accès, la divulgation, l’escalade et la reprise.
La plupart des discussions sur la résilience cloud se concentrent sur les deux premières couches.
Le problème de souveraineté se situe dans la troisième.
Le périmètre du support peut changer. L’escalade peut être retardée. L’accès peut être restreint. La divulgation peut être imposée. Un fournisseur peut rester stable sur le plan opérationnel pendant que le client perd sa capacité pratique à décider de l’issue.
Ce n’est pas une panne.
C’est un déplacement de gouvernance.
Les contrats ne survivent pas toujours à leur première escalade juridique.
Cette distinction est essentielle, car beaucoup d’organisations construisent leurs plans de continuité autour de la défaillance technique plutôt que de la perte d’autorité.
Elles se préparent à des systèmes dégradés, des pannes régionales, des incidents fournisseur ou des pertes de données.
Elles se préparent moins souvent à un scénario dans lequel le service fonctionne encore, mais où l’organisation ne contrôle plus les conditions de reprise, de divulgation, d’escalade ou de réponse juridique.
C’est là que la souveraineté devient mesurable.
Pas comme slogan.
Comme fonction de perte.
La résilience n’est pas la propriété
Une fois le contrôle déplacé, la question n’est plus de savoir ce que l’organisation possède.
La question est de savoir si elle peut encore agir.
Beaucoup de stratégies de souveraineté confondent propriété et capacité d’action. Fournisseurs nationaux, centres de données locaux, contrats de sauvegarde ou architectures multicloud peuvent améliorer la continuité. Ils ne créent pas automatiquement une autonomie de reprise.
La propriété ne garantit pas la restauration.
Une infrastructure domestique ne garantit pas l’indépendance si l’identité, la gestion des accès, la supervision, la coordination d’incident, les clés cryptographiques, l’orchestration des sauvegardes, les chaînes de mise à jour ou les procédures d’escalade restent contrôlées ailleurs.
À l’inverse, une infrastructure étrangère peut rester stratégiquement acceptable pour certaines charges si les chemins de reprise sont réellement indépendants.
La question centrale est brutale :
l’organisation peut-elle restaurer ses fonctions critiques sans l’autorisation, la coopération, le plan d’identité, le canal de support, les outils ou l’approbation discrétionnaire du fournisseur dominant ?
Si la réponse est non, la résilience est conditionnelle.
La résilience ne se prouve qu’après la perte de contrôle.
C’est à ce moment que les dépendances cachées deviennent visibles.
Les charges de production peuvent être répliquées. Les données peuvent être sauvegardées. L’infrastructure as code peut exister. Un second fournisseur peut être sous contrat.
Mais si l’identité dépend du fournisseur principal, les administrateurs peuvent être bloqués.
Si la supervision dépend du même écosystème, la visibilité d’incident peut disparaître.
Si les sauvegardes sont orchestrées à travers le même plan de contrôle, la restauration peut échouer.
Si les clés cryptographiques sont gérées à l’extérieur, la souveraineté des données devient cosmétique.
Si les outils de réponse à incident dépendent de la plateforme sous contrainte, la coordination devient fragile.
Le résultat n’est pas nécessairement un effondrement complet. Il prend souvent la forme d’une restauration partielle, d’une autorité dégradée, d’une reprise retardée et d’une dépendance stratégique au pire moment.
C’est pourquoi la résilience doit être mesurée par l’indépendance de restauration, pas par les schémas d’architecture.
La réglementation seule ne crée pas de capacité d’infrastructure
L’Europe dispose d’un fort pouvoir réglementaire.
Le RGPD a influencé les normes mondiales en matière de protection des données. Le Digital Markets Act et le Digital Services Act ont accru la pression sur les plateformes dominantes. La régulation de l’intelligence artificielle influence déjà les débats mondiaux sur la gouvernance technologique.
Mais le pouvoir réglementaire n’est pas le pouvoir d’infrastructure.
Cette réglementation peut contraindre les comportements, augmenter le coût des abus et orienter les incitations. Elle ne crée pas, à elle seule, une capacité hyperscale, des écosystèmes d’ingénierie profonds, des outils souverains, une attraction développeur, une profondeur de sécurité ou une capacité industrielle.
Cette distinction est souvent brouillée.
L’Europe peut réguler les conditions de sa dépendance sans éliminer la dépendance elle-même.
L’écart d’échelle est structurel. Le cloud hyperscale est un environnement très consommateur de capitaux, dominé par une logique de concentration. Il récompense l’échelle précoce, la profondeur d’écosystème, l’adoption par les développeurs, la demande mondiale et l’investissement continu. La concentration du marché n’est pas un accident. C’est un résultat économique propre aux infrastructures numériques.
C’est pourquoi les standards seuls ne peuvent pas produire la souveraineté.
Les cadres, certifications et labels de confiance peuvent améliorer la transparence. Ils peuvent réduire l’ambiguïté. Ils peuvent augmenter le coût de la mauvaise représentation.
Mais des standards sans capacité peuvent simplement formaliser la dépendance.
L’erreur stratégique serait de confondre influence normative et contrôle opérationnel.
Une régulation peut définir ce qui devrait se produire.
La capacité détermine ce qui peut réellement se produire.
La souveraineté reste atteignable si elle est définie par le contrôle
La souveraineté numérique est souvent présentée comme un principe.
En pratique, c’est une décision budgétaire contrainte par l’économie des infrastructures.
Reconstruire localement l’ensemble de la chaîne hyperscale exigerait des investissements considérables : centres de données, calcul, stockage, réseau, identité, outils de sécurité, plateformes développeur, opérations et capacité d’innovation.
Pour la plupart des acteurs européens, l’autonomie complète sur toute la chaîne n’est pas économiquement cohérente.
Cela ne signifie pas que la souveraineté est impossible.
Cela signifie qu’elle doit être définie de manière sélective.
La souveraineté coûte cher. La dépendance, elle, est déjà intégrée dans les prix.
Le cadrage binaire est trompeur.
Le choix n’est pas entre indépendance totale et dépendance totale. Les systèmes modernes sont organisés en couches. Le contrôle varie selon les couches. Certaines dépendances sont acceptables. D’autres sont stratégiquement inacceptables.
Le calcul sans état, le stockage standard, les applications non critiques et les charges scalables peuvent être externalisés rationnellement si leur défaillance ne compromet pas la gouvernance.
D’autres couches sont différentes.
L’identité et la gestion des accès, le contrôle des clés cryptographiques, les outils de gouvernance, la coordination d’incident, l’intégrité des audits, l’indépendance des sauvegardes et les composants open source fondamentaux déterminent qui peut agir sous contrainte.
Ce sont des couches de contrôle.
Elles doivent recevoir un prix du risque différent.
Un système est souverain si ses modes de défaillance les plus critiques peuvent être gérés en interne, sans approbation, intervention ou coopération discrétionnaire d’une autorité externe.
La souveraineté s’arrête là où la reprise exige la validation d’une autorité externe.
Cette définition est volontairement étroite. Elle évite les débats symboliques et impose une question plus difficile :
quels modes de défaillance sont trop importants pour être externalisés ?
C’est là que le capital doit être engagé.
Pas dans la duplication performative.
Pas dans le branding patriotique.
Pas dans une infrastructure locale qui ne modifie pas réellement le contrôle.
Mais dans les couches où la perte de marge de manœuvre créerait un dommage stratégique irréversible.
Le vrai prix de la souveraineté numérique
L’Europe n’a pas perdu Internet.
Elle a perdu un contrôle prévisible sur certains modes de défaillance numériques critiques.
Le diagnostic est différent, et plus utile.
Une infrastructure étrangère n’est pas automatiquement hostile. Une infrastructure domestique n’est pas automatiquement souveraine. Des données localisées ne sont pas automatiquement contrôlées. L’efficacité du cloud n’est pas automatiquement une faiblesse stratégique.
La vraie question est celle du pouvoir de décision : qui peut approuver la reprise ? Qui peut retarder l’escalade ou imposer une divulgation ? Qui contrôle l’identité, les clés cryptographiques et l’intégrité des audits ? Qui peut restaurer les opérations sans autorisation externe ?
Ces questions transforment la souveraineté en risque opérationnel mesurable.
La réponse stratégique n’est pas d’éliminer toute dépendance. Ce serait irréaliste et économiquement incohérent.
La réponse consiste à budgéter la dépendance honnêtement.
Certaines dépendances sont efficaces.
Certaines sont tolérables.
Certaines sont existentielles.
Le rôle des dirigeants est de savoir les distinguer avant que les conditions de stress ne le fassent à leur place.
La souveraineté numérique n’est pas une question de symbole ou de localisation. Elle concerne la capacité à conserver une marge de manœuvre lorsque les pressions juridiques, politiques et opérationnelles convergent.
Si le contrôle de l’identité, des clés cryptographiques, de l’escalade, de l’auditabilité et de la reprise est externe, la souveraineté n’existe pas, quel que soit l’emplacement de l’infrastructure.
Les marchés ont déjà intégré le prix de la dépendance.
La question décisive est de savoir si l’Europe, et les organisations qui y opèrent, sont prêtes à budgéter le coût du contrôle.