Les secrets de l'Allemagne dans le cloud de Google : le cloud ND prévu est-il vraiment dépourvu de souveraineté ?

Hors ligne, mais dépendants ? Le prix risqué de la technologie Google pour les services d’information allemands

Le cloud de Google pour les agences de renseignement allemandes : que se passe-t-il si le fournisseur tombe en panne ?

Un service cloud isolé d'Internet peut protéger efficacement les informations classifiées, mais il peut aussi engendrer une dépendance à long terme vis-à-vis de son fournisseur de technologie. Le projet ND Cloud, destiné au Service fédéral de renseignement (BND), à l'Office fédéral de protection de la Constitution (BfV) et au Service de contre-espionnage militaire (MAD), illustre précisément cette tension. Il vise à permettre l'échange sécurisé d'informations hautement sensibles tout en fonctionnant sans connexion directe à Internet. Cependant, cette isolation, dite « air gap », ne répond pas à toutes les questions : qui assurera la maintenance, la mise à jour et le développement de la plateforme au fil des ans ? Et quelles options restent à l'État en cas d'évolution du contexte technique ou politique ?

Pour un projet dont le budget annoncé s'élève à au moins 500 millions d'euros, les enjeux dépassent largement le simple choix de l'emplacement des serveurs et des mesures de sécurité. La question cruciale est de savoir si l'Allemagne peut maîtriser la plateforme sur le long terme et migrer vers une autre si nécessaire. Cela implique de prendre en compte non seulement la protection des données, mais aussi la fourniture de logiciels, l'expertise, les coûts de migration et les alternatives potentielles. Le cloud envisagé peut constituer une étape importante vers la modernisation, mais la véritable souveraineté numérique ne sera atteinte que lorsque l'État contrôlera non seulement les opérations en cours, mais disposera également d'options viables pour l'avenir.

En lien avec ceci :

• Les forces armées allemandes font affaire avec Google : quelle part de souveraineté l’Allemagne abandonne-t-elle réellement pour le cloud de Google ?

Les secrets de l'Allemagne, la technologie de Google : le prix de la souveraineté numérique

Le mode hors ligne est loin d'être indépendant

Un service cloud isolé d'Internet peut protéger efficacement les informations classifiées, tout en créant une dépendance à long terme vis-à-vis de son fournisseur technologique. La plateforme de données commune envisagée par le Service fédéral de renseignement (FIA), le Bureau fédéral de protection de la Constitution (FOPC) et le Service de contre-espionnage militaire (MCS) se situe précisément au cœur de cette tension : l'isolation technique prévue répond à la question de l'accès au réseau externe, mais pas encore à celle d'une liberté d'action technologique durable.

La question économiquement déterminante n'est donc pas de savoir si le logo d'une entreprise américaine ou européenne apparaît sur la plateforme. Ce qui importe, c'est de savoir qui définit les conditions de son développement, de son dépannage, de son exploitation et de sa migration potentielle tout au long de son cycle de vie. Une stratégie de souveraineté convaincante doit allier performance, exigences de sécurité et liberté de choix à long terme, et non se limiter à la seule localisation des serveurs.

Une plateforme de données aux implications stratégiques

D'après l'état d'avancement du projet, accessible au public au 28 octobre 2026, le système dit « ND Cloud » vise à permettre l'échange électronique d'informations classifiées SECRET entre les trois services fédéraux de renseignement ; ultérieurement, les offices de protection de la Constitution des Länder pourraient également y être intégrés. Techniquement, il s'agirait de Google Distributed Cloud en configuration sécurisée, les informations étant stockées en Allemagne et Google n'ayant pas d'accès direct aux données.

Il ne s'agit pas de stocker des secrets d'État sur un service internet ordinaire. Il s'agit plutôt de concevoir une infrastructure distincte, capable de fonctionner sans connexion directe à l'internet public ni au cloud de Google. Cette distinction est cruciale car elle modifie la nature des menaces : un réseau techniquement isolé et géré au niveau national doit être évalué différemment d'un service cloud standard administré de l'extérieur.

Le chiffre annoncé publiquement s'élève à au moins 500 millions d'euros ; il s'agit d'une estimation et non d'un détail complet des coûts. Le lancement, initialement prévu pour le premier trimestre 2027, sera probablement reporté, et des informations essentielles concernant l'architecture, l'étendue des services et les coûts récurrents ne sont pas publiques. Sur la base de ces informations, il est impossible de calculer un retour sur investissement fiable ou d'affirmer avec certitude qu'une alternative particulière serait moins chère d'un pourcentage fixe.

Cependant, l'ampleur même du projet démontre que la plateforme serait bien plus qu'un simple système informatique. Elle façonnerait les flux de travail, les modèles de données et les qualifications pour les années à venir. Plus les organismes gouvernementaux harmoniseront leurs procédures spécialisées avec des services techniques partagés, plus l'importance stratégique des décisions qui, de prime abord, semblent relever uniquement de l'infrastructure, sera grande.

