Deutschland-Stack devient opérationnel : 250 millions pour le cloud fédéral d’IA

250 millions d’euros, deux consortiums, aucun hyperscaler américain. Avec l’attribution du 21 mai 2026, le ministère fédéral du Numérique et de la Modernisation de l’État a pris la plus grande décision d’infrastructure d’IA de l’État fédéral à ce jour, et elle se lit comme un document d’architecture, pas comme un communiqué de presse. L’État fédéral n’achète pas un site plateforme. Il achète une architecture cloud souveraine en tant que Platform-as-a-Service, la construit via des consortiums d’acteurs allemands et européens, et inscrit le Zero-Trust, la maîtrise des clés et l’Open Source dans les conditions contractuelles. Pour les opérateurs de clouds privés, le texte d’attribution est donc une lecture obligatoire : il montre en détail à quoi ressemble un cloud souverain en exploitation.

Les points clés en bref

• 250 millions d’euros, deux lots : Le consortium autour de T-Systems et SAP remporte 70 %, tandis que le consortium composé de SVA, Schwarz Digits et Codesphere en détient 30 %. Aucun lot n’est attribué à un hyperscaler américain.
• La souveraineté est inscrite dans le contrat, pas dans le marketing : Zero-Trust, Bring Your Own Key et les composants Open Source sont des conditions d’attribution, pas des options. Les opérateurs, l’infrastructure et la gestion des clés sont ancrés dans l’UE.
• L’enseignement pour les opérateurs privés : Qui veut vendre de la souveraineté doit fournir la maîtrise des clés, des interfaces ouvertes et une conformité vérifiable, pas seulement l’affirmer. L’État fédéral vient de définir à quoi ressemble le cahier des charges.

En lien :Modèle Frontier hors ligne par décision administrative  /  NIS2 et DORA : séparer proprement les clusters de conformité dans Kubernetes

1. La souveraineté devient un critère d’attribution, pas un simple mot

« Souveraineté numérique » a longtemps sonné comme un discours solennel. Dans cet appel d’offres, le terme devient une condition de réception assortie de critères de vérification. L’État fédéral exige que les opérateurs, l’infrastructure, la gestion des clés et les logiciels de la plateforme soient entièrement ancrés dans l’UE. Pour la première fois, un cloud d’IA fédéral voit le jour sur une stack où aucun lot n’est attribué à un hyperscaler américain.

Concrètement, cela signifie deux choses qui comptent en exploitation. Premièrement, le Zero-Trust : chaque accès est vérifié individuellement, qu’il provienne du réseau interne ou externe. Deuxièmement, le Bring Your Own Key : les administrations utilisatrices conservent le contrôle cryptographique de leurs propres clés, l’opérateur de la plateforme ne devant pas avoir accès aux données en clair. Voici la définition technique du contrôle, pas la définition juridique.

Pour les opérateurs privés, le message est sans équivoque. Une souveraineté sans maîtrise des clés n’est qu’une étiquette. Ceux qui souhaitent servir des clients du secteur public ou des secteurs régulés seront désormais évalués précisément sur ces deux points.

2. L’open source est devenu une obligation contractuelle

La plateforme doit s’appuyer explicitement sur des interfaces ouvertes et autoriser les composants open source. Cela ressemble à une déclaration de principe, mais agit comme un frein au verrouillage. L’État fédéral a tiré les leçons du passé : un cloud dont les interfaces appartiennent à un seul fournisseur n’est pas un cloud souverain, mais une dépendance avec un centre de données allemand.

L’effet est stratégique. Les interfaces ouvertes réduisent les coûts de migration et maintiennent la concurrence ouverte au sein de la stack. C’est précisément cette logique qui motive également les opérateurs privés cherchant à maîtriser leurs coûts multi-cloud, comme le montre le modèle de cloud broker. Là où les standards ouverts s’appliquent, le pouvoir de négociation revient au client.

L’épreuve de vérité réside dans l’exit. Une plateforme n’est considérée comme ouverte que si le passage à un autre opérateur ne déclenche pas un projet de migration s’étalant sur des mois. Les composants open source et les interfaces documentées transforment une option de migration théorique en une possibilité concrète. Pour les opérateurs, cela signifie : celui qui construit ouvert doit tester activement l’exit, et non se contenter de le promettre. Un export de données nécessitant trois semaines de travail manuel en cas d’urgence ne constitue pas, dans le cahier des charges de l’État fédéral, une preuve de souveraineté.

