Technologie de localisation : Mode Allemagne au lieu de dogme du cloud

16.07.2026

6 min de lecture

De nombreux groupes du DACH se retrouvent entre exigences de souveraineté, OT d’usine et standards cloud globaux. Traiter l’IT de site comme pure infrastructure sous-estime gouvernance, modèle opérationnel et pilotage Capex. Les décideurs ont besoin d’un modèle opérationnel qui pilote les deux et remplace le choix idéologique de plateforme.

Les points clés en bref

Gérer trois logiques en parallèle. Les plateformes corporate, les systèmes OT proches des sites de production et les exigences réglementaires s’entremêlent – la souveraineté consiste à maîtriser de manière contraignante le site, le lieu de traitement, l’exploitant et le chemin de sortie.
Cinq classes de workloads. Au moins cinq classes de workloads, allant des SaaS aux systèmes centraux en passant par l’IA, le Edge et les traitements réglementés, remplacent les directives génériques « Cloud-First » ou « On-Prem ».
Séparer les rôles et les budgets. L’IT corporate définit les lignes de base, la région adapte la conformité, et l’usine gère la proximité OT – Volkswagen et Siemens séparent les plateformes centrales des workloads proches de la production.
Arbre décisionnel avant le lancement. La classe de données, la latence et l’intégration déterminent le lieu et l’exploitant – la preuve opérationnelle, avec RTO et RPO selon la norme ISO 22301, parachève l’architecture.

Articles associésSouveraineté numérique 2026 : Ce que les DSI doivent savoir sur Delos Cloud, Gaia-X et le Règlement européen sur les données / Cloud souveraine : la voie de l’Europe vers la souveraineté numérique

Le champ de tension entre souveraineté, OT et plateformes globales

Les DSI et CDO doivent aujourd’hui concilier trois logiques simultanément. Les plateformes corporate poussent à la standardisation, aux économies d’échelle et aux cycles de release globaux. Les systèmes des sites et des usines exigent une disponibilité maximale, des latences déterminées et un couplage étroit avec les machines, les systèmes de pilotage et les transitions de poste. Les exigences réglementaires et contractuelles en matière de résidence des données, de traitement des données par des tiers et de traçabilité ajoutent des contraintes supplémentaires. Cela ne suffit pas à définir une architecture.

Le champ de tension apparaît lorsque l’une de ces trois logiques devient l’unique boussole. Une directive générique « Cloud-First » peut entraîner des problèmes de latence, de maintenance et de validation pour les workloads proches de l’OT. Une directive « On-Prem » systématique alourdit les coûts des applications standard et complique la discipline des correctifs et de la gestion des identités. La souveraineté, au sens IT, n’est pas un engagement politique. C’est la capacité à maîtriser de manière contraignante le site, le lieu de traitement, l’exploitant et le chemin de sortie.

En pratique, cela signifie que les classes de données, les lieux de traitement et les responsabilités opérationnelles doivent être définis avant même le choix de la plateforme. Le catalogue de critères C5 du BSI impose aux fournisseurs de cloud de garantir, dans leur description système, la transparence sur le siège juridique, les lieux de traitement des données et les obligations de réponse aux autorités. La version C5:2026 renforce encore les exigences techniques en matière de souveraineté et de séparation des mandants. Parallèlement, le chapitre V du RGPD (art. 44 et suivants) encadre les transferts de données personnelles vers des pays tiers. Le Data Act européen (règlement (UE) 2023/2854), applicable depuis septembre 2025, complète ces dispositifs en instaurant des droits de migration cloud et des mécanismes de protection contre les accès non autorisés de pays tiers aux données non personnelles stockées dans l’UE. Si ces exigences ne sont définies qu’après la migration vers le cloud, les coûts de correction et les risques d’audit augmentent. Cela vaut particulièrement lorsque les données de production, les données RH et les interfaces fournisseurs se retrouvent sur la même pile.

Des classes de charge de travail plutôt qu’une règle « Cloud First » généralisée

Un modèle opérationnel solide commence par des classes de charge de travail, et non par les fournisseurs. Il est judicieux de définir au moins cinq catégories : les services SaaS et de collaboration à l’échelle de l’entreprise, les systèmes centraux nécessitant une forte intégration, les charges de travail analytiques et d’IA, les traitements proches du edge (contrôle et capteurs), ainsi que les traitements réglementés ou liés à un site spécifique. Chaque classe doit s’accompagner de critères précis concernant la latence, la classification des données, la fréquence des modifications, la capacité opérationnelle et les coûts de sortie.

Le cloud se prête aux situations où l’élasticité, les identités globales et les processus opérationnels standardisés génèrent de la valeur. Le edge et les capacités de calcul locales conviennent là où les cadences de production, la capacité de fonctionnement hors ligne ou l’intégration étroite avec l’OT dictent le rythme. L’hybride consiste à attribuer de manière planifiée les charges de travail aux lieux et aux modes d’exploitation adaptés. Des modèles de référence éprouvés offrent une orientation : la hiérarchie fonctionnelle selon ISA-95 (IEC 62264) sépare le processus physique, le contrôle, l’exécution de la fabrication et les systèmes d’entreprise. La série de normes ISA/IEC 62443 complète ce cadre en introduisant des zones et des conduits, c’est-à-dire des zones de sécurité aux exigences de protection comparables et des chemins de communication contrôlés entre elles.