Pourquoi une infrastructure partagée peut être économiquement avantageuse

La nécessité d'une modernisation est tout à fait justifiée : l'échange d'informations sensibles entre les systèmes gouvernementaux protégés est actuellement complexe, tandis que les besoins en stockage et en analyses automatisées augmentent. Une plateforme partagée peut simplifier les transferts de données, fournir des outils standardisés et accélérer la collaboration, à condition que les autorisations et les responsabilités soient clairement définies.

D'un point de vue économique, les économies d'échelle offrent des avantages potentiels. Si la puissance de calcul, la sauvegarde des données, la surveillance et les processus de sécurité sont fournis conjointement, toutes les autorités n'ont pas besoin de développer simultanément les mêmes capacités. Cela permet d'optimiser l'utilisation des ressources et d'alléger la charge de travail du personnel qualifié, souvent rare. BWI décrit ainsi une infrastructure cloud standardisée et automatisée comme un moyen d'offrir des services informatiques plus flexibles et plus efficaces.

À cela s'ajoute l'avantage d'un traitement de l'information plus rapide. Un environnement technique performant permet d'éviter que les renseignements existants ne soient disponibles trop tard en raison de procédures trop lourdes. Cet avantage est difficile à quantifier en euros pour les services de renseignement, mais il n'en est pas moins significatif sur le plan économique. Toutefois, un gain de sécurité plausible ne doit pas servir d'argument arbitrairement souple pour justifier a posteriori toute dépendance technologique.

La comparaison pertinente ne s'effectue donc pas entre un cloud moderne et une infrastructure existante sans risque. Les systèmes hérités fragmentés engendrent eux aussi des coûts et des risques de sécurité, notamment liés à une maintenance complexe et à des processus manuels. Une évaluation adéquate doit prendre en compte les risques de migration ainsi que les coûts de l'inaction ; toutefois, le seul besoin de modernisation ne garantit pas la viabilité économique à long terme de chaque plateforme proposée à cet effet.

L'espace d'air ne résout qu'une partie du problème

Le terme « isolation physique » désigne ici une séparation d'avec l'internet public et les autres réseaux externes, et non pas nécessairement un isolement complet de chaque ordinateur. Au sein d'un réseau gouvernemental protégé, les systèmes peuvent continuer à collaborer, tandis que des limites strictes encadrent l'accès externe. Google précise que sa plateforme est opérationnelle en permanence sans connexion au cloud public de Google.

Cette caractéristique constitue un atout majeur en matière de sécurité et ne doit pas être sous-estimée. L'absence de connexions externes limite certains vecteurs d'attaque et favorise un fonctionnement contrôlé. Toutefois, cela ne signifie pas que la plateforme puisse être maintenue en toute sécurité ou étendue fonctionnellement indéfiniment sans services supplémentaires du fabricant ; l'indépendance technique vis-à-vis du réseau et l'indépendance vis-à-vis de la fourniture de logiciels sont deux propriétés distinctes.

On peut illustrer ce phénomène en le comparant à une usine de production entièrement située sur un site industriel allemand. Si la localisation garantit le contrôle physique, elle ne garantit pas la disponibilité permanente des pièces détachées, des logiciels de contrôle et des connaissances spécialisées. Le simple fait qu'une entreprise exploite l'usine ne lui permet pas nécessairement de la développer de manière indépendante. Ce même raisonnement économique s'applique à un environnement cloud très complexe.

La souveraineté ne se résume donc pas à un simple interrupteur. La souveraineté des données, le contrôle administratif, la sécurité juridique, la transparence de la chaîne d'approvisionnement et l'adaptabilité technologique doivent être considérés séparément. Une plateforme peut exceller dans certains de ces domaines et présenter d'importantes dépendances dans d'autres ; c'est précisément cette différenciation qui permet une évaluation pertinente.

Les mises à jour comme interface du pouvoir économique

La documentation de sécurité de Google décrit un processus de mise à jour contrôlé : le fabricant signe les packages logiciels, l’opérateur d’infrastructure les examine, puis les déploie dans l’environnement isolé. Ce processus concerne non seulement les logiciels cloud, mais aussi les systèmes d’exploitation, les firmwares et autres composants critiques pour la sécurité. Une connexion Internet automatique n’est pas requise, mais la relation d’approvisionnement technique est maintenue.

Il s'agit là, dans un premier temps, d'un fonctionnement normal des logiciels professionnels et non d'une preuve de faute de la part du fabricant. La situation devient problématique lorsqu'un seul fournisseur est en mesure de fournir des mises à jour fiables et en temps voulu. Dans ce cas, la sécurité pratique du système dépend non seulement de l'opérateur national, mais aussi d'un organisme de développement externe et de son cadre juridique et économique.

