Cadre de gestion des risques TIC

Un cadre de gestion du risque TIC ne se résume pas à un document de politique signé par la direction et rangé dans un espace documentaire. C'est un dispositif vivant, articulé autour de cinq fonctions — identifier, protéger, détecter, répondre et apprendre — que les articles 5 à 15 de DORA rendent obligatoires pour toute entité financière, avec une exigence structurante : ce cadre doit être approuvé, revu et effectivement piloté par l'organe de direction, pas délégué en silence à la seule fonction informatique.

Ce chapitre couvre les quatre briques qui, en pratique, déterminent si un cadre TIC tient la route lors d'un contrôle ou d'un incident réel : la politique et sa gouvernance, l'inventaire des actifs, la classification par criticité, et les plans de continuité et de reprise, avant de traiter leur rattachement au dispositif de gestion des risques d'entreprise.

DORA ne demande pas un cadre TIC séparé du reste de la gestion des risques de l'entité. Il demande l'inverse : un cadre TIC qui soit une composante à part entière du dispositif global de gestion des risques, avec les mêmes exigences de gouvernance, de reporting et de responsabilité que le risque de crédit ou le risque de marché. Un cadre TIC construit en silo, sans lien avec le comité des risques de l'entité, est une non-conformité structurelle même s'il est techniquement complet.

Le socle réglementaire : articles 5 à 15

L'article 5 pose l'exigence de gouvernance : l'organe de direction définit, approuve, supervise et est responsable de la mise en œuvre du cadre de gestion du risque TIC. Il ne peut pas déléguer cette responsabilité, même s'il délègue l'exécution opérationnelle. L'article 6 précise le contenu attendu du cadre lui-même — stratégie de résilience numérique, tolérance au risque, dispositif de contrôle interne. L'article 7 porte sur les systèmes, protocoles et outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire TIC utilisés, qui doivent être appropriés, fiables et suffisamment capacitaires. L'article 8 impose l'identification : cartographie des fonctions, processus et actifs, avec une classification selon leur criticité. Les articles 9 et 10 couvrent la protection, la prévention et la détection. L'article 11 impose une politique de continuité d'activité et des plans de réponse et de reprise. L'article 12 détaille les politiques de sauvegarde et les méthodes de restauration. Les articles 13 et 14 couvrent l'apprentissage post-incident et la communication de crise. L'article 15 renvoie à des normes techniques réglementaires (RTS) qui précisent le contenu détaillé attendu pour chacun de ces éléments.

La politique ICT : contenu attendu et gouvernance

La politique de gestion du risque TIC est le document-cadre qui formalise la stratégie de résilience numérique de l'entité. Les RTS associés à l'article 6 en précisent le contenu minimal attendu : objectifs de résilience alignés sur la stratégie d'entreprise, appétence au risque TIC exprimée de façon mesurable, rôles et responsabilités clairement attribués (y compris au niveau de l'organe de direction et, le cas échéant, d'une fonction dédiée de gestion du risque TIC), périmètre couvert incluant les systèmes hérités, et mécanisme de revue périodique.

Deux écueils reviennent systématiquement dans les cadres bâtis à la hâte. Le premier est une politique rédigée en termes trop génériques pour être opposable — « l'entité s'engage à assurer un niveau de sécurité approprié » ne dit rien de vérifiable. Le second est une politique correctement rédigée mais jamais formellement approuvée par l'organe de direction avec traçabilité de cette approbation (procès-verbal, date, version), ce qui rend impossible de démontrer la responsabilité effective exigée par l'article 5.

L'organe de direction doit pouvoir démontrer, documents à l'appui, qu'il a effectivement examiné et approuvé la politique TIC — pas simplement qu'elle existe. Un procès-verbal de conseil qui se contente de « prendre acte » du document ne suffit généralement pas : les autorités attendent une approbation active, avec traçabilité des échanges, des questions posées et des arbitrages rendus, notamment sur la tolérance au risque.

