DORA à taille humaine : méthode pour les structures qui n'ont pas d'équipe dédiée

Réponse rapide — Une petite structure peut tenir DORA sans équipe dédiée, à condition de partir de ses fonctions critiques, et non de ses contrats. Distinguez proportionnalité (article 4), cadre simplifié (article 16) et allègements microentreprise. Puis enchaînez sept étapes : cadrage, fonctions, dépendances et risques, mesures techniques, prestataires, preuves, maintien.

Étape	Objectif	Livrable
1. Cadrer	Régime, rôles, externalisation	Note de cadrage validée
2. Fonctions	Criticité métier	3 à 5 fonctions critiques ou importantes
3. Dépendances & risques	Chaîne et traitements	Cartographie + RoI cohérent
4. Technique	Preuves de sécurité / reprise	État des mesures par périmètre
5. Prestataires	Clauses et sortie	Fiches prestataires critiques
6. Preuves	Incidents et tests	Procédure + plan de tests
7. Maintien	Survivre à une personne	Calendrier et reporting direction

Pour beaucoup de sociétés de gestion, d'établissements de paiement ou de courtiers, DORA a d'abord été lu comme un texte écrit pour les grandes banques. Près de deux ans après son entrée en application, la supervision est active. La question n'est plus « sommes-nous concernés ? », mais « comment tenir avec nos moyens ? ».

Dans ces structures, DORA repose souvent sur une seule personne, qui porte déjà la conformité, les risques et parfois la relation avec une informatique externalisée. Cet article propose une méthode en sept étapes, pensée pour cette réalité. Chaque étape a un objectif, une façon de faire, un livrable et un piège à éviter. Pour structurer le dispositif dans l'outil : Démarrer un dispositif DORA.

Avant la méthode : ce que la proportionnalité permet vraiment

La phrase la plus répandue dans les petites structures est « nous sommes petits, DORA s'applique en version allégée ». Elle est rarement exacte.

Proportionné ne veut pas dire simplifié

DORA distingue deux mécanismes, souvent confondus.

• Le principe de proportionnalité (article 4) s'applique à toutes les entités. Il ne supprime aucune exigence. Il permet de dimensionner la réponse selon la taille, le profil de risque global, la nature, l'échelle et la complexité de l'activité.
• Le cadre simplifié de gestion du risque TIC (article 16), précisé par le RTS 2024/1774, écarte les articles 5 à 15 au profit d'un cadre documenté allégé. Mais il ne vise qu'une liste fermée d'entités : petites entreprises d'investissement non interconnectées, établissements de paiement et de monnaie électronique exemptés, établissements de crédit exemptés dans les conditions de l'article 16, petites institutions de retraite professionnelle.

Une société de gestion de 30 personnes ou un établissement de paiement agréé ne figure pas dans cette liste. Il relève du régime complet, appliqué avec proportionnalité. Sur le contexte SGP : Supervision AMF des sociétés de gestion.

Les vraies marges de manœuvre