L'ampleur de ces dépendances est illustrée par les conditions générales d'utilisation de Google Distributed Cloud (environnement isolé). Celles-ci stipulent que les nouvelles versions doivent être installées dans les 30 jours suivant leur notification ; elles contiennent également des règles relatives à l'arrêt de la maintenance et à la cessation d'utilisation du logiciel après l'expiration de la licence. Toutefois, ces conditions générales ne doivent pas être confondues avec les dispositions spécifiques, encore inconnues, de la plateforme de messagerie prévue.

Cette distinction est cruciale. Il est impossible de vérifier publiquement les droits d'exploitation individuels, les périodes d'audit ou les mesures de sécurité supplémentaires mises en place pour le cloud ND. De même, il serait infondé de déduire d'une dépendance continue aux mises à jour l'existence d'un accès distant secret ou d'un mécanisme d'arrêt technique. Ce qui est documenté, c'est le rôle continu du fabricant dans la fourniture du logiciel, et non un accès externe arbitraire.

La différence dangereuse entre autonomie et sécurité

En cas d'interruption du support constructeur, plusieurs scénarios doivent être envisagés. Un système déjà installé peut continuer à fonctionner techniquement dans un premier temps, mais les failles de sécurité nouvellement découvertes ne seront plus corrigées. Parallèlement, les droits d'utilisation, la disponibilité des pièces détachées et le support des applications dépendantes peuvent être affectés. Dès lors, la question de la durée de fonctionnement des ordinateurs importe moins que celle de la durée pendant laquelle un fonctionnement responsable sera possible.

Il est impossible de déduire de ces données une durée de vie fixe et générale. Celle-ci dépendrait notamment des vulnérabilités existantes, des possibilités de réparation locales, du recours à des services complémentaires et de la disponibilité de personnel qualifié. Affirmer catégoriquement qu'un cloud isolé devient inévitablement inutilisable après un certain nombre de mois serait tout aussi imprécis que de prétendre à une indépendance illimitée.

Sur le plan économique, cela pose un problème d'options : un État a besoin non seulement de fonctionnalités actuelles, mais aussi de la capacité d'agir en cas de changement de circonstances. Cette option a de la valeur, même si elle reste inutilisée pendant des années. La financer revient à s'assurer contre une perte rare, mais potentiellement très coûteuse, de pouvoir de décision technologique.

Un plan d'urgence efficace devrait donc faire la distinction entre la poursuite limitée des opérations, la restauration complète et la migration vers une autre plateforme. Des prérequis spécifiques devraient être examinés pour chacun de ces scénarios. Par exemple, une simple sauvegarde des données est d'une utilité limitée si les programmes nécessaires au traitement efficace des informations et à l'application des règles d'accès pertinentes font défaut.

La dépendance augmente avec chaque intervention spécialisée

Le terme fréquemment employé de « verrouillage » décrit une situation où changer de fournisseur reste théoriquement possible, mais devient de plus en plus complexe en pratique. Dans les systèmes cloud, ce verrouillage résulte de l'interaction entre les fonctions de la plateforme, les interfaces, les structures de données et les processus opérationnels établis. Plus les applications spécialisées requièrent des services spécifiques d'un fournisseur particulier, plus il est difficile de reproduire des fonctionnalités équivalentes ailleurs.

L'utilisation de technologies propriétaires n'est pas toujours non rentable. Un outil spécialisé peut offrir un gain de productivité significatif. La difficulté réside dans le fait que les avantages à court terme sont souvent évidents, tandis que les coûts de transition futurs restent incertains. Cela risque de créer un déséquilibre systémique : la commodité actuelle est pleinement prise en compte, tandis que la dépendance future n'est évoquée que de manière abstraite.

La liaison au niveau applicatif est particulièrement pertinente. Une machine virtuelle peut être transférée relativement facilement, contrairement à une application métier complexe avec des services de base de données, d'identité et d'analyse spécifiques à un fournisseur. Par conséquent, la prise en charge des conteneurs par une plateforme ne constitue pas une preuve suffisante de son interchangeabilité. Le facteur crucial est de savoir si l'ensemble des fonctionnalités métier peut être déployé dans un environnement différent avec un effort raisonnable.

Une architecture cohérente devrait mettre en balance les avantages des services spécifiques de la plateforme et les obstacles au changement qu'ils engendrent. L'objectif ne serait pas une uniformité technique totale, mais plutôt une différenciation délibérée : les fonctions de base standardisées devraient rester interchangeables autant que possible, tandis que les fonctions spécialisées essentielles seraient analysées séparément en fonction de leur valeur ajoutée et de leurs dépendances.

Le problème du marché européen commence par une question d'échelle