Une segmentation rigoureuse des classes de charge de travail permet d’éviter deux erreurs typiques. La première consiste à migrer uniquement des systèmes critiques proches de l’usine sous prétexte que la norme du groupe impose le cloud. La seconde réside dans le blocage de charges de travail standard sans risque, derrière des arguments de souveraineté qui ne tiennent ni techniquement ni juridiquement. La question décisive est la suivante : quel contrôle, quel lieu et quel opérateur pour cette classe ?

Rôles de l’usine, de la région et de l’IT du groupe

Sans rôles clairement définis, l’hybride se transforme en IT fantôme et en redondances. L’IT du groupe établit les principes d’architecture, les bases d’identité et de sécurité, les cadres d’approvisionnement et les normes de plateforme. L’IT régionale adapte ces directives aux réalités locales en matière de conformité, de contrats et d’exploitation. L’échelon de l’usine est responsable de la proximité avec l’OT, du travail en équipes, de la gestion des perturbations locales et de l’interface avec la maintenance et la production.

Cette interface doit être formalisée. Les droits de modification et de release, la propriété des incidents et les circuits de validation pour les changements liés à l’OT doivent figurer dans un modèle opérationnel doté de voies d’escalade claires. Les identités, les zones réseau et les journaux ne doivent pas être réinventés à chaque site. Parallèlement, l’usine doit disposer d’une marge de manœuvre pour les systèmes tactiques ne pouvant suivre le rythme des releases du groupe.

Sur le plan financier, les dépenses d’investissement (Capex) et les dépenses d’exploitation (Opex) se séparent selon ces rôles. Les plateformes du groupe peuvent souvent être budgétisées en tant que services partagés. Les infrastructures locales et l’intégration avec l’OT restent davantage pilotées par l’investissement et nécessitent une planification pluriannuelle de maintenance et de modernisation. Des exemples concrets d’entreprises confirment cette séparation des niveaux de contrôle : Volkswagen construit avec la Group Private Cloud 2.0, basée sur la T Cloud Private de T-Systems, une plateforme centrale pour les applications d’entreprise, et souligne, selon Hauke Stars, membre du directoire IT du groupe, la combinaison de partenariats et d’infrastructures propres. Le « cloud-only » n’y est explicitement pas envisagé. En parallèle, Volkswagen exploite des charges de travail proches de la production via la plateforme Digitale Produktionsplattform avec AWS. Siemens décrit, dans son usine de moteurs de Bad Neustadt, la convergence de l’IT et de l’OT comme un cas d’exploitation local avec une fabrication pilotée par les données. Sans cette séparation des rôles et des budgets, des budgets fantômes et des priorités concurrentes apparaissent entre l’usine et le siège.

Risques d’approvisionnement et d’exploitation dans le cadre allemand

Le cadre allemand présente des risques d’approvisionnement typiques. Les longs délais de livraison pour les serveurs, le matériel réseau et OT se heurtent à des fenêtres de maintenance restreintes dans la production. Les contrats-cadres avec des hyperscalers mondiaux et des hébergeurs locaux fonctionnent en parallèle et génèrent des incohérences au niveau des SLA, des droits d’audit et des clauses de sortie. Les pénuries de personnel dans les rôles opérationnels proches de l’OT renforcent la dépendance envers les intégrateurs et le support des fabricants.

Les risques opérationnels découlent de l’architecture. La séparation des identités entre IT et OT augmente les surfaces d’attaque et complique la traçabilité forensique. Une résidence des données floue dans les pipelines de sauvegarde, de journalisation et d’IA entraîne des corrections ultérieures. Des retards de correctifs sur les systèmes proches du edge apparaissent lorsque les mises à jour de sécurité ne sont pas coordonnées avec les validations de production. Le BSI souligne dans ses recommandations ICS et OT que l’OT nécessite des temps de fonctionnement plus longs, des fenêtres de maintenance rares et des exigences en temps réel. Les mesures de protection de l’IT bureautique ne peuvent donc être que partiellement transposées. Les « Principes de cybersécurité OT » du BSI (2024) s’adressent aux décideurs et exigent une gestion holistique de la planification à l’exploitation. La norme ISA/IEC 62443 propose, avec les zones, les conduits et le rapport technique 62443-2-3, des bases concrètes pour la segmentation et la gestion des correctifs dans les systèmes industriels d’automatisation et de contrôle. Le module de base de protection IT IND.1 du BSI complète ces exigences par des spécifications pour les techniques de conduite de processus et d’automatisation.

L’approvisionnement doit donc suivre l’architecture, et non l’inverse. Une approche multi-cloud basée uniquement sur des réflexes de négociation augmente les coûts d’exploitation et de gouvernance si les classes de workload et les flux de données ne sont pas définis au préalable. Le colocation local ou les variantes d’hébergement souverain ne sont utiles que si les processus opérationnels, la gestion des clés et la reprise après sinistre sont testés et budgétisés. Le DSI gère ici les risques résiduels et la capacité de sortie.

