Résilience opérationnelle · Gestion des risques TIC · Services financiers
Le Digital Operational Resilience Act (DORA), Règlement (UE) 2022/2554, s’applique aux entités financières de l’Union Européenne depuis le 17 janvier 2025. Parmi ses objectifs centraux figure l’exigence que les entreprises détectent rapidement les incidents TIC (technologies de l’information et de la communication) et maintiennent la disponibilité des services soutenant des fonctions critiques ou importantes.
Atteindre cet objectif nécessite une surveillance reflétant la disponibilité réelle des services orientés client, et pas seulement la santé interne des systèmes qui les sous-tendent. Les outils d’observabilité internes rapportent sur l’infrastructure depuis le réseau de l’entreprise. Ils ne confirment pas si un service est accessible et fonctionnel du point de vue d’un utilisateur externe. La surveillance synthétique externe y répond en exécutant des transactions scriptées contre les services en production depuis des emplacements hors du réseau, selon un calendrier défini.
Cet article identifie les obligations spécifiques de DORA relatives à la surveillance continue et à la détection, et explique comment la surveillance synthétique externe et la plateforme Dotcom-Monitor en particulier répondent à chacune d’entre elles.
Obligations de détection et de disponibilité selon DORA
DORA est basée sur les résultats plutôt que sur les outils prescrits. Il n’impose pas un produit ou une fréquence de contrôle spécifique. Il établit des obligations de détection, disponibilité et supervision, la surveillance étant le contrôle opérationnel au travers duquel plusieurs de ces obligations sont remplies. Quatre dispositions sont particulièrement pertinentes.
Article 9 (Protection et prévention) exige des entités financières qu’elles surveillent et contrôlent en continu la sécurité et le bon fonctionnement des systèmes et outils TIC. L’obligation est continue, ce qui exclut les contrôles périodiques ou manuels comme seuls moyens suffisants.
Article 10 (Détection) demande la mise en place de mécanismes permettant de détecter rapidement des activités anormales, y compris les problèmes de performance des réseaux TIC et les incidents TIC, ainsi que d’identifier les points critiques de défaillance uniques. L’article 10(2) précise que ces mécanismes doivent assurer plusieurs niveaux de contrôle, définir des seuils d’alerte, et inclure des alertes automatiques à destination du personnel responsable de la gestion des incidents.
« Les entités financières doivent disposer de mécanismes permettant de détecter rapidement des activités anormales, y compris les problèmes de performance des réseaux TIC et les incidents liés aux TIC. »
DORA, Article 10 (Détection)
Articles 17 et 19 (Gestion et notification des incidents) requièrent un processus documenté de gestion des incidents liés aux TIC et, pour les incidents majeurs, la notification de l’autorité compétente dans un délai réglementaire mesuré en heures et non en jours. La rapidité de cette notification dépend directement de celle de la détection.
Article 28 (Risque tiers TIC) impose aux entités de gérer et surveiller le risque lié aux prestataires tiers de services TIC. Lorsqu’un prestataire soutient une fonction critique ou importante, sa disponibilité relève de la responsabilité de surveillance de l’entité.
Ces dispositions imposent cinq capacités de surveillance : surveillance continue, détection rapide des incidents, validation de la disponibilité, supervision des tiers TIC et alerte précoce en cas de dégradation du service. Les sections ci-dessous abordent chacune d’elles.
Le rôle de la vérification externe
Les outils internes, comme la gestion de la performance applicative (APM), les métriques serveurs et l’analyse des journaux, observent les systèmes depuis l’intérieur du réseau. Ils rapportent fidèlement l’état de l’infrastructure mais ne détectent pas une catégorie de défaillances qui surviennent entre l’utilisateur et les serveurs. Celles-ci incluent :
- Modifications DNS qui résolvent incorrectement pour des utilisateurs d’une région ou d’un réseau spécifique.
- Certificats TLS expirés ou mal configurés, rejetés par les clients.
- Défaillances de routage CDN ou FAI sur le chemin vers le centre de données.
- Scripts ou API tiers bloqués, empêchant la complétion d’une page.
- Équilibreurs de charge qui renvoient une réponse valide à une vérification de santé mais échouent sur une transaction utilisateur complète.
Dans chacune de ces situations, la surveillance interne rapporte un fonctionnement normal alors que le service est indisponible pour les utilisateurs. La surveillance synthétique externe exécute la transaction utilisateur depuis l’extérieur du réseau et enregistre donc l’échec au point où il affecte les utilisateurs.
La vérification externe a aussi une valeur probante pour la conformité. Un enregistrement de la disponibilité est plus crédible auprès d’un examinateur lorsque la mesure provient de l’extérieur du système mesuré. Les données indépendantes avec horodatage soutiennent les obligations d’audit et de reporting associées aux exigences de détection de DORA.
Cartographie des exigences DORA aux capacités de Dotcom-Monitor
Les sous-sections suivantes énoncent chaque exigence et la capacité correspondante qui y répond. Dotcom-Monitor est une plateforme de surveillance synthétique réalisant des contrôles depuis l’extérieur du réseau, ce qui correspond aux obligations de détection et de disponibilité exposées ci-dessus.
Surveillance continue (Article 9)
Exigence. Surveiller en continu et contrôler le fonctionnement des systèmes TIC supportant les services orientés client.
Comment c’est adressé. Des contrôles synthétiques planifiés s’exécutent à intervalles définis, aussi fréquents qu’une minute, offrant une couverture ininterrompue des services surveillés. La surveillance des applications web charge le service dans un vrai navigateur et mesure le rendu, plutôt que de confirmer uniquement la réponse d’un serveur. Cela fournit un enregistrement continu du fonctionnement du service tel que l’utilisateur le rencontre.
Détection rapide des activités anormales (Article 10)
Exigence. Détecter rapidement les activités anormales, y compris les problèmes de performance réseau TIC et les incidents, et identifier les points critiques majeurs de défaillance.
Comment c’est adressé. Une transaction synthétique qui échoue, ou dépasse un temps de réponse défini, signale la condition au cycle de contrôle où elle survient, indépendamment des rapports utilisateurs. Le script complet de parcours utilisateur avec le EveryStep recorder étend la détection au-delà de la disponibilité des pages vers les processus multi-étapes comme l’authentification, le paiement, ou l’ouverture de compte, où l’échec d’une étape seule constitue un incident.
Seuils d’alerte et alertes automatiques (Article 10(2))
Exigence. Définir des seuils d’alerte et fournir des alertes automatiques au personnel responsable de la gestion des incidents.
Comment c’est adressé. L’alerte configurable se déclenche sur des conditions définies, incluant un temps de réponse supérieur au seuil, une réponse d’erreur ou une étape de transaction échouée. Les alertes sont automatiquement envoyées par email, SMS ou outils intégrés de gestion d’incidents, ciblant les répondants désignés plutôt qu’une file partagée. L’alerte basée sur le seuil de dégradation, pas uniquement sur une panne complète, soutient les multiples niveaux de contrôle requis par l’article 10(2).
Validation de la disponibilité et preuves d’audit
Exigence. Démontrer la disponibilité des services supportant des fonctions critiques ou importantes, avec des enregistrements adaptés à l’audit et à la revue post-incident.
Comment c’est adressé. Les rapports de disponibilité et SLA fournissent un historique horodaté de la disponibilité de chaque service surveillé. Parce que la mesure provient de l’extérieur du réseau, ce registre constitue une preuve indépendante de la disponibilité ainsi que du moment et de la durée de toute interruption. Ces enregistrements soutiennent aussi bien les revues internes que les demandes d’examinateurs. Les cibles de disponibilité associées sont couvertes dans les ressources de monitoring de disponibilité de la plateforme.
Supervision des tiers TIC (Article 28)
Exigence. Surveiller la disponibilité et la performance des prestataires tiers TIC qui supportent des fonctions critiques ou importantes.
Comment c’est adressé. La surveillance des API vérifie les endpoints REST, SOAP et GraphQL dont dépend une application, y compris ceux exploités par des tiers. Pour les applications hébergées utilisées en production, la surveillance SaaS suit directement la disponibilité du prestataire, donnant à l’entité une visibilité indépendante d’une dépendance plutôt que de se fier au reporting de statut du fournisseur.
Alerte précoce et notification d’incident (Articles 10, 17, 19)
Exigence. Fournir une alerte précoce en cas de dégradation du service et détecter les incidents majeurs dans les délais de notification.
Comment c’est adressé. Parce que les contrôles sont continus depuis l’extérieur du réseau, la dégradation et la panne sont détectées près du point d’occurrence, ce qui réduit l’intervalle entre le début de l’incident et sa détection. Cet intervalle est important pour les articles 17 et 19, dont le délai de notification est mesuré en heures. Une détection plus précoce augmente le temps disponible pour classer, répondre et notifier un incident. Cette capacité soutient aussi la détection précoce des pannes et est analysée plus en détail dans le contexte de la surveillance synthétique dans les services financiers.
Couverture des systèmes internes
Exigence. Surveiller les applications internes qui supportent des fonctions critiques ou importantes, en plus des services publics.
Comment c’est adressé. Les services publics sont contrôlés depuis le réseau global de surveillance. Les applications internes derrière le pare-feu sont contrôlées par des agents privés déployés dans l’environnement de l’entité, appliquant les mêmes contrôles aux systèmes internes et externes depuis une plateforme unique.
Résumé exigences-capacités
Le tableau ci-dessous consolide la cartographie présentée plus haut.
| Disposition DORA | Exigence | Capacité Dotcom-Monitor |
|---|---|---|
| Article 9 | Surveillance continue des systèmes TIC | Contrôles programmés en vrai navigateur à des intervalles aussi courts qu’une minute |
| Article 10(1) | Détection rapide des activités anormales | Transactions synthétiques signalant échecs et franchissements de seuil par cycle |
| Article 10(2) | Seuils d’alerte et alertes automatiques | Alertes configurables vers répondants désignés sur erreur ou dégradation |
| Articles 17, 19 | Détection rapide des incidents pour notification | Détection externe continue qui réduit le temps d’alerte |
| Article 28 | Supervision des tiers TIC | Surveillance API et SaaS des dépendances externes |
| Audit et revue | Preuve de disponibilité | Rapports horaires et SLA horodatés depuis l’extérieur du réseau |
Exemples de lacunes de détection
Deux conditions de défaillance illustrent pourquoi la vérification externe est nécessaire. Les deux sont indétectables par la surveillance interne seule.
Mauvaise configuration DNS régionale. Une modification DNS se résout incorrectement pour un seul fournisseur d’accès Internet. Les métriques côté serveur restent nominales car les requêtes affectées n’atteignent pas l’infrastructure. Un contrôle externe exécuté depuis la région affectée enregistre l’échec à son prochain cycle et déclenche une alerte, indiquant le lieu concerné.
Latence d’authentification tierce partie. Un fournisseur d’identité externe reste disponible mais répond lentement, ajoutant plusieurs secondes à chaque authentification. Aucune erreur interne n’est signalée. Une transaction synthétique qui complète la connexion mesure le temps de réponse élevé, dépasse le seuil configuré, et identifie la dépendance comme source. C’est la visibilité que l’article 28 exige pour les fournisseurs tiers.
Configuration recommandée pour la surveillance
La configuration suivante établit une base de surveillance alignée sur les obligations de détection et disponibilité ci-dessus. Elle privilégie les chemins critiques plutôt que la couverture exhaustive.
Étape 1 : Identifier les fonctions critiques ou importantes. Enumérer les services orientés client dont la défaillance nécessiterait un rapport d’incident, tels que l’authentification, les paiements, les transferts, l’ouverture de compte, et l’accès aux relevés. Ceux-ci définissent la priorité de surveillance.
Étape 2 : Script complet des parcours utilisateurs. Pour chaque fonction, enregistrer le flux complet utilisateur avec l’EveryStep recorder, jusqu’à une étape confirmant que le service a fonctionné, comme un transfert réalisé ou une vue de compte chargée. Un contrôle limité à la page d’accueil ne détectera pas une défaillance à une étape ultérieure.
Étape 3 : Surveiller depuis des emplacements pertinents. Sélectionner des emplacements de surveillance correspondant à la géographie des clients de l’entité dans le réseau global, afin de détecter les pannes régionales.
Étape 4 : Surveiller les dépendances tierces. Configurer des contrôles séparés pour les API tierces et applications hébergées sur lesquelles les fonctions critiques dépendent, afin d’attribuer la source d’une panne à l’entité ou à un fournisseur.
Étape 5 : Définir les seuils et la routage des alertes. Fixer les seuils pour temps de réponse et conditions d’erreur, et acheminer les alertes vers les répondants désignés et les systèmes de gestion d’incidents. Configurer les alertes sur la dégradation ainsi que sur la panne complète.
Étape 6 : Conserver les enregistrements de disponibilité. Activer les rapports de disponibilité et SLA dès le départ, pour accumuler automatiquement l’historique de disponibilité et disposer de preuves pour l’audit et la revue post-incident.
Étape 7 : Étendre la couverture aux systèmes internes. Déployer des agents privés pour les applications internes supportant des fonctions critiques, afin que ces systèmes reçoivent des contrôles continus équivalents.
Portée et limites
La surveillance synthétique externe est un contrôle parmi un programme DORA et ne satisfait donc pas à elle seule la réglementation dans son intégralité. Elle fournit une validation de disponibilité et une détection rapide, mais pas la gouvernance des risques TIC, ni les procédures de classification et de notification des incidents, les tests de pénétration ciblés par menace, les sauvegardes et la récupération, ni les arrangements contractuels pour les fournisseurs tiers que DORA exige également. Ces obligations sont remplies par d’autres contrôles du programme de résilience de l’entité.
La surveillance synthétique vérifie aussi uniquement les transactions scriptées. Un parcours utilisateur non configuré n’est pas surveillé, donc la couverture doit être maintenue au fil des évolutions des services. Dans cette portée définie, la surveillance synthétique externe fournit des preuves de détection et de disponibilité que peu d’autres contrôles produisent.
Conclusion
DORA oblige les entités financières à détecter rapidement les incidents TIC et à maintenir, ainsi qu’à prouver, la disponibilité des services soutenant des fonctions critiques ou importantes. La surveillance interne rapporte l’état de l’infrastructure et ne détecte pas les défaillances qui surviennent entre l’utilisateur et les serveurs. La surveillance synthétique externe vérifie en continu la transaction complète utilisateur depuis l’extérieur du réseau et à travers les régions pertinentes, y compris les dépendances tierces, et conserve des enregistrements horodatés des résultats.
Ces capacités correspondent directement à l’obligation de surveillance continue de l’article 9, aux obligations de détection et d’alerte de l’article 10, à la rapidité requise par les articles 17 et 19, et à la supervision des tiers requise par l’article 28. La surveillance synthétique externe ne constitue pas à elle seule la conformité DORA, mais elle est un moyen direct et documenté de satisfaire aux exigences de détection et de disponibilité posées par la réglementation.