Le défi structurel dépasse largement le cadre des services de renseignement allemands. Le marché européen des services d'infrastructure cloud a atteint un volume d'environ 61 milliards d'euros en 2024, soit près de six fois plus qu'en 2017. Ce chiffre inclut les services d'infrastructure et de plateforme ainsi que les clouds privés hébergés, mais pas l'intégralité du marché des logiciels. Les fournisseurs européens ont plus que triplé leurs revenus régionaux respectifs durant cette période, mais ont néanmoins perdu des parts de marché relatives.

Leur part de marché cumulée est passée de 29 % en 2017 à environ 15 % en 2022 et s'est ensuite maintenue à ce niveau ; Amazon, Microsoft et Google représentaient ensemble environ 70 % du marché selon l'étude de marché publiée mi-2025. Ces chiffres concernent le marché européen et ne doivent pas être assimilés à un marché limité exclusivement à l'UE, ni au segment spécifique des systèmes de renseignement fermés.

Cette situation démontre que la croissance du chiffre d'affaires ne garantit pas à elle seule l'indépendance technologique. Les entreprises européennes peuvent prospérer tout en accusant un retard sur les plus grandes plateformes. Les principaux fournisseurs répartissent les coûts de développement et les investissements sur une clientèle très large ; par conséquent, l'évolutivité et les investissements financés à long terme jouent un rôle crucial sur le marché européen des infrastructures.

Une stratégie européenne réaliste n'aurait donc pas besoin de copier toutes les fonctions des plus grands géants du cloud. Il serait plus judicieux de développer des alternatives robustes pour les domaines d'application particulièrement critiques et de faire progresser conjointement les fondements techniques existants. Un marché de niche axé sur la sécurité peut présenter des facteurs de succès différents de ceux du marché de masse de la puissance de calcul standardisée. La position dominante d'une entreprise sur son marché général ne garantit pas automatiquement sa supériorité pour toutes les applications gouvernementales.

L’État comme moteur des courbes d’apprentissage technologique

Lorsque de nombreuses institutions publiques partagent des exigences similaires en matière de souveraineté des données et de collaboration sécurisée, des normes communes peuvent créer un marché plus vaste et plus fiable. Les entreprises disposent alors d'une base plus solide pour investir dans la documentation, les audits de sécurité et des opérations professionnelles. L'écosystème openDesk, avec ses nombreux partenaires logiciels et opérationnels, démontre qu'une telle approche collaborative est déjà mise en œuvre dans la pratique.

Cela justifie, sur le plan économique, le recours ciblé à des solutions européennes adaptées. Leurs avantages ne se limitent pas au lieu de travail initial, mais peuvent s'étendre à des applications ultérieures et à d'autres installations. La réutilisation des composants, la qualification du personnel et l'efficacité éprouvée des modèles opérationnels permettent de réduire les coûts d'entrée pour les utilisateurs suivants. Ces effets positifs sont souvent sous-estimés lorsqu'on ne considère que la mise en œuvre initiale.

Parallèlement, cela ne doit pas créer un droit à une protection permanente. Les fournisseurs européens doivent eux aussi démontrer leurs performances, leur fiabilité et leur viabilité économique. Une politique protégeant systématiquement toute solution locale, quelle que soit sa qualité, risquerait d'engendrer des coûts élevés et de nouvelles dépendances. L'enjeu crucial n'est pas l'élimination de la concurrence, mais la création de véritables alternatives techniques et économiques.

Il est également crucial d'empêcher qu'un monopole international ne cède la place à une dépendance nationale à peine vérifiable. Des interfaces ouvertes, un savoir-faire opérationnel transférable et la multiplicité des prestataires de services qualifiés sont donc tout aussi importants que le siège social de l'entreprise. En définitive, la souveraineté doit renforcer la capacité d'action de l'utilisateur, et non se limiter à modifier l'origine de son principal fournisseur.

Centre de sécurité et de défense - Image : Xpert.Digital

Le Pôle Sécurité et Défense offre des conseils d'experts et des informations actualisées pour accompagner efficacement les entreprises et les organisations dans le renforcement de leur rôle dans la politique européenne de sécurité et de défense. En étroite collaboration avec le groupe de travail Défense de SME Connect, il soutient tout particulièrement les petites et moyennes entreprises (PME) désireuses de développer leur capacité d'innovation et leur compétitivité dans le secteur de la défense. Point de contact central, le Pôle constitue ainsi un lien essentiel entre les PME et la stratégie européenne de défense.

En lien avec ceci :

• Le groupe de travail SME Connect Défense – Renforcer les PME dans la défense européenne

OpenDesk est pertinent, mais ne remplace pas complètement le cloud

La suite bureautique et collaborative openDesk a été lancée en octobre 2024 et, selon le Centre pour la souveraineté numérique (CDS), elle était installée sur environ 100 000 postes de travail administratifs en octobre 2026. Ce chiffre représente le taux d’adoption déclaré et non la preuve de 100 000 utilisateurs actifs quotidiens ou d’un nombre équivalent de postes de travail hautement confidentiels. Il démontre néanmoins que la collaboration open source en Europe a depuis longtemps dépassé le stade de petits projets pilotes.

