Arrêtez de chercher un logiciel de conformité DORA

Si vous dirigez les risques ou la conformité dans une banque, un assureur ou une entreprise d'investissement, votre boîte de réception a un nouveau thème cette année. Chaque fournisseur TIC, chaque plateforme GRC, chaque cabinet de conseil vous vend un logiciel de conformité DORA. L'argumentaire est toujours le même : le règlement sur la résilience opérationnelle numérique est en vigueur, l'échéance est passée, et il vous faut un outil pour cela.

Vous n'avez pas besoin d'un outil pour cela. Vous devez gouverner la résilience opérationnelle, et si vous le faites déjà bien, vous avez déjà l'essentiel de DORA. Voici pourquoi le réflexe d'achat est le mauvais, et ce qu'il faut regarder à la place avant de signer quoi que ce soit.

DORA n'a pas créé un nouveau problème

Le règlement sur la résilience opérationnelle numérique s'applique aux entités financières de l'UE depuis le 17 janvier 2025. C'est un règlement réel avec de vraies dents, et il n'est pas vague : il fixe des exigences en matière de gestion du risque TIC, de notification des incidents, de tests de résilience, de risque lié aux tiers TIC et de partage d'informations. Vingt types d'entités financières entrent dans son champ, des établissements de crédit aux prestataires de services sur crypto-actifs, ainsi que les prestataires TIC dont ils dépendent.¹

Lisez les exigences et remarquez ce qui manque : quoi que ce soit de nouveau. La gestion du risque TIC, c'est de la gestion des risques. La notification d'incidents, c'est de la notification d'incidents. La surveillance des tiers, c'est le risque fournisseurs que vous étiez censé gérer. Ce que DORA a fait, c'est prendre un ensemble de pratiques que les institutions financières matures appliquaient déjà, et les rendre juridiquement contraignantes et cohérentes dans toute l'Union. La nouveauté, c'est la contrainte, pas la substance.

Cela compte parce que cela change la question. « Quel produit DORA devrions-nous acheter » suppose que DORA est une chose distincte que l'on visse par-dessus. Ce n'est pas le cas. C'est un plancher juridique sous des disciplines que l'on pratique ou que l'on ne pratique pas. Un établissement doté d'un cadre de résilience opérationnelle qui fonctionne, d'un registre vivant de ses dépendances TIC et d'un processus d'incidents qui respecte déjà des délais de notification serrés est presque arrivé. Un établissement qui achète un outil DORA en 2026 est en général un établissement qui admet qu'il ne pratiquait pas ces disciplines, et qui espère que le logiciel masquera l'écart.

Le logiciel ne masque pas un écart de gouvernance. Il le rend auditable.

Le registre d'informations est un symptôme, pas la maladie

La panique la plus recherchée de DORA est le registre d'informations : l'inventaire structuré de tous les accords contractuels de services TIC, avec un schéma prescrit que les superviseurs peuvent collecter. C'est réellement minutieux. Il comporte des champs précis, des identifiants d'entité et un format que les régulateurs s'attendent à recevoir. Des fournisseurs ont bâti des produits entiers autour de sa production au format de soumission, et des établissements les paient.

Prenez du recul et demandez pourquoi le registre est difficile. Il est difficile parce que la plupart des établissements ne connaissent pas leur parc de tiers TIC. Les contrats sont éparpillés entre les achats, la sécurité et les métiers. Personne ne sait quels prestataires soutiennent les fonctions critiques ou importantes. Personne ne peut dire, à la demande, quelles quatrièmes parties se trouvent derrière les dépendances. Le registre est difficile à produire parce que le risque tiers TIC sous-jacent n'a jamais été géré comme un inventaire vivant.

Un produit qui génère le registre à partir d'un tableur rempli une fois résout l'artefact et ignore la maladie. L'année prochaine, le parc aura dérivé, les contrats auront changé, un prestataire aura été racheté, et vous remplirez le tableur à nouveau. Le registre d'informations n'est pas un document à produire. C'est le résultat d'une connaissance continue de vos dépendances TIC. Si vous gérez ce parc correctement, le registre est un rapport que l'on exécute. Sinon, aucun outil ne vous sauve, car l'outil n'est jamais plus à jour que la dernière mise à jour manuelle.