La gouvernance attendue distingue en général trois niveaux : l'organe de direction, responsable ultime et approbateur de la stratégie ; une fonction de gestion du risque TIC, souvent rattachée à la fonction de gestion des risques globale, chargée de la mise en œuvre et du reporting ; et les propriétaires opérationnels de chaque fonction ou processus, responsables au quotidien du respect des contrôles définis. Un tableau RACI documenté sur ces trois niveaux facilite considérablement la démonstration de conformité lors d'un audit.

Inventaire des actifs informationnels

L'article 8 exige une identification exhaustive : systèmes d'information, applications, processus métier, actifs physiques et logiciels, ainsi que les interdépendances entre eux. En pratique, la difficulté n'est jamais de constituer un premier inventaire — beaucoup d'entités disposent déjà d'une CMDB (configuration management database) ou d'un registre d'actifs informatiques — mais de le maintenir à jour et de le relier aux processus métier qu'il supporte, ce qui suppose une gouvernance de mise à jour régulière plutôt qu'un exercice ponctuel.

Un inventaire réellement exploitable comporte, pour chaque actif : un identifiant unique, un propriétaire métier désigné (pas seulement un propriétaire technique), les processus métier qu'il supporte, ses dépendances amont et aval (autres systèmes, prestataires tiers, infrastructures réseau), sa localisation physique ou son fournisseur d'hébergement, et sa date de dernière revue.

Une entreprise d'investissement recense son système de tenue de compte-titres comme un actif unique dans sa CMDB technique. Lors d'une analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire, elle découvre que ce système dépend en réalité d'un service d'horodatage externe, d'une base de référentiel de valeurs mobilières maintenue par un prestataire tiers, et d'une interface avec le système de règlement-livraison du dépositaire central. Sans cartographie des dépendances, l'entité aurait sous-estimé son exposition : une indisponibilité du seul service d'horodatage suffit à bloquer l'ensemble de la chaîne de traitement, alors qu'il n'apparaissait dans aucun registre de criticité avant cette analyse.

L'inventaire doit également couvrir les actifs dits « informationnels » au sens large — pas seulement les systèmes, mais les donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire elles-mêmes, classées selon leur sensibilité (données à caractère personnel, secrets d'affaires, informations réglementées), car un incident TIC peut affecter la disponibilité d'un système sans compromettre les données, ou inversement compromettre des données sans affecter la disponibilité du système.

Classification par criticité des fonctions

Étape indissociable de l'inventaire, la classification consiste à qualifier chaque fonction, processus ou actif comme « critique ou important » au sens de DORA, ou non. Cette qualification conditionne directement l'intensité des exigences applicables ailleurs dans le règlement : fréquence des tests de résilience, profondeur des clauses contractuelles avec les prestataires tiers, délais de notification en cas d'incident affectant la fonction.

Les critères de classification les plus couramment retenus combinent plusieurs dimensions :

Construisez une échelle de criticité à trois ou quatre niveaux (par exemple critique, important, standard, mineur), avec une définition écrite et des exemples concrets pour chaque niveau. Une échelle binaire « critique / non critique » masque des écarts d'exposition considérables et complique l'arbitrage des priorités de remédiation quand les ressources sont limitées, ce qui est presque toujours le cas.

La classification n'est pas figée : elle doit être revue à chaque changement significatif — migration technique, externalisation d'une fonction auparavant internalisée, évolution réglementaire sectorielle — et à intervalle régulier même en l'absence de changement identifié, typiquement une fois par an pour les fonctions critiques.

Continuité d'activité (BCP) et reprise après sinistre (DR)

L'article 11 distingue la politique de continuité d'activité, qui couvre l'ensemble des mesures organisationnelles permettant à l'entité de continuer à fonctionner malgré une perturbation, et les plans de réponse et de reprise, plus techniques, centrés sur le rétablissement des systèmes TIC eux-mêmes. Ces deux volets sont complémentaires et doivent être testés conjointement : un plan de reprise informatique qui restaure les serveurs en quatre heures ne sert à rien si les équipes métier n'ont pas de procédure pour continuer à traiter les opérations pendant ces quatre heures.

Deux indicateurs structurent tout plan de reprise : le RTO (recovery time objective), délai maximal toléré avant rétablissement du service, et le RPO (recovery point objective), volume de données qu'il est acceptable de perdre, exprimé en durée depuis la dernière sauvegarde valide. Ces deux objectifs doivent être définis fonction par fonction, en cohérence avec la classification de criticité établie précédemment — un système classé critique avec un RTO de 24 heures est une incohérence qui n'échappera pas à un contrôle sérieux.

