Reshoring vs offshore : ETI allemandes restructurent chaîne cloud

6 min. de lecture

Le reshoring n’est plus en 2026 un label marketing, mais un poste budgétaire. Les ETI allemandes rapatrient des charges concrètes depuis les régions US des hyperscalers vers des centres de données UE – certaines entièrement, beaucoup de manière hybride. Les moteurs sont rarement les seuls débats de souveraineté. Ce sont les questions d’audit issues des contrôles BSI-KRITIS, les attestations C5 des clients et les obligations de la loi-cadre KRITIS à partir d’octobre 2025 qui pèsent opérationnellement.

En lienCloud Repatriation 2026 : le modèle TCO  /  Broadcom-VMware Channel : le paysage des prestataires 2026

Le mouvement ne se joue pas comme une sortie massive. Il se joue comme un triage de charges : qu’est-ce qui doit impérativement aller en UE, qu’est-ce qui peut tourner en hybride, qu’est-ce qui reste pragmatiquement sur AWS us-east-1 ou Azure East US. Ce texte décrit ce qui se passe réellement dans les projets depuis début 2026 – et où le narratif bute sur la réalité d’échelle des hyperscalers.

Quelles charges sont concrètement rapatriées

Il existe trois clusters nets que les ETI migrent activement en 2026. Premier cluster : les charges pertinentes pour KRITIS. Depuis la loi-cadre KRITIS et la transposition NIS2 en Allemagne, les exploitants d’installations critiques doivent fournir la preuve du lieu, de l’accès et du pouvoir d’instruction sur le traitement des données. Énergéticiens, services des eaux et groupements cliniques rapatrient leurs données patients et de commande, souvent sur Open Telekom Cloud ou IONOS.

Deuxième cluster : analytics de données personnelles et données CRM avec risque Schrems II. Les entreprises qui s’étaient appuyées en 2024/25 sur les SCC AWS et le EU-US Data Privacy Framework rencontrent des retours lors des audits. Les pipelines d’analyse migrent vers des fournisseurs natifs UE ou vers AWS Frankfurt (eu-central-1) avec des politiques explicites de région-lock.

Troisième cluster : sauvegardes et archives long terme avec obligation légale de conservation (droit commercial et fiscal, §257 HGB, §147 AO). Ici, les données froides migrent de S3 aux États-Unis vers des fournisseurs UE compatibles S3 ou vers OVHcloud Object Storage. L’effort de migration est maîtrisable, l’argument conformité fort.

Ce que poussent réellement les certifications

Trois cadres structurent la discussion, chacun avec un poids différent. C5 (Cloud Computing Compliance Criteria Catalogue) du BSI est en pratique le levier le plus important. Les grands clients et les donneurs d’ordre publics exigent C5 type 2 comme base contractuelle. AWS, Azure et Google Cloud ont des attestations C5 pour leurs régions UE, mais les critères additionnels (DEU C5:2020) sur la localisation des données contraignent à une configuration de région explicite. Qui déployait jusqu’ici en mode global doit réarchitecturer.

BSI-KRITIS n’est pas un certificat, mais un régime obligatoire pour les exploitants d’infrastructures critiques. L’obligation de preuve selon §8a BSI-Gesetz exige un contrôle tous les deux ans des mesures de protection adaptées. En pratique, cela signifie : externalisations cloud documentées, contrats de sous-traitance étanches, stratégies de sortie fiables. Les AVV standard des hyperscalers ne suffisent souvent plus.

Gaia-X livre un cadre d’architecture et de label (Gaia-X Labels Level 1 à 3) qui garantit la souveraineté des données. Les charges productives sur des services certifiés Gaia-X sont rares. Gaia-X agit surtout comme critère d’appel d’offres dans le secteur public et comme gabarit argumentatif pour la gouvernance interne. Qui attend Gaia-X comme un cloud clé en main sera déçu.

Où le narratif bute sur la réalité des hyperscalers

Le récit de souveraineté sonne propre : sortir des clouds US, entrer dans les fournisseurs UE. Dans la réalité projet, le narratif se fissure sur trois points.

Premier point de rupture : services managés. Qui tourne en production sur Amazon Aurora, DynamoDB ou Azure Cosmos DB n’a pas, chez les fournisseurs UE, de service managé équivalent. La migration signifie souvent basculer sur du PostgreSQL auto-géré ou sur des catalogues de services plus restreints. C’est faisable, mais cela coûte du temps d’ingénierie.

Deuxième point de rupture : dépendances SaaS. Microsoft 365, Salesforce, ServiceNow appartiennent à des groupes US. Même les offres Microsoft EU Cloud (EU Data Boundary) n’échappent pas entièrement au CLOUD Act. Qui veut sérieusement exclure l’accès US doit commencer par la couche SaaS, pas par l’IaaS.

