Cloud et défense européenne : trois ans pour ne plus dépendre de quelqu'un qui peut couper le robinet

# Cloud et défense européenne : trois ans pour ne plus dépendre de quelqu'un qui peut couper le robinet

Imaginez qu'un sous-traitant critique de votre SI soit soumis, du jour au lendemain, à une injonction gouvernementale étrangère qui lui interdit de vous servir. Pas une fiction dystopique : c'est exactement le cadre juridique dans lequel opèrent AWS, Microsoft Azure et Google Cloud depuis le Cloud Act de 2018. En 2026, après des années de mise en garde restées lettre morte, cette réalité commence à peser concrètement sur les arbitrages des DSI européens — et pas seulement dans les ministères.

Ce qui a changé depuis 2024

La bascule n'est pas venue d'un texte de loi européen ni d'une directive. Elle est venue de la géopolitique elle-même. Le retour d'une posture américaine plus unilatérale sur les dossiers de sécurité collective, les interrogations sur la fiabilité des garanties OTAN, et plusieurs incidents diplomatiques survenus entre 2024 et 2025 ont brutalement rendu concret ce qui relevait jusqu'alors du débat théorique : peut-on héberger des données critiques — défense, énergie, santé, infrastructure — sur des plateformes soumises à une juridiction étrangère dont les priorités peuvent diverger des nôtres ?

La réponse, que beaucoup de DSI connaissaient déjà mais évitaient de formuler trop clairement, est non. Pas sans conditions. Pas sans risque résiduel.

Ce qui est nouveau en 2026, c'est que cette réponse commence à se traduire en budgets, en appels d'offres et en roadmaps. La Commission européenne a accéléré plusieurs chantiers — le Cyber Resilience Act, les exigences de localisation des données dans certains secteurs, et le travail de fond autour du label EUCS (European Union Cybersecurity Certification Scheme for Cloud Services) — qui crée enfin un référentiel commun pour qualifier ce qu'est un cloud « de confiance » en Europe. Le niveau d'assurance le plus élevé de ce schéma implique une immunité aux lois extraterritoriales, ce qui exclut de facto les filiales européennes des hyperscalers américains telles qu'elles sont structurées aujourd'hui.

C'est un changement de paradigme. Pas une révolution immédiate, mais un signal clair envoyé au marché.

Le malentendu des « régions européennes »

Il faut s'arrêter sur un argument qu'on entend encore trop souvent dans les comités de direction : « nos données sont hébergées en Irlande ou en Allemagne, donc on est protégés. » C'est un raccourci dangereux.

L'emplacement physique des serveurs n'a jamais été la variable déterminante. Ce qui compte, c'est la juridiction à laquelle est soumise l'entreprise qui les opère. Or AWS Europe, Azure Germany, Google Cloud EMEA sont des entités dont la maison mère est américaine, soumise au Cloud Act, au FISA et à d'autres textes qui permettent aux autorités américaines d'accéder à des données sans nécessairement passer par une commission rogatoire internationale.

Les hyperscalers l'admettent eux-mêmes dans leurs conditions générales, parfois en tout petits caractères. Ils ont par ailleurs développé des offres dites « souveraines » en partenariat avec des acteurs locaux — Microsoft avec son offre opérée par Bleu en France, par exemple, en partenariat avec Orange et Capgemini — mais ces architectures restent complexes à auditer, et la question de la dépendance technologique profonde (les briques logicielles, les API, les formats propriétaires) demeure entière, même si les données ne quittent pas le territoire.

Autrement dit : délocaliser les données ne suffit pas. Il faut aussi s'interroger sur qui détient les clés, qui peut mettre à jour le logiciel, qui peut décider demain de modifier les conditions tarifaires ou de service.

Ce que ça change concrètement pour vous

Pour un DSI ou un CTO de PME ou d'ETI, la question peut sembler lointaine. La souveraineté numérique, ça sonne comme un sujet de grand groupe ou de service public. C'est une erreur de perspective.

Premier point concret : si votre entreprise travaille avec des donneurs d'ordre publics, des industriels de défense, des opérateurs d'importance vitale ou simplement des clients dans des secteurs régulés (santé, finance, énergie), les exigences vont se cascader vers vous. Le RGPD l'a déjà montré : ce qui s'applique au grand groupe finit par s'appliquer à son fournisseur. Les clauses contractuelles vont évoluer. Anticiper vaut mieux que subir.

Deuxième point : la concentration technologique est elle-même un risque opérationnel. Dépendre à 80 ou 90 % d'un seul fournisseur cloud — quelle que soit sa nationalité — crée une fragilité que les équipes de gestion des risques regardent de plus en plus attentivement. La question de la souveraineté rejoint ici celle de la résilience.

