Cyber Resilience Act – que signifie ce règlement européen pour les applications IBM i vieilles de plusieurs décennies, mais toujours en production ?

Résumé pour la direction

Le Cyber Resilience Act (CRA), ou règlement européen sur la cyberrésilience,1 impose des exigences contraignantes en matière de cybersécurité pour certains produits matériels et logiciels mis à disposition sur le marché de l'Union européenne. Pour les entreprises utilisant IBM i (AS400), cela ne signifie pas que des applications RPG éprouvées doivent être remplacées au seul motif de leur ancienneté.
Le rôle de l'entreprise est déterminant : les fabricants et fournisseurs de produits logiciels peuvent être directement concernés par le CRA. En revanche, une application développée en interne et utilisée exclusivement au sein de l'entreprise n'est pas soumise aux exigences du règlement relatives aux produits du seul fait de son utilisation. Des dispositions transitoires s'appliquent également aux produits existants, tandis que certaines obligations de notification sont déjà en vigueur.
Indépendamment des obligations légales applicables, la maîtrise des accès, la sécurisation des interfaces, la documentation des applications et la disponibilité des compétences spécialisées restent essentielles à une exploitation sûre. Le CRA constitue donc moins un argument pour remplacer des applications IBM i éprouvées qu'une occasion d'examiner attentivement leur sécurité et leur maintenabilité.

Faut-il maintenant abandonner l'ancienne AS400 ?

Cet article devait initialement porter le titre quelque peu provocateur « Cyber Resilience Act – faut-il maintenant abandonner l'ancienne AS400 ? ». Il résume une inquiétude qui surgit rapidement face à de nouvelles exigences légales : faut-il désormais remplacer par de nouveaux logiciels les systèmes utilisés depuis de nombreuses années ?
La réponse courte est : Non, certainement pas au seul motif du CRA. Le règlement n'impose pas la mise au rebut généralisée des anciens systèmes informatiques. Il vise à renforcer la sécurité des produits numériques et à obliger leurs fabricants à gérer de manière structurée les risques de sécurité et les vulnérabilités. L'application de ces obligations, ainsi que leur portée, dépend du produit concerné et de sa mise à disposition sur le marché de l'Union européenne.2
Dans l'environnement IBM i, il faut par ailleurs distinguer la plateforme elle-même, ses composants et les applications qui y fonctionnent. Une application RPG utilisée en interne depuis plusieurs décennies n'est pas automatiquement assimilable, sur le plan juridique, à un produit logiciel commercialisé.

Deux dates clés – des conséquences différentes

11 septembre 2026

Depuis cette date, les obligations de notification prévues à l'article 14 du CRA s'appliquent. Les fabricants de produits logiciels relevant du règlement doivent notifier les vulnérabilités activement exploitées ainsi que les incidents de sécurité graves ayant une incidence sur la sécurité de leurs produits.
En principe, une alerte précoce doit être transmise dans les 24 heures suivant la prise de connaissance de l'événement, puis une autre notification dans les 72 heures. Des rapports finaux supplémentaires sont requis selon la nature de l'événement. Ces obligations de notification concernent également les produits déjà présents sur le marché. Elles s'adressent principalement aux fabricants et non aux entreprises qui se contentent d'utiliser les logiciels.3

11 décembre 2027

À partir de cette date, l'essentiel des autres dispositions du CRA s'appliquera. Les nouveaux produits relevant de son champ d'application et mis sur le marché de l'Union européenne devront notamment satisfaire à des exigences de sécurité, de gestion des vulnérabilités, de documentation, de mises à jour de sécurité et d'évaluation de la conformité. Les produits déjà mis sur le marché ne seront, en principe, soumis à ces exigences supplémentaires que s'ils font l'objet d'une modification substantielle. L'existence d'une telle modification doit être appréciée au cas par cas.4 5 Les obligations de notification déjà en vigueur restent applicables indépendamment de ces dispositions.

Quelles conséquences pour IBM i et RPG ?

Pour un fabricant qui développe des logiciels sur IBM i et les propose en tant que produits sur le marché de l'Union européenne, le CRA peut être directement pertinent. En revanche, l'utilisation d'une application développée en interne et réservée exclusivement à l'entreprise ne fait pas naître d'obligations de fabricant au titre du CRA. Lorsqu'une application est mise à disposition de tiers ou fait l'objet d'une modification substantielle, les circonstances concrètes doivent être examinées plus attentivement.6 7
Sur le plan technique, nombre des questions de sécurité soulevées ne sont pas nouvelles : qui peut accéder à quelles données ? Les droits des utilisateurs et les autorisations sur les objets sont-ils configurés correctement ? Comment les interfaces sont-elles sécurisées ? Les modifications font-elles l'objet de tests et d'une documentation traçables ? Existe-t-il un processus structuré pour traiter les vulnérabilités identifiées ?
Une apparence moderne ne garantit pas automatiquement la sécurité d'une application. Inversement, une application RPG qui a évolué pendant de nombreuses années n'est pas dangereuse du seul fait de son ancienneté. La sécurité dépend de l'architecture, de la configuration, de l'exploitation, de la maintenance et de la gestion responsable des modifications.

