Migration KRITIS vers le cloud : ce qui garantit la securite
Les operateurs KRITIS migrent leurs systemes sensibles vers le cloud. La reussite depend de la conformite, disponibilite et certification C5.
À partir du 17 mars 2026, le KRITIS-Dachgesetz (loi-cadre allemande sur les infrastructures critiques) entre en vigueur. Quiconque transfère dès à présent des systèmes sensibles vers le cloud doit intégrer dès le départ la disponibilité, la souveraineté des données et l’obligation de preuve. C’est la migration qui déterminera si l’audit ultérieur se résumera à une simple formalité ou se transformera en véritable chantier.
L’essentiel en bref
- Le cercle s’agrandit : Plus de 30.000 entreprises sont désormais soumises à des obligations de sécurité élargies depuis la loi de transposition NIS2, dont beaucoup se classent pour la première fois comme entité importante ou particulièrement importante.
- C5 se durcit : Le nouveau catalogue de critères C5:2026 compte 168 critères au lieu de 121 jusqu’ici et réglemente pour la première fois explicitement les conteneurs, la chaîne d’approvisionnement et le Confidential Computing. Il deviendra obligatoire à partir du 1. Juni 2027.
- L’ordre prime sur la vitesse : Celui qui clarifie le niveau de protection requis avant de choisir son fournisseur évite des reconstructions coûteuses. L’architecture et le plan de sortie déterminent si la migration reste un fardeau de conformité ou devient un gain en résilience.
Connexe :La puce cloud bon marché au retour coûteux / Ingress-NGINX est abandonné : la voie vers la Gateway API
D’abord le besoin de protection, puis le fournisseur
Qu’est-ce que KRITIS ? Sont considérées comme infrastructures critiques les installations dont la défaillance met en danger l’approvisionnement de la population, par exemple dans les domaines de l’énergie, de l’eau, de la santé, des finances ou des transports. Leurs exploitants sont soumis à des obligations particulières en matière de sécurité et de déclaration. Depuis la loi de transposition de la NIS2 (NIS2-Umsetzungsgesetz) et la loi-cadre KRITIS (KRITIS-Dachgesetz), cela concerne nettement plus d’entreprises qu’auparavant.
La séquence la plus courante est aussi la plus coûteuse : choisir d’abord l’hyperscaler, puis se demander ce qu’il faut réellement protéger. Pour les opérateurs d’infrastructures critiques, l’ordre s’inverse. Tout commence par la classification de chaque workload selon son besoin de protection, sa criticité pour la mission d’approvisionnement et son temps de redémarrage. Un système de facturation contenant des données personnelles n’a pas le même niveau d’exigence qu’un wiki interne. C’est précisément cette distinction qui détermine ensuite le modèle de déploiement.
Concrètement, il s’agit de répartir les données et les services en trois classes. Ce qui peut aller dans une région publique, ce qui doit rester dans un environnement souverain et ce qui, pour l’instant, demeure dans le propre centre de données. Celui qui établit cette carte avant le premier ticket de migration négocie avec le fournisseur sur la base d’exigences concrètes plutôt que de présentations marketing.
Résidence des données : Où les workloads se trouvent-ils réellement
Une région de l’UE dans un menu déroulant ne constitue pas une preuve de souveraineté des données. Ce qui compte, c’est de savoir qui, techniquement et juridiquement, peut accéder aux données, dans quel pays est établi l’opérateur et si le support ou la maintenance provient de pays tiers. Pour les workloads sensibles relevant des infrastructures critiques (KRITIS), les questions essentielles sont les suivantes : la clé est-elle détenue par le fournisseur ou par le client ? L’accès du prestataire peut-il être techniquement exclu, par exemple via du Confidential Computing ou des clés gérées par le client ?
Le C5:2026 prend ces points nettement plus au sérieux que son prédécesseur. Avec 168 critères au lieu de 121, le catalogue aborde pour la première fois la gestion des conteneurs, les chaînes d’approvisionnement et le Confidential Computing comme blocs d’exigences distincts. Pour la migration, cela signifie que la résidence des données est un sujet d’architecture qui relie chiffrement, gestion des clés et modèle opérationnel. Une simple case à cocher dans le formulaire d’achat ne suffit pas.
Un C5-Testat ouvre la porte, et rien de plus
Un C5-Testat du fournisseur constitue souvent le sésame pour les achats liés aux infrastructures critiques (KRITIS). Il atteste que le prestataire respecte le catalogue, mais ne dit rien sur l’utilisation effective de cette sécurité dans la configuration propre. La sécurité cloud est une responsabilité partagée : le fournisseur livre la plateforme certifiée, l’opérateur configure les identités, la segmentation réseau et la journalisation. Un testat parfait ne protège pas contre un bucket de stockage ouvert.
Dans le choix du fournisseur, une comparaison sobre des modèles d’exploitation s’impose. Chacun trouve sa place selon la classe de besoin de protection définie à l’étape un.
| Modèle d’exploitation | Adéquation KRITIS | Compromis |
|---|---|---|
| Cloud public, région UE | Moyen à élevé, selon la souveraineté des clés | Scalabilité contre accès du fournisseur et risque de pays tiers |
| Cloud souveraine | Élevée, exploitation et personnel locaux | Souveraineté des données contre catalogue de services plus restreint et coûts plus élevés |
| Hybride avec cœur propre | Élevée pour les workloads les plus critiques | Contrôle total contre charge opérationnelle et intégration lourde |
Le plan de sortie décide de la disponibilité
La disponibilité porte chez les opérateurs KRITIS (infrastructures critiques) la mission d’approvisionnement. Si le service tombe, l’approvisionnement s’effondre. Une migration cloud n’améliore la résilience que si le plan de panne précède celui du fonctionnement normal. Tout commence par le verrouillage : à quelle vitesse peut-on basculer un service vers un second fournisseur ou le rapatrier dans son propre centre de données si le prestataire tombe en panne, si les prix s’envolent ou si une autorité l’exige ?
Qui s’appuie sur des briques portables pour ses services critiques – conteneurs et interfaces standardisées plutôt que services managés propriétaires – garde la porte de sortie ouverte. Le multi-cloud ne se justifie vraiment que lorsque la défaillance d’un fournisseur met en cause la mission d’approvisionnement. Pour les services non critiques, cela reste un surcoût inutile.
L’audit commence avant la migration
La preuve de conformité révèle la qualité – ou les failles – d’une architecture. Les entités concernées doivent s’enregistrer auprès du BSI (Bundesamt für Sicherheit in der Informationstechnik). Avec le KRITIS-Dachgesetz, qui renforce la résilience physique des infrastructures critiques en Allemagne, s’ajoute une seconde inscription auprès du BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe), dont l’échéance est fixée au 17 juillet 2026. Reporter la journalisation, l’inventaire des actifs et les processus d’incident après la migration, c’est documenter des lacunes plutôt que démontrer un contrôle effectif.
Il faut donc intégrer la démonstration de conformité dès la planification de la migration : journalisation centralisée, registre tenu à jour des services externalisés et circuits de notification clairs dès le premier jour. L’audit final se résumera alors à l’extraction d’un rapport issu du fonctionnement courant.
Questions fréquentes
Les opérateurs d’infrastructures critiques (KRITIS) peuvent-ils transférer des données sensibles vers le cloud public ?
Il n’existe pas d’interdiction générale. Tout dépend du niveau de protection requis, de la maîtrise des clés de chiffrement et d’un modèle d’exploitation qui limite l’accès du fournisseur. Les charges de travail hautement critiques sont plutôt hébergées dans des environnements souverains ou hybrides, tandis que les services moins sensibles peuvent tourner dans une région européenne avec des clés conservées par le client.
Un rapport C5 du fournisseur suffit-il pour assurer la conformité ?
Ce document constitue une condition préalable à de nombreux appels d’offres, mais il ne remplace pas une vérification interne. Le rapport porte sur l’état de certification chez le fournisseur. Celui qui l’utilise doit en examiner le périmètre : quels services, quelles régions et quelle date de référence sont couverts ? Aucun fournisseur ne vérifie la configuration propre du client.
Que change le C5:2026 par rapport à la version précédente ?
Le catalogue passe de 121 à 168 critères et encadre pour la première fois de manière explicite la gestion des conteneurs, la sécurité de la chaîne d’approvisionnement, la cryptographie post-quantique et le Confidential Computing. Le suivi et la gestion des incidents sont renforcés. Le C5:2026 devient obligatoire à partir du 1er juin 2027 ; une mise en œuvre anticipée est recommandée.
Dans quel délai les entités concernées doivent-elles s’enregistrer ?
L’enregistrement auprès du BSI doit intervenir au plus tard trois mois après qu’une entreprise entre pour la première fois dans le champ d’application. Pour la résilience physique prévue par la loi-cadre KRITIS, un enregistrement supplémentaire auprès du BBK est requis, avec une échéance fixée au 17 juillet 2026.
Pourquoi le plan de sortie est-il si important lors d’une migration KRITIS ?
Un fournisseur unique devient lui-même un risque dans l’environnement KRITIS. Sans procédure de retour éprouvée, une panne chez le fournisseur ou une résiliation de contrat allonge directement le temps d’indisponibilité. Le plan de sortie doit être testé : un exercice régulier permet de vérifier que le retour s’effectue dans le délai de reprise prévu.
Conseils de lecture de la rédaction
La loi-cadre KRITIS rencontre NIS2 et la mise à niveau C5
Coûts de conformité : l’architecture fait la différence
FinOps : réduire de 30 % les coûts du cloud, un objectif réaliste
Autres contenus du réseau MBF Media
À partir de quand l’horloge des délais de déclaration commence-t-elle vraiment à tourner
Source de l’image : généré par IA (juin 2026)
