Le temps que DORA prend à votre CTO

DORA, le règlement européen sur la résilience opérationnelle numérique du secteur financier, s’applique depuis le 17 janvier 2025. Quand nous en parlons avec la direction d’une fintech, la conversation commence rarement par le texte lui-même. Le constat est plus simple : « Notre CTO passe beaucoup de temps là-dessus, et je ne suis pas sûr que ce soit à lui de tout faire. »

Avant de planifier la mise en conformité, il faut donc savoir qui fera le travail en interne, et combien de temps cela lui prendra.

Pourquoi DORA retombe souvent sur le CTO

DORA a l’air d’un sujet technique : cartographier les prestataires de technologies de l’information et de la communication (TIC), tester la résilience des systèmes, classifier les incidents. Le dossier revient donc naturellement à la personne la plus à l’aise avec ce vocabulaire : le directeur technique (CTO), le responsable de l’ingénierie, parfois le dirigeant lui-même dans une petite équipe. L’intitulé dépend de votre organisation. Dans cet article, nous parlons du CTO, mais c’est le rôle qui compte.

DORA n’est pourtant pas un projet uniquement technique. Il faut tenir un registre à jour, rédiger des politiques et organiser les preuves que le superviseur pourra demander. Or le CTO est souvent la seule personne à connaître à la fois l’architecture, les prestataires et les processus concernés. Il devient le point de passage de tout le projet, même s’il n’a ni le temps ni le mandat pour le porter seul.

Dans les entreprises qui nous contactent, le sujet avance entre deux livraisons, au gré des disponibilités d’une personne qui a déjà d’autres responsabilités.

Le travail à prévoir

La charge dépend trop de l’organisation pour annoncer un nombre de jours valable partout. Nous pouvons en revanche détailler les principaux chantiers qu’impose le règlement (UE) 2022/2554.

• Documenter le cadre de gestion des risques TIC : politiques, inventaire des systèmes, continuité d’activité, sauvegardes. La direction en reste responsable, et le cadre doit être réexaminé régulièrement.
• Cartographier les prestataires TIC : recenser les fournisseurs technologiques dont vous dépendez (hébergeurs, sous-traitants, éditeurs de logiciels), repérer ceux qui soutiennent vos fonctions critiques ou importantes, puis vérifier que leurs contrats comportent les clauses exigées par l’article 30. Ce travail touche toutes les équipes, pas seulement l’infrastructure.
• Tenir le registre d’informations : DORA impose de recenser tous les contrats de services TIC, avec pour chacun le prestataire, le service rendu, les fonctions qu’il soutient, la localisation des données et la chaîne de sous-traitance. Ce n’est pas un fichier que l’on remplit une fois : il évolue avec vos contrats. Nous détaillons son contenu dans notre article sur le registre d’informations DORA.
• Construire un programme de tests de résilience : analyses de vulnérabilités, revues de code source, tests d’intrusion, proportionnés à vos risques. Hors microentreprises, les systèmes qui soutiennent des fonctions critiques ou importantes sont testés au moins une fois par an, et les faiblesses relevées doivent être corrigées.
• Formaliser la gestion des incidents : un processus de détection, de classification et de notification qui respecte les délais réglementaires, et non le rythme habituel de l’équipe. La notification initiale d’un incident majeur doit être adressée au superviseur dans les 4 heures suivant sa classification, et au plus tard 24 heures après que vous en avez eu connaissance.

Chacun de ces chantiers demande autant de rigueur documentaire que de compréhension technique. C’est ce mélange qui manque souvent aux équipes produit.

Le coût du travail en interne

Confier ce travail à une personne déjà salariée ne le rend pas gratuit. Pour comparer ce choix à un accompagnement externe, il faut compter le temps que cette personne retire à ses autres responsabilités.

Une journée passée à cartographier des prestataires ou à remplir le registre d’informations n’est pas consacrée à une revue d’architecture, à un recrutement ou à la feuille de route produit. Comme ce coût n’apparaît sur aucune facture, il est facile de le sous-estimer, jusqu’à ce que d’autres sujets prennent du retard.

Ce qu’une plateforme ou un cabinet laisse au CTO

Une plateforme de conformité peut automatiser la collecte de certaines preuves, fournir des modèles de procédures et surveiller des contrôles techniques en se connectant à vos outils. Il reste à choisir les modèles pertinents, à les adapter à l’entreprise et à décider des mesures à prendre. Ces choix dépendent de l’architecture, des risques et de l’organisation.

Il est ainsi possible d’avoir des intégrations actives et des preuves qui remontent, sans que les procédures aient été relues ni adaptées. Le travail revient alors à la personne qui a déployé l’outil.

