Retour d’expérience d’une entreprise du secteur de la défense
Comment une entreprise de défense a migré l’intégralité de son infrastructure Azure vers un cloud européen en 12 semaines : méthodologie, arbitrages et leçons apprises.
À propos de l'auteur
Flavien Berwick a construit son expertise à l’intersection du cloud, de la cybersécurité et des environnements à haute contrainte réglementaire. Il a notamment évolué au ministère des Armées, où il a travaillé sur des infrastructures classifiées et des projets de transformation numérique au sein de l’institution militaire, ainsi qu’au ministère de l’Intérieur et des Outre-mer. Il exerce actuellement chez Exo, une société basée à Montréal au Canada
Auteur de l’ouvrage « Le DevOps pour transformer les institutions », préfacé par le général Éric Autelet , figure de référence sur les sujets de souveraineté numérique en France, Flavien combine une vision stratégique des enjeux géopolitiques du cloud avec une expérience opérationnelle concrète des migrations vers des infrastructures souveraines. C’est cette double casquette, terrain et stratégie, qui rend son retour d’expérience particulièrement pertinent pour les DSI qui envisagent une démarche de souveraineté.
Expert Cloud, DevOps & Infrastructures souveraines
Introduction
Cet article est issu d’un webinar organisé par Hubadviser sur le thème « Concilier Cloud et Souveraineté ». L’objectif : dépasser les débats théoriques sur la souveraineté numérique pour entrer dans le concret, à travers le retour d’expérience d’un expert qui a réellement piloté des migrations vers des infrastructures souveraines.
Vous trouverez dans cet article :
- Un cadrage rapide des risques juridiques liés à la dépendance aux clouds américains (Cloud Act, FISA, OFAC).
- Le récit détaillé d’une migration d’Azure vers Scaleway pour une entreprise du secteur de la défense, menée en 12 semaines.
- Un panorama des trois modèles de cloud souverain disponibles en Europe (clouds de confiance, clouds publics européens, self-hosted).
- La cartographie complète des alternatives européennes et open source, fonction par fonction.
- Les cinq leçons opérationnelles tirées de cette expérience.
1. Pourquoi la souveraineté numérique est devenue un enjeu opérationnel
La souveraineté numérique n’est plus un sujet théorique. En 2024-2025, plusieurs signaux forts en ont fait une priorité concrète pour les DSI : application de sanctions extraterritoriales américaines touchant des acteurs européens (gel de comptes via Visa, Amazon ou PayPal), alertes croissantes sur la dépendance technologique de l’Europe, qualifiée de « vassalisation numérique », et montée en puissance de la dimension géopolitique des infrastructures numériques, désormais perçues comme des actifs stratégiques.
Derrière ces signaux, trois mécanismes juridiques exposent concrètement les organisations européennes : le Cloud Act (accès des autorités américaines aux données hébergées hors US par des fournisseurs américains), le FISA Section 702 (collecte de renseignement sur les citoyens non américains), et la possibilité pour un État d’interdire la vente ou le renouvellement d’une licence logicielle à un pays tiers.
« Le risque n’est pas qu’un cloud provider américain coupe l’accès à un pays entier, ce serait délétère pour leur propre économie. Le risque, c’est le ciblage : une personne clé, une entreprise sensible, un organisme d’importance vitale. » Flavien Berwick
Le cloud, un impératif incontournable
Dans le même temps, les DSI sont soumis à une pression croissante pour gagner en agilité, en réactivité et pour permettre l’adoption de l’intelligence artificielle par leur organisation. Infrastructures scalables, accès aux GPU à la demande, capacité à déployer rapidement de nouveaux services : le cloud n’est plus une option, c’est un prérequis pour répondre aux enjeux de compétitivité et de transformation numérique.
Dès lors, l’équation se complexifie. Il ne s’agit plus de choisir entre cloud et souveraineté, les deux sont impératifs. La véritable question devient : comment les concilier ? C’est précisément l’objet de ce retour d’expérience.
C’est dans ce contexte que Flavien Berwick, expert en infrastructures souveraines passé par le ministère des Armées et le ministère de l’Intérieur, partage le détail d’une migration qu’il a pilotée pour une entreprise du secteur de la défense.
2. Point de départ : une entreprise de défense sur Azure
L’entreprise concernée conçoit des solutions à destination du secteur de la défense. À ce titre, elle devait impérativement respecter des exigences strictes de souveraineté afin de pouvoir répondre aux appels d’offres de ses clients. Son infrastructure était historiquement hébergée sur Microsoft Azure, choix initial lié à un parc de machines Windows.
L’état des lieux révèle une dépendance quasi-totale aux services américains.
La question fondatrice
« La première question que j’ai posée au CTO : contre quoi souhaitez-vous vous prémunir ? Comme en cybersécurité, on ne peut pas viser l’autarcie complète. Il faut cibler précisément ce dont on veut se protéger. » — F. Berwick
La réponse du CTO : éviter un ciblage américain sur ses services, rupture d’accès à Azure ou vol de propriété industrielle. Le choix du cloud souverain s’imposait.
3. Avant / Après : la transformation en un coup d’œil
Le tableau ci-dessous synthétise l’état initial de l’infrastructure (100 % dépendante de services américains) et l’état final après migration vers une stack souveraine. Au-delà du changement de cloud provider, la migration a été l’occasion de structurer l’infrastructure (VPN, IAM, observabilité, gouvernance) là où elle ne l’était pas.
Fonction | État initial (Azure + US stack) | État final (souverain) |
Cloud IaaS | Azure | Scaleway |
Bureautique / Email | Microsoft 365 + Exchange | Nextcloud + OnlyOffice + Infomaniak |
Dépôt de code | GitHub | GitLab (self-hosted) |
Protection web / CDN | Cloudflare | Bunny.net |
VPN | Cisco AnyConnect | Tailscale |
Authentification / IAM | Microsoft | Samba + FreeIPA + Keycloak |
Configuration management | Manuel / partiel | Ansible (IaC) |
Observabilité | Non en place | FluentBit + OpenSearch |
Documentation / Wiki | Non en place | Wiki.js |
Gouvernance | Partielle | Documentée et formalisée |
4. Panorama des alternatives : trois modèles de cloud souverain
Les clouds de confiance (joint ventures)
Des joint ventures entre acteurs européens et américains (S3NS pour Thales/Google, Bleu pour Orange-Cap Gemini/Microsoft, Azure Sovereign Cloud). Technologies américaines hébergées en France, clés de chiffrement locales (BYOK), mises à jour en quarantaine. Avantage : familiarité pour les équipes. Limite : sous-ensemble du produit original (pas de services IA, pas de Cloud Shell, pas de notebooks), dépendance aux licences US, accès souvent derrière un « Contact us ».
Les clouds publics européens
Structures de droit européen, logiciels open source ou développés en interne (Scaleway, OVHcloud, Outscale, United Cloud, Hetzner). Historiquement moins de fonctionnalités mais accès immédiat et innovations propres (quantum, IPFS, vRack layer 2). En réalité, 95 % des besoins sont couverts. Montée en compétence plus souple depuis le on–premise.
Le self-hosted / colocation
Réservé aux systèmes critiques : défense, énergie, santé. Systèmes air-gappés pour homologation Diffusion Restreinte ou Secret, colocation eIDAS. Technologies : OpenStack, Rancher, NexUs, Proxmox, VMware perpétuel, plateformes custom homologuées.
5. Le choix Scaleway
Parmi les clouds publics européens disponibles, le choix s’est porté sur Scaleway. Filiale du groupe Iliad, Scaleway s’est imposé ces dernières années comme l’un des cloud providers européens les plus ambitieux, avec un positionnement clair : proposer une alternative souveraine aux hyperscalers américains, sans compromis sur l’expérience développeur.
Profil de Scaleway
Scaleway est un fournisseur cloud français de droit européen, dont l’ensemble des datacenters sont situés en France et aux Pays-Bas. Contrairement aux clouds de confiance (S3NS, Bleu), Scaleway a développé sa propre stack logicielle en interne à partir de composants open source, sans dépendance technologique à un éditeur américain. L’entreprise propose une gamme complète de services : instances (VM), Kubernetes managé (Kapsule/Kosmos), bases de données managées, stockage objet (compatible S3), load balancing, réseau privé (vRack), et une offre GPU dédiée à l’IA.
Certifications et conformité
- ISO 27001:2022 : norme de référence pour les systèmes de gestion de la sécurité de l’information.
- HDS (Hébergeur de Données de Santé) : certification obtenue en juillet 2024, permettant l’hébergement de données de santé conformes aux exigences du ministère de la Santé.
- SecNumCloud (en cours) : Scaleway a obtenu le jalon J0 de l’ANSSI en janvier 2025 et vise la qualification complète. Point différenciant : Scaleway qualifie l’ensemble de son offre cloud, et non une offre spécifique créée pour l’occasion.
- RGPD natif : données hébergées en Europe, opérées par des équipes européennes, sans exposition aux législations extraterritoriales.
Pourquoi Scaleway dans ce contexte précis
Plusieurs facteurs concrets ont orienté le choix de l’entreprise accompagnée :
- Accès en libre-service : contrairement à S3NS ou Bleu où l’inscription passe par un processus commercial (« Contact us »), Scaleway propose une inscription immédiate, comparable à AWS ou Azure. Pour une entreprise de taille moyenne, c’est un critère déterminant.
- Familiarité des équipes : les deux administrateurs système de l’entreprise avaient déjà utilisé Scaleway sur d’autres projets. La montée en compétence n’a pas été un sujet.
- Simplicité de prise en main : la courbe d’apprentissage depuis le on-premise vers Scaleway est plus douce que vers AWS, où la profondeur du catalogue (300+ services) peut s’avérer déroutante.
- Vivier de talents : Scaleway est suffisamment réputé en Europe pour que l’entreprise puisse recruter des profils compétents sur cette plateforme.
- Certifications adaptées : ISO 27001 et HDS couvraient les besoins immédiats, et la démarche SecNumCloud en cours offrait une perspective d’évolution pour de futurs appels d’offres publics.
« Chez Scaleway, vous pouvez vous inscrire directement, au même titre qu’AWS ou Azure. Vous n’êtes pas face à trois jours de discussion avec les équipes de vente. Pour une équipe technique qui veut avancer vite, ça fait la différence. » — F. Berwick
Il est important de noter que ce choix n’est pas un partenariat ni une recommandation commerciale. D’autres clouds européens (OVHcloud, Outscale, Hetzner) auraient également pu convenir selon le contexte. Le choix Scaleway résulte ici d’un alignement entre les compétences existantes, les certifications requises et la simplicité d’accès à la plateforme.
6. Le calendrier : migration en 12 semaines
La migration s’est déroulée en trois phases distinctes sur 12 semaines. L’entreprise disposait de deux administrateurs système déjà familiers avec Scaleway.
Phase | Actions clés |
1. Alignement et cadrage Semaines 1 à 2 | • Entretien CTO : besoins, périmètre, estimation • Présentation de la vision à toute l’entreprise • Collecte feedbacks & réponses aux inquiétudes • Élaboration du plan final avec les administrateurs système |
2. Construction de la plateforme Semaines 3 à 8 | • Gouvernance & documentation (Wiki.js) • Landing zone Scaleway : réseau, IAM, VPN, load balancer • Identité : FreeIPA, Samba, Keycloak, SSO • Services : Nextcloud, GitLab, reverse proxy • Migration VMs Azure → Scaleway (qcow2) • Backups + observabilité (FluentBit / OpenSearch) • Automatisation : Ansible, certificats, GPOs |
3. Bascule et adoption Semaines 9 à 12 | • Migration emails (Infomaniak) & DNS (Bunny.net) • Onboarding progressif des collaborateurs • Accompagnement, récolte des retours, ajustements, stabilisation |
Le cœur du défi : reconstruire l’équivalent d’Active Directory
La force de Microsoft réside dans sa capacité à intégrer dans un seul produit (Azure AD / Entra ID) ce qui nécessite plusieurs briques dans un environnement souverain. Voici l’architecture mise en place :
- VPN — Tailscale : connexion sécurisée aux services internes, remplaçant Cisco AnyConnect.
- Authentification Windows — Samba AD : gestion du parc Windows existant.
- Authentification Linux — FreeIPA : gestion des accès sur les serveurs Linux.
- SSO — Keycloak : authentification unifiée sur l’ensemble des services.
- Configuration management — Ansible : automatisation des mises à jour, certificats, GPOs.
- Observabilité — FluentBit + OpenSearch : centralisation des logs et monitoring.
7. Cartographie complète des alternatives
Le tableau ci-dessous présente, pour chaque fonction IT, les trois catégories de solutions disponibles : outil traditionnel (généralement américain), alternative open source, et alternative privée européenne ou canadienne.
Sujet | Outil traditionnel | Outil open-source | Outil privé européano-canadien |
Authentification | Microsoft Active Directory | Samba AD DC, FreeIPA | Univention |
Unified Endpoint Management | InTune (M365), Jamf Pro, NinjaOne, ManageEngine | Fleetdm, opsi | Relution, Matrix42, SOTI |
Suite bureautique | Office 365, Google Workspace | LaSuite.coop, Nextcloud, OnlyOffice | Infomaniak, Proton, Leviia, Wimi, Hexagone |
VPN | OpenVPN, Cloudflare, Cisco AnyConnect | OpenVPN, Pangolin, Headscale | Tailscale, Netbird |
DNS & CDN | Cloudflare, Akamai, AWS CloudFront | NGINX, Varnish, PowerDNS | Bunny.net |
Fournisseur Cloud | Azure, GCP, AWS, Oracle | OpenStack, CloudStack, OpenNebula, Microcloud, Proxmox, Rancher | Scaleway, OVHCloud, Outscale, United Cloud, Hetzner, IONOS, Exoscale |
Modèle IA | OpenAI, Anthropic, Google, Azure, AWS | Hugging Face (Meta, Deepseek, Qwen, bge, Google, Mistral AI, OpenAI) | Mistral AI, H Company, Cohere, Black Forest Labs, Aleph Alpha |
Système d’exploitation | Windows, RHEL, macOS | Debian, AlmaLinux, Ubuntu, CentOS Stream, openSUSE | SUSE Linux Enterprise |
8. Cinq leçons apprises
1. Vos équipes techniques sont déjà partantes
C’est une constante : les équipes techniques vivent la migration vers l’open source comme une évolution professionnelle. Passer de Windows à Linux, de VMware à Kubernetes, c’est travailler sur des technologies tendance, valorisantes sur le marché. Le frein n’est quasiment jamais technique : il est politique.
2. La décision est politique, pas technique
Migrer vers un cloud souverain change la nature des investissements, la politique RH, les habitudes de consommation IT. Ce n’est pas une décision que la DSI peut prendre seule. Elle doit être validée au comité de direction avec un sponsorship explicite de la direction générale.
3. Commencer par un périmètre limité, mais aller en production
Identifier un projet pilote avec des équipes volontaires, expérimenter, puis basculer en production. Le piège classique : rester en phase d’expérimentation avec deux infrastructures côte à côte, sans jamais trancher. Cela coûte cher et ne produit aucun apprentissage durable.
4. Internaliser les compétences
Se faire accompagner au démarrage est pertinent. Mais l’objectif doit être de rendre les équipes internes autonomes. Externaliser à outrance revient à remplacer une dépendance technologique par une dépendance humaine.
5. Capitaliser le savoir systématiquement
Chaque incident, chaque bug, chaque arbitrage doit être documenté dans un post-mortem et centralisé dans un wiki collaboratif (Wiki.js dans ce RETEX). Cette discipline est ce qui fait la différence entre une migration réussie et une infrastructure fragile.
9. L’approche pragmatique : le cloud hybride
Migrer vers un cloud souverain ne signifie pas abandonner AWS, Azure ou GCP à 100 %. La recommandation issue de ce RETEX est une approche hybride à trois niveaux :
- Opérations quotidiennes sur un cloud européen (Scaleway, OVHcloud) pour l’hébergement et les services du quotidien.
- Innovation et expérimentation sur des hyperscalers pour des besoins spécifiques (IA avancée, prototypage) non encore disponibles en Europe.
- Systèmes critiques en SecNumCloud ou self-hosted pour les données classifiées ou les périmètres réglementés.
« 95 % des besoins sont déjà couverts par les capacités actuelles de Scaleway ou OVHcloud. Réfléchissez bien à vos besoins réels avant de partir chez un hyperscaler américain. » — F. Berwick
10. Ce qu’il faut retenir
Ce retour d’expérience montre qu’une migration vers un cloud souverain est réalisable en 12 semaines pour une organisation de taille moyenne, à condition de respecter quatre principes :
- Développer une capacité souveraine propre, même partielle.
- Assumer que le choix de la souveraineté est avant tout politique et nécessite un sponsorship au plus haut niveau.
- Associer les parties prenantes dès le départ, équipes techniques, direction, utilisateurs métier.
- Être ouvert à une approche cloud hybride : souverain pour le quotidien, ouvert pour l’innovation.
La souveraineté numérique n’est ni un fantasme ni un renoncement au progrès. C’est un choix d’indépendance stratégique qui, comme le montre ce RETEX, peut être mis en œuvre de manière pragmatique, progressive et maîtrisée.
