Souveraineté numérique : SecNumCloud vs APPI, comment on navigue.

Vous êtes CIO d'un groupe avec des activités en France, au Japon et en Amérique du Nord. Côté Paris, votre DPO réclame du SecNumCloud et des données hébergées à Roubaix. Côté Tokyo, votre legal vous parle de l'APPI révisée et du Economic Security Promotion Act, mais accepte AWS Tokyo. Côté Montréal, on vous parle de la Loi 25. Bienvenue dans le casse-tête de la souveraineté multi-juridictions.

France : SecNumCloud comme dogme

Depuis le SREN et la circulaire "Cloud au centre", SecNumCloud devient quasi obligatoire pour tout ce qui touche aux données sensibles publiques ou de santé. L'ANSSI ne plaisante pas : les fournisseurs hyperscalers américains, même via des partenariats (Bleu, S3NS), ne sont pas qualifiés à date. Vous arbitrez entre OVH SecNumCloud, Outscale, Scaleway. Réduit, mais clair.

Japon : pragmatisme apparent, exigences cachées

Le Japon n'a pas d'équivalent SecNumCloud strict. AWS Tokyo, Azure Japan East, GCP Tokyo sont largement utilisés, y compris par des banques. Mais l'Economic Security Promotion Act (2022) classe certains secteurs en "infrastructure critique" : finance, énergie, télécoms, transport. Pour ceux-là, des exigences de localisation et d'audit s'appliquent, plus floues mais bien réelles. L'APPI 2022 ajoute des contraintes sur les transferts internationaux de données personnelles, similaires au RGPD mais pas identiques.

L'architecture hybride qui passe les deux audits

Nous avons construit pour un client industriel franco-japonais (3 000 personnes, opérations dans les deux pays) une architecture qui satisfait simultanément l'ANSSI et le METI. Les principes :

• Séparation stricte des données par juridiction. Les données françaises restent en France (Outscale Cloud Gouv), les données japonaises restent au Japon (AWS Tokyo + chiffrement KMS local).
• Plan de contrôle unifié, plan de données fédéré. Une seule console d'administration (hébergée dans un cloud souverain européen), zéro flux de données opérationnel cross-region.
• Chiffrement E2E avec clés détenues par le client. AWS KMS Custom Key Store côté Japon, Atos Trustway côté France. Aucun fournisseur cloud ne peut lire en clair.
• Audit trail centralisé via OpenTelemetry, anonymisé et exporté dans un SIEM hébergé en Suisse pour neutralité juridictionnelle.

Le code de la conformité

hcl
# OpenTofu : provisioning multi-region avec contraintes souveraines
module "data_plane_fr" {
  source   = "./modules/sovereign-fr"
  provider = outscale.eu_west_2
  
  data_classification = "RESTRICTED_FR"
  encryption_kms      = var.atos_trustway_key_arn
  audit_export        = "siem-eu-only"
}

module "data_plane_jp" {
  source   = "./modules/sovereign-jp"
  provider = aws.ap_northeast_1
  
  data_classification = "APPI_PERSONAL"
  encryption_kms      = var.aws_kms_jp_cks_arn
  cross_border_transfer = false  # Hard constraint
}

GDPR + Japan Supply Chain Security : ce qu'il faut savoir

Depuis 2024, le Japon a renforcé ses exigences sur la chaîne d'approvisionnement logicielle (Supply Chain Security Guidelines, METI). Concrètement, vous devez documenter chaque dépendance open-source, chaque sous-traitant, chaque service tiers. Cela rejoint le SBOM (Software Bill of Materials) imposé par la Cyber Resilience Act européenne. Bonne nouvelle : faire les deux en même temps coûte 1.2x, pas 2x.

Les arbitrages que personne ne veut faire

Vouloir SecNumCloud strict ET AWS Bedrock pour les LLMs ET la performance d'un CDN global : c'est incompatible. Les CIO qui réussissent sont ceux qui acceptent de classer leurs données par criticité réelle, pas par paranoïa générique. 80 % des données d'une entreprise n'ont pas besoin de SecNumCloud. Les 20 % restants, oui, et ces 20 % méritent une architecture dédiée.

Si vous opérez sur plusieurs juridictions et que votre matrice de conformité tient sur trois Excel non synchronisés, nos équipes franco-japonaises ont déjà conçu et fait certifier ce type d'architecture. Discutons-en avant le prochain audit.