TL;DR : héberger en Europe, c'est bien. Mais une région « EU » sur un cloud américain n'est pas de la souveraineté. Le CLOUD Act garde la porte ouverte. La vraie souveraineté, c'est une infra que tu possèdes, chez un hébergeur européen, décrite en Terraform et Ansible. Voici le playbook que j'utilise. Quels composants open-source remplacent quels services US. Où vivent tes données. Et comment rester prêt pour l'IA sans dépendre d'un fournisseur américain.
Cet article est pour les CTO et lead techs de PME et scale-ups européennes qui manipulent des données sensibles. Fintech, santé, secteur public.
La souveraineté n'est plus un discours. C'est une décision d'architecture.
En 2026, la souveraineté numérique est passée du slogan à la contrainte technique. La souveraineté numérique, c'est garder le contrôle de tes données et de ton infra. Qui peut y accéder, sous quelle loi, et depuis où.
Le cadre européen s'est empilé, texte après texte. Le RGPD protège les données personnelles depuis 2018. La directive NIS2 durcit les obligations cyber, et les États la transposent depuis fin 2024. DORA oblige les acteurs financiers à gérer leur dépendance au cloud, et elle s'applique depuis janvier 2025. Le Data Act facilite le changement de fournisseur cloud, et il s'applique depuis septembre 2025.
L'AI Act mérite une nuance importante. Il est entré en vigueur en août 2024. Ses règles de transparence s'appliquent bien en août 2026. Mais attention à un piège de calendrier. En mai 2026, l'UE a décidé de repousser les obligations des systèmes à haut risque à décembre 2027. Alors ne monte pas ta stack pour respecter une seule date. Monte-la parce que la pression est structurelle, pas ponctuelle.
L'autre moteur, c'est la résilience. L'été 2026 l'a rappelé sans douceur. AWS a connu plusieurs pannes en juillet. Le 16, un incident sur son service CloudFront a duré plus de trois heures. Le 24, une panne dans sa région d'Oregon a coupé Apple Pay, Reddit et d'autres, pendant environ 80 minutes. C'était le troisième incident notable en trois mois.
Un hyperscaler, c'est un géant du cloud comme AWS, Azure ou Google Cloud. Quand tout le monde dépend des mêmes hyperscalers, tout le monde tombe en même temps. Le mouvement de fond est réel, jusqu'au sommet. En avril 2026, la Commission européenne a attribué un marché de cloud souverain. Jusqu'à 180 millions d'euros sur six ans, pour ses propres institutions.
De mon côté, je monte des stacks self-host souveraines depuis un moment. J'ai deux projets perso qui me servent de base. Un forfait DevSecOps clé en main, et un mesh VPN zero-trust auto-hébergé. Les deux tournent sur Hetzner, un hébergeur allemand. Les deux se déploient entièrement en code, pas à la main.
Une région « EU » sur un cloud US n'est pas de la souveraineté
Voici l'erreur la plus fréquente. Tu coches « région Europe » chez ton cloud américain, et tu te crois en règle. Le problème n'est pas où la donnée est stockée. Le problème, c'est qui peut la réclamer.
Le CLOUD Act est une loi américaine de 2018. Elle permet aux autorités US d'exiger les données d'une entreprise américaine. Même quand ces données sont stockées en Europe. Donc la filiale européenne d'un groupe américain reste sous cette loi. La localisation du serveur n'y change rien.
La justice européenne a déjà pointé ce risque. L'arrêt Schrems II, en 2020, a invalidé le cadre de transfert de données vers les États-Unis. Le motif : l'accès possible des autorités étrangères à tes données.
Les hyperscalers proposent maintenant des offres dites « souveraines ». Des régions isolées, opérées en Europe. C'est mieux que rien. Mais la maison mère reste américaine, donc sous droit américain. La souveraineté, ce n'est pas juste un lieu de stockage. C'est le contrôle. Qui possède l'infra, qui détient les clés, qui répond aux réquisitions. La réponse la plus simple à ces trois questions, c'est d'héberger toi-même, chez un fournisseur européen.
Remplace chaque service US par un composant que tu contrôles
Bonne nouvelle : pour presque chaque service US, il existe un équivalent open-source que tu héberges toi-même. C'est le coeur du forfait DevSecOps que je déploie chez mes clients, sur leur propre infra. Voici la table de correspondance que j'utilise :
- Identité et SSO : Keycloak remplace Okta, Auth0 ou Entra ID. Le SSO, ou single sign-on, c'est un seul login pour toutes tes apps. Keycloak gère aussi les rôles et le second facteur.
- Réseau zero-trust : Netbird remplace Tailscale ou Zscaler. C'est un VPN maillé basé sur WireGuard. Le zero-trust part d'un principe simple : on ne fait confiance à personne par défaut, même à l'intérieur du réseau.
- Secrets : Vaultwarden garde les mots de passe d'équipe. Pour les secrets des applications, tu ajoutes Vault ou Infisical. Tout reste chez toi, jamais dans un coffre tiers.
- Monitoring et logs : Grafana, Prometheus et Loki remplacent Datadog ou New Relic. Tu vois tes métriques et tes logs sans les envoyer dehors.
- Sauvegardes : Restic et pgBackRest écrivent vers MinIO. MinIO est un stockage objet compatible S3 que tu héberges toi-même.
- Entrée HTTPS et DNS : Traefik gère le reverse proxy et les certificats Let's Encrypt. Pour le DNS, un acteur européen comme OVH suffit.
Chaque brique est open-source. Tu peux l'auditer, la forker, la faire tourner sans licence. Et surtout, tes données ne quittent jamais ton périmètre.
Déploie tout en Terraform et Ansible, pas à la main
Une stack montée à la main n'est pas souveraine longtemps. Elle dérive, et bientôt personne ne sait la reconstruire. Alors je décris tout en code. Deux outils se partagent le travail. Terraform crée l'infrastructure : la machine, le réseau, le pare-feu, le DNS. Ansible configure ensuite la machine : les paquets, les services, le durcissement.
Mon projet de VPN self-host le montre bien. Terraform provisionne une VM chez Hetzner et gère le DNS chez OVH. Deux fournisseurs européens, un seul fichier de code :
terraform {
required_providers {
hcloud = { source = "hetznercloud/hcloud", version = "~> 1.45" } # VM on Hetzner (DE)
ovh = { source = "ovh/ovh", version = "~> 0.50" } # DNS on OVH (FR)
}
}
# Then Ansible hardens the host and installs the service:
# roles/system-hardening -> updates, firewall, fail2ban
# roles/netbird-install -> the self-hosted serviceAnsible prend le relais. Un rôle durcit le système. Un autre installe le service. Le tout passe par un pipeline GitHub Actions. Un plan sur chaque pull request. Un déploiement au merge. Un job séparé pour tout détruire proprement.
Le vrai gain, c'est la reproductibilité. Tu redéploies la même stack ailleurs en une commande. Si ton hébergeur augmente ses prix ou tombe, tu bouges sans repartir de zéro. Le même code me sert sur Hetzner, OVH, GCP ou DigitalOcean. C'est ça, l'inverse du lock-in.
Durcis l'hôte et chiffre tes sauvegardes
Posséder l'infra, c'est aussi la protéger. Personne ne le fait à ta place. Mon rôle Ansible de durcissement fait le minimum vital. Mises à jour de sécurité automatiques. Pare-feu fermé par défaut. fail2ban contre les attaques par force brute. Services inutiles coupés. fail2ban bannit une adresse IP après trop d'essais de connexion ratés.
Ensuite, les sauvegardes. Une infra que tu possèdes, c'est aussi toi qui réponds quand un disque meurt. Je chiffre les sauvegardes avec Restic. La base Postgres part avec pgBackRest. Les deux écrivent vers un stockage que tu contrôles, pas vers le S3 d'un tiers. Et je teste la restauration pour de vrai. Une sauvegarde jamais restaurée n'est pas une sauvegarde.
Ce point rejoint une exigence de DORA. Les acteurs financiers doivent pouvoir sortir d'un fournisseur, sans se retrouver bloqués. Avec du code et des sauvegardes portables, cette sortie est déjà prête. Tu ne l'improvises pas le jour de la panne.
Reste prêt pour l'IA sans donner tes données à un fournisseur US
Souverain ne veut pas dire coupé de l'IA. Ça veut dire garder la maîtrise. Le piège, c'est d'envoyer tes données brutes à une API américaine. Là, tu perds la résidence et le contrôle d'un seul coup.
Alors je traite le modèle comme une pièce détachée. Il se branche derrière une passerelle, et il se remplace. Je garde le modèle en bout de chaîne, jamais au centre du système. J'en ai fait un article entier. Et je masque les données personnelles avant qu'elles n'atteignent le modèle, comme pour sécuriser un agent.
Pour la souveraineté, tu as deux voies. Un fournisseur européen comme Mistral. Ou un modèle open-weight que tu héberges toi-même. Un modèle open-weight a ses poids publics. Tu peux donc le faire tourner sur ta propre machine. Tu le sers sur un GPU européen, chez OVHcloud ou Scaleway.
Ton plan de données reste chez toi. Le modèle devient un détail d'implémentation, pas une dépendance. Résultat : tu profites de l'IA, mais c'est toi qui décides où vont les données.
Le coût a changé en 2026. Fais le vrai calcul.
Le cloud s'est vendu sur deux promesses. Simple : plus de serveurs à gérer. Et pas cher : tu paies ce que tu consommes. En 2026, les deux ont pris un coup de vieux.
Simple, ça l'est de moins en moins. Suivre la facture est devenu un métier, avec son nom : le FinOps. Pas cher non plus. Le paiement à l'usage punit les charges qui tournent en continu. La sortie de données se facture, et les services managés s'empilent.
Du coup, des entreprises font le chemin inverse. On appelle ça la repatriation : revenir sur sa propre infra. 37signals a ramené sa facture cloud de 3,2 à 1,3 million de dollars par an. Une étude Flexera estime qu'environ un cinquième des charges parties au cloud sont déjà revenues.
Un mot honnête sur l'argent. Le self-host n'est pas toujours moins cher. En 2026, même les hébergeurs européens ont augmenté. Hetzner a relevé ses prix plusieurs fois. Au 1er avril, jusqu'à environ 37 %. Au 15 juin, certains plans à vCPU dédié ont plus que doublé. La cause n'est pas la marge. Le prix de la mémoire DRAM a bondi de plus de 90 % en un seul trimestre.
Donc fais le vrai calcul, avec de vrais chiffres. Trois réflexes aident :
- Dimensionne juste. Beaucoup de stacks tournent sur bien moins que ce qu'on provisionne par réflexe.
- Choisis le bon type d'instance. Les plans Arm ont bien moins augmenté que le vCPU dédié.
- Compte le coût total, pas juste la VM. Chez un hyperscaler, la sortie de données et les services managés gonflent la facture.
Et compte ce que la souveraineté t'apporte en face. Pas de lock-in, une conformité plus simple, une sortie toujours possible. Le lock-in, c'est la dépendance qui rend un départ trop coûteux. Pour une PME à données sensibles, ce contrôle vaut souvent plus que quelques euros de VM.
La checklist du self-host souverain
Avant de te dire « souverain », coche toutes ces cases.
- L'hébergeur est européen, et hors de portée du CLOUD Act
- Tu ne confonds pas « région EU » et souveraineté réelle
- Chaque service US a un équivalent open-source auto-hébergé : identité, secrets, réseau, monitoring, sauvegardes
- Toute l'infra est décrite en Terraform et Ansible, pas montée à la main
- Le même code peut redéployer la stack chez un autre hébergeur
- L'hôte est durci : mises à jour auto, pare-feu, fail2ban, services inutiles coupés
- Les sauvegardes sont chiffrées, portables, et tu as déjà testé une restauration
- Le modèle IA est isolé derrière une passerelle, et remplaçable
- Les données personnelles sont masquées avant d'atteindre le modèle
- Tu as fait le vrai calcul de coût : dimensionnement, type d'instance, coût total
- Une stratégie de sortie existe, prête à jouer, dans l'esprit de DORA
Ce qu'il faut retenir
La souveraineté n'est pas un badge marketing. C'est une chaîne de décisions techniques. Une région EU sur un cloud US ne suffit pas. Le contrôle vient de l'infra que tu possèdes vraiment.
La bonne nouvelle, c'est que les briques existent, toutes open-source. Terraform et Ansible les assemblent en une stack que tu maîtrises. Et cette stack reste prête pour l'IA, à tes conditions.
Tu veux monter une stack souveraine, ou vérifier que la tienne l'est vraiment ? C'est exactement ce que je fais. Écris-moi. Héberge en Europe. Mais héberge sur une infra qui est vraiment la tienne.