Arbre de décision pour les cas hybrides et edge

Un arbre de décision utilisable commence par la classe de données et de processus. Les décideurs doivent d’abord clarifier si le workload traite des données personnelles, sensibles ou critiques pour la production, et quelles obligations de résidence et de contrôle s’appliquent. Ensuite, la question de la latence et de la disponibilité se pose : une zone cloud régionale suffit-elle ? Faut-il une proximité avec l’usine ou une capacité hors ligne ? Viennent ensuite la fréquence des modifications et la densité d’intégration avec le MES (Manufacturing Execution System), le SCADA (Supervisory Control and Data Acquisition), l’ERP et les services d’identité.

Ce n’est qu’après que la décision concernant le lieu et l’exploitant est prise. Le SaaS est acceptable si la classe de données, le contrat et la sortie sont adaptés. Le cloud privé ou virtuel privé convient aux systèmes centraux intégrés avec des exigences de contrôle élevées. Les instances edge et on-premise sont utilisées pour les couplages OT, les limites de latence strictes ou les validations liées au site. L’approche hybride émerge lorsque le prétraitement des données est local et que l’analyse ou l’entraînement sont centralisés, avec des interfaces standardisées.

L’arbre se termine par la preuve opérationnelle. Qui exploite, qui applique les correctifs, qui escalade et comment la reprise après sinistre est assurée dans quel délai doit être répondu avant le lancement. La norme ISO 22301 sur la gestion de la continuité d’activité définit à cet effet les objectifs clés RTO (Recovery Time Objective, temps d’interruption maximal tolérable) et RPO (Recovery Point Objective, perte de données maximale tolérable). L’absence de cette preuve rend l’architecture incomplète, même si la plateforme cible est formellement approuvée.

Pour le DSI et le CDO, la conclusion est claire : l’IT sur site devient un objet de pilotage avec les classes de workload, le modèle de rôles et l’arbre de décision. Le cloud reste un outil. La souveraineté reste une capacité de pilotage. L’OT reste une réalité opérationnelle. Qui relie ces trois niveaux dans le modèle opérationnel réduit les mauvaises allocations de Capex et crée des décisions hybrides fiables pour le mode allemand.

Foire aux questions

Pourquoi les risques d’audit augmentent-ils avec les décisions de résidence et de sortie différées ?

Les catégories de données, les lieux de traitement et les responsabilités opérationnelles doivent être définis avant le choix de la plateforme. Le référentiel C5:2026 exige une transparence sur le for juridique, les emplacements des données et la séparation des mandats. Le chapitre V du RGPD encadre les transferts vers des pays tiers, tandis que l’EU Data Act, en vigueur depuis septembre 2025, renforce les droits de migration et la protection contre les accès non autorisés depuis des États tiers. Les corrections ultérieures génèrent des coûts de mise aux normes et des risques d’audit dès que les données de production, de personnel et de fournisseurs se retrouvent dans la même infrastructure.

Quels risques d’approvisionnement influencent particulièrement la configuration en Allemagne ?

Les délais d’approvisionnement longs pour les serveurs, le matériel réseau et les équipements OT se heurtent à des fenêtres de maintenance restreintes dans la production. Les contrats-cadres parallèles avec des hyperscalers et des hébergeurs locaux créent des incohérences en matière de SLA, de droits d’audit et de clauses de sortie. Les pénuries de personnel dans les rôles opérationnels proches de l’OT accentuent la dépendance vis-à-vis des intégrateurs et du support des fabricants. La stratégie d’approvisionnement suit l’architecture dès que les classes de charge de travail et les flux de données sont définis.

Comment formaliser l’interface entre la DSI du groupe et l’usine ?

Les droits de changement et de mise en production, la propriété des incidents et les processus d’approbation pour les modifications pertinentes pour l’OT doivent être intégrés dans un modèle opérationnel doté de voies d’escalade claires. Les identités, les zones réseau et les journaux restent standardisés à l’échelle du groupe. Parallèlement, l’usine conserve une marge de manœuvre décisionnelle pour les systèmes tactiques en dehors du rythme de publication du groupe. Les dépenses d’investissement (Capex) et les dépenses d’exploitation (Opex) obéissent à la même logique de rôles et séparent les services partagés du groupe de l’infrastructure locale, pilotée par des investissements.

Quand l’architecture reste-t-elle incomplète malgré une plateforme cible approuvée ?

Lorsque la preuve opérationnelle fait défaut avant le lancement. Il faut répondre de manière contraignante à la question de savoir qui opère, qui applique les correctifs, qui gère les escalades et comment la reprise après sinistre est assurée. La norme ISO 22301 définit à cet effet le RTO comme le temps d’arrêt maximal tolérable et le RPO comme la perte de données maximale admissible. Sans ces objectifs et des voies claires de responsabilité, l’architecture reste incomplète.