À quoi ressemble une bonne gestion du risque TIC

Voici la partie inconfortable pour quiconque espère s'acheter une sortie. Chaque pilier de DORA se résout en une pratique continue, pas en un livrable ponctuel.

La gestion du risque TIC n'est pas un document de politique. C'est un environnement de contrôles vivant, avec des responsables, des preuves et des cycles de revue. La notification d'incidents n'est pas un modèle de document. C'est un processus d'incidents câblé assez finement pour classifier un incident majeur et notifier un superviseur dans la fenêtre de notification, qui pour la notification initiale se mesure en heures, pas en jours. Les tests de résilience ne sont pas un pentest annuel. Pour les entités désignées par leur superviseur, ils incluent des tests de pénétration fondés sur la menace sur un cycle pluriannuel, et pour tous, un programme de tests dont les constats retournent dans les contrôles. Le risque lié aux tiers TIC n'est pas un contrat signé. C'est une surveillance continue de la concentration, des stratégies de sortie et des prestataires précis derrière les fonctions critiques.

Un cadre de résilience opérationnelle digne de ce nom relie tout cela. Il cartographie les services opérationnels importants, identifie les dépendances TIC et tierces sous chacun, fixe des tolérances d'impact et prouve, preuves à l'appui, que l'établissement peut rester dans ces tolérances quand quelque chose casse. C'est la discipline que DORA teste. Une liste de contrôle cochée en décembre et oubliée en janvier n'est pas cette discipline. C'est du théâtre avec une piste d'audit.

Les établissements qui passeront confortablement une revue de supervision DORA ne sont pas ceux qui ont le meilleur logiciel DORA. Ce sont ceux pour qui DORA est une couche de reporting au-dessus d'une gouvernance qu'ils pratiquaient déjà.

Le Royaume-Uni a déjà joué cette partie

Rien de tout cela n'est spéculatif, car une expérience très similaire a déjà eu lieu à côté. Les règles de résilience opérationnelle de la FCA et de la PRA ont exigé des firmes financières britanniques qu'elles identifient leurs services opérationnels importants, fixent des tolérances d'impact et cartographient leurs dépendances, avec l'attente de rester dans les tolérances au 31 mars 2025. La logique recoupe DORA presque ligne à ligne ; seul l'accent réglementaire change.

Les firmes qui ont traité le régime britannique comme un exercice de cartographie et de tolérances, fait une fois puis classé, ont fini par le refaire. Les firmes qui l'ont traité comme un modèle opérationnel, où la cartographie des dépendances et les tests sont continus, ont absorbé DORA avec beaucoup moins de drame, parce que le travail difficile était déjà institutionnel. La leçon se transfère directement. Les régulateurs de toutes les juridictions convergent vers la même attente : prouver, en continu, que vous pouvez résister à une disruption et vous en remettre. Ils ne convergent pas vers l'attente que vous possédiez un logiciel particulier.

Si vous évaluez votre posture DORA, la comparaison la plus utile n'est pas avec d'autres outils DORA. C'est avec la façon dont votre firme a géré la résilience opérationnelle FCA et PRA. Les écarts riment.

Le révélateur : achetez-vous un outil ou construisez-vous une discipline

Il existe un diagnostic simple pour savoir si vous êtes sur le point de bien dépenser. Demandez ce que fait le produit entre les audits.

Un outil DORA qui vous aide à produire le registre, à générer un pack de politiques et à exporter un lot de preuves pour l'évaluateur optimise pour le moment de l'inspection. Il rend l'audit plus fluide. Il ne fait rien pendant les cinquante-et-une autres semaines de l'année, pendant lesquelles le parc continue de changer. Un outil de ce type traite la conformité comme un événement. Entre les événements il reste inactif, pendant que la gouvernance pourrit en silence sous le rapport propre.