Techniquement, la comparaison doit rester précise. OpenDesk regroupe des applications pour le travail de bureau et la collaboration, tandis que Google Distributed Cloud est une infrastructure et une plateforme de services beaucoup plus vaste. Une suite collaborative ne remplace pas automatiquement l'architecture de stockage, les bases de données, les ressources de calcul et les services spécialisés d'un environnement d'intelligence artificielle complet. Quiconque présente ces deux offres comme des solutions complètes et directement interchangeables confond différents niveaux techniques.

Néanmoins, openDesk est un acteur important du débat, car la collaboration quotidienne ne nécessite pas systématiquement une plateforme propriétaire. Lorsque les autorités publiques éditent conjointement des documents, coordonnent des projets ou communiquent, les applications ouvertes peuvent offrir des alternatives concrètes. Cela permet au moins de réduire la dépendance, même si des infrastructures différentes sont utilisées en sous-jacentes.

En octobre 2026, le fonctionnement d'openDesk dans des environnements totalement isolés a été démontré et testé. Parallèlement, l'accent a été mis sur sa sécurisation pour la classification « VS-NUR FÜR DEN DIENSTGEBRAUCH » (Restreint – Usage interne uniquement). Il ne faut pas interpréter cela comme une preuve de préparation opérationnelle pour toutes les tâches de traitement jusqu'au niveau « GEHEIM » (Secret), car ces classifications sont clairement distinctes. Une démonstration hors ligne fonctionnelle constitue une étape technique importante, mais ne prouve pas systématiquement l'adéquation à tous les cas d'utilisation hautement sensibles.

La matrice illustre les avantages d'une communication ouverte

Element et le protocole ouvert Matrix offrent également des points de départ concrets. BwMessenger s'appuie sur ces composants et est exploité par BWI dans les centres de données de la Bundeswehr ; BunsMessenger transpose cette approche à l'administration publique. Ainsi, une expérience concrète de communication étatique sur une base technique ouverte existe déjà.

L'avantage économique de telles fondations réside dans la séparabilité fondamentale du logiciel, de l'exploitation et du service. Si une autorité publique exploite sa propre infrastructure ou peut choisir parmi différents opérateurs, les conditions de concurrence s'en trouvent renforcées. Le contrôle du service en cours n'est alors pas nécessairement laissé au fabricant du logiciel d'origine.

Cependant, même un service de messagerie instantanée ne constitue pas une plateforme d'analyse complète. La messagerie sécurisée, l'édition collaborative de documents et le traitement de grands ensembles de données sont des tâches distinctes. De plus, chaque configuration spécifique doit répondre aux exigences de sécurité requises ; l'utilisation par un gouvernement n'implique pas automatiquement une conformité à tous les niveaux de classification de sécurité. La communication ouverte est donc un élément important d'une architecture souveraine, mais non une solution universelle à tous les problèmes d'infrastructure.

L'ouverture d'esprit ne remplace pas la compétence

Les logiciels libres peuvent élargir les options de contrôle grâce à la transparence de leur structure et à la possibilité, en principe, de répartir leur développement entre plusieurs acteurs. Cependant, ce potentiel ne se déploie pleinement que si des spécialistes qualifiés, des outils de développement adaptés et un financement durable des responsabilités sont disponibles. La transparence du code source ne suffit pas à éliminer automatiquement les failles de sécurité ni les dépendances problématiques.

Surtout pour les systèmes complexes, il ne suffit pas, en théorie, de pouvoir modifier des programmes individuellement. Il est indispensable de comprendre leurs interactions, de créer des packages d'installation fiables et de tester les nouvelles versions. L'importance accordée à la robustesse des composants essentiels et à la sécurité des chaînes d'approvisionnement au sein de l'écosystème open source gouvernemental illustre le rôle crucial de ce niveau organisationnel.

L'ouverture est donc davantage une condition préalable à la mise en œuvre de nouvelles pistes d'action qu'une garantie absolue. Son avantage économique réside dans la facilité de réutilisation des investissements en matière de connaissances et de développement entre les institutions. Pour ce faire, les adaptations devraient idéalement être réintégrées dans des fondations gérées conjointement. À l'inverse, la multiplication de versions spécialisées et cloisonnées augmenterait les coûts de maintenance et les risques de sécurité.

Il est également essentiel de s'attaquer de manière réaliste aux pénuries de personnel. Une agence ne devient pas souveraine en prenant en charge l'intégralité du travail. Un modèle plus judicieux consiste pour l'État à disposer de pouvoirs d'évaluation et de contrôle internes suffisants, tout en pouvant faire appel à plusieurs prestataires de services professionnels. Cela ne supprime pas totalement les dépendances, mais les rend plus facilement vérifiables et gérables.

Les forces armées allemandes présentent un tableau plus nuancé

