Quand l'explosion des data centers américains force une ETI européenne à revoir ses fondations cloud

# Quand l'explosion des data centers américains force une ETI européenne à revoir ses fondations cloud

Le signal d'alarme est venu d'une facture

Tout a commencé par une anomalie budgétaire. Une ETI industrielle de 800 salariés, spécialisée dans la fabrication de composants mécaniques pour l'automobile et l'aéronautique, constate en début d'année 2025 une dérive inexpliquée de ses coûts d'infrastructure cloud. Pas un dérapage spectaculaire — le genre de glissement progressif qui échappe aux tableaux de bord tant qu'il ne franchit pas un seuil visible.

Son DSI, en poste depuis quatre ans, mandate alors une revue complète de l'architecture. Ce qu'il découvre dépasse la simple question de facturation. L'entreprise s'est progressivement retrouvée dans une situation de dépendance structurelle vis-à-vis d'un seul opérateur cloud américain, sur des périmètres aussi sensibles que la gestion des données de production, les outils collaboratifs et les sauvegardes des ERP métier.

Aucune décision délibérée n'a conduit à ce résultat. C'est l'accumulation de choix pragmatiques — un projet par-ci, une migration opportuniste par-là — qui a construit, en silence, une architecture où la maîtrise réelle du système d'information a glissé vers l'extérieur.

2026 : un contexte qui rend l'inaction intenable

Ce cas n'est pas isolé. Il prend en 2026 une résonance particulière dans le contexte du boom des data centers. Les investissements massifs annoncés depuis 2024 par les acteurs américains en Europe — des enveloppes considérables promises sur le sol européen — ont longtemps été présentés comme une bonne nouvelle pour les entreprises du continent. La capacité disponible allait augmenter, les latences diminuer, les prix se stabiliser.

La réalité opérationnelle est plus nuancée. Ces infrastructures restent juridiquement soumises à des législations extraterritoriales — le Cloud Act américain au premier rang. La proximité géographique d'un data center situé en Allemagne ou aux Pays-Bas ne change rien à la nature du contrat passé avec l'opérateur. Les données hébergées restent potentiellement accessibles à des autorités étrangères, dans des conditions que peu d'entreprises européennes ont réellement évaluées sur le plan juridique.

Pour les équipes IT des PME et ETI, ce point est souvent traité comme une abstraction juridique. Il devient concret le jour où un client grand compte — soumis, lui, à des exigences de conformité strictes — demande à auditer la chaîne d'hébergement. Ou le jour où un appel d'offres public exige une localisation et une gouvernance des données certifiées.

L'ETI industrielle citée ici a vécu exactement cette situation : un partenaire de rang 1 dans sa filière a conditionné le renouvellement d'un contrat à une démonstration de conformité sur la localisation des données techniques partagées. La question abstraite est devenue, en quelques semaines, un enjeu commercial direct.

Ce que ça change concrètement pour les équipes IT

La décision de revoir l'architecture cloud n'est pas seulement stratégique. Elle a des conséquences très opérationnelles sur le quotidien des équipes.

Premier constat du DSI : ses équipes avaient progressivement perdu la main sur certaines briques fondamentales. La gestion des identités, les politiques de sauvegarde, les configurations réseau — autant de périmètres qui, dans un environnement cloud managé par un opérateur dominant, sont en partie délégués à des interfaces propriétaires. Revoir l'architecture, c'est aussi réapprendre à administrer ce qu'on avait sous-traité de facto à une console SaaS.

Ce retour en main n'est pas sans coût humain. L'équipe infrastructure — trois personnes pour 800 salariés, ce qui est représentatif de la réalité des ETI — a dû monter en compétence sur des outils qu'elle ne maîtrisait plus. La mémoire technique s'était érodée au fil des années de délégation.

Deuxième constat : la question de l'observabilité. Dans l'environnement précédent, les tableaux de bord fournis par l'opérateur américain donnaient une visibilité confortable — mais filtrée par sa propre interface, selon ses propres métriques, dans son propre format de facturation. Migrer vers une infrastructure où l'on reprend le contrôle implique de reconstruire une couche d'observabilité interne. C'est un investissement en temps et en compétences que peu d'ETI anticipent au moment de lancer une démarche de souveraineté.

Troisième point, moins visible mais structurant : la gestion du changement auprès des métiers. Les utilisateurs finaux — les équipes de production, les bureaux d'études, les fonctions support — se sont habitués à des interfaces et des flux de travail construits autour des outils de l'opérateur dominant. Changer de socle d'infrastructure, même à périmètre fonctionnel équivalent, génère des frictions. Le DSI de l'ETI en question souligne que c'est là que réside une partie significative de la charge réelle du projet : non pas dans la migration technique, mais dans l'accompagnement humain.

Vers quoi se tourner — sans liste de courses

L'ETI n'a pas opté pour une rupture totale. Elle a appliqué une logique de découplage progressif, en identifiant les briques les plus sensibles sur le plan de la souveraineté — données de production, plans techniques, données RH — et en les migrant en priorité vers des opérateurs relevant du droit européen.

Sur ce segment, Scaleway, filiale du groupe Iliad, a été évalué comme opérateur de substitution pour une partie des workloads. Non pas parce qu'il s'agit d'une solution universelle, mais parce qu'il répond à des critères précis : gouvernance française, infrastructure localisée en Europe, engagements contractuels compatibles avec les exigences RGPD et, progressivement, avec les certifications SecNumCloud.

Le reste de l'architecture — les périmètres moins sensibles, les outils collaboratifs génériques — a fait l'objet d'une revue fonctionnelle. Pas pour en sortir à tout prix, mais pour remettre sur la table une question que l'entreprise n'avait jamais posée explicitement : pour chaque brique, quel niveau de dépendance est acceptable, et à quelles conditions ?

Cette formalisation, aussi simple qu'elle paraisse, a changé la nature des décisions futures. L'ETI dispose désormais d'une cartographie des risques de dépendance numérique, mise à jour à chaque nouveau projet IT. C'est un outil de gouvernance, pas un document de conformité destiné à rester dans un tiroir.

Ce que ce cas enseigne

Plusieurs enseignements se dégagent de cette situation, transférables à d'autres organisations de taille comparable.

D'abord, la dépendance cloud se construit par défaut, pas par décision. Les équipes IT des ETI n'ont généralement ni le temps ni les ressources pour challenger chaque choix technologique à l'aune de la souveraineté. La dérive se fait donc naturellement vers ce qui est disponible, connu et bien intégré — c'est-à-dire, dans la plupart des cas, l'offre dominante américaine.

Ensuite, le déclencheur de prise de conscience est rarement interne. Dans ce cas, c'est une exigence client qui a forcé la main. D'autres entreprises citent un incident de sécurité, une hausse de tarifs non anticipée, ou une modification unilatérale de conditions contractuelles. L'enjeu est de ne pas attendre ce déclencheur externe pour engager la réflexion.

Enfin, la souveraineté numérique n'est pas un projet : c'est un mode de gouvernance permanent. Elle ne s'épuise pas dans une migration. Elle se traduit par des réflexes, des critères de décision intégrés aux processus d'achat IT, et une capacité à évaluer en continu le niveau de maîtrise réelle du système d'information.

Pour les DSI et CTO d'ETI européennes, le boom des data centers américains en Europe n'est pas une garantie de souveraineté. C'est, au contraire, un signal qui appelle à distinguer ce qui est proche géographiquement de ce qui est réellement maîtrisé juridiquement et opérationnellement. La nuance est décisive.