Le texte prévoit quelques allègements ciblés, notamment pour les microentreprises (moins de 10 personnes et 2 M€ de chiffre d'affaires ou de bilan, article 3(60)) :

• pas d'obligation de confier le risque TIC à une fonction de contrôle indépendante (article 6(4)) ;
• une revue du cadre de gestion du risque TIC « périodique » plutôt qu'annuelle (article 6(5)) ;
• pas de stratégie formalisée sur le risque lié aux prestataires tiers (article 28(2)).

Au-delà de ces cas, la proportionnalité joue sur le « comment » : la profondeur de l'analyse, la fréquence des tests, le niveau de formalisme. Jamais sur le « quoi ».

La proportionnalité se démontre

Dire « nous sommes petits » ne suffit pas. L'article 4 demande aussi aux autorités de tenir compte de la proportionnalité lors de leurs contrôles. Encore faut-il leur donner de quoi l'apprécier.

Un choix de proportionnalité non écrit ressemble à une lacune. Un choix argumenté (« nous testons notre plan de continuité une fois par an, par un exercice sur table, parce que nos deux fonctions critiques reposent sur un seul prestataire ») devient une décision défendable. Toute la méthode qui suit repose sur ce réflexe : chaque arbitrage est tracé, avec sa justification.

Étape 1 : fixer le cadre et décider qui porte quoi

Objectif : savoir exactement à quel régime on est soumis, et qui est responsable de quoi, avant de produire le moindre document.

Comment faire — étape 1

1. Qualifier son régime. Article 16 ou régime complet ? Microentreprise ou non ? Cette réponse dimensionne tout le chantier. Elle tient en une page, à faire valider.
2. Placer l'organe de direction au bon endroit. Il porte la responsabilité finale du risque TIC (article 5(2)) et doit entretenir ses connaissances (article 5(4)). Dans une petite structure, c'est un avantage : les dirigeants sont accessibles et peuvent réellement s'impliquer, là où un grand groupe se contente souvent d'une validation formelle. Voir Responsabilité de l'organe de direction.
3. Répartir les rôles. Qui pilote le dispositif ? Qui suit les prestataires (article 5(3), sauf microentreprises) ? Qui qualifie un incident un vendredi soir ? Une matrice simple suffit, à condition que chaque rôle ait un titulaire et un suppléant.
4. Décider ce que l'on externalise. C'est ici que se pose la question du RSSI externe ou d'une fonction mutualisée.

Externaliser l'exécution, jamais la responsabilité

Un RSSI externe à temps partagé est souvent la réponse la plus pertinente pour une structure qui n'a ni le volume ni le budget d'un poste à temps plein. DORA l'autorise : l'article 6(10) permet de confier la vérification de conformité à une entreprise externe.

Mais le même article précise que l'entité reste pleinement responsable. Une fonction externalisée se pilote comme n'importe quel prestataire :

• un mandat écrit, avec un périmètre clair (ce que le RSSI externe fait, ce qu'il ne fait pas) ;
• des livrables et un calendrier, pas seulement un volume de jours ;
• un reporting direct à l'organe de direction, au moins semestriel ;
• une réversibilité : la documentation et les preuves appartiennent à l'entité, pas au prestataire.

Le bon modèle est simple : l'expertise vient de l'extérieur, la décision reste à l'intérieur.

Livrable — étape 1

Une note de cadrage de deux à trois pages : régime applicable, matrice des rôles, fonctions externalisées et leur encadrement. Validée par la direction.

Piège — étape 1

Croire qu'en externalisant la fonction, on a externalisé le sujet. Une direction qui signe ce qu'elle ne comprend pas reste la première exposée lors d'un contrôle.

Étape 2 : partir des fonctions, pas des contrats

Objectif : identifier les quelques fonctions dont l'interruption mettrait réellement l'entité en difficulté. C'est l'étape que presque tout le monde saute.

Le scénario classique

La plupart des structures commencent par l'inventaire des fournisseurs. On extrait la liste depuis la comptabilité ou les achats, on obtient 150 lignes, et l'on tente de remplir le registre d'information. Trois mois plus tard, le fichier est à moitié complet, personne ne sait lesquels de ces prestataires comptent vraiment, et l'énergie est épuisée.

Le problème n'est pas le volume. C'est l'absence de critère pour savoir où mettre l'effort.

La bonne entrée : les fonctions critiques ou importantes

DORA définit une fonction critique ou importante comme une fonction dont la perturbation est susceptible de nuire sérieusement à la performance financière, à la continuité de l'activité ou au respect des obligations réglementaires (article 3(22)). C'est elle qui déclenche les exigences renforcées : clauses contractuelles complètes, stratégie de sortie, tests.

1. Lister les activités de l'entité à un niveau métier : gestion des portefeuilles, passage d'ordres, valorisation, relation client, paiements, reporting réglementaire, comptabilité. Une dizaine de lignes suffit.
2. Évaluer l'impact d'une interruption pour chacune : sur les clients, sur les finances, sur les obligations réglementaires. Une grille simple à trois niveaux fait l'affaire.
3. Fixer des objectifs de reprise pour les fonctions retenues : combien de temps peut-on s'en passer, combien de données peut-on perdre ?
4. Faire valider la liste par la direction, avec la justification de chaque choix.

Dans une petite structure, on aboutit en général à trois à cinq fonctions critiques ou importantes. C'est précisément ce qui rend le chantier tenable.

Livrable — étape 2

Une cartographie des fonctions, avec leur niveau de criticité, leurs objectifs de reprise et la justification de chaque classement.

Piège — étape 2

Confondre « prestataire important » et « fonction critique ». Un fournisseur coûteux n'est pas forcément critique. Et un petit éditeur de logiciel peut porter à lui seul une fonction critique. Ce sont les fonctions qui disent quels tiers comptent, pas l'inverse.

Étape 3 : cartographier les dépendances et les risques

Objectif : relier chaque fonction critique aux applications, aux actifs et aux prestataires dont elle dépend. Puis identifier les risques qui pèsent sur cette chaîne. Le registre d'information et la cartographie des risques deviennent alors des conséquences de l'analyse, et non des points de départ.

Comment faire — étape 3

1. Pour chaque fonction critique, remonter la chaîne : quelles applications l'exécutent ? Sur quelle infrastructure ? Quel prestataire fournit, héberge ou maintient chacune d'elles ? Un atelier d'une heure par fonction, avec la personne qui l'opère au quotidien, suffit souvent.
2. Identifier les sous-traitants qui comptent. Un éditeur hébergé chez un fournisseur cloud crée une dépendance de rang 2. Pour les fonctions critiques, elle doit être connue.
3. Compléter ensuite le reste du périmètre. Attention : le registre doit couvrir tous les accords de services TIC (article 28(3)), pas seulement ceux qui supportent des fonctions critiques. Partir des fonctions ne dispense pas de l'exhaustivité. Cela change la profondeur : analyse complète pour les tiers critiques, informations de base pour les autres.
4. Rattacher les contrats à chaque prestataire, puis alimenter le registre à partir de cette cartographie.

Cartographier les risques

Une fois la chaîne connue, la cartographie des risques (article 8) devient utile : rattacher chaque risque à un objet actionnable (actif, application, prestataire), partir de scénarios concrets (perte du prestataire principal, rançongiciel, SaaS critique, personne clé), évaluer simplement, puis décider de réduire, transférer ou accepter — avec signature de la direction. Elle oriente directement les garanties (étape 4), les clauses (étape 5) et les tests (étape 6).

Livrable — étape 3

Une cartographie des dépendances (fonctions, applications, actifs, prestataires, contrats), un registre d'information cohérent avec elle, et une cartographie des risques avec son plan de traitement.

Piège — étape 3

Tenir la cartographie et le registre dans deux fichiers séparés. Au premier changement de prestataire, ils divergent, et le registre remis au superviseur ne décrit plus la réalité.

Étape 4 : reprendre la main sur la sécurité et la résilience technique

Objectif : s'assurer que les mesures techniques exigées par DORA (protection, détection, sauvegarde, reprise) existent réellement sur tout le périmètre, quel que soit celui qui les opère. C'est le volet le plus souvent oublié par les petites structures, parce qu'il est « chez le prestataire ».

Ce que DORA attend, et comment le prouver

Les articles 9 à 12, précisés par le RTS 2024/1774, couvrent un socle technique : accès et authentification forte, chiffrement, correctifs, vulnérabilités, journalisation, détection, sauvegarde, restauration, objectifs de reprise. Ces exigences s'appliquent à l'entité, même quand elle n'opère aucun serveur. La question n'est pas « qui fait ? », mais « comment le prouve-t-on ? ».

Cas le plus fréquent : une infogérance unique. L'entité a souvent perdu la visibilité ; la responsabilité, elle, est restée chez elle. Il faut des garanties écrites sur sécurité (MFA, comptes à privilèges, correctifs), détection (qui surveille, comment l'alerte vous parvient), sauvegardes (périmètre, fréquence, copie isolée), RTO/RPO alignés sur les fonctions critiques, notification d'incident compatible avec vos délais, et preuves (PV de restauration, rapport de sécurité). Un prestataire qui ne peut pas répondre est, en soi, un risque.

En cloud / SaaS, trois idées reçues à corriger : « c'est sauvegardé » (souvent faux pour vos données), « le fournisseur s'occupe de la sécurité » (configuration, admin et journaux restent chez vous), « nos outils sont connus » (le Shadow IT compte aussi). En interne, la maîtrise est totale — et la charge de preuve aussi, avec le risque classique de la personne unique.

Modèle	Ce que vous ne voyez pas	Ce qu'il faut obtenir ou faire	La preuve
Infogérance unique	Les mesures réellement en place	Garanties : sécurité, détection, sauvegardes, RTO/RPO	PV de restauration, rapports du prestataire
Cloud et SaaS	Sauvegarde de vos données, votre configuration	Revue de config, sauvegarde indépendante, inventaire SaaS	Rapport de revue, tests de restauration
Interne	Rien, mais tout repose sur vous	Socle technique, tests, restaurations testées	Rapports, journaux, inventaire

Livrable — étape 4

Pour chaque périmètre, un état des mesures en place, les garanties obtenues, et les lacunes reportées dans la cartographie des risques.

Piège — étape 4

Confondre disponibilité et résilience. Un service qui « ne tombe jamais » n'est pas une capacité démontrée à restaurer vos données et à reprendre vos fonctions critiques dans les délais fixés.

Étape 5 : encadrer les prestataires critiques

Objectif : réduire le risque là où il est réellement concentré. Dans une petite structure, il porte presque toujours un nom : le prestataire unique.

La réalité des petites structures

Le risque n'est pas d'avoir trop de prestataires. C'est d'en avoir un seul qui porte toute l'informatique : infogérance globale, DSI externalisée, ou éditeur métier qui fait tourner l'essentiel de l'activité. Ce prestataire devient, de fait, le cœur opérationnel de l'entité.

Comment faire — étape 5

1. Évaluer chaque prestataire critique avant et pendant la relation : sécurité, continuité, solidité financière, localisation des données, sous-traitance. Les garanties techniques obtenues à l'étape 4 en forment le socle ; un questionnaire proportionné couvre le reste. Voir le questionnaire fournisseur TIC.
2. Mettre les contrats à niveau, en commençant par ceux qui comptent. L'article 30 impose des clauses pour tous les contrats TIC, et des clauses renforcées pour ceux qui supportent une fonction critique : niveaux de service précis, droits d'accès et d'audit, assistance en cas d'incident, participation aux tests, stratégie de sortie.
3. Choisir ses batailles. On ne renégocie pas les conditions standard d'un grand fournisseur cloud. On s'appuie sur ses engagements publiés, et l'on concentre la négociation sur les prestataires avec lesquels on a un vrai poids : l'infogérant, l'éditeur spécialisé.
4. Rendre la sortie réaliste. Pour chaque fonction critique, une stratégie de sortie (article 28(8)) qui répond à trois questions : vers qui ? en combien de temps ? avec quelles données ? Une page par prestataire, mais une page crédible.

Livrable — étape 5

Une fiche par prestataire critique : évaluation, état des clauses de l'article 30, clauses manquantes et plan d'action, stratégie de sortie.

Piège — étape 5

Signer un avenant « DORA » fourni par le prestataire et considérer le sujet clos. Une clause d'audit que l'on n'a jamais exercée, ou une sortie que personne n'a chiffrée, ne protège pas grand-chose.

Étape 6 : passer de la documentation à la preuve

Objectif : démontrer que le dispositif fonctionne, pas seulement qu'il est écrit. C'est exactement ce que regardent les superviseurs depuis 2026.

Les incidents : être prêt avant le premier

Beaucoup de petites structures n'ont jamais déclaré d'incident majeur. Ce n'est pas une preuve de maturité. La vraie question est : sauriez-vous qualifier un incident et le notifier dans les délais (notification initiale dans les 4 heures suivant la classification, au plus tard 24 heures après la détection, RTS 2025/301) ?

1. Une procédure courte : qui détecte, qui qualifie, qui décide de notifier, qui prévient le prestataire.
2. Une grille de classification reprenant les critères réglementaires, pré-remplie avec les fonctions critiques identifiées à l'étape 2.
3. Un registre de tous les incidents, majeurs ou non. C'est lui qui prouve que le processus tourne.

Détail : Notification d'incident majeur DORA.

Les tests : proportionnés, mais réels

Les tests avancés de type TLPT ne concernent que les entités désignées par l'autorité. Pour les autres, un programme de tests proportionné suffit, à condition qu'il soit exécuté :

• un exercice sur table par an sur un scénario tiré de la cartographie des risques (perte du prestataire principal, rançongiciel) ;
• un test de restauration des sauvegardes des fonctions critiques ;
• les tests de vulnérabilité ou d'intrusion adaptés à l'exposition réelle ;
• et surtout, le suivi des actions correctives issues de chaque test.

Les politiques : courtes et appliquées

Une politique de 40 pages que personne n'applique pèse moins qu'une procédure de trois pages, testée, avec sa preuve. Pour chaque exigence, la bonne question n'est pas « avons-nous un document ? », mais « que pourrions-nous montrer demain ? ».

Livrable — étape 6

Une procédure incidents, un plan de tests annuel justifié, et pour chaque exigence clé, la preuve associée.

Piège — étape 6

Acheter un corpus documentaire générique et le signer tel quel. Le superviseur ne lit pas des politiques, il vérifie qu'elles correspondent à ce que fait l'entité.

Étape 7 : faire vivre le dispositif sans dépendre d'une personne

Objectif : que le dispositif survive à l'été, au départ d'un collaborateur et au changement de prestataire. C'est souvent là que les petites structures décrochent.

Le risque de la personne unique

Dans une petite structure, DORA vit fréquemment dans la tête et dans les fichiers d'une seule personne. Le jour où elle part, le registre, l'historique des décisions et les preuves partent avec elle. C'est un risque opérationnel à part entière, et il se traite comme tel :

• les décisions et leurs justifications sont tracées dans un espace partagé, pas dans des courriels ;
• chaque rôle de la matrice de l'étape 1 a un suppléant formé ;
• les preuves sont rattachées aux exigences, et non rangées dans des dossiers que seul leur auteur sait lire.

Voir aussi Du diagnostic ponctuel au dispositif vivant.

S'outiller et tenir le rythme

Le tableur suffit au premier diagnostic. Il ne suffit plus pour maintenir RoI, contrats, preuves et qualification d'incident sous quatre heures. Un bon outil relie fonctions, prestataires, contrats, incidents et preuves, exporte le registre, et reste utilisable sans équipe dédiée. Voir Quand quitter Excel.

Rythme : mise à jour du registre à chaque nouveau contrat et des incidents en continu ; point trimestriel sur les prestataires critiques ; revue annuelle du cadre, exercice de continuité et rapport à la direction.

Livrable — étape 7

Un calendrier de pilotage et un reporting annuel à la direction, qui montrent que le dispositif est vivant.

Piège — étape 7

Traiter DORA comme un projet avec une date de fin. C'est un dispositif à maintenir, et c'est sa tenue dans le temps que le superviseur évalue.

Feuille de route : les 90 premiers jours

Appliquées dans l'ordre, les sept étapes tiennent en trois mois pour une structure de quelques dizaines de personnes, avec une personne à temps partiel et un appui externe ponctuel. Le calendrier est indicatif : il s'allonge si l'informatique est éclatée entre de nombreux prestataires.

Phase	Semaines	Focus	Livrables de passage
Cadrer	1–3	Régime, rôles, fonctions	Note de cadrage + 3 à 5 fonctions critiques validées
Cartographier et sécuriser	4–8	Dépendances, risques, technique, contrats	Cartographie, garanties prestataire, clauses art. 30, procédure incidents
Démontrer	9–12	RoI, tests, reporting	Registre cohérent, 1er exercice / restauration, rapport direction

Chaque phase produit des livrables que la suivante utilise : sans fonctions critiques validées, la cartographie n'a pas de point d'appui ; sans cartographie, le registre n'est qu'une liste. La checklist détaillée (rôles, mandats, garanties prestataire, premier exercice) peut vivre dans votre plan de projet ; le critère de passage, lui, est dans le tableau ci-dessus.

Conclusion : la petite taille est un atout

Une petite structure n'a pas les moyens d'un grand groupe. Mais elle a ce qui manque souvent aux grands : un périmètre lisible, des chaînes de décision courtes et des dirigeants qui peuvent réellement s'approprier le sujet.

Bien mené, un dispositif DORA à taille humaine est plus simple à démontrer qu'un dispositif tentaculaire. Trois à cinq fonctions critiques, des dépendances connues, des arbitrages justifiés, des preuves rattachées : c'est exactement ce que la supervision cherche aujourd'hui. Pas l'épaisseur de la documentation, mais la réalité du dispositif.

Questions fréquentes

Une petite SGP ou un EP agréé relève-t-il du cadre simplifié (article 16) ?

En général non. L'article 16 vise une liste fermée. Une SGP ou un EP agréé relève du régime complet, appliqué avec proportionnalité.

Par où commencer si l'on n'a qu'une personne sur le sujet ?

Qualifier le régime, poser une matrice de rôles, puis identifier trois à cinq fonctions critiques ou importantes — avant l'inventaire fournisseurs.

Peut-on confier DORA à un RSSI externe ?

Oui pour l'exécution (article 6(10)). L'entité reste pleinement responsable : mandat, livrables, reporting direction et réversibilité des preuves.

---

Cet article propose une analyse opérationnelle et ne constitue pas un avis juridique. Les arbitrages de conformité relèvent de votre organisation.