Troisième point de rupture : stack IA. Les fournisseurs UE investissent (STACKIT a une plateforme IA, OVHcloud propose des instances GPU), mais l’écart avec Bedrock ou Vertex AI est grand. Les équipes qui bâtissent des produits basés sur des LLM restent, au moins pour l’inférence, souvent chez les hyperscalers US. Le reshoring signifie ici : données en UE, inférence des modèles là où les modèles tournent.

Étapes pratiques pour un projet de reshoring

Qui lance un projet de reshoring devrait procéder dans cet ordre :

1. Triage des charges (semaines 1-3) : classer toutes les charges selon trois critères – pertinence KRITIS, caractère personnel, obligation de conservation. Migrer uniquement les charges avec un vrai moteur conformité. Le reste reste pour le moment là où il est. Résultat : liste priorisée à 15 à 20 % au maximum du portefeuille.
2. Définir l’architecture cible (semaines 3-6) : par cluster de charges, choisir un fournisseur cible. Bases de données sur Open Telekom Cloud ou IONOS, object storage sur OVHcloud, base Kubernetes sur STACKIT. Pas de stratégie multi-fournisseurs dans un cluster – cela coûte de la complexité d’exploitation sans gain de souveraineté.
3. Proof of Migration avec une charge (mois 2-3) : migrer une application concrète, non critique. Mesurer réellement comportement en exécution, qualité du support et coûts. Ne passer à l’échelle qu’après. Les entreprises qui migrent directement cinq charges en parallèle produisent des risques d’exploitation sans gain de connaissance.
4. Établir des processus d’exploitation avec capacité de sortie (mois 3-5) : Infrastructure as Code (Terraform, Pulumi), conteneurs portables et formats d’export de données standardisés dès le départ. Qui atterrit en vendor lock chez un fournisseur UE n’a fait que déplacer géographiquement le problème initial.
5. Reporting et mapping des certificats (mois 4-6) : intégrer les attestations C5 du fournisseur dans ses propres dossiers d’audit, actualiser les preuves KRITIS, adapter les circuits de déclaration BSI. C’est la partie qui rend le bénéfice du projet visible au directoire et au conseil de surveillance.

Le reshoring 2026 n’est pas une position politique, mais un projet d’ingénierie avec un moteur conformité. L’approche la plus propre est peu spectaculaire : prioriser les charges, tester avec rigueur un fournisseur, intégrer la capacité de sortie. Qui le fait avec discipline obtient de la souveraineté des données sans les reculs d’échelle que le narratif tait souvent. Qui planifie le reshoring comme une sortie totale des clouds US atterrit vite dans des débats SaaS que l’équipe IaaS ne peut pas régler.

Au bout du compte, la question qui décide, c’est : pour quoi a-t-on besoin du tampon d’audit ? Pour les obligations KRITIS et les appels d’offres publics, dans la majorité des cas, le passage par un fournisseur UE s’impose. Pour les plateformes IA et data productives, la réalité hybride demeure : région UE chez l’hyperscaler, verrous de région stricts, fournisseur natif UE additionnel pour les parties qui exigent impérativement C5 type 2. Cette architecture à deux couches n’est pas sexy, mais elle survit aux prochains cycles d’audit.

Comment Gaia-X et EuroStack s’invitent dans le débat reshoring

Gaia-X est rarement en 2026 un point d’exigence autonome dans le travail d’architecture opérationnel, mais il apparaît régulièrement dans les appels d’offres du secteur public et des branches régulées. En pratique, ce qui est pertinent, ce sont les schémas Self-Description et le système de labels : un fournisseur avec un Gaia-X Label Level 2 ou 3 signale que certains critères de souveraineté (siège du traitement, droits d’accès, juridiction) sont contractuellement garantis. Pour une entreprise KRITIS qui doit expliquer à son commissaire aux comptes pourquoi une charge particulière reste dans un cloud US, le label est un argument exploitable. Sans label, la discussion s’allonge.

EuroStack est plus jeune, politiquement plus chargé et, actuellement, surtout un débat de roadmap. L’idée de bâtir une stack d’infrastructure européenne continue – du silicium au compute jusqu’aux services de plateforme – n’est pas encore une base pour les décisions d’architecture des ETI en 2026. Mais elle apparaît dans des appels à financement et influence la question de savoir quels fournisseurs UE resteront stratégiquement intéressants sur les cinq prochaines années. Qui planifie du reshoring aujourd’hui devrait vérifier la liste des fournisseurs qui participent activement aux projets EuroStack. Ce n’est pas un critère d’achat, mais un signal sur la volonté d’investissement à long terme.

Concrètement, cela donne : dans l’appel d’offres, Gaia-X Label comme critère obligatoire, participation EuroStack comme évaluation positive. Les deux se communiquent en interne sans dramatiser. Qui enflamme Gaia-X comme sujet marketing perd la direction conformité ; qui l’ignore perd les appels d’offres publics.

RGPD, Schrems II et la question de la juridiction

