Tous les articles

Blog

Formation DORA, NIS2, PCI DSS : le registre ne prouve pas l'efficacité

Formation DORA, NIS2, PCI DSS, ISO 27001 : ce que les textes exigent des développeurs, ce que l'auditeur vérifie, et la preuve qui manque.

  • Par Azziz ERRIME
  • 12 min de lecture
Salle d'audience parlementaire vide, sans drapeau ni emblème, classeur fermé devant une chaise de témoin

TL;DR

  • Formation DORA, NIS2 ou PCI DSS : les textes obligent à former les développeurs et à le documenter, rarement à prouver que leurs pratiques ont changé.
  • PCI DSS exige une formation tous les 12 mois, et l’évaluateur la vérifie en examinant des registres et en interrogeant le personnel.
  • Je préparerais l’audit en deux colonnes : ce qui a été fait, et ce qui a changé dans les revues de code.

Le 3 octobre 2017, l’ancien PDG d’Equifax explique au Congrès américain que l’alerte de sécurité était bien partie vers les bonnes équipes, et que le protocole avait été suivi. La fuite touchait environ 147 millions de personnes. Les obligations de formation DORA, NIS2 et PCI DSS rejouent cette scène à leur échelle : elles demandent de montrer que le dispositif existe, beaucoup moins qu’il fonctionne.

Ce 3 octobre, à Washington, Richard Smith fait face à la commission Énergie et Commerce de la Chambre des représentants. Equifax, prévenue en mars, ne découvre l’intrusion qu’en juillet. Devant les élus, il déroule la chaîne prévue : le lendemain de l’alerte du CERT, l’équipe sécurité prévient un large groupe de l’équipe technique. Ces personnes doivent trouver la faille et appliquer le correctif, puis lancer quelques jours plus tard un scanner de vérification.

La chaîne s’est rompue à un maillon, selon la transcription de l’audition. Smith le dit ainsi : « The human error was the individual who is responsible for communicating in the organization to apply the patch did not. » Puis il résume en deux temps : « Both human deployment of the patch and the scanning deployment did not work », et « The protocol was followed ».

La FTC rapporte en 2019 que la règle interne demandait de corriger sous 48 heures. L’accord conclu prévoit au moins 575 millions de dollars. Le protocole avait été suivi, et il prévoyait sa propre vérification. Elle n’a rien vu non plus.

Un protocole suivi ne prouve pas qu’un contrôle fonctionne

La scène montre l’écart entre deux preuves qu’on confond volontiers. La première dit qu’une action a eu lieu : une alerte envoyée, un scanner programmé, une procédure signée. La seconde dit que l’action a changé quelque chose : le correctif est en place, le serveur ne répond plus à l’attaque. La première se range facilement dans un dossier d’audit, la seconde beaucoup moins.

L’attaquant ne lit pas vos procédures. Il cherche le serveur qui n’a pas reçu le correctif, le formulaire que personne n’a filtré, la pull request relue en vitesse. Concrètement, il teste l’application en production, et ce qu’il y trouve mesure l’efficacité réelle de vos contrôles, formation comprise.

La formation des développeurs vit exactement dans cet écart. Un registre dit qu’un développeur a suivi un module sur l’injection SQL en mars. Il ne dit pas s’il a repéré, en septembre, l’injection glissée dans le code d’un collègue. Les textes qui encadrent la formation DORA, NIS2 ou PCI DSS se contentent-ils de la première preuve ?

La formation DORA, NIS2 ou PCI DSS se vérifie surtout sur registre

Le tableau s’appuie sur les textes eux-mêmes, lus au Journal officiel de l’Union, et sur la norme PCI DSS 4.0.1. Il résume ce qu’ils exigent des équipes qui écrivent du code.