Pour contextualiser le ND Cloud, il convient de rappeler que le cloud privé des forces armées allemandes intègre également la technologie Google et que BWI y joue un rôle central. Toutefois, cette plateforme ne se limite pas à un seul Google Cloud : les forces armées allemandes privilégient une approche utilisant plusieurs environnements technologiques distincts, notamment VMware, Google et des logiciels libres.

La première phase du déploiement a débuté en 2025 ; le développement et l’intégration de la suite Google ont été définis à partir de 2026, avec une finalisation prévue pour fin 2027. La plateforme SAP Business Technology est citée comme cas d’usage spécifique, tandis que deux environnements distincts sont prévus pour les informations ouvertes et classifiées (VS-NfD). Ce calendrier publié ne doit pas être interprété comme un état opérationnel définitif.

Cet exemple illustre comment des décisions logicielles fondamentales peuvent engendrer des décisions d'infrastructure ultérieures. Si une plateforme spécialisée est nécessaire, avec des environnements d'exploitation strictement définis, le choix se restreint avant même d'envisager les fournisseurs de cloud. Une analyse de souveraineté doit donc examiner l'ensemble de la chaîne technique et ne peut se limiter à l'infrastructure visible.

Cependant, la multiplicité des plateformes n'offre une véritable évolutivité que si les applications essentielles peuvent effectivement être déplacées d'une plateforme à l'autre. Trois environnements distincts, chacun avec ses propres procédures rigides, impliquent initialement une diversité, mais pas encore une interopérabilité totale. BWI cite explicitement la réduction de la dépendance vis-à-vis des fournisseurs et la migration aisée des applications comme objectifs de son approche.

Les risques juridiques exigent une précision technique

Les débats sur les technologies américaines font souvent référence au CLOUD Act. Ce texte juridique stipule que les entreprises soumises à la législation américaine peuvent être contraintes de divulguer les données en leur possession, sous leur garde ou sous leur contrôle, quel que soit leur lieu de stockage. Par conséquent, le simple fait d'être implanté en Allemagne n'élimine pas automatiquement tous les risques juridiques.

À l'inverse, un droit légal de divulguer des données ne crée pas un accès technique qui n'existait pas auparavant. Si un fournisseur n'a véritablement ni accès aux données ni contrôle sur les clés nécessaires, cette architecture doit être prise en compte dans l'analyse juridique. Par conséquent, une plateforme isolée ne peut être assimilée à un service internet classique exploité par un fabricant.

Concernant le cloud ND, des détails non publics demeurent cruciaux : quels rôles sont disponibles localement ? Comment fonctionnent les procédures d’accès d’urgence ? Quelles informations sont nécessaires à l’analyse des erreurs ? Qui contrôle les clés cryptographiques ? La documentation générale de Google décrit des rôles opérationnels distincts et des procédures d’urgence spécifiques, mais cela ne correspond pas automatiquement à la mise en œuvre finale en Allemagne. Une affirmation catégorique de sécurité serait donc tout aussi inappropriée que l’allégation non fondée d’un accès automatique aux données américaines.

Il convient de distinguer ce risque de celui d'interruption de service. Même si l'accès aux données est techniquement impossible, des conflits juridiques ou géopolitiques pourraient affecter des services tels que la maintenance et le support logiciel. Une évaluation complète de la souveraineté doit donc examiner à la fois le contrôle de l'information et la continuité des services essentiels.

Ce que devrait contenir un calcul de coûts honnête

Une analyse économique complète devrait prendre en compte bien plus que les seuls coûts matériels et logiciels initiaux. Elle doit également inclure l'intégration, le personnel, l'énergie, la formation, la surveillance de la sécurité, la sauvegarde des données, les capacités de redémarrage et l'adaptation continue des processus spécialisés. Pour le ND Cloud, les données détaillées accessibles au public ne permettent pas de quantifier précisément ces composantes ; l'estimation connue d'au moins 500 millions d'euros ne saurait remplacer cette ventilation.

De plus, il convient de prendre en compte les coûts spécifiques à une migration. Ceux-ci incluent le transfert de données, l'adaptation des programmes, l'exploitation en parallèle temporaire et les audits de sécurité renouvelés. C'est pourquoi la réglementation européenne relative à la migration vers le cloud distingue plusieurs étapes techniques, de l'extraction des données à leur migration vers un environnement cible. Une migration d'envergure financière implique donc bien plus que le simple téléchargement d'une archive de fichiers.

Il est également important de distinguer les coûts pour les ménages des effets macroéconomiques. Les services fournis par les centres de données et les prestataires de services allemands peuvent générer de la valeur ajoutée locale, même si le logiciel principal provient d'une multinationale. Inversement, un fournisseur européen n'est pas exempt de dépendances vis-à-vis des chaînes d'approvisionnement mondiales. Une analyse pertinente doit donc prendre en compte la répartition réelle des compétences et des revenus, plutôt que de simplement imputer toutes les dépenses à un seul pays d'origine.

