BSI C3A : La souveraineté dans le cloud devient vérifiable

En avril 2026, le BSI a présenté pour la première fois, avec le catalogue C3A, un référentiel vérifiable pour la souveraineté du cloud. Ainsi, ce qui n’était qu’un terme marketing devient une exigence que l’on peut inscrire dans un appel d’offres. Pour les architectes des PME de la région DACH, c’est une véritable rupture : la souveraineté peut désormais être exigée au même titre que n’importe quelle autre caractéristique technique.

Les points clés en bref

• C3A complète C5 : Là où le célèbre catalogue C5 vérifie la sécurité de l’information, le C3A évalue la souveraineté numérique. La conformité C5 en est le prérequis, sur lequel le C3A vient s’appuyer.
• Six domaines progressifs : De SOV-1 à SOV-6, avec des critères de base et des exigences avancées. Plus le niveau est élevé, plus le contrôle du client sur ses données et ses opérations est important.
• Un outil contre le sovereignty-washing : Inscrire le C3A dans un appel d’offres oblige les fournisseurs à faire des déclarations vérifiables plutôt que de simples promesses publicitaires.

Articles liés :Hyperscaleurs allemands : ceux qui ont de la substance  /  Le verrouillage vacille

Ce que le C3A vérifie au-delà du C5

Le catalogue C5 du BSI est depuis des années la référence en matière de sécurité des services cloud. Il répond à la question de savoir si un fournisseur opère de manière propre et traçable. Ce à quoi il ne répond pas, c’est la question du contrôle : le client peut-il gérer ses données et ses processus indépendamment du fournisseur, même si leurs relations se dégradent ?

C’est précisément cette lacune que comble le C3A, dont le nom complet est Criteria enabling Cloud Computing Autonomy. Le catalogue évalue si une offre cloud peut être utilisée de manière autonome dans son contexte de risque spécifique. Point important pour la pratique : le C3A exige le C5. Un fournisseur qui ne satisfait pas aux exigences de sécurité n’est tout simplement pas éligible à l’évaluation de souveraineté. La version en langue allemande est annoncée pour la fin du deuxième trimestre 2026.

Six domaines de SOV-1 à SOV-6

Le BSI divise la souveraineté en six domaines, de SOV-1 à SOV-6, qui s’appuient les uns sur les autres. Chaque domaine comprend des critères de base et des exigences avancées, identifiés dans le catalogue par les lettres C et AC. Il en résulte un modèle par niveaux, où une offre atteint un degré de maturité défini, du domaine de base jusqu’au niveau d’autonomie le plus élevé.

Pour les architectes, cette gradation constitue le véritable progrès. Elle permet une décision fondée sur les risques. Une charge de travail de développement non critique n’a pas besoin du niveau maximal, contrairement à un traitement impliquant des données particulièrement sensibles. La structure en domaines oblige à se poser honnêtement la question du niveau de souveraineté réellement exigé par un cas d’usage concret.

Comment classer les fournisseurs

La valeur du C3A ne se révèle que dans son application à des offres réelles. Une stack opérée exclusivement en Europe par un fournisseur sans maison mère hors UE atteint d’autres domaines qu’une zone souveraine qu’un hyperscaler américain isole techniquement, mais dont l’opérateur reste soumis à une juridiction non européenne. Les deux peuvent être légitimes. Le C3A rend cette différence visible, au lieu de la reléguer dans les petites lignes des contrats.

Pour les achats, cela signifie que la question n’est plus de savoir si un fournisseur arbore le mot « souverain » dans sa fiche technique. La question est désormais de savoir quel domaine C3A il atteint de manière vérifiable et si ce niveau correspond aux besoins de protection de la charge de travail.

La question de l’autonomie : opérer sans le fournisseur

L’épreuve la plus rude de la souveraineté est une expérience de pensée aux fondements bien réels. Que se passe-t-il si le fournisseur venait à tomber en panne, à résilier le contrat ou à être bloqué légalement ? Le client peut-il maintenir l’exploitation ou migrer sans repartir de zéro ? Les domaines C3A les plus élevés répondent précisément à cette autonomie : maîtrise des clés, portabilité des données et indépendance de l’exploitation.

Dans la pratique, l’autonomie échoue rarement en raison de la technique, mais souvent à cause des formats et des contrats. Quiconque intègre profondément des formats de données propriétaires et des services gérés exclusifs dans sa propre architecture perd sa souveraineté, quoi qu’en dise le certificat. Le C3A fournit ici le vocabulaire pour identifier précocement de telles dépendances.

Check-list pour les architectes avant l’appel d’offres

Trois étapes permettent d’exploiter le C3A en interne. Premièrement : déterminer le besoin de protection par classe de charge de travail et en déduire le domaine de souveraineté requis. Deuxièmement : inscrire le domaine comme critère contraignant dans l’appel d’offres et exiger une preuve, et non une simple déclaration sur l’honneur. Troisièmement : penser la sortie dès le départ, c’est-à-dire sécuriser contractuellement les formats de données, la maîtrise des clés et le chemin de migration.

Les fournisseurs qui investissent tôt dans les audits C3A se procurent un avantage précisément dans les appels d’offres réglementés qui vont se multiplier en 2026. Pour les achats, le catalogue est un filtre ; pour le fournisseur, un ticket d’entrée.

Foire aux questions

Les conseils de lecture de la rédaction

• Hyperscaler allemand : qui a vraiment du poids
• Les infrastructures critiques dans le cloud : sécuriser la migration
• AWS et Azure sous surveillance de l’UE : le verrouillage s’émousse

Plus d’articles du réseau MBF Media

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