Logiciel de conformité DORA : quand quitter Excel et comment choisir sans subir un RFP trompeur

Un logiciel de conformité DORA devient nécessaire lorsque l’organisation ne peut plus produire, dans les délais et sans rapprochements manuels, un registre d’information cohérent, la preuve d’un contrôle ou une vue consolidée de ses risques liés aux TIC. Le seuil ne dépend pas d’un nombre universel d’entités : il est franchi dès que les versions concurrentes, les dépendances entre prestataires, les incidents et les demandes d’audit rendent Excel non traçable ou le cabinet indispensable à chaque mise à jour. DORA n’impose pas l’achat d’un logiciel ; il impose des résultats que le dispositif doit pouvoir reproduire et justifier.

Réponse courte : basculer quand la preuve n’est plus reproductible

Le critère de bascule est l’impossibilité de restituer rapidement une information complète, datée et attribuable sans retraitement manuel. Un test simple consiste à demander aux équipes de produire, puis de reproduire quelques jours plus tard, quatre livrables sur le même périmètre :

1. le RoI — registre d’information — aux niveaux individuel, sous-consolidé ou consolidé requis par l’article 28, paragraphe 3, du règlement DORA ;
2. la chaîne reliant une entité, une fonction, le service TIC utilisé, le contrat, le prestataire tiers de services TIC et ses sous-traitants ;
3. l’historique d’une décision ou d’une validation, avec son auteur, sa date et les éléments examinés ;
4. un export exploitable sans reconstruction parallèle du fichier.

Le test décisif : produire deux fois le même périmètre et obtenir le même résultat

Des écarts entre les deux productions révèlent une faiblesse de piste d’audit : données modifiées sans journal, règles de consolidation appliquées manuellement, pièces conservées dans des messageries ou arbitrages non rattachés à leur source. Une restitution correcte obtenue grâce à l’intervention de la personne qui « connaît le fichier » ne constitue pas un processus reproductible.

Pourquoi aucun seuil universel d’entités ou de prestataires n’est défendable

Une structure mono-entité peut dépasser ce seuil avec plusieurs délégataires, des chaînes de sous-traitance et des contrats hétérogènes. À l’inverse, un groupe peut encore maîtriser un tableur si son périmètre est limité, ses identifiants normalisés et ses mises à jour contrôlées. Le bon seuil est donc opérationnel : nombre de rapprochements manuels, fréquence des changements, niveau de consolidation demandé et capacité à produire une preuve sans dépendance individuelle.

Signaux d’alerte : Excel et le cabinet deviennent un goulot d’étranglement

Le tableur cesse de scaler lorsque la conformité repose sur des réconciliations humaines entre entités, fonctions, contrats, incidents et prestataires. Le cabinet atteint sa limite lorsqu’il devient le détenteur opérationnel de la donnée plutôt que son contrôleur ou son conseiller.

Multi-entités : les doublons empêchent la consolidation fiable

Les signaux les plus visibles sont des identifiants différents pour un même prestataire, plusieurs versions d’un contrat, des sous-traitants saisis sous des dénominations non normalisées ou des services TIC rattachés à des criticités différentes selon l’entité. La consolidation additionne alors des lignes au lieu de reconstituer des dépendances.

RoI : la mise à jour périodique masque une donnée opérationnelle obsolète

Le RoI devient fragile lorsqu’il est actualisé seulement avant une remise ou un contrôle, par collecte de fichiers et de courriels. Le règlement d’exécution (UE) 2024/2956 fixe les modèles normalisés applicables au registre, avec une restitution lisible par machine en xBRL-CSV. Un fichier techniquement exportable reste toutefois inexploitable si les contrats, fonctions critiques ou importantes, prestataires et sous-traitants ne sont pas reliés et gouvernés en amont. Les erreurs récurrentes sont détaillées dans notre analyse du registre d’information DORA.

Audits et contrôles : l’absence d’historique transforme chaque demande en projet

La bascule est justifiée lorsque l’organisation ne peut pas isoler les changements depuis le dernier audit, retrouver le propriétaire d’une donnée ou démontrer qui a approuvé une évaluation. Autres alertes : pièces collectées à nouveau à chaque campagne, registre reconstruit par le cabinet et export impossible sans ses fichiers de travail. Le cabinet devient alors un opérateur externalisé du dispositif, avec un risque de continuité et de connaissance.

Grille de choix : évaluer des preuves et des exports, pas une liste de fonctions

Un logiciel doit être évalué sur des scénarios exécutés avec des données représentatives de l’acheteur. Chaque scénario doit aboutir à un livrable vérifiable, noté selon son exactitude, sa traçabilité et le volume de retraitements restant.

RoI et export superviseur : tester les modèles, identifiants et consolidations

Le candidat doit importer un échantillon de contrats et produire le RoI selon les modèles réglementaires applicables. Le test doit couvrir les identifiants, les contrôles de cohérence, les relations entre tables et les niveaux individuel, sous-consolidé et consolidé. Un « export DORA » annoncé dans une fiche produit ne vaut rien si des corrections manuelles restent nécessaires avant transmission.