Texte Ce qu’il exige Ce que l’on montre à l’audit Efficacité demandée ?
DORA, art. 13, § 6 Programmes de sensibilisation et formations « sous forme de modules obligatoires », pour tous les employés et la direction, prestataires TIC le cas échéant Le programme et sa réalisation Non
DORA, art. 5, § 4 Formation régulière de l’organe de direction, proportionnée au risque lié aux TIC Le suivi des formations Non
RTS DORA 2024/1774, art. 16 Examens du code source avec tests statiques et dynamiques ; code tiers et open source analysé, dans la mesure du possible, avant la production Les examens, le plan d’action, son suivi Indirectement, par les résultats
PCI DSS 4.0.1, 6.2.2 Formation des développeurs de logiciels sur mesure au moins une fois tous les 12 mois Registres de formation et entretiens (6.2.2.b) Non
PCI DSS 4.0.1, 6.2.3 et 6.2.3.1 Revue du code avant la production ; en revue manuelle, un relecteur autre que l’auteur Traces des revues (6.2.3.b) Indirectement
NIS2, art. 20, § 2 Les États imposent la formation des organes de direction ; formation du personnel encouragée Selon la loi nationale Non
NIS2, art. 21, § 2, e à g Sécurité du développement ; évaluation de l’efficacité des mesures ; formation à la cybersécurité Selon la loi nationale Oui, pour l’ensemble des mesures
ISO/IEC 27001:2022, 7.2 Compétence du personnel, et évaluation de l’efficacité des actions menées Informations documentées Oui
AI Act, art. 4, modifié en 2026 Mesures pour soutenir la maîtrise de l’IA, sans niveau garanti Les mesures prises Non

DORA, le règlement européen sur la résilience opérationnelle numérique du secteur financier, ne dit ni comment former ni à quel rythme. Son article 13 impose des programmes et des formations « destinés à tous les employés et aux membres de la direction », d’un « niveau de complexité proportionné à leurs fonctions ». La formation DORA est une obligation d’organiser des modules, sans résultat à mesurer.

PCI DSS, la norme des cartes de paiement, va plus loin dans le détail. L’exigence PCI DSS 6.2.2 fixe le rythme : au moins une fois tous les 12 mois. Elle fixe aussi le contenu, soit la sécurité logicielle propre à la fonction et aux langages, la conception et les techniques de code sécurisé. Sa procédure de contrôle dit ce que l’évaluateur regarde : « Examine training records and interview personnel ». Des registres et des entretiens.

Ces deux textes décrivent donc une formation réalisée. Que se passe-t-il entre le registre et le code ?

Tampon encreur sans motif sur une pile de feuilles d’émargement d’une formation DORA, à côté d’un écran éteint

Le tampon certifie la présence. L’écran, lui, n’a encore rien montré.

Aucun texte ne demande de relier le registre aux revues de code

Même l’objectif que PCI DSS donne à son exigence de formation reste du côté du savoir. Dans l’approche personnalisée, la norme vise des développeurs qui « remain knowledgeable about secure development practices ». Un développeur peut rester informé et laisser passer une faille en revue, parce qu’il relisait la logique métier ce jour-là.

L’article 16 du règlement délégué DORA 2024/1774 regarde, lui, le code. Il impose « la réalisation d’examens du code source comprenant des tests aussi bien statiques que dynamiques ». Les entités doivent ensuite identifier les vulnérabilités, adopter un plan d’action et en suivre la mise en œuvre. Ces examens produisent exactement les données qui manquent au registre de formation, mais rien dans le texte ne demande de les rapprocher.

On pourrait conclure que l’auditeur se contente du registre, et qu’il serait inutile d’en faire plus. Deux textes du tableau disent pourtant le contraire.

Deux textes demandent déjà d’évaluer l’efficacité

La norme ISO/IEC 27001, dans sa version de 2022, traite la compétence dans sa clause 7.2. Selon les reprises fiables de ce texte payant, elle demande de mener les actions nécessaires pour acquérir la compétence, puis d’évaluer leur efficacité. Elle demande aussi de conserver des informations documentées comme preuve. Une formation suivie est une action, et son efficacité est une autre question, que la norme pose explicitement.

La directive NIS2 le fait aussi, à l’échelle de toutes les mesures de sécurité. Son article 21 liste, au point e, la sécurité de l’acquisition, du développement et de la maintenance des systèmes. Au point g figurent « les pratiques de base en matière de cyberhygiène et la formation à la cybersécurité ». Entre les deux, le point f exige « des politiques et des procédures pour évaluer l’efficacité des mesures de gestion des risques en matière de cybersécurité ». Je lis le point f comme valant aussi pour le point g, la formation. Aucun des deux textes ne lie encore tout le monde. ISO 27001 vaut pour qui vise la certification, et NIS2 attend sa loi française.

Le guide NIST SP 800-50, dans sa révision 1 publiée le 12 septembre 2024, n’oblige personne. Il propose pourtant des « suggested metrics and evaluation methods » pour faire évoluer un programme de formation.