Le risque sous-estimé : la disparition du savoir-faire

Que se passe-t-il lorsqu'une vulnérabilité de sécurité est détectée dans une application importante, mais que plus personne ne comprend suffisamment les programmes RPG ou les traitements CL correspondants ?
L'absence de mises à jour n'est pas le seul problème : une documentation insuffisante et la perte de connaissances sur les applications peuvent également devenir critiques. Sans connaissance des dépendances et des interfaces, il est difficile d'évaluer les risques et d'apporter des corrections fiables. Il existe ici un lien direct avec notre précédent article de blog : « Il faut demander à notre administrateur ».
La maintenance ciblée, la documentation et le développement continu des applications IBM i existantes peuvent donc constituer une meilleure solution que leur remplacement précipité. Encore faut-il que les risques puissent réellement être identifiés et corrigés.

Une distinction importante : CRA, NIS2 et DORA

Le CRA n'est pas un règlement général sur la sécurité de l'exploitation informatique applicable à toutes les entreprises et à l'ensemble de leurs systèmes internes. Il porte avant tout sur les produits numériques et les obligations des opérateurs économiques concernés, notamment les fabricants.
D'autres dispositions peuvent toutefois jouer un rôle dans la sécurité de l'exploitation des systèmes informatiques. La directive NIS28 concerne la cybersécurité de certaines entreprises et entités dans les secteurs couverts ; leurs obligations concrètes résultent de la transposition nationale applicable. Le règlement DORA9 fixe des exigences particulières en matière de résilience opérationnelle numérique dans le secteur financier. Ces dispositions ne doivent pas être confondues avec les obligations des fabricants liées aux produits prévues par le CRA.

IBM i – une longue tradition de sécurité

Dans le débat sur le Cyber Resilience Act, il ne faut pas oublier un point essentiel : depuis des décennies, l'AS400/IBM i fait partie des plateformes dotées d'une architecture de sécurité particulièrement rigoureuse. Dès l'origine, le système d'exploitation a été conçu avec un modèle d'autorisations élaboré, une architecture basée sur les objets et une intégration étroite du système d'exploitation et de la base de données. De nombreux mécanismes de sécurité, que d'autres plateformes ont dû ajouter ultérieurement, étaient déjà intégrés très tôt à ce système.
Et IBM ne se repose nullement sur ses acquis. Avec les nouvelles versions, les releases, les Technology Refreshes et les PTF, IBM développe et améliore continuellement les fonctions de sécurité de la plateforme. Un exemple récent est l'authentification multifacteur (MFA) intégrée, introduite avec IBM i 7.6. En plus du mot de passe, un code à usage unique limité dans le temps peut être exigé. L'accès au système s'en trouve nettement mieux protégé.10
Naturellement, IBM i n'est pas à l'abri des risques de sécurité. Des autorisations mal configurées, des interfaces non sécurisées ou des mises à jour de sécurité manquantes peuvent compromettre même la meilleure architecture.
Mais une application RPG vieille de plusieurs décennies ne fonctionne pas pour autant sur une plateforme obsolète ou non sécurisée.
L'évolution continue d'IBM i montre que les applications éprouvées et les exigences modernes de sécurité ne sont nullement incompatibles.

Conclusion

Le Cyber Resilience Act ne fixe aucune date de péremption à IBM i ou à RPG. Il attire néanmoins l'attention sur les responsabilités, les risques de sécurité et la capacité à corriger les vulnérabilités tout au long du cycle de vie d'un produit logiciel.
Pour les exploitants d'applications IBM i existantes, un état des lieux est donc utile : les accès et les interfaces sont-ils sécurisés ? Les programmes et leurs dépendances sont-ils documentés ? Les compétences spécialisées disponibles sont-elles suffisantes pour effectuer de manière fiable les corrections critiques ?
Ce n'est pas l'âge d'une application qui détermine sa sécurité, mais la manière dont elle est développée, exploitée, maintenue et protégée.

Remarque : cet article donne un aperçu général et ne remplace pas une analyse juridique du cas particulier.

Cet article est une traduction de l'original allemand réalisée à l'aide de l'intelligence artificielle

Article original : Cyber Resilience Act – was bedeutet die EU-Verordnung für jahrzehntealte, aber weiterhin produktive IBM-i-Anwendungen?