3. PaaS signifie : l’État fédéral loue la plateforme, pas la responsabilité

Le cloud est explicitement attribué en tant que Platform-as-a-Service, et non comme une simple infrastructure. Le consortium autour de T-Systems et SAP fournit les services PaaS, SVA assume l’architecture et l’intégration, Schwarz Digits met à disposition l’infrastructure via la stack cloud certifiée BSI StackIT, et Codesphere apporte la couche plateforme. Les tâches sont clairement séparées, mais la responsabilité reste du côté de l’État fédéral.

C’est précisément le point où de nombreux débats sur la souveraineté achoppent. Le PaaS externalise l’exploitation, mais pas la responsabilité. Celui qui loue la plateforme doit tout de même savoir comment les clés sont renouvelées, comment les incidents sont escaladés et qui décroche le téléphone à 03h40 en cas d’urgence. La question de l’opérateur ne disparaît pas, elle est simplement déléguée aux contrats.

Pour les fournisseurs privés, il est intéressant d’examiner les calculs sous-jacents. La rentabilité d’une stack souveraine dépend de l’utilisation, du personnel et des choix make-or-buy, une question que Digital Chiefs analyse à travers des modèles de coûts concrets.

4. Le niveau d’exigence en matière de conformité s’élève de manière mesurable

Les références sont la norme ISO/IEC 27001 et le BSI C5. L’appel d’offres mentionne ensuite le catalogue de souveraineté C3A, qui renforce la preuve de souveraineté. Il ne s’agit pas d’une simple case à cocher dans le cahier des charges. Cela définit un objectif mouvant : celui qui livre aujourd’hui doit pouvoir prouver qu’il répondra demain aux exigences plus strictes du catalogue.

C’est précisément ici que l’ambition se distingue de l’exploitation. La souveraineté, le Zero-Trust et la gestion auditable des clés doivent fonctionner ensemble, sinon on obtient une « sécurité par incident » au lieu d’une « sécurité par conception ». En cas de doute, la différence peut coûter une semaine de sommeil et une question de surveillance, comme le montre le débat parallèle autour de NIS2 et DORA dans les clusters Kubernetes.

Un objectif de conformité mouvant modifie également la logique contractuelle. Celui qui vend une certification comme une photographie instantanée échoue dès que le prochain catalogue entre en vigueur. Plus judicieux est un modèle d’exploitation qui planifie les audits comme un rythme récurrent : la rotation des clés, la journalisation et la production de preuves s’effectuent en continu, et non uniquement lors du contrôle. Pour les opérateurs privés, c’est la conséquence inconfortable de l’attribution. La barre ne reste pas en place, donc le concept de sécurité ne doit pas non plus stagner.

5. Ce que les opérateurs de cloud privés retiennent de l’attribution

Un détail est presque passé inaperçu dans les gros titres : l’attribution n’a été possible qu’après que les soumissionnaires malheureux, Google et Adesso, ont retiré leurs recours. La souveraineté s’impose ici doublement, techniquement dans la stack et politiquement face aux recours juridiques des grands fournisseurs. Celui qui souhaite proposer une solution souveraine dispose désormais d’un cas de référence, auquel les clients privés peuvent également se référer.

Trois points sont transférables. Premièrement : la souveraineté devient achetable lorsqu’elle est formulée comme un cahier des charges, et non comme une promesse de valeurs. Deuxièmement : l’open source et les interfaces ouvertes sont le moyen le plus efficace contre le verrouillage, y compris dans les contrats privés. Troisièmement : le fournisseur qui combine la maîtrise des clés et une conformité prouvable remporte les clients régulés, et non celui qui dispose du plus gros budget marketing.

Le Deutschland-Stack est donc bien plus qu’un projet gouvernemental. Il constitue le premier test à grande échelle pour vérifier si un cloud souverain peut fonctionner opérationnellement en Allemagne. S’il y parvient, le cahier des charges de l’État deviendra la référence pour tous ceux qui souhaitent vendre des solutions souveraines dans l’espace DACH.

Foire aux questions

Lectures recommandées

• 800 volts en courant continu dans les data centers : le tournant de NVIDIA pour le cloud
• Sauvegarde cloud avec IaC : résilience plutôt que risque de restauration
• Inférence désagrégée : pourquoi AWS et Cerebras séparent le GPU

Plus d’articles du réseau MBF Media

Image de titre : générée par IA (juin 2026)

Images dans l’article : générées par IA (mai 2026)

Source de l’image : générée par IA (Juli 2026)