L'article 12 impose que les politiques de sauvegarde et les méthodes de restauration soient elles-mêmes testées périodiquement, dans des conditions représentatives, avec documentation des résultats. Une sauvegarde qui n'a jamais fait l'objet d'un test de restauration complet n'est pas une garantie de reprise : c'est une hypothèse non vérifiée. Les incidents les plus coûteux observés dans le secteur financier ces dernières années impliquent fréquemment des sauvegardes existantes mais corrompues, incomplètes ou incompatibles avec l'infrastructure de secours au moment où elles auraient dû servir.

Les plans doivent également couvrir les scénarios extrêmes mais plausibles prévus par les RTS : perte totale d'un site, défaillance simultanée de plusieurs prestataires TIC critiques, cyberattaque affectant à la fois la production et les sauvegardes (scénario de rançongiciel avec chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire des sauvegardes connectées). Ce dernier scénario impose en pratique de maintenir au moins une copie de sauvegarde isolée du réseau de production (« air gap » ou équivalent logique), faute de quoi la stratégie de reprise repose sur une hypothèse déjà démentie par plusieurs incidents sectoriels documentés.

Intégration dans l'ERM

Le risque TIC n'est pas une catégorie à part : DORA exige qu'il soit intégré au dispositif de gestion des risques d'entreprise (ERM) au même titre que le risque de crédit, le risque de marché ou le risque opérationnel au sens large. Concrètement, cela suppose que le risque TIC apparaisse dans la cartographie des risques globale de l'entité, que les indicateurs de risque TIC remontent au comité des risques avec la même régularité que les autres catégories de risque, et que l'appétence au risque TIC soit cohérente avec l'appétence au risque globale approuvée par l'organe de direction.

Cette intégration a une conséquence pratique souvent négligée : le risque TIC doit être exprimé dans un langage compréhensible par un comité des risques généraliste, pas uniquement en termes techniques (disponibilité, latence, taux d'erreur) mais aussi en termes d'impact métier et financier (perte de revenus estimée, exposition réglementaire, atteinte à la réputation). Les entités qui réussissent le mieux cet exercice traduisent systématiquement chaque indicateur technique en un équivalent business avant de le présenter au niveau de gouvernance concerné.

Checklist de mise en œuvre

1. Vérifier que la politique TIC a été formellement approuvée par l'organe de direction, avec traçabilité de cette approbation.
2. Constituer ou mettre à jour l'inventaire des actifs informationnels, avec propriétaire métier et cartographie des dépendances.
3. Appliquer une échelle de classification par criticité documentée, cohérente avec les RTO/RPO fixés.
4. Distinguer explicitement plan de continuité (organisationnel) et plan de reprise (technique), et les tester conjointement.
5. Vérifier l'existence d'une sauvegarde isolée du réseau de production pour les fonctions critiques.
6. Intégrer les indicateurs de risque TIC dans le reporting régulier au comité des risques de l'entité.
7. Fixer un cycle de revue périodique de chaque brique du cadre, avec date et responsable identifiés.

Pièges fréquents

• Un inventaire d'actifs techniquement exhaustif mais sans propriétaire métier désigné, ce qui rend impossible toute décision d'arbitrage rapide en cas d'incident.
• Une classification de criticité réalisée une seule fois lors du projet de mise en conformité initial, jamais mise à jour depuis.
• Des RTO/RPO définis en théorie mais jamais confrontés à un test de restauration réel.
• Un plan de continuité d'activité qui couvre le siège social mais ignore les sites secondaires ou le travail à distance généralisé.
• Un risque TIC piloté uniquement par la direction informatique, sans remontée structurée vers le comité des risques de l'entité.

Les chapitres suivants s'appuient directement sur les briques posées ici : la gestion des incidents majeurs suppose une classification de criticité déjà établie pour apprécier le seuil de notification, et les tests de résilience opérationnelle numérique ciblent en priorité les fonctions identifiées comme critiques dans l'inventaire construit à ce stade.