Vendre des logiciels aux infrastructures critiques japonaises

Ce qui a changé le 1er octobre 2026

Ces deux évolutions sont souvent présentées comme une seule, mais elles n'ont ni la même base juridique ni les mêmes destinataires.

	Loi sur la cyberdéfense active	Normes unifiées
Nature	Loi n° 42 de 2025, en japonais サイバー対処能力強化法	Une norme arrêtée par le Cybersecurity Strategic Headquarters le 31 juillet 2026
Destinataires	Exploitants désignés d'infrastructures fondamentales (基幹インフラ)	Les administrations publiques et, par leur intermédiaire, les exploitants de 16 secteurs d'infrastructures critiques
Ce qui est demandé	Notifier les actifs clés et signaler les incidents au gouvernement	Des mesures de sécurité transversales, de la gouvernance et du risque lié à la chaîne d'approvisionnement à la gestion des vulnérabilités
Force contraignante	Obligations légales assorties de sanctions	Non exécutoires par elles-mêmes. Elles atteignent les exploitants par le biais des normes de sûreté de chaque secteur

Les 16 secteurs sont l'information et les communications, la finance, l'aviation, les aéroports, les chemins de fer, l'électricité, le gaz, les services gouvernementaux, les services médicaux, l'eau, la logistique, la chimie, le crédit, le pétrole, les ports et les services postaux.

En parallèle de ces normes, le National Cybersecurity Office japonais a publié des lignes directrices pour la rédaction de ces normes de sûreté, elles aussi en vigueur depuis le 1er octobre. C'est le document le plus utile pour un fournisseur, car il détaille ce que l'on attend des exploitants vis-à-vis des entreprises auprès desquelles ils achètent.

Pourquoi cela concerne les fournisseurs

Les obligations pèsent sur l'exploitant : l'effet sur vous est donc commercial plutôt que juridique. Il prend la forme de clauses contractuelles, de critères d'achat et de questionnaires. Ce qui s'applique à un client donné dépend de son secteur et de ses propres normes de sûreté : interrogez donc le client plutôt que de présumer.

Les Normes unifiées demandent aux exploitants de comprendre comment leurs systèmes critiques dépendent de la chaîne d'approvisionnement, de connaître le niveau de sécurité de leurs fournisseurs et de fixer des exigences de sécurité lorsqu'ils achètent des produits et des services. Les lignes directrices traduisent cela en points précis.

Ce que les exploitants peuvent vous demander

Les lignes directrices distinguent les mesures que les exploitants devraient prendre de celles qui sont souhaitables. Le tableau présente les deux, avec la part des preuves qui peut provenir de votre build.

Ce que décrivent les lignes directrices	Niveau	Preuves issues du build
Des exigences de sécurité inscrites dans les contrats, avec des exemples comme la façon dont les vulnérabilités graves sont traitées et signalées (2.9 ②-2)	À prendre	Une trace de chaque vulnérabilité, du tri à la version corrigée
Les fournisseurs de systèmes achetés signalent, traitent et divulguent les vulnérabilités dans le cadre du contrat de maintenance (3.6 ①-2)	À prendre	La surveillance continue de ce que vous avez livré, et les versions touchées par chaque vulnérabilité
Un moyen de partager rapidement l'information avec le fournisseur lorsqu'une vulnérabilité ou un incident est découvert (2.9 ③-3)	À prendre	Un historique des builds qui montre quelles versions contiennent un paquet
Lorsque l'achat exige de la transparence, demander au fournisseur de créer et de fournir une SBOM (2.9 ③-4)	Souhaitable	Une SBOM de chaque build, exportée en CycloneDX ou SPDX
Vérifier que le fournisseur développe selon des pratiques de développement logiciel sécurisé (2.9 ③-4)	Souhaitable	Des jobs de build isolés et une politique de trafic sortant appliquée

Le Japon exige-t-il une SBOM ?

Pas au titre des Normes unifiées, qui ne mentionnent pas les SBOM. Les lignes directrices les citent comme une option : un exploitant qui a besoin de transparence dans ses achats peut demander à un fournisseur d'en créer et d'en fournir une, et elles renvoient au guide SBOM du METI, version 2.0. Il vaut sans doute quand même la peine de répondre à une telle demande, car un contrat peut rendre une option contraignante pour vous.

