By Olivier B in Confiance numérique — 9 juil. 2026

#6 bis Zoom : le C3A allemand et le paysage fragmenté des certifications cloud souverain en Europe

🇩🇪 L'Allemagne vient de publier le C3A : 6 critères vérifiables pour mesurer l'autonomie réelle d'un cloud — pas juste sa sécurité. Clause la plus spectaculaire ? En cas d'état de défense, l'État peut reprendre la main sur l'infra cloud, code source inclus. SecNumCloud + C3A, même combat. 🔐

Série « Souveraineté numérique » — Comprendre le C3A et ses voisins réglementaires

Le 27 avril 2026, le BSI — l'agence fédérale allemande de cybersécurité, homologue de l'ANSSI — publiait un document de 30 pages au nom austère mais à l'ambition considérable : les C3A, Criteria enabling Cloud Computing Autonomy.

Pour la première fois, un État membre de l'Union européenne traduisait en critères techniques vérifiables ce que le Cloud Sovereignty Framework de la Commission (décrit dans l'article #6 de cette série) avait posé en principes.

Et pour la première fois aussi, un référentiel national osait inscrire une clause que peu d'observateurs attendaient : en cas d'état de défense déclaré par un État membre de l'UE, le prestataire cloud doit permettre à l'administration de reprendre le contrôle opérationnel complet de l'infrastructure — personnel, code source et outils d'administration inclus.

Cet article propose un zoom approfondi sur le C3A : ce qu'il contient précisément, comment il se positionne par rapport au C5 (son prédécesseur sécuritaire), et surtout comment il s'inscrit dans un paysage européen de certifications cloud déjà passablement fragmenté — SecNumCloud, C5, ENS, EUCS — dont le lecteur de cette série a déjà croisé les grandes lignes dans les articles précédents.

Pourquoi le C5 ne suffisait plus

Pour comprendre l'apport du C3A, il faut d'abord comprendre la limite structurelle du C5 — le référentiel de sécurité cloud allemand existant depuis 2016, déjà présenté dans cette série.

Le C5 confirme que la porte d'entrée est verrouillée. Il ne dit rien sur qui détient le second jeu de clés, ni si le propriétaire de l'immeuble peut couper unilatéralement l'accès.

C'est une image efficace pour saisir la différence de nature entre les deux référentiels : le C5 répond à la question "ce service est-il sécurisé techniquement ?", tandis que le C3A répond à la question "ce service peut-il être utilisé de manière autonome, indépendamment d'un acteur tiers, dans un contexte de risque donné ?"

Ce sont deux questions différentes, et c'est précisément leur confusion qui a alimenté, comme le précédent article l'a montré, le décalage entre la Forrester Wave (qui mesure une forme de souveraineté fonctionnelle proche du C5) et le Cloud Sovereignty Framework de la Commission (qui mesure une souveraineté juridictionnelle et stratégique).

Le C3A : six dimensions, pas huit