En définitive, il conviendrait d'évaluer séparément les différents scénarios de crise. Une interruption de service de courte durée, un arrêt prolongé des mises à jour et un changement de plateforme temporaire auraient chacun des conséquences différentes. Plutôt que de fournir un chiffre unique et apparemment précis pour l'ensemble des risques, il serait plus judicieux de rendre transparents les marges de manœuvre, les hypothèses et les conséquences particulièrement graves. À l'heure actuelle, les données publiques disponibles sur le projet sont insuffisantes pour déterminer ces valeurs.

Une autonomie mesurable plutôt que des étiquettes rassurantes

Avec les Critères d'autonomie du cloud computing, publiés en avril 2026, l'Office fédéral allemand de la sécurité des systèmes d'information (BSI) a présenté un cadre visant à rendre l'utilisation autonome des services cloud plus systématiquement évaluable. Ces critères complètent les exigences C5 axées sur la sécurité, mais n'ont pas de valeur réglementaire propre. La sécurité et la souveraineté sont ainsi explicitement traitées comme des problématiques d'évaluation liées, mais distinctes.

Ce cadre distingue les aspects stratégiques, juridiques, liés aux données, opérationnels, à la chaîne d'approvisionnement et technologiques. Des indicateurs de performance spécifiques, tels que la transférabilité des connaissances opérationnelles, la disponibilité d'une maintenance indépendante et la capacité à assurer la continuité des opérations en cas de défaillance d'un tiers, sont pertinents. Ces caractéristiques sont plus significatives pour une plateforme de haute sécurité qu'une simple auto-déclaration de souveraineté.

Pour une utilisation pratique, une procédure de redémarrage régulièrement testée serait particulièrement précieuse. Elle permettrait de vérifier si les sauvegardes, la documentation et l'expertise existantes suffisent à restaurer les fonctions essentielles en cas de panne clairement définie. Elle permettrait également de tester quelles données et applications sont réellement utilisables dans un environnement secondaire. Un test concluant serait plus efficace qu'une simple option théorique de basculement.

Même les avancées réglementaires ne résolvent pas ce défi technique. La loi sur les données interdit les frais de changement de prestataire pour les services de traitement de données concernés à compter du 12 janvier 2027. Cependant, cela ne signifie pas automatiquement que tous les environnements de renseignement spécifiques sont concernés par cette interdiction, ni que les coûts de migration interne, de développement et de sécurité sont éliminés. La gratuité du changement pour le fournisseur et l'interchangeabilité technique réelle sont deux choses différentes.

Une puissance de calcul accrue nécessite des limites d'accès claires

Une plateforme partagée peut faciliter la coopération, mais elle ne doit pas uniformiser les règles du jeu en simplifiant les aspects techniques et en minimisant les différences de responsabilités juridiques et de droits sur les données. Une infrastructure partagée n'octroie pas automatiquement à toutes les parties l'autorisation générale d'utiliser librement toutes les informations qu'elle contient. En particulier, lors d'échanges d'informations entre les services de renseignement et la police, des exigences constitutionnelles renforcées s'appliquent et ne doivent pas être confondues avec de simples échanges entre services de renseignement.

Du point de vue de l'architecture, cela implique que les rôles, les finalités, l'origine et le partage autorisé des données doivent être correctement définis. Les plateformes techniques peuvent prendre en charge des règles d'accès précises et une journalisation traçable ; la documentation de Google décrit les autorisations basées sur les rôles et les attributs, ainsi que la journalisation des accès. Cependant, la mise en œuvre pratique et conforme à la loi demeure la seule responsabilité des parties concernées.

De plus, il existe un risque de concentration. Une infrastructure partagée peut mutualiser l'expertise en sécurité, mais une panne grave pourrait affecter plusieurs organismes. Il est donc essentiel d'envisager conjointement la séparation logique, la reprise d'activité et des mécanismes de contrôle indépendants. L'évaluation économique ne doit pas se fonder uniquement sur le taux d'utilisation du centre de données, mais aussi sur la capacité à maintenir les fonctions critiques en cas de pannes partielles.

L'IA déplace la dépendance au niveau du modèle

La traduction, la synthèse et l'analyse automatisées de grands ensembles de données constituent des applications pertinentes pour un cloud fermé ; Google propose des fonctions d'IA correspondantes pour cette gamme de produits. L'intégration technique s'étend ainsi au-delà de l'infrastructure pour inclure les modèles, les interfaces et l'organisation des flux de travail analytiques. Plus les processus spécialisés sont associés à des services d'IA spécifiques, plus leur interopérabilité devient cruciale.