L'alternative est de traiter DORA comme un cadre de plus posé sur une capacité de risque TIC et de gouvernance des tiers que vous exploitez en continu. Dans ce modèle, les exigences sont mappées sur des contrôles, les contrôles portent des responsables et des preuves, le parc de tiers TIC est un inventaire entretenu plutôt qu'une reconstruction annuelle, et le registre d'informations est une vue sur cet inventaire plutôt qu'un document que l'on reconstruit. Quand un nouveau règlement arrive, et un autre arrivera, vous le mappez sur le même environnement de contrôles au lieu d'acheter un autre outil ponctuel.

C'est la différence entre acheter un logiciel de conformité DORA et construire la résilience opérationnelle. La discipline survit au prochain règlement ; l'achat d'outil ne fait que préparer le cycle d'achat suivant.

Où une plateforme aide, et où elle n'aide pas

Pour être juste envers la catégorie, l'outillage n'est pas l'ennemi. L'erreur est d'acheter un outil limité à un seul règlement. Une plateforme de gouvernance mérite sa place quand elle fait l'inverse : elle tient un seul environnement de contrôles sur lequel de nombreux cadres se mappent, garde un inventaire vivant des fournisseurs et des dépendances TIC, et attache les preuves aux contrôles pour que la piste d'audit soit un sous-produit du travail plutôt qu'un exercice d'urgence de fin d'année.

C'est le modèle sur lequel VerifyWise est construit. La plateforme gère les cadres comme des exigences mappées sur des contrôles avec preuves et évaluations, maintient un registre des fournisseurs et des tiers comme des données vivantes, et gouverne déjà le risque de modèle en services financiers sous des régimes comme SR 11-7 (désormais SR 26-2), SS1/23 et OSFI E-23. Le parc de tiers TIC qui intéresse DORA est le même parc que suit un module de risque fournisseurs. Les preuves continues dont un cadre de résilience opérationnelle a besoin sont les mêmes preuves que produit un environnement de contrôles.

Pour être clair sur le périmètre : DORA est un règlement que l'architecture de VerifyWise est conçue pour gouverner, pas une liste de contrôle préconstruite que l'on active. Tout fournisseur qui vous dit que son logiciel vous rend conforme à DORA par défaut vous vend un produit pour le jour de l'audit dans une plus jolie boîte.

La version honnête de l'argumentaire est plus petite et plus utile que celle du marché. Aucun logiciel ne vous rend résilient. Le logiciel rend la résilience mesurable, répétable et auditable, une fois que vous pratiquez la gouvernance. Si vous ne la pratiquez pas, commencez là, pas dans un portail d'achats.

Si vous voulez voir à quoi ressemble une gouvernance continue plutôt que la recherche d'un outil mono-règlement, parlez avec nous.

Avant d'acheter, posez cette question

DORA n'est pas le dernier règlement de résilience opérationnelle que vous rencontrerez. C'est l'un d'un ensemble convergent, et les suivants poseront la même question centrale avec des mots légèrement différents : pouvez-vous prouver, en continu, que vous comprenez vos dépendances TIC et que vous pouvez maintenir les services critiques dans leurs tolérances quand les choses tombent en panne.

Alors avant de chercher un logiciel de conformité DORA, demandez si le problème est qu'il vous manque un outil, ou qu'il vous manque la discipline sur laquelle l'outil est censé rendre compte. Si c'est la discipline, un produit ponctuel ne la réparera pas, et le registre d'informations sera tout aussi douloureux l'année prochaine. Si c'est réellement la couche de reporting, alors achetez une plateforme qui gouverne la discipline en continu et traite DORA comme un cadre parmi d'autres, pas un outil mono-règlement que vous remplacerez dès l'arrivée du prochain acronyme.

Les firmes qui arrêtent d'acheter et commencent à gouverner sont celles pour qui le prochain règlement est un exercice de cartographie plutôt qu'un exercice d'urgence.

Footnotes

1. L'article 2 du règlement énumère 21 catégories à lettres. La vingt-et-unième est celle des prestataires tiers de services TIC, qui ne sont pas des entités financières ; le décompte des types d'entités financières est donc de vingt. Certains résumés publics citent vingt-et-un en additionnant tous les points à lettres. ↩