Le C3A reprend la structure du Cloud Sovereignty Framework européen (SOV-1 à SOV-8, détaillé dans l'article #6), mais en écarte volontairement deux objectifs.

SOV-7 (Sécurité et conformité)

Il n'est pas repris car déjà couvert par les publications existantes du BSI — le C5:2026, l'IT-Grundschutz (le référentiel allemand de sécurité des systèmes d'information) et le HA Benchmark compact.
Le C3A présuppose explicitement que le prestataire satisfait déjà aux critères du C5 — c'est une condition préalable, pas une option.

SOV-8 (Durabilité environnementale)

Il n'est pas repris car hors du périmètre de responsabilité du BSI, qui est une agence de cybersécurité et non une agence environnementale.

Restent donc six dimensions : souveraineté stratégique, juridique, des données et de l'IA, opérationnelle, de la chaîne d'approvisionnement, et technologique.

Sur chacune, le BSI introduit des critères vérifiables par audit, répartis en deux catégories :

les critères (exigences de base)
les critères additionnels (exigences renforcées, pour les usages les plus sensibles),

accompagnés d'informations complémentaires explicatives.

Les dispositions les plus marquantes du C3A

Le double prisme UE/Allemagne

C'est l'innovation méthodologique la plus distinctive du C3A par rapport au Cloud Sovereignty Framework européen.
Sur plusieurs critères clés — la juridiction applicable, la localisation du siège social, le contrôle effectif, ou encore la localisation du stockage des données client — le BSI propose systématiquement deux niveaux d'exigence au choix :

un niveau "UE" : le prestataire ou la donnée doit relever du droit ou du territoire de l'Union européenne
un niveau "Allemagne" : exigence resserrée au seul territoire et droit allemand.

Cette approche à la carte permet à un acheteur public ou privé de calibrer précisément son niveau d'exigence selon la criticité réelle de son usage — une administration fédérale gérant des données de défense pourra exiger le niveau "Allemagne", tandis qu'une collectivité locale pourra se satisfaire du niveau "UE".

Le critère de contrôle effectif est défini avec précision : la possibilité d'exercer une influence directe ou indirecte sur les décisions stratégiques, financières ou opérationnelles clés du prestataire — une définition qui rejoint celle de SecNumCloud sur l'absence de contrôle capitalistique non-européen.

La transparence sur la chaîne d'approvisionnement logicielle

Le C3A impose au fournisseur d'identifier, service par service, l'ensemble des composants logiciels utilisés et leurs pays d'origine, sous forme de liste disponible sur demande — éventuellement sous accord de confidentialité.

L'objectif est qu'un client puisse savoir si un service cloud repose sur des composants d'origine américaine, chinoise ou autre, et en évaluer le risque souverain en connaissance de cause.

Un critère additionnel va plus loin en exigeant une flexibilité architecturale permettant de substituer des composants critiques en cas de besoin.

Cette exigence répond directement à l'objectif SOV-5 (chaîne d'approvisionnement) du Cloud Sovereignty Framework — celui qui pèse le plus lourd dans le score de souveraineté européen (20 %).

Le critère de continuité en cas de coupure — la réponse opérationnelle au risque de kill switch

Le critère technique SOV-4-09-C exige qu'un service cloud conserve son intégrité et sa disponibilité même en cas d'interruption de la connexion avec des instances non-européennes.

Les entreprises qui revendiquent ce niveau de souveraineté sont soumises à une obligation de contrôle annuel, avec une preuve technique que l'instance locale reste capable de fonctionner de manière autonome.

C'est la traduction technique la plus aboutie, à ce jour dans un référentiel officiel d'un État membre, du risque de "kill switch" documenté par le rapport FOTI et déjà longuement discuté dans l'article #2 de cette série.

Là où le rapport FOTI se contentait de documenter le risque, le C3A propose un test vérifiable pour s'en protéger.

La clause d'état de défense

C'est la disposition la plus commentée — et la plus inattendue — du C3A.

Si un État membre de l'UE déclare l'état de défense, le prestataire cloud doit permettre à l'État de reprendre la main sur l'exploitation du cloud, avec les actifs physiques et le personnel nécessaires, dans la limite des possibilités légales.

Concrètement, le fournisseur doit maintenir en permanence une documentation, un code source et des outils d'administration dans un format portable, utilisables de manière autonome par une autorité étatique du jour au lendemain.

C'est, en substance, une clause de réquisition numérique en temps de guerre appliquée à des acteurs privés.
Sa portée est toutefois tempérée par une réserve significative : elle ne s'applique que dans les limites de ce que le droit national permet déjà — le C3A ne crée pas de nouveau pouvoir régalien, il structure juridiquement et techniquement l'exercice d'un pouvoir que l'État possède déjà en théorie.

La granularité des données

Le C3A distingue trois catégories :

les données client : les données métier proprement dites,
les données de compte : informations de facturation, de contact, générées à l'achat du service et sous contrôle du prestataire,
les données dérivées : résultant de l'interaction avec les services cloud — logs, métadonnées d'usage.

Pour les données client, deux niveaux de localisation du stockage et du traitement sont proposés, là encore au choix : UE ou Allemagne.

Cette granularité est précieuse pour les responsables de la protection des données (DPO) : elle oblige à raisonner sur la nature et la sensibilité de chaque flux de données, plutôt que sur un volume total indifférencié — une amélioration notable par rapport à des approches plus binaires.

✏️ Le chiffrement à clé externalisée

Le C3A ajoute un critère de chiffrement des données client avec une clé disponible exclusivement en dehors de l'environnement du fournisseur de service cloud (CSP).
C'est une exigence directement comparable au mécanisme évoqué dans l'article #2 à propos des HSM externalisés — avec la même contrepartie déjà identifiée : si la gestion des clés est déléguée à un tiers externe, le CSP ne maîtrise plus entièrement ses propres engagements de continuité de service.

Une genèse concertée avec l'industrie, pas un diktat administratif

Le C3A n'a pas été élaboré dans un bureau fermé.
Le BSI a collaboré avec des fournisseurs de cloud nationaux et internationaux avec lesquels il entretient des accords de coopération — incluant, d'après les informations disponibles, des échanges avec des acteurs comme Google Cloud, dont les retours d'expérience pratique ont directement nourri le référentiel.

Le résultat de cette concertation s'observe dans le réalisme de certaines dispositions : l'aveu du BSI selon lequel l'option de localisation nationale du stockage "est plus rare pour le SaaS", mais "devrait être proposée si c'est techniquement faisable et approprié", illustre un pragmatisme qui tranche avec une approche purement déclarative de la souveraineté.

Cette méthode de coproduction avec l'industrie distingue le C3A de certaines lectures plus dogmatiques du débat sur la souveraineté numérique — sans pour autant renoncer à l'ambition normative, comme le montre la clause d'état de défense.

Le C3A dans le paysage européen des référentiels : une cartographie

Si vous avez lu les précédents articles de cette série, vous avez désormais croisé six référentiels ou cadres distincts.

Une cartographie comparative s'impose pour clarifier leurs rôles respectifs.

Référentiel	Pays / Portée	Nature	Couvre la souveraineté juridictionnelle ?	Contraignant ?
SecNumCloud 3.2	France	Référentiel national, ANSSI	Oui (article 19.6)	Oui pour OIV/OSE et marchés sensibles
BSI C5:2026	Allemagne	Référentiel sécurité technique	Non	Oui pour la santé (Code social)
BSI C3A	Allemagne	Référentiel souveraineté/autonomie	Oui (double prisme UE/Allemagne)	Non, mais déclarable en exigence minimale
ENS (Esquema Nacional de Seguridad)	Espagne	Référentiel sécurité technique	Non	Oui pour l'administration publique
EUCS	Union européenne	Schéma de certification harmonisé (en négociation)	En débat — nœud du conflit décrit dans l'article #6	À déterminer selon la version finale
Cloud Sovereignty Framework	Union européenne (Commission)	Outil contractuel d'achat public	Oui (8 objectifs SOV)	Appliqué aux marchés de la Commission

Ce tableau récapitulatif révèle une logique claire, déjà esquissée dans l'article #6 mais que la publication du C3A permet désormais d'illustrer concrètement : chaque État membre ayant une doctrine affirmée de souveraineté numérique tend à se doter de deux référentiels complémentaires :

un référentiel de sécurité technique (C5 pour l'Allemagne, et pour la France un équivalent intégré dans SecNumCloud)
un référentiel de souveraineté proprement dit (le C3A pour l'Allemagne, l'article 19.6 de SecNumCloud pour la France).

SecNumCloud et C3A : convergence ou divergence ?

C'est certainement la question que vous vous posez naturellement, en tant que lecteurs français de cette série.

Trois éléments de réponse.

Sur le fond, une forte convergence.
Les deux référentiels poursuivent le même objectif — garantir qu'un service cloud reste utilisable de manière autonome, sans dépendance critique à un acteur extra-européen — et s'appuient tous deux, explicitement ou implicitement, sur la même matrice de référence : le Cloud Sovereignty Framework de la Commission.

Le critère de contrôle capitalistique du C3A rejoint très directement l'article 19.6 de SecNumCloud sur l'absence de contrôle non-européen.

Sur la méthode, une différence d'approche notable.
SecNumCloud reste structuré comme un référentiel de qualification binaire — une offre est qualifiée SecNumCloud ou ne l'est pas, avec un référentiel unique et exigeant.

Le C3A introduit une logique plus modulaire et graduée : critères de base, critères additionnels, et surtout le double choix UE/Allemagne qui permet d'ajuster le niveau d'exigence à la criticité réelle de l'usage.

Cette modularité pourrait inspirer une évolution de SecNumCloud, dont l'ANSSI travaille déjà sur la prochaine version, avec un alignement attendu sur le Cloud Sovereignty Framework européen.

Sur la portée institutionnelle, une différence de statut.
SecNumCloud peut être rendu obligatoire par la réglementation française pour certains secteurs (santé via l'hébergement de données de santé ou la défense par exemple).

Le C3A, comme le rappelle son propre vice-président, n'est pas contraignant en lui-même, mais peut devenir la référence pour l'administration fédérale allemande via son intégration dans les obligations existantes de l'IT-Grundschutz et de la norme MST-NCD (norme minimale pour l'utilisation de services cloud externes) pour les agences fédérales.

L'enjeu pour les entreprises sous NIS2

Le C3A prend une dimension particulièrement concrète pour les entreprises soumises à la directive européenne NIS2 — déjà mentionnée dans cette série à propos de la sécurité de la chaîne d'approvisionnement.

L'article 21 de NIS2 impose aux entreprises concernées de garantir la sécurité de leur chaîne d'approvisionnement.
Toute organisation qui utilise des services cloud doit désormais être en mesure de démonstrer comment elle évalue sa dépendance à des juridictions non-européennes et les risques associés — au premier rang desquels le CLOUD Act américain.

Pour ces organisations, le C3A — bien que non contraignant en tant que tel pour le secteur privé — fournit une base méthodique pour identifier et évaluer systématiquement les dépendances dans la chaîne d'approvisionnement numérique, et peut être utilisé comme grille d'exigences dans les appels d'offres ou pour répondre aux obligations de vigilance du dispositif de gestion des risques imposé par NIS2.

Ce que cela signifie pour la suite du cadre réglementaire européen

La publication du C3A intervient à un moment charnière.

Comme vu précédemment, l'EUCS reste bloqué depuis 2020 sur la question précise de l'inclusion de critères de souveraineté juridictionnelle.
Le C3A allemand, en complément de SecNumCloud français, constitue désormais un second précédent national concret et documenté.

Si ces critères venaient à être incorporés dans les annexes de textes de sécurité informatique comme NIS2 ou dans le futur Cybersecurity Act révisé associé au Cloud and AI Development Act (CAIDA) européen — déjà évoqué dans l'article #3 à propos de l'alliance ESTIA — il deviendrait difficile pour les hyperscalers américains de continuer à les contourner par une approche uniquement fonctionnelle de la souveraineté.

La question de savoir si les grands hyperscalers pourront satisfaire ces critères dépendra largement des exigences réelles formulées par leurs clients, et de la pression politique en faveur de solutions véritablement souveraines.

C'est une formulation prudente, mais qui résume bien l'enjeu central de cette série d'articles : le cadre réglementaire se construit, les outils de mesure existent désormais, mais leur portée effective dépendra in fine des choix d'achat — publics et privés — qui seront réellement faits dans les mois et années à venir.

📌 En Conclusion

Le C3A allemand (du 27 avril 2026) est la traduction opérationnelle la plus aboutie à ce jour du Cloud Sovereignty Framework européen, dans un État membre.

Il reprend 6 des 8 objectifs SOV de la Commission, en écartant la sécurité (déjà couverte par le C5) et la durabilité environnementale (hors périmètre du BSI).

Ses apports les plus innovants :

un double niveau d'exigence UE/Allemagne sur les critères clés, un critère technique vérifiable de continuité en cas de coupure avec des instances non-européennes (réponse directe au risque de kill switch),
une exigence de transparence sur la chaîne d'approvisionnement logicielle,
une clause inédite de réquisition numérique en cas d'état de défense.

Le paysage européen des référentiels cloud reste fragmenté entre SecNumCloud (France), C5 et C3A (Allemagne), ENS (Espagne), en attendant une éventuelle harmonisation via l'EUCS — dont l'issue dépendra largement de la capacité des États membres à dépasser le clivage entre souveraineté fonctionnelle et souveraineté juridictionnelle.

Pour les entreprises soumises à NIS2, le C3A constitue, qu'il soit ou non rendu obligatoire, un outil méthodique immédiatement exploitable pour structurer l'évaluation des dépendances de leur chaîne d'approvisionnement numérique.