Un logiciel DORA sert à rendre les décisions et preuves de résilience numérique retrouvables, à jour et exploitables par une entité financière. Il ne rend pas conforme un contrat incomplet, ne classe pas correctement un incident sans faits et ne remplace pas les responsabilités de l’organe de direction. Le bon achat dépend du point de rupture réel : registre d’information des prestataires TIC, circuit de déclaration, suivi des mesures de risque ou tests de résilience. Cette page aide à mettre plusieurs approches à l’épreuve d’un même dossier. Elle ne classe pas des éditeurs et n’attribue ni certification ni prix non vérifié.
Le règlement DORA s’applique depuis le 17 janvier 2025. Son article 2 définit les catégories d’entités financières et certaines exclusions ; un prestataire TIC y est traité différemment d’une entité financière soumise aux obligations opérationnelles. Une entreprise ne doit donc pas acheter une plateforme sur la seule étiquette « finance ». Elle doit confirmer sa catégorie, ses autorités compétentes, ses fonctions critiques ou importantes et les dispositions proportionnées à sa taille et à ses risques. Le guide DORA en France traite le périmètre de fond ; ici, la question est celle d’un outil capable de soutenir le travail vérifiable.
Commencer par l’obligation qui bloque réellement
Demandez aux équipes risques, informatique, achats et métiers de citer une tâche qui échoue aujourd’hui. Est-ce qu’un nouveau prestataire n’apparaît pas dans le registre ? Une filiale emploie-t-elle un identifiant différent pour le même groupe fournisseur ? Le responsable d’un incident majeur ignore-t-il quel canal de déclaration correspond à l’entité ? Ou bien les tests ont-ils produit des mesures sans propriétaire ? Ces problèmes n’appellent pas nécessairement la même solution. Un registre dédié peut suffire au premier ; un outil de gestion du risque TIC ou une plateforme GRC devient plus pertinent lorsque les décisions doivent traverser plusieurs équipes.
Le cadre de gestion du risque TIC des articles 5 à 16 contient gouvernance, identification, protection, détection, réponse, rétablissement et apprentissage. Les articles 17 à 23 portent sur les incidents ; les articles 24 à 27 sur les tests ; les articles 28 à 30 sur le risque des prestataires. Ne réduisez pas DORA à un fichier de contrats. Une organisation peut avoir un registre très propre et aucun exercice crédible de reprise. À l’inverse, un bon dispositif de continuité peut laisser des accords tiers mal documentés. Pour chaque domaine, indiquez ce qui existe, qui décide et quel élément l’outil doit produire. Le plan de continuité et le plan de reprise aident à décrire les scénarios sans faire du logiciel un substitut au test.
Évitez de demander une démonstration sur un dossier idéal fourni par l’éditeur. Préparez un cas fictif mais réaliste : deux entités du groupe utilisent le même prestataire cloud ; l’une lui confie une fonction critique ou importante, l’autre un service moins sensible. Un sous-traitant change de lieu d’exécution et une panne perturbe seulement l’une des entités. Le candidat doit conserver ces différences. S’il transforme automatiquement tous les services en fonctions critiques, ou s’il masque la dépendance commune, sa carte est peu utile. Faites expliquer les champs laissés inconnus plutôt que de les compléter au hasard.
Le registre d’information n’est pas le registre RGPD
L’article 28, paragraphe 3, de DORA exige un registre des informations relatif à tous les accords contractuels portant sur l’utilisation de services TIC fournis par des prestataires tiers. Il est tenu et mis à jour au niveau de l’entité et, selon le cas, à des niveaux sous-consolidé et consolidé. Le modèle d’exécution est précisé par le règlement d’exécution (UE) 2024/2956. L’AMF décrit la remise du registre à l’autorité compétente au moins une fois par an pour les entités relevant d’elle. Vérifiez le canal et le calendrier applicables à la catégorie d’entité étudiée, au lieu de copier une ancienne date de campagne.
Un registre DORA relie entités, accords, services TIC, fonctions, prestataires et, selon les exigences du modèle, leurs chaînes de sous-traitance. Le guide du registre d’information DORA détaille les données attendues. Le registre des activités de traitement du RGPD décrit, lui, des finalités et flux de données personnelles sous l’article 30 du RGPD. Les deux peuvent référencer le même hébergeur, mais ne sont ni identiques ni interchangeables. Un logiciel multi-référentiels est intéressant s’il maintient une identité fournisseur cohérente tout en préservant deux exports et deux bases juridiques distincts. Demandez au candidat de montrer ces liens et la correction d’une donnée commune sans écraser l’historique de l’autre registre.
Dans la démonstration, créez un accord, ajoutez un service puis changez le sous-traitant annoncé par le prestataire. Le logiciel doit permettre de distinguer une information déclarée par le fournisseur, une confirmation contractuelle et un fait technique vérifié. Exportez ensuite le jeu de données dans le format demandé pour le registre et passez-le par une validation de structure disponible pour la campagne de remise concernée. Une jolie fiche à l’écran n’assure ni l’exhaustivité des relations ni la conformité de l’export. Si l’outil revendique un modèle « natif », demandez sa version, sa date de mise à jour et une démonstration sur votre structure de groupe.
Un tableur reste possible si l’entité maîtrise les identifiants, versions, relations et contrôles nécessaires. DORA n’achète pas une licence à votre place. En revanche, une liste plate devient fragile lorsque plusieurs entités et accords partagent des services et fournisseurs. Comparez donc le taux d’erreurs et le temps de correction sur votre cas fictif, avec le même nombre de personnes, plutôt que d’affirmer qu’Excel échoue toujours. Un export lisible et vérifiable a plus de valeur qu’un tableau de bord qui ne permet pas de reconstituer les sources.
Incidents : qualification, décision et canal
L’article 19 impose aux entités concernées de notifier les incidents majeurs liés aux TIC à leur autorité compétente, selon les critères, délais et modèles précisés par les textes techniques, notamment les règlements (UE) 2025/301 et 2025/302. Tous les événements de sécurité ne sont pas automatiquement des incidents majeurs DORA. Le système doit conserver la chronologie : détection, faits connus, classification, approbation de la notification, transmission, informations complémentaires et clôture. Un compteur isolé est dangereux s’il démarre sur le mauvais événement ou ne distingue pas la qualification de l’incident de la connaissance initiale. Faites tester les champs manquants et la correction d’un rapport après envoi.
En France, le canal dépend de l’autorité et du statut. L’ACPR publie une FAQ DORA sur les entités relevant d’elle, les remises et les cas d’intermédiaires. L’AMF indique ses formulaires et canaux pour les entités qu’elle supervise. Demandez à l’éditeur de configurer le cas réel de l’acheteur plutôt que de promettre un « envoi ACPR » universel. Conservez la preuve de dépôt et les échanges de reprise si un canal ne fonctionne pas. La solution doit laisser une personne autorisée valider la classification et le contenu avant transmission.
Une panne du prestataire de paiement fictif peut aussi constituer une violation de données personnelles, mais les deux analyses ne se confondent pas. Le RGPD article 33 impose, lorsque ses conditions sont réunies, une notification à la CNIL sans retard injustifié et, si possible, dans les 72 heures après connaissance, sauf si le risque pour les personnes est improbable ; un retard doit être motivé. DORA suit son propre cadre. Un outil partagé peut réutiliser la chronologie et les faits, mais doit garder les destinataires, critères, décisions et preuves séparés. La gestion des incidents en registre RGPD traite cette autre obligation. Si une autre entité du groupe relève aussi de la NIS2, le choix d’un logiciel de conformité NIS2 mérite une évaluation distincte : cette qualification ne découle pas du seul usage d’un prestataire TIC DORA.
Prestataires, contrats, concentration et sortie
Avant la signature, l’article 28 demande d’évaluer les risques liés au service TIC et, pour les fonctions critiques ou importantes, la concentration, l’auditabilité et la sortie. L’article 30 fixe des éléments contractuels minimaux, avec exigences additionnelles pour les services qui soutiennent de telles fonctions. Le guide des prestataires TIC explique le contrat ; le choix du logiciel consiste à voir si l’acheteur peut relier l’accord à un service, une fonction et une décision datée. Une simple pièce jointe marquée « conforme » n’établit pas que ses clauses répondent au contexte.
Dans notre cas fictif, un même hébergeur soutient deux fonctions. Demandez à l’outil de montrer le risque de concentration sans conclure automatiquement qu’il est interdit. Ajoutez une clause de changement de lieu et vérifiez qui reçoit l’alerte, quel contrat est concerné et quel service doit être réévalué. Puis simulez la sortie : quels jeux de données, configurations, journaux et dépendances faut-il transférer ? Qui valide un prestataire de remplacement et à quel moment un essai de reprise est-il réalisé ? Une stratégie de sortie est un travail opérationnel, pas un bouton de résiliation. Les conditions plus strictes liées à une fonction critique ou importante doivent rester visibles.
Vérifiez les responsabilités du prestataire dans la chaîne. L’autorisation de sous-traitance, l’information sur les changements, les droits d’accès et d’audit ainsi que les régions de traitement doivent correspondre aux accords réellement conclus. Si l’entité est aussi responsable de données personnelles, l’article 28 RGPD peut imposer un contrat ou autre acte juridique contraignant distinct pour la sous-traitance des données ; ce n’est pas le même article 28 que celui de DORA. Un logiciel qui confond les deux parce que leur numéro est identique augmente le risque de mauvaise décision. Le guide RGPD sur la sous-traitance aide à séparer ces engagements.
Tests de résilience : couvrir le bon niveau
DORA prévoit des tests de résilience opérationnelle numérique adaptés et documentés. Les tests de pénétration fondés sur la menace, ou TLPT, ne concernent pas toutes les entités de façon indifférenciée : les autorités identifient celles qui répondent aux critères et le cadre est spécialisé. Le guide des TLPT explique cette branche. N’achetez pas un module TLPT onéreux parce qu’un tableau de conformité rouge laisse croire que chaque petite entité y est soumise. Le candidat doit pouvoir représenter une décision « non applicable selon l’évaluation et les instructions compétentes » avec sa source, et relier un test applicable aux vulnérabilités et à leur remédiation.
Une question utile consiste à demander comment un résultat de test modifie le risque d’un service TIC. Une faiblesse de sauvegarde peut nécessiter une mesure technique, une révision d’accord et un essai de reprise. L’outil doit rendre ce chemin visible sans dupliquer trois tâches contradictoires. Il faut aussi pouvoir démontrer que la mesure a été mise en œuvre et vérifiée, pas seulement attribuée. Une plateforme GRC peut être adaptée à cette circulation ; un module registre seul ne la couvrira peut-être pas. C’est un besoin à éprouver, non une capacité présumée d’une marque.
Quatre familles d’outils à comparer sans faux prix
Un module de registre dédié peut convenir si les autres processus ont déjà des propriétaires et des preuves solides. Un outil TPRM est pertinent quand le suivi des prestataires et des contrats est la faiblesse principale. Une plateforme de risque TIC/GRC peut relier incidents, contrôles, tests et direction. Un dispositif multi-référentiels peut éviter de ressaisir les informations communes à DORA, RGPD ou d’autres cadres, à condition de distinguer les obligations et les exports. Le guide des outils multi-référentiels peut éclairer cette dernière option et un cahier des charges centré sur les preuves aide à rendre les offres comparables. Pour une banque ou une assurance, la comparaison de logiciels sectoriels est un autre point de départ ; elle ne remplace pas l’essai DORA de votre catégorie et de votre autorité.
Demandez le même devis pour chaque famille : entités, utilisateurs, accords TIC, volume d’incidents, formats d’import/export, aide à la configuration, support, maintenance du modèle réglementaire et réversibilité. Un prix publié sans ce périmètre ne permet pas de comparer les offres. Ajoutez le travail interne pour identifier les services, vérifier les contrats, nettoyer les fournisseurs et maintenir les décisions. Ne supposez pas qu’un logiciel DORA coûte moins qu’un tableur ni qu’il évite une sanction. Son intérêt économique se mesure par la qualité des informations et la réduction des corrections sur votre essai.
Avant de signer, réalisez l’export complet : registre, décisions de qualification, dossiers d’incidents, liens contractuels, tâches, preuves et versions. Faites expliquer le résultat à une personne qui n’a pas suivi la démonstration. Demandez ce qui reste accessible après la fin du contrat, quelles données sont restituées ou supprimées et comment les copies sont traitées selon les obligations applicables. Un fournisseur qui ne peut expliquer la sortie de sa propre plateforme n’aide pas beaucoup à satisfaire l’esprit des exigences de résilience.
Questions fréquentes
DORA impose-t-il un logiciel particulier ?
Non. Le règlement impose des obligations et des livrables, mais ne désigne pas un logiciel. Un tableur contrôlé peut être possible pour un périmètre simple. Comparez l’effort et les erreurs sur un registre représentatif avant d’acheter, puis vérifiez les autres processus que le registre ne couvre pas.
Tout prestataire TIC est-il lui-même une entité financière soumise aux mêmes obligations ?
Non. L’article 2 distingue les catégories d’entités financières et les prestataires TIC. Les relations contractuelles, les exigences applicables au prestataire et l’éventuelle supervision européenne des prestataires désignés critiques ne signifient pas que chaque fournisseur hérite de toutes les obligations opérationnelles de sa cliente financière.
Faut-il un module TLPT pour chaque entité ?
Non. DORA prévoit un programme de tests proportionné et un cadre TLPT ciblé. Confirmez le statut de l’entité et les instructions de l’autorité compétente avant de choisir le module ; en attendant, les tests et leur remédiation doivent rester traçables.
Un seul outil remplace-t-il les analyses DORA et RGPD ?
Il peut partager une cartographie technique et des faits, mais pas fusionner les deux décisions juridiques. Les registres, destinataires de notifications et critères d’application diffèrent. Testez un incident et un prestataire communs pour vérifier que le produit conserve ces distinctions.
Choisir après l’essai
Sélectionnez l’approche qui permet de refaire, sous contrôle humain, la trajectoire d’un service TIC depuis le contrat jusqu’à l’incident, la mesure corrective et la sortie. Exigez le bon format de registre et les bons canaux français pour votre statut, mais ne confondez pas leur présence dans un menu avec une transmission réussie. Le dossier d’essai, l’export et les conditions contractuelles sont des preuves plus fortes qu’une promesse de conformité DORA « automatique ».