Le cœur juridique de la vague reshoring ne se trouve pas à Berlin, mais à Luxembourg. Depuis l’arrêt Schrems II de 2020 et les débats ultérieurs autour du EU-US Data Privacy Framework, le transfert de données personnelles vers les États-Unis n’est licite qu’avec des mesures techniques et organisationnelles additionnelles. Le Data Privacy Framework de 2023 a formellement stabilisé la situation, mais il reste sous observation continue. Plusieurs autorités de contrôle des données personnelles dans l’UE ont indiqué qu’elles feraient, le cas échéant, réexaminer le cadre s’il bascule politiquement ou juridiquement.

Pour l’architecture, cela signifie : qui exploite aujourd’hui des systèmes productifs avec des données personnelles dans des régions US porte un risque résiduel qui peut être atténué par des verrous de région en UE, mais pas totalement annulé. Le CLOUD Act autorise, sous certaines conditions, les autorités US à accéder aux données chez des entreprises US, indépendamment du lieu physique des données. Pour la plupart des ETI, ce n’est pas un problème opérationnel, mais un élément auditable – et les éléments auditables finissent tôt ou tard dans le registre de risques.

La réponse d’architecture la plus propre en 2026 n’est pas la sortie totale, mais la séparation par classes de données : données personnelles à haute sensibilité (santé, données RH, communications) chez des fournisseurs natifs UE, données d’exploitation sans caractère personnel toujours chez les hyperscalers, cas mixtes au cas par cas. C’est plus d’administration, mais cela réduit significativement la surface juridique d’attaque – et c’est exactement le langage que les autorités RGPD veulent entendre.

Ce que le reshoring ne règle pas

Deux malentendus persistent avec ténacité. Premièrement : le reshoring ne règle pas la dépendance aux stacks logiciels US. Qui stocke ses données dans un centre de données UE mais les traite avec Microsoft 365, Salesforce ou ServiceNow n’a pas vraiment quitté la juridiction. La question SaaS est un projet à part et demande ses propres réponses – mot-clé : alternatives européennes comme Nextcloud, Open-Xchange ou du vertical SaaS spécialisé du DACH.

Deuxièmement : le reshoring n’est pas un projet de réduction de coûts. Les fournisseurs natifs UE sont, dans la plupart des comparaisons de prix, plus chers que les hyperscalers, en particulier sur les charges élastiques. Il faut le dire honnêtement au CFO, sinon le projet bascule au premier tour de budget. Le business case se justifie par la soutenabilité d’audit, pas par la facture d’infrastructure. Qui inverse cela construit un projet de reshoring qui sera défait deux ans plus tard, parce que l’attente d’économies n’aura pas été tenue.

Questions fréquentes

À partir de quand vaut-il la peine de poser le reshoring comme projet ?

Au plus tard quand les obligations KRITIS, les attestations C5 ou les directives BSI sont sur la table au prochain cycle d’audit et que le commissaire aux comptes adresse explicitement la question de juridiction. En-dessous de ce seuil, un verrou de région proprement documenté dans la région UE de l’hyperscaler suffit dans beaucoup de cas – moins d’effort et couvre la plupart des exigences en ETI.

Dois-je sortir complètement du cloud US pour faire du reshoring ?

Non. La majorité des projets 2026 tourne en hybride : charges critiques par classe de données chez des fournisseurs natifs UE, le reste reste sur AWS, Azure ou Google Cloud avec verrou de région UE. La rhétorique de sortie totale fonctionne dans les discours officiels, rarement dans la roadmap.

Quels certificats sont réellement pertinents dans le débat reshoring ?

En pratique : C5 type 2 du BSI comme règle de base, ISO 27001 comme socle, Gaia-X Label Level 2+ pour les appels d’offres publics. Les preuves KRITIS s’ajoutent selon le secteur (B3S). Tout le reste est complément marketing – pas sans importance, mais pas un critère de décision.

Comment éviter de glisser du lock-in US à un lock-in UE ?

Dès le jour 1, miser sur des technologies portables : Kubernetes plutôt qu’orchestration propriétaire, Terraform plutôt que console spécifique à un fournisseur, formats de données ouverts plutôt que spécificités de services managés. Ne pas écrire le plan de sortie seulement quand le changement se profile, mais le fixer contractuellement dans l’onboarding du nouveau fournisseur.

Qu’est-ce que le reshoring implique pour le paysage SaaS de l’entreprise ?

Peu à rien, tant que le focus est sur l’IaaS. Le débat SaaS est un projet à part, avec d’autres moteurs et souvent des coûts politiques plus élevés. Qui fait proprement le reshoring lors du déménagement IaaS et exclut la question SaaS a livré une réponse honnête – personne ne lâche Microsoft 365 en projet secondaire d’un programme d’infrastructure.

Source image de couverture : Pexels / Sergei Starostin (px:6466141)