Incidents : vérifier la chronologie, la classification et les versions

Le scénario doit partir d’un événement réel ou fictif documenté et montrer sa qualification, sa chronologie, les validations et la conservation des versions notifiées. Il faut pouvoir distinguer les informations disponibles à chaque étape, retrouver l’auteur d’un changement et rattacher les éléments ayant conduit à classer ou non un incident majeur lié aux TIC. La logique attendue est détaillée dans l’arbre de décision de classification des incidents.

TPRM : relier criticité, concentration, sous-traitance et sortie

Le TPRM ne doit pas être un questionnaire fournisseur isolé. Le test doit relier l’évaluation du tiers aux services fournis, aux fonctions soutenues, aux contrats, aux sous-traitants, au risque de concentration et aux stratégies de sortie. Une vue fournisseur sans dépendances par entité et par fonction ne permet pas de mesurer l’exposition réelle. Voir également le cycle de vie TPRM sous DORA.

Preuves : exiger source, propriétaire, date, statut et historique

Pour chaque contrôle, la plateforme doit conserver la source, le propriétaire, la date de collecte, le statut, l’approbateur, les commentaires et l’historique. Une pièce jointe déposée dans une bibliothèque n’est pas, à elle seule, une preuve de contrôle : il faut démontrer ce qui a été vérifié, selon quelle règle et avec quelle conclusion.

Réversibilité : récupérer données, relations et journaux

Le test final consiste à sortir les données, pièces jointes, relations, référentiels et journaux dans des formats réutilisables. Les API, délais de restitution, coûts, documentation et conditions de sortie doivent être contractualisés. Cette grille doit s’appliquer sans exception à tout éditeur évalué, Axenia compris.

Ce qu’un logiciel ne remplace pas : décision, responsabilité et négociation

La plateforme structure les données et conserve les preuves ; elle ne transfère ni la responsabilité réglementaire ni les arbitrages.

La direction et les métiers restent propriétaires des arbitrages

L’article 5 de DORA maintient la responsabilité de l’organe de direction sur le cadre de gestion du risque lié aux TIC. L’entité doit décider quelles fonctions sont critiques ou importantes, apprécier la matérialité d’un incident, accepter ou refuser un risque résiduel et valider une stratégie de sortie. Un score calculé par le logiciel peut instruire la décision, pas la prendre.

Le cabinet apporte interprétation, revue indépendante et négociation

Le cabinet reste pertinent pour interpréter une exigence, revoir le dispositif, challenger une classification, négocier un contrat ou préparer un contrôle. Il ne devrait pas être nécessaire pour chaque modification de prestataire ou chaque export. La complémentarité est nette : le cabinet conseille et contrôle ; l’entité gouverne ; la plateforme opère la donnée et sa traçabilité.

La plateforme conserve, relie et restitue les décisions prises

L’article 28 précise que le recours à des services TIC ne décharge pas l’entité financière de ses obligations. L’article 30 impose notamment la description des services, les localisations, la protection des données, les conditions d’accès, de récupération et de restitution, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation et la participation aux actions de sensibilisation. Pour les services soutenant des fonctions critiques ou importantes s’ajoutent notamment des objectifs de performance détaillés, des droits d’audit, des dispositifs de continuité testés, la participation aux tests, l’encadrement de la sous-traitance et des stratégies de sortie. Le détail figure dans notre analyse des clauses contractuelles obligatoires de l’article 30.

Erreurs de sélection : cinq raccourcis qui rendent le RFP inutilisable

Confondre couverture fonctionnelle et preuve de contrôle

Les réponses oui/non doivent être exclues pour les exigences déterminantes. Remplacez « gestion du RoI : oui/non » par une démonstration produisant le registre, ses contrôles de cohérence et son journal de modifications.

Croire qu’un outil peut certifier à lui seul la conformité DORA

Une déclaration de « conformité DORA » de l’éditeur ne remplace pas l’analyse du paramétrage, des données, des processus et des responsabilités. Aucun logiciel ne peut certifier que les classifications, risques acceptés ou clauses négociées par l’entité sont juridiquement suffisants.

Évaluer une démonstration sans données représentatives

Un environnement préchargé masque les difficultés d’identification, de dédoublonnage et de consolidation. Le contrôle éliminatoire doit porter sur un échantillon fourni par l’acheteur : contrats réels anonymisés, variantes de dénomination, sous-traitants et historique incomplet.

Sous-estimer la reprise des données et leur gouvernance

Le RFP doit préciser qui nettoie les données, rapproche les prestataires, qualifie les fonctions, valide les migrations et maintient chaque objet. Sans responsabilités de mise à jour, le nouveau logiciel reproduira les défauts du tableur dans une interface plus coûteuse.

Omettre la réversibilité et recréer une dépendance critique

L’absence d’engagement sur les exports, journaux, API, pièces jointes, délais et coûts de restitution crée une nouvelle dépendance envers un prestataire TIC. La réversibilité doit être testée avant la signature, puis intégrée aux conditions contractuelles et à la stratégie de sortie.