Ce que votre client peut aussi regarder

• L'évaluation par un tiers. Les lignes directrices suggèrent de recourir à des évaluations externes pour alléger le travail de vérification des fournisseurs. Elles citent l'évaluation de conformité ISMS et le dispositif d'évaluation SCS du METI et du National Cybersecurity Office, dont le démarrage est prévu vers la fin de l'exercice budgétaire japonais 2026.
• Les dispositifs pour produits et services. Elles orientent aussi les exploitants vers JC-STAR pour les produits IoT, ISMAP pour les services cloud et JISEC pour les produits informatiques lorsqu'ils fixent leurs critères de sélection.
• Les évaluations de vulnérabilités. Les exploitants évaluent périodiquement leurs propres systèmes, et les clauses contractuelles peuvent étendre l'évaluation et le signalement à votre entreprise.
• Les clauses sur les données. Les contrats peuvent préciser où les données sont situées, stockées, conservées, transférées et éliminées.

Ce que cela signifie si vous vous préparez déjà au CRA

Une grande partie du travail est réutilisable. Le Cyber Resilience Act de l'UE est un régime distinct assorti de ses propres obligations : le respecter ne satisfait donc pas ce que demande un client japonais. Mais les deux reviennent aux mêmes questions : que contient le logiciel que vous avez livré, quelles versions une vulnérabilité touche-t-elle et qu'avez-vous fait à ce sujet ? Si ces réponses proviennent de votre build, vous pouvez les réutiliser pour un client japonais au lieu de les rassembler à nouveau.

La place de CRACI

CRACI enregistre ce que chaque job GitHub Actions a réellement récupéré et produit une SBOM à partir du build, puis surveille ce qui a été livré et suit les vulnérabilités, du tri à une version corrigée. Vous disposez ainsi de preuves pour les demandes du tableau ci-dessus.

CRACI ne couvre qu'une partie de ce qu'un exploitant peut attendre. CRACI ne réalise ni évaluations de vulnérabilités ni tests d'intrusion, ne corrige pas les systèmes déployés et ne fait aucun signalement aux autorités japonaises. CRACI ne vous rend conforme à aucune norme sectorielle. CRACI est hébergé en Europe et ISO/IEC 27001 est sa seule certification : vérifiez donc ces deux points au regard des clauses sur les données et des critères de sélection de votre client.

Infrastructures critiques au Japon : questions fréquentes

La loi japonaise sur la cyberdéfense active s'applique-t-elle aux éditeurs de logiciels étrangers ?

Ses obligations de notification et de signalement des incidents pèsent sur les exploitants d'infrastructures désignés. Un fournisseur la ressentira plutôt à travers ce que ces clients demandent dans leurs contrats : vérifiez donc auprès du client et de votre conseiller juridique.

Les Normes unifiées sont-elles obligatoires ?

Pas par elles-mêmes. Elles s'adressent principalement aux administrations publiques et définissent ce que les normes de sûreté sectorielles devraient contenir : ce qui lie un exploitant dépend donc de son secteur.

Quels sont les secteurs concernés ?

Il y en a seize : l'information et les communications, la finance, l'aviation, les aéroports, les chemins de fer, l'électricité, le gaz, les services gouvernementaux, les services médicaux, l'eau, la logistique, la chimie, le crédit, le pétrole, les ports et les services postaux.

Le Japon exige-t-il une SBOM ?

Pas au titre des Normes unifiées, qui ne mentionnent pas les SBOM. Les lignes directrices sur les normes de sûreté citent la SBOM comme un élément qu'un exploitant peut demander à un fournisseur, et un contrat peut rendre cela contraignant.

Que demande la section sur la gestion des vulnérabilités ?

La section 3.3.6 des Normes unifiées demande aux exploitants de vérifier si des vulnérabilités touchent les systèmes en exploitation, d'évaluer périodiquement leurs systèmes et de définir des procédures d'application des correctifs, en tenant compte du fait que l'IA raccourcit le délai entre la découverte et l'exploitation.

La préparation au CRA couvre-t-elle les exigences japonaises ?

Non, mais une grande partie des preuves est réutilisable. Les SBOM, la trace des versions touchées par une vulnérabilité et la trace de son traitement sont utiles dans les deux cas.