En France, la conformité NIS2 reste suspendue au texte national. Le délai de transposition a expiré le 17 octobre 2024, selon InCyber. Le projet de loi de transposition NIS2 arrive en examen à l’Assemblée nationale à partir du 7 octobre 2026, selon Kohen Avocats.

La preuve d’efficacité d’une formation DORA est déjà dans vos revues de code

J’en tire que la matière de cette preuve existe déjà dans les entreprises soumises à DORA ou à PCI DSS. Elle dort dans les examens de code que ces textes imposent. PCI DSS demande des traces de revue avant chaque mise en production, et le RTS DORA des examens du code source avec un plan d’action. Il reste à les mettre en face du registre de formation.

Voici ce que je mettrais dans le dossier d’audit, à côté du registre :

  • le registre de formation DORA ou PCI DSS tel que l’évaluateur l’attend, avec les modules suivis par chaque développeur ;
  • les constats des revues de code et des tests du code source sur la même période, classés par type de faille ;
  • le rapprochement des deux : les failles que la formation couvrait, et celles qui passent encore la revue ;
  • le plan d’action qui en découle et son suivi, comme le demande l’article 16 du RTS DORA ;
  • la même mesure refaite après chaque cycle de formation, pour voir si la courbe bouge.

Ce rapprochement nourrit l’évaluation que demandent la clause 7.2 d’ISO 27001 et le point f de l’article 21 de NIS2. Il donne surtout au comité de direction autre chose qu’un taux de complétion. C’est aussi ce que je mesure en ce moment : ce que les développeurs repèrent, ou laissent passer, quand ils relisent du code écrit par une IA. J’en parlais dans un précédent article sur la revue de code.

Balance à deux plateaux, certificats roulés d’un côté, pièce mécanique usinée de l’autre

D’un côté, des certificats. De l’autre, une pièce qui a changé.

Après un incident, c’est la seconde colonne qu’on lit

Devant les élus, Richard Smith décrit un protocole qui existait, et une alerte partie le lendemain. Le protocole prévoyait même un contrôle de l’effet, le scanner, et ce contrôle a échoué lui aussi.

Une formation DORA, NIS2 ou PCI DSS bien tenue ressemble souvent à ce protocole. Le registre est complet, les modules sont à jour, l’évaluateur repart satisfait. Je préparerais pourtant l’audit en deux colonnes, ce qui a été fait et ce qui a changé dans les revues. Après un incident, c’est la seconde qu’on vous demandera.

Je garde un doute. Je ne sais pas si les régulateurs iront jusqu’à exiger cette preuve de façon explicite, ni si la loi française sur NIS2 le précisera. Les deux textes qui le demandent déjà suffisent à mes yeux pour commencer.

Questions fréquentes sur la formation DORA et ses voisines

Quelles obligations de formation découlent du règlement DORA ?

Les obligations du règlement DORA en matière de formation tiennent dans deux articles. La formation DORA relève d’abord de l’article 13, paragraphe 6, du règlement : programmes de sensibilisation à la sécurité des TIC et formations à la résilience opérationnelle numérique. Ils s’intègrent à la formation du personnel « sous forme de modules obligatoires », pour tous les employés et la direction. L’article 5 ajoute une formation régulière pour l’organe de direction. Le texte ne fixe ni fréquence ni durée.

Que dit l’exigence PCI DSS 6.2.2 ?

PCI DSS 4.0.1 impose que les développeurs de logiciels sur mesure soient formés « at least once every 12 months ». La formation porte sur la sécurité logicielle propre à leur fonction et à leurs langages, conception et techniques de code sécurisé comprises. Pour le vérifier, l’évaluateur examine les registres de formation et interroge le personnel, selon la procédure 6.2.2.b.

Quand NIS2 entre-t-elle en vigueur en France ?

La directive NIS2 devait être transposée avant le 17 octobre 2024. En France, le projet de loi de transposition arrive en examen à l’Assemblée nationale à partir du 7 octobre 2026, selon Kohen Avocats. Les obligations nationales, formation comprise, dépendront du texte adopté. La directive oblige chaque État à imposer cette formation aux organes de direction. En France, l’obligation attend donc la loi.

Que dit l’article 4 de l’AI Act ?

Dans sa version de 2024, l’article 4 de l’AI Act visait les fournisseurs et les déployeurs de systèmes d’IA. Ils devaient garantir, « dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA » pour leur personnel. Depuis le règlement Omnibus entré en vigueur le 27 juillet 2026, il leur demande de soutenir cette maîtrise, sans garantir de niveau, selon Law & Technology.

Sources