Troisième point, souvent sous-estimé : le pouvoir de négociation. Quand vous êtes captif d'un hyperscaler, vous négociez peu. Vos coûts de sortie (migration des données, réécriture des intégrations, formation des équipes) sont si élevés que vous acceptez des hausses tarifaires que vous n'accepteriez d'aucun autre fournisseur. C'est une logique de lock-in assumée, et elle se referme progressivement sur ceux qui n'ont pas anticipé.

Des alternatives existent, mais la lucidité s'impose

L'écosystème cloud européen a progressé. OVHcloud reste l'acteur de référence en matière d'infrastructure pure, avec une empreinte européenne réelle et une structure capitalistique non soumise aux lois américaines. Scaleway, dans le groupe Iliad, a développé une offre cohérente orientée développeurs. En Allemagne, Deutsche Telekom avec sa filiale T-Systems pousse une offre cloud souveraine pour les acteurs industriels germanophones. Ces acteurs existent, ils sont viables, et plusieurs grandes entreprises européennes ont commencé à leur confier des charges de travail significatives.

Mais soyons honnêtes : la parité fonctionnelle avec AWS ou Azure n'est pas atteinte sur tous les segments. Les services managés, les outils d'intelligence artificielle, les capacités de data analytics à grande échelle — l'écart reste réel. Prétendre le contraire serait mentir aux DSI qu'on est censés aider.

La question n'est donc pas « faut-il basculer tout d'un coup vers le cloud européen ? » mais « quelles charges de travail, quelles données, quels processus méritent d'être traités différemment en fonction de leur sensibilité ? »

C'est une approche de classification, pas de remplacement brutal. Et c'est là que le travail de fond commence — souvent avec les équipes juridiques et les RSSI, avant même d'impliquer les architectes techniques.

Trois ans : un horizon réaliste à condition de commencer maintenant

L'horizon de trois ans n'est pas arbitraire. C'est à peu près le temps nécessaire pour mener à bien une migration d'infrastructure substantielle dans une organisation de taille intermédiaire, en gérant la continuité de service, la formation des équipes et les renégociations contractuelles. C'est aussi le tempo auquel les réglementations européennes vont vraisemblablement se cristalliser — le schéma EUCS devrait produire ses premiers effets concrets d'ici là.

Mais trois ans, ça commence aujourd'hui. Pas dans six mois, après le prochain audit. Les migrations cloud sont sous-estimées en durée et en complexité par la quasi-totalité des organisations qui les entreprennent. Si vous attendez qu'une contrainte réglementaire ou contractuelle vous y force, vous serez en position de faiblesse.

Quelques chantiers préparatoires qui ne nécessitent pas de décision d'architecture majeure : cartographier précisément où sont vos données les plus sensibles et sous quelle juridiction elles sont traitées. Auditer vos contrats cloud actuels sur les clauses d'accès aux données par des tiers. Identifier vos dépendances aux API propriétaires qui rendraient une migration coûteuse. Ce travail de fond, beaucoup d'organisations ne l'ont toujours pas fait.

La vraie question de fond

Derrière le débat technique sur les clouds souverains se cache une question plus profonde que les DSI ne peuvent pas trancher seuls : quel niveau de risque géopolitique une entreprise est-elle prête à accepter dans son infrastructure numérique, et qui prend cette décision ?

Jusqu'à présent, cette décision a souvent été prise par défaut, dans les couloirs des appels d'offres, à l'avantage des acteurs qui offraient les meilleures fonctionnalités au meilleur prix à court terme. C'est une logique parfaitement rationnelle dans un monde stable. Nous ne sommes plus dans ce monde.

Cela ne signifie pas qu'il faille paniquer ni idéologiser la question. Un ERP sur Azure ne met pas en danger la sécurité nationale. Mais les données de R&D d'un sous-traitant de défense, les plans de continuité d'activité d'un opérateur d'infrastructure critique, les communications chiffrées d'une direction générale impliquée dans des négociations sensibles — là, la question mérite d'être posée sérieusement, et pas seulement par les grandes entreprises.

Le cloud souverain n'est pas une fin en soi. C'est un outil parmi d'autres pour répondre à une question de gouvernance que personne ne peut esquiver indéfiniment : de qui dépendons-nous, et est-ce que nous l'acceptons vraiment en connaissance de cause ?

*Le débat sur les niveaux d'assurance du schéma EUCS est toujours en cours au sein des institutions européennes, avec des positions divergentes entre États membres. Suivre son évolution est probablement l'une des veilles réglementaires les plus utiles qu'un DSI puisse entretenir en ce moment.*