Le même problème se pose avec un cabinet qui maîtrise la réglementation mais connaît mal votre environnement technique. Il produira les documents attendus, mais devra solliciter le CTO pour cartographier les risques TIC et comprendre les choix d’architecture. La charge est déplacée, elle ne disparaît pas.

Ce que les superviseurs contrôlent en 2026

Selon votre agrément, votre superviseur est l’Autorité de contrôle prudentiel et de résolution (ACPR) ou l’Autorité des marchés financiers (AMF). Toutes deux ont annoncé des contrôles pour 2026.

Dans son programme de travail pour 2026, publié le 19 janvier, l’ACPR retient trois priorités de contrôle sur les risques TIC : la gestion des incidents, la mise en place du cadre de gestion de ces risques et la conformité des contrats avec les prestataires informatiques. Elle prévoit des contrôles sur place ciblant les entités les plus exposées aux risques, et sera attentive à la réalisation régulière de tests d’intrusion.

L’AMF, de son côté, prévoit dans ses priorités d’action et de supervision pour 2026 des contrôles sur la cybersécurité des entités qu’elle régule.

Lors d’un contrôle, un registre incomplet ou des politiques restées sur le papier se remarquent vite. Laisser le chantier inachevé, ou reporter sa mise à jour, devient plus risqué : la conformité ne peut plus être traitée comme un exercice uniquement documentaire.

Ce que nous prenons en charge

Un accompagnement sert d’abord à répartir autrement le travail.

Un workshop hebdomadaire d’une heure réunit le CTO et notre équipe : avancement, décisions à prendre, priorités de la semaine suivante. Entre deux workshops, nous cartographions les prestataires, tenons le registre d’informations, rédigeons les politiques et la procédure de gestion des incidents, puis préparons le programme de tests. Le CTO apporte les informations techniques, valide les choix et mobilise son équipe quand c’est nécessaire. Les questions qui ne peuvent pas attendre le workshop suivant trouvent une réponse en asynchrone.

La rédaction, le suivi documentaire et la préparation des contrôles ne reposent donc plus sur lui seul.

Dans ce fonctionnement, nous tenons le rôle de responsable de la sécurité des systèmes d’information (RSSI) et votre CTO garde la main sur la technique : c’est notre offre RSSI externalisé, test d’intrusion inclus.

Si vous avez déjà un RSSI ou un responsable des risques, il garde le pilotage avec notre offre Accompagnement à la conformité : nous apportons notre lecture du règlement, rédigeons les politiques et les procédures, et l’aidons à préparer les échanges avec le superviseur.

Questions fréquentes

Notre CTO peut-il déléguer DORA à un chef de projet ?

En partie. La coordination et le suivi documentaire peuvent être délégués à un chef de produit ou à un chef de projet. La cartographie des risques TIC et la classification des incidents demandent en revanche une compréhension fine de votre architecture et de vos dépendances. Sans elle, le registre existe sur le papier mais ne reflète pas votre exposition réelle, et la charge revient presque toujours au CTO au moment où cela compte.

Sommes-nous une entité financière au sens de DORA, ou seulement un prestataire ?

Les deux cas existent, et les obligations diffèrent. Si vous êtes une entité financière régulée (paiement, monnaie électronique, gestion d’actifs, assurance, financement participatif…), le règlement s’applique directement à vous. Si vous êtes un éditeur de logiciel en ligne (SaaS) au service de clients financiers, DORA vous atteint indirectement, par les clauses contractuelles que ces clients doivent désormais vous imposer.

Un prestataire TIC n’est supervisé au titre de DORA que s’il est désigné comme critique par les autorités européennes de surveillance. Nous détaillons ces situations sur notre page DORA.

Qu’est-ce qui change si nous sommes accompagnés ?

Avec le RSSI externalisé, nous prenons en charge la cartographie, le registre, les politiques et la préparation du programme de tests, dont 5 jours par an de test d’intrusion ou d’audit technique, au choix, que nous réalisons nous-mêmes. Votre équipe fournit les informations nécessaires et valide les décisions lors du workshop hebdomadaire. Elle garde la main sur la technique : les changements qui demandent ses accès restent de son ressort.

Combien de temps faut-il prévoir ?

Comptez 6 à 12 mois selon votre statut et votre maturité de départ. Le délai se raccourcit nettement si vous êtes déjà avancés sur ISO 27001 : la norme couvre une bonne partie des exigences de gestion des risques et des incidents, sans valoir conformité DORA. Notre page DORA détaille la démarche, étape par étape.

La décision à prendre en interne

Si DORA s’applique à votre entreprise, il reste à décider qui préparera les documents, tiendra le registre à jour et coordonnera les tests. Ce choix détermine la part du projet qui restera à la charge du CTO.

Pour arbitrer cette répartition, parlons de votre projet DORA : si nos offres ne sont pas encore pertinentes pour vous, nous vous le dirons.