Dès le lancement du programme, vous avez fait le choix de ne pas aborder DORA comme un simple exercice de conformité. Pour quelles raisons ?
Avec mon équipe qui porte la mise en œuvre de DORA, nous avons, dès le départ, fait le choix de ne pas considérer DORA comme un simple programme de mise en conformité réglementaire, mais comme une revue complète de notre stratégie en matière de cybersécurité. Nous avons repris l’ensemble de notre plan stratégique et nous l’avons réévalué à l’aune des exigences de DORA. La Caisse des Dépôts est dans une situation particulière en étant formellement assujettis à DORA que depuis le 1er janvier 2026, en vertu d’un décret spécifique publié début septembre.
Pour autant, l’Autorité de contrôle prudentiel et de régulation (ACPR) nous a demandé de mettre en place, dès 2025, le pilier relatif au reporting des incidents. L’objectif était clair : disposer d’un panorama global de la menace au niveau du système financier et identifier tout risque potentiel de nature systémique. Nous avons donc déployé ce pilier dès mars 2025. Depuis, nous avons des échanges réguliers et des entretiens de suivi rapproché avec le régulateur afin de partager l’état d’avancement, les difficultés rencontrées et les arbitrages opérés.
En revanche, au niveau Groupe, je pilote le programme DORA de manière transverse et j’ai une visibilité directe sur les entités déjà concernées depuis le 17 janvier 2025, notamment CNP Assurances, La Banque Postale, Bpifrance ou encore la Sfil.
Vous avez mis en place une double gouvernance. Pourquoi ce choix est-il déterminant pour un programme comme DORA, et qu’apporte-t-il en termes d’arbitrage et de légitimité ?
Le programme DORA s’est appuyé sur une réorganisation intervenue en avril 2024 au sein de la filière Risques opérationnels, dont relèvent les risques IT et cyber. Mon rôle, en tant que directrice cybersécurité groupe, couvre la maîtrise des risques IT et cyber au sens large. Cela inclut notamment des fonctions de contrôle de second niveau, de cartographie des risques et de pilotage transverse. Nous avons mis en place une gouvernance forte, avec un double niveau. Ma directrice des risques est naturellement sponsor du programme et nous avons également nommé comme sponsor la directrice générale déléguée de la Caisse des Dépôts, Catherine Mayenobe, qui supervise notamment les directions IT et achats. Ce choix est structurant : il permet de couvrir un périmètre très large et de donner au programme DORA une visibilité et une légitimité fortes au niveau du comité exécutif.
L’identification des fonctions critiques est un pilier central de DORA. Comment avez-vous mené cet exercice ?
Comme l’ensemble des établissements financiers, nous avons débuté par une analyse d’écart, réalisée de manière déclarative, afin d’évaluer notre niveau de maturité par rapport aux exigences de DORA. Cette analyse a conduit à la mise en place de chantiers prioritaires. Nous avons identifié onze fonctions critiques, un nombre cohérent avec celui observé dans d’autres établissements de taille comparable notamment ceux du groupe comme la CNP. Parmi ces fonctions figurent notamment l’exécution des virements, la gestion des actifs ou encore la cybersécurité elle-même. Il s’agit de processus transverses, structurants pour l’ensemble de l’organisation. À partir de ces fonctions critiques, nous avons ensuite décliné l’analyse au niveau applicatif, puis au niveau des fournisseurs. Cela nous a permis d’identifier les prestataires critiques. Nous avons revu l’ensemble de nos prestations de services externalisées afin de les mettre en cohérence avec les fonctions critiques DORA, et d’assurer un alignement complet.
Vous soulignez que le principal défi du programme DORA réside dans la gestion du risque fournisseur. Pourquoi ce pilier est-il aujourd’hui le plus complexe à mettre en œuvre ?
La principale difficulté du programme DORA réside clairement dans la gestion du risque fournisseur, c’est-à-dire le pilier 4 du Third Party Risk Management (TPRM). Nous avons intégré des clauses spécifiques DORA dans nos contrats, notamment en matière de continuité et de reprise d’activité. Ces exigences sont désormais systématiquement intégrées dans les nouveaux appels d’offres et les renouvellements contractuels. En revanche, le stock de contrats existants représente un enjeu majeur. La durée moyenne de nos contrats étant d’environ quatre ans, il faudra entre trois et quatre ans pour mettre à niveau l’ensemble du parc contractuel. C’est un chantier long, structurant et très consommateur de ressources. DORA introduit par ailleurs une vision élargie du système d’information, intégrant non seulement les fournisseurs directs, mais également les fournisseurs de rang 2, voire au-delà. Cette approche « supply chain » est essentielle, mais elle est complexe à mettre en œuvre. Aujourd’hui, nous avons une visibilité satisfaisante jusqu’au rang 2, notamment via un GIE interne, mais la transparence dépend largement du degré de maturité des prestataires. L’exemple d’Harvest, éditeur de logiciels à destination des professionnels de la finance dont les services ont été interrompus pendant plusieurs semaines à la suite d’une cyberattaque, illustre parfaitement ce point : un fournisseur considéré comme non critique, sans plan de continuité adapté à une cyberattaque d’ampleur, peut générer des impacts significatifs. Cet épisode a confirmé la pertinence de l’approche DORA et la nécessité de renforcer les contrôles sur l’ensemble de la chaîne.
La Caisse des Dépôts dispose déjà d’un dispositif de tests avancé. En quoi les tests TLPT vont-ils plus loin ?
Sur le pilier 3, relatif aux tests, nous disposons déjà d’un dispositif mature, structuré et gradué. Nous réalisons systématiquement des tests d’intrusion lors du lancement d’un nouvel applicatif ou lorsqu’un applicatif a évolué de manière significative. À défaut, un test est refait lorsqu’il n’a pas été réalisé depuis un certain temps, généralement deux ans.
Nous menons également des exercices de red teaming (audit complet), à raison d’environ un par an. Dans ce cadre, nous mandatons un prestataire externe avec un objectif précis : accéder à un fichier sensible, tenter d’exécuter un virement ou atteindre une ressource critique. Ces exercices permettent de tester la capacité de détection, de réaction et de remédiation de bout en bout. Une fois ces bases en place, nous déployons nos sites sous bug bounty (primes à la détection des bugs). Nous travaillons depuis plus de quatre ans avec la plateforme YesWeHack, avec laquelle nous venons de renouveler notre contrat. Aujourd’hui, 40 URL sont placées sous bug bounty, ce qui est un volume important, c’est-à-dire que nous permettons à des hackers de tester nos systèmes et de nous remonter les failles. Lors du dernier événement organisé par YesWeHack, en 48 heures, neuf vulnérabilités critiques ont été identifiées et corrigées. Le coût financier est réel, mais le retour sur investissement est très élevé. Trouver neuf vulnérabilités critiques en deux jours permet de fermer des portes que nous n’aurions parfois jamais identifiées autrement. Nous disposons également d’une compétence interne capable de réaliser des tests d’intrusion et qui pilote l’ensemble des prestataires externes. Cela permet une meilleure compréhension des résultats et facilite le dialogue avec les métiers.
Concernant les tests de pénétration avancés de type « Threat-Led Penetration Testing » (TLPT ou test d’intrusion basé sur la menace), nous n’avons pas encore été notifiés par l’ACPR. Nous anticipons néanmoins leur mise en œuvre à partir de 2026, avec une phase de préparation et de collecte d’information au premier semestre, suivie de tests au second semestre. Ces exercices sont longs, coûteux et très engageants, avec des cycles pouvant atteindre 60 semaines entre la notification et le rapport final. Nous avons pris soin de diversifier nos prestataires et de mobiliser également des ressources internes certifiées, afin d’anticiper les risques d’engorgement du marché.
Le reporting des incidents majeurs impose des délais très contraints. Quelle est votre approche dans ce domaine ?
Sur le volet du reporting des incidents majeurs DORA, la contrainte des délais est réelle. En cas d’incident majeur, nous disposons de quatre heures pour effectuer la déclaration initiale. Cela suppose d’identifier rapidement la nature de l’incident, de qualifier son caractère au regard des critères réglementaires et d’éviter de surdéclarer des incidents sans impact significatif. Nous avons mis en place un comité de validation chargé de qualifier les incidents. Il est possible de préremplir une déclaration et de la retirer si l’incident ne se révèle finalement pas majeur. Mais notre approche est volontairement prudente : nous préférons déclarer lorsque le caractère majeur est avéré, plutôt que de « crier au loup ». Après cette déclaration initiale, nous disposons de 72 heures pour fournir des éléments techniques plus détaillés, puis d’un mois pour le reporting final. À ce stade, nous devrions terminer l’année sans incident majeur DORA. D’autres établissements ont fait le choix de déclarer dès le moindre doute. De notre côté, nous privilégions une approche fondée sur l’expérience de la gestion de crise informatique, qui fait partie intégrante de la vie d’un système d’information.
L’usage de l’intelligence artificielle constitue-t-il un facteur de risque supplémentaire ?
L’intelligence artificielle (IA) est la fois un facteur de risque et un levier de défense. Nous observons une sophistication croissante des attaques, notamment via des campagnes de phishing générées par IA. Sur ce sujet, nous travaillons à plusieurs niveaux. DORA prévoit explicitement des actions de formation, y compris au niveau du comité exécutif. J’ai d’ailleurs animé, en décembre dernier, une session de formation dédiée à DORA pour l’ensemble du comité exécutif. L’objectif n’était pas seulement de leur présenter la réglementation – qu’ils connaissent déjà – mais de leur rappeler très concrètement leur rôle et leurs responsabilités dans le cadre de DORA. Nous avons également organisé des sessions spécifiques pour environ 300 collaborateurs directement concernés par la réglementation. Enfin, une formation obligatoire sera déployée à destination de l’ensemble des collaborateurs. En parallèle, sur les sujets de phishing, de fraude au président et plus largement de sensibilisation aux menaces cyber, nous avons mis en place des dispositifs très classiques pour une banque : modules e-learning obligatoires, campagnes de sensibilisation et exercices réguliers. Nous menons également des campagnes de phishing régulières. Celles-ci sont désormais largement industrialisées : nous avons acquis un outil dédié qui permet de maintenir un niveau de vigilance élevé dans la durée. En parallèle, nous utilisons nous-mêmes des outils fondés sur l’IA pour détecter les comportements anormaux, les malwares ou les tentatives d’accès non conformes. Ces dispositifs s’inscrivent dans un cadre strict, défini par la charte d’utilisation des systèmes d’information. Les analyses sont statistiques et non nominatives, et toute alerte fait l’objet d’une validation humaine. Le contrôle humain reste indispensable.
La question du cloud est également déterminante dans le risque cyber, quel a été votre choix dans ce domaine, avez-vous opté pour un cloud interne ?
Cela constitue effectivement l’une des grandes évolutions dans notre manière de travailler. Sur le plan organisationnel, de nombreuses banques expliquent aujourd’hui qu’elles cherchent, autant que possible, à héberger leurs données critiques sur des environnements cloud internes ou, à tout le moins, sur des infrastructures parfaitement maîtrisées, plutôt que de recourir exclusivement à des clouds publics opérés par les grands acteurs du marché. De notre côté, la démarche est comparable. Toutes les fonctions critiques sont portées sur des environnements considérés comme internes – même s’ils sont techniquement hébergés – en l’occurrence à la Banque de France, dans des conditions de sécurité très élevées. Nous n’hébergeons donc pas l’ensemble de nos données sur des clouds publics, comme Azure par exemple, car la sensibilité des données manipulées est trop importante. Nous avons ainsi défini une politique de sécurité des systèmes d’information spécifique à l’hébergement cloud. En fonction des usages, nous autorisons soit le recours à des clouds publics (les grands fournisseurs comme Google Cloud ou AWS), soit à des clouds de confiance, avec des mesures de cybersécurité renforcées. Cela peut inclure, par exemple, l’ajout d’une couche de chiffrement complémentaire, lorsque les mécanismes proposés par le fournisseur ne sont pas jugés suffisants. Enfin, il existe ce que nous appelons le cloud souverain, qui correspond à des environnements que nous maîtrisons directement, hébergés sur des infrastructures qui nous sont propres. Cette politique a parfois été perçue, à ses débuts, comme un frein à l’innovation. Avec le recul, et à la lumière des enjeux liés aux lois d’extraterritorialité et à la souveraineté numérique, elle s’avère au contraire pertinente et payante.
Quels sont les effectifs au sein de votre service, cherchez-vous à les renforcer ?
En incluant les trois lignes de défense, la cybersécurité mobilise aujourd’hui entre 80 et 90 personnes à la Caisse des Dépôts. Le risque cyber est identifié comme un risque opérationnel majeur, ce qui justifie cet effort. Le recrutement reste néanmoins un enjeu clé. Les profils sont rares, et nous faisons le choix de constituer des équipes pluridisciplinaires. Au-delà des experts techniques, nous intégrons des profils issus de l’audit, du juridique, de la maîtrise d’ouvrage ou encore de la gestion des risques. Ce sont les équipes, et non les individus isolés, qui constituent le véritable « mouton à cinq pattes ».
En conclusion, quel est votre point de vue sur DORA ?
De manière générale, j’ai toujours considéré DORA comme une réglementation intelligente, car elle prend pleinement en compte l’étendue réelle de la menace. Les chiffres sont très parlants : environ deux tiers des organisations, tous secteurs confondus, indiquent que le principal risque cyber provient aujourd’hui de la supply chain. La vision d’un système d’information étendu est donc particulièrement pertinente. Nous l’avons constaté très concrètement à travers nos propres incidents, qui, pour la plupart, ne relevaient pas de cyberattaques directes, mais de défaillances de fournisseurs.