Un modèle exploité localement n'est toutefois pas automatiquement souverain. Les droits d'utilisation, la possibilité de mise à jour, les composants disponibles et la capacité de continuer à utiliser l'outil malgré l'évolution de la situation sont également des éléments importants ; les conditions générales du produit établissent une distinction claire entre les différents modèles et modes d'utilisation. La disponibilité générale du produit ne permet pas de déduire si certaines offres d'IA sont destinées au ND Cloud.

D'un point de vue économique, l'IA doit donc être évaluée à l'aune de la qualité de ses résultats, et non uniquement du nombre de documents traités. Les dépenses supplémentaires peuvent s'avérer judicieuses si elles accélèrent l'analyse et facilitent la recherche d'informations pertinentes. Toutefois, elles peuvent également engendrer un travail de suivi si des résumés erronés ou des liens incorrects doivent être vérifiés ; le fournisseur signale généralement les erreurs potentielles dans les résultats des systèmes génératifs.

Une conception stratégiquement robuste séparerait donc le stockage des données, les modèles et les interfaces utilisateur de la manière la plus claire possible. Cela permettrait de mettre à jour individuellement les outils d'analyse sans avoir à remplacer l'intégralité de la plateforme. Face à l'évolution rapide des technologies d'IA, la capacité à mettre en œuvre des mises à jour contrôlées représente un avantage économique, et non une simple exigence politique.

coopération internationale sans dépendance permanente à un noyau central

Les échanges avec les services partenaires peuvent nécessiter des procédures techniques compatibles. Cependant, cela n'implique pas nécessairement que tous les processus internes doivent se dérouler sur la même plateforme. La Bundeswehr, armée allemande, considère l'interopérabilité internationale comme un objectif clé de sa stratégie multiplateforme et l'associe explicitement à la réduction de sa dépendance vis-à-vis des fournisseurs.

Une approche judicieuse consisterait à distinguer les opérations nationales essentielles des fonctions d'échange clairement définies. Des interfaces spécialisées et des procédures de transfert approuvées pourraient être utilisées pour la coopération internationale, tandis que les référentiels de données centraux et la collaboration fondamentale resteraient gérés de manière indépendante. Le recours à un fournisseur de technologies international serait ainsi une décision fonctionnellement limitée et ne constituerait pas automatiquement le fondement de tous les processus internes.

Cependant, les interfaces ne résolvent pas tous les problèmes. Les différents niveaux de confidentialité, modèles de données et règles de diffusion engendrent des coûts supplémentaires. Une architecture plus découplée peut donc s'avérer initialement plus onéreuse et complexe. Son avantage réside dans la possibilité de modifier les fonctions de collaboration individuelles sans impacter de la même manière le fonctionnement du système central national. Il conviendra d'examiner, au cas par cas, si cet avantage justifie les coûts supplémentaires.

La compétence essentielle est la capacité à s'adapter

D'un point de vue technique, l'approche la plus convaincante ne réside ni dans un rejet catégorique de la technologie américaine, ni dans l'idée que la séparation technique des réseaux résout tous les problèmes de souveraineté. Le projet de cloud ND pourrait certes remédier à de réels problèmes de performance ; toutefois, son architecture isolée et sa dépendance persistante à l'égard de fournisseurs de logiciels externes doivent faire l'objet d'une évaluation distincte.

Pour une collaboration générale, les solutions ouvertes adaptées méritent une évaluation systématique, car openDesk et les services basés sur Matrix sont déjà des éléments constitutifs largement déployés. Des exigences techniques différentes peuvent s'appliquer aux traitements hautement spécialisés. Il est essentiel que les exceptions justifiées ne soient pas généralisées et permanentes, et que les risques résiduels soient explicitement identifiés.

Une stratégie efficace doit donc combiner une expertise interne en matière d'évaluation, des processus de mise à jour transparents et des plans de continuité d'activité éprouvés. Toutes les applications ne nécessitent pas une plateforme secondaire pleinement fonctionnelle et immédiatement disponible. Toutefois, les fonctions critiques doivent être conçues de manière à ce qu'une défaillance externe n'entraîne pas nécessairement une paralysie des services gouvernementaux. Cela requiert des garanties techniques, du personnel qualifié et un financement à long terme.

La véritable épreuve de souveraineté ne se présente pas lors d'un fonctionnement normal et ininterrompu. Elle commence dès qu'un fournisseur modifie ses conditions, que le support technique fait défaut ou que le contexte politique évolue. Un cloud performant est précieux pour l'État. Il ne devient stratégiquement gérable que lorsque l'État maîtrise non seulement son fonctionnement actuel, mais dispose également d'options viables pour l'avenir.

Markus Becker

Je serais heureux de vous servir de conseiller personnel.

Responsable du développement commercial

Président du groupe de travail SME Connect Défense

LinkedIn

Konrad Wolfenstein

Je serais heureux de vous servir de conseiller personnel.

wolfenstein∂xpert.digitalmeVous pouvez contacter à ou

Appelez-moi simplement au +49 7348 4088 965 .

LinkedIn