{"id":34268,"date":"2026-07-24T20:28:29","date_gmt":"2026-07-24T20:28:29","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/external-synthetic-monitoring-dora\/"},"modified":"2026-07-24T20:28:29","modified_gmt":"2026-07-24T20:28:29","slug":"external-synthetic-monitoring-dora","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/external-synthetic-monitoring-dora\/","title":{"rendered":"Surveillance Synth\u00e9tique Externe pour la R\u00e9silience Op\u00e9rationnelle DORA"},"content":{"rendered":"
R\u00e9silience op\u00e9rationnelle \u00b7 Gestion des risques TIC \u00b7 Services financiers<\/em><\/p>\n Le Digital Operational Resilience Act (DORA), R\u00e8glement (UE) 2022\/2554<\/a>, s\u2019applique aux entit\u00e9s financi\u00e8res de l\u2019Union Europ\u00e9enne depuis le 17 janvier 2025. Parmi ses objectifs centraux figure l\u2019exigence que les entreprises d\u00e9tectent rapidement les incidents TIC (technologies de l\u2019information et de la communication) et maintiennent la disponibilit\u00e9 des services soutenant des fonctions critiques ou importantes.<\/p>\n Atteindre cet objectif n\u00e9cessite une surveillance refl\u00e9tant la disponibilit\u00e9 r\u00e9elle des services orient\u00e9s client, et pas seulement la sant\u00e9 interne des syst\u00e8mes qui les sous-tendent. Les outils d\u2019observabilit\u00e9 internes rapportent sur l\u2019infrastructure depuis le r\u00e9seau de l\u2019entreprise. Ils ne confirment pas si un service est accessible et fonctionnel du point de vue d\u2019un utilisateur externe. La surveillance synth\u00e9tique externe y r\u00e9pond en ex\u00e9cutant des transactions script\u00e9es contre les services en production depuis des emplacements hors du r\u00e9seau, selon un calendrier d\u00e9fini.<\/p>\n Cet article identifie les obligations sp\u00e9cifiques de DORA relatives \u00e0 la surveillance continue et \u00e0 la d\u00e9tection, et explique comment la surveillance synth\u00e9tique externe et la plateforme Dotcom-Monitor en particulier<\/a> r\u00e9pondent \u00e0 chacune d\u2019entre elles.<\/p>\n DORA est bas\u00e9e sur les r\u00e9sultats plut\u00f4t que sur les outils prescrits. Il n\u2019impose pas un produit ou une fr\u00e9quence de contr\u00f4le sp\u00e9cifique. Il \u00e9tablit des obligations de d\u00e9tection, disponibilit\u00e9 et supervision, la surveillance \u00e9tant le contr\u00f4le op\u00e9rationnel au travers duquel plusieurs de ces obligations sont remplies. Quatre dispositions sont particuli\u00e8rement pertinentes.<\/p>\n Article 9 (Protection et pr\u00e9vention)<\/strong> exige des entit\u00e9s financi\u00e8res qu\u2019elles surveillent et contr\u00f4lent en continu la s\u00e9curit\u00e9 et le bon fonctionnement des syst\u00e8mes et outils TIC. L\u2019obligation est continue, ce qui exclut les contr\u00f4les p\u00e9riodiques ou manuels comme seuls moyens suffisants.<\/p>\n Article 10 (D\u00e9tection)<\/strong> demande la mise en place de m\u00e9canismes permettant de d\u00e9tecter rapidement des activit\u00e9s anormales, y compris les probl\u00e8mes de performance des r\u00e9seaux TIC et les incidents TIC, ainsi que d\u2019identifier les points critiques de d\u00e9faillance uniques. L\u2019article 10(2) pr\u00e9cise que ces m\u00e9canismes doivent assurer plusieurs niveaux de contr\u00f4le, d\u00e9finir des seuils d\u2019alerte, et inclure des alertes automatiques \u00e0 destination du personnel responsable de la gestion des incidents.<\/p>\n \u00ab\u00a0Les entit\u00e9s financi\u00e8res doivent disposer de m\u00e9canismes permettant de d\u00e9tecter rapidement des activit\u00e9s anormales, y compris les probl\u00e8mes de performance des r\u00e9seaux TIC et les incidents li\u00e9s aux TIC.\u00a0\u00bb Articles 17 et 19 (Gestion et notification des incidents)<\/strong> requi\u00e8rent un processus document\u00e9 de gestion des incidents li\u00e9s aux TIC et, pour les incidents majeurs, la notification de l\u2019autorit\u00e9 comp\u00e9tente dans un d\u00e9lai r\u00e9glementaire mesur\u00e9 en heures et non en jours. La rapidit\u00e9 de cette notification d\u00e9pend directement de celle de la d\u00e9tection.<\/p>\n Article 28 (Risque tiers TIC)<\/strong> impose aux entit\u00e9s de g\u00e9rer et surveiller le risque li\u00e9 aux prestataires tiers de services TIC. Lorsqu\u2019un prestataire soutient une fonction critique ou importante, sa disponibilit\u00e9 rel\u00e8ve de la responsabilit\u00e9 de surveillance de l\u2019entit\u00e9.<\/p>\n Ces dispositions imposent cinq capacit\u00e9s de surveillance : surveillance continue, d\u00e9tection rapide des incidents, validation de la disponibilit\u00e9, supervision des tiers TIC et alerte pr\u00e9coce en cas de d\u00e9gradation du service. Les sections ci-dessous abordent chacune d\u2019elles.<\/p>\n Les outils internes, comme la gestion de la performance applicative (APM), les m\u00e9triques serveurs et l\u2019analyse des journaux, observent les syst\u00e8mes depuis l\u2019int\u00e9rieur du r\u00e9seau. Ils rapportent fid\u00e8lement l\u2019\u00e9tat de l\u2019infrastructure mais ne d\u00e9tectent pas une cat\u00e9gorie de d\u00e9faillances qui surviennent entre l\u2019utilisateur et les serveurs. Celles-ci incluent :<\/p>\n Dans chacune de ces situations, la surveillance interne rapporte un fonctionnement normal alors que le service est indisponible pour les utilisateurs. La surveillance synth\u00e9tique externe ex\u00e9cute la transaction utilisateur depuis l\u2019ext\u00e9rieur du r\u00e9seau et enregistre donc l\u2019\u00e9chec au point o\u00f9 il affecte les utilisateurs.<\/p>\n La v\u00e9rification externe a aussi une valeur probante pour la conformit\u00e9. Un enregistrement de la disponibilit\u00e9 est plus cr\u00e9dible aupr\u00e8s d\u2019un examinateur lorsque la mesure provient de l\u2019ext\u00e9rieur du syst\u00e8me mesur\u00e9. Les donn\u00e9es ind\u00e9pendantes avec horodatage soutiennent les obligations d\u2019audit et de reporting associ\u00e9es aux exigences de d\u00e9tection de DORA.<\/p>\n Les sous-sections suivantes \u00e9noncent chaque exigence et la capacit\u00e9 correspondante qui y r\u00e9pond. Dotcom-Monitor est une plateforme de surveillance synth\u00e9tique r\u00e9alisant des contr\u00f4les depuis l\u2019ext\u00e9rieur du r\u00e9seau, ce qui correspond aux obligations de d\u00e9tection et de disponibilit\u00e9 expos\u00e9es ci-dessus.<\/p>\n Exigence.<\/strong> Surveiller en continu et contr\u00f4ler le fonctionnement des syst\u00e8mes TIC supportant les services orient\u00e9s client.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> Des contr\u00f4les synth\u00e9tiques planifi\u00e9s s\u2019ex\u00e9cutent \u00e0 intervalles d\u00e9finis, aussi fr\u00e9quents qu\u2019une minute, offrant une couverture ininterrompue des services surveill\u00e9s. La surveillance des applications web<\/a> charge le service dans un vrai navigateur et mesure le rendu, plut\u00f4t que de confirmer uniquement la r\u00e9ponse d\u2019un serveur. Cela fournit un enregistrement continu du fonctionnement du service tel que l\u2019utilisateur le rencontre.<\/p>\n Exigence.<\/strong> D\u00e9tecter rapidement les activit\u00e9s anormales, y compris les probl\u00e8mes de performance r\u00e9seau TIC et les incidents, et identifier les points critiques majeurs de d\u00e9faillance.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> Une transaction synth\u00e9tique qui \u00e9choue, ou d\u00e9passe un temps de r\u00e9ponse d\u00e9fini, signale la condition au cycle de contr\u00f4le o\u00f9 elle survient, ind\u00e9pendamment des rapports utilisateurs. Le script complet de parcours utilisateur avec le EveryStep recorder<\/a> \u00e9tend la d\u00e9tection au-del\u00e0 de la disponibilit\u00e9 des pages vers les processus multi-\u00e9tapes comme l\u2019authentification, le paiement, ou l\u2019ouverture de compte, o\u00f9 l\u2019\u00e9chec d\u2019une \u00e9tape seule constitue un incident.<\/p>\n Exigence.<\/strong> D\u00e9finir des seuils d\u2019alerte et fournir des alertes automatiques au personnel responsable de la gestion des incidents.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> L\u2019alerte configurable<\/a> se d\u00e9clenche sur des conditions d\u00e9finies, incluant un temps de r\u00e9ponse sup\u00e9rieur au seuil, une r\u00e9ponse d\u2019erreur ou une \u00e9tape de transaction \u00e9chou\u00e9e. Les alertes sont automatiquement envoy\u00e9es par email, SMS ou outils int\u00e9gr\u00e9s de gestion d\u2019incidents, ciblant les r\u00e9pondants d\u00e9sign\u00e9s plut\u00f4t qu\u2019une file partag\u00e9e. L\u2019alerte bas\u00e9e sur le seuil de d\u00e9gradation, pas uniquement sur une panne compl\u00e8te, soutient les multiples niveaux de contr\u00f4le requis par l\u2019article 10(2).<\/p>\n Exigence.<\/strong> D\u00e9montrer la disponibilit\u00e9 des services supportant des fonctions critiques ou importantes, avec des enregistrements adapt\u00e9s \u00e0 l\u2019audit et \u00e0 la revue post-incident.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> Les rapports de disponibilit\u00e9 et SLA<\/a> fournissent un historique horodat\u00e9 de la disponibilit\u00e9 de chaque service surveill\u00e9. Parce que la mesure provient de l\u2019ext\u00e9rieur du r\u00e9seau, ce registre constitue une preuve ind\u00e9pendante de la disponibilit\u00e9 ainsi que du moment et de la dur\u00e9e de toute interruption. Ces enregistrements soutiennent aussi bien les revues internes que les demandes d\u2019examinateurs. Les cibles de disponibilit\u00e9 associ\u00e9es sont couvertes dans les ressources de monitoring de disponibilit\u00e9<\/a> de la plateforme.<\/p>\n Exigence.<\/strong> Surveiller la disponibilit\u00e9 et la performance des prestataires tiers TIC qui supportent des fonctions critiques ou importantes.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> La surveillance des API<\/a> v\u00e9rifie les endpoints REST, SOAP et GraphQL dont d\u00e9pend une application, y compris ceux exploit\u00e9s par des tiers. Pour les applications h\u00e9berg\u00e9es utilis\u00e9es en production, la surveillance SaaS<\/a> suit directement la disponibilit\u00e9 du prestataire, donnant \u00e0 l\u2019entit\u00e9 une visibilit\u00e9 ind\u00e9pendante d\u2019une d\u00e9pendance plut\u00f4t que de se fier au reporting de statut du fournisseur.<\/p>\n Exigence.<\/strong> Fournir une alerte pr\u00e9coce en cas de d\u00e9gradation du service et d\u00e9tecter les incidents majeurs dans les d\u00e9lais de notification.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> Parce que les contr\u00f4les sont continus depuis l\u2019ext\u00e9rieur du r\u00e9seau, la d\u00e9gradation et la panne sont d\u00e9tect\u00e9es pr\u00e8s du point d\u2019occurrence, ce qui r\u00e9duit l\u2019intervalle entre le d\u00e9but de l\u2019incident et sa d\u00e9tection. Cet intervalle est important pour les articles 17 et 19, dont le d\u00e9lai de notification est mesur\u00e9 en heures. Une d\u00e9tection plus pr\u00e9coce augmente le temps disponible pour classer, r\u00e9pondre et notifier un incident. Cette capacit\u00e9 soutient aussi la d\u00e9tection pr\u00e9coce des pannes<\/a> et est analys\u00e9e plus en d\u00e9tail dans le contexte de la surveillance synth\u00e9tique dans les services financiers<\/a>.<\/p>\n Exigence.<\/strong> Surveiller les applications internes qui supportent des fonctions critiques ou importantes, en plus des services publics.<\/p>\n Comment c\u2019est adress\u00e9.<\/strong> Les services publics sont contr\u00f4l\u00e9s depuis le r\u00e9seau global de surveillance<\/a>. Les applications internes derri\u00e8re le pare-feu sont contr\u00f4l\u00e9es par des agents priv\u00e9s<\/a> d\u00e9ploy\u00e9s dans l\u2019environnement de l\u2019entit\u00e9, appliquant les m\u00eames contr\u00f4les aux syst\u00e8mes internes et externes depuis une plateforme unique.<\/p>\n Le tableau ci-dessous consolide la cartographie pr\u00e9sent\u00e9e plus haut.<\/p>\n Deux conditions de d\u00e9faillance illustrent pourquoi la v\u00e9rification externe est n\u00e9cessaire. Les deux sont ind\u00e9tectables par la surveillance interne seule.<\/p>\n Mauvaise configuration DNS r\u00e9gionale.<\/strong> Une modification DNS se r\u00e9sout incorrectement pour un seul fournisseur d\u2019acc\u00e8s Internet. Les m\u00e9triques c\u00f4t\u00e9 serveur restent nominales car les requ\u00eates affect\u00e9es n\u2019atteignent pas l\u2019infrastructure. Un contr\u00f4le externe ex\u00e9cut\u00e9 depuis la r\u00e9gion affect\u00e9e enregistre l\u2019\u00e9chec \u00e0 son prochain cycle et d\u00e9clenche une alerte, indiquant le lieu concern\u00e9.<\/p>\n Latence d\u2019authentification tierce partie.<\/strong> Un fournisseur d\u2019identit\u00e9 externe reste disponible mais r\u00e9pond lentement, ajoutant plusieurs secondes \u00e0 chaque authentification. Aucune erreur interne n\u2019est signal\u00e9e. Une transaction synth\u00e9tique qui compl\u00e8te la connexion mesure le temps de r\u00e9ponse \u00e9lev\u00e9, d\u00e9passe le seuil configur\u00e9, et identifie la d\u00e9pendance comme source. C\u2019est la visibilit\u00e9 que l\u2019article 28 exige pour les fournisseurs tiers.<\/p>\n La configuration suivante \u00e9tablit une base de surveillance align\u00e9e sur les obligations de d\u00e9tection et disponibilit\u00e9 ci-dessus. Elle privil\u00e9gie les chemins critiques plut\u00f4t que la couverture exhaustive.<\/p>\n \u00c9tape 1 : Identifier les fonctions critiques ou importantes.<\/strong> Enum\u00e9rer les services orient\u00e9s client dont la d\u00e9faillance n\u00e9cessiterait un rapport d\u2019incident, tels que l\u2019authentification, les paiements, les transferts, l\u2019ouverture de compte, et l\u2019acc\u00e8s aux relev\u00e9s. Ceux-ci d\u00e9finissent la priorit\u00e9 de surveillance.<\/p>\n \u00c9tape 2 : Script complet des parcours utilisateurs.<\/strong> Pour chaque fonction, enregistrer le flux complet utilisateur avec l\u2019EveryStep recorder, jusqu\u2019\u00e0 une \u00e9tape confirmant que le service a fonctionn\u00e9, comme un transfert r\u00e9alis\u00e9 ou une vue de compte charg\u00e9e. Un contr\u00f4le limit\u00e9 \u00e0 la page d\u2019accueil ne d\u00e9tectera pas une d\u00e9faillance \u00e0 une \u00e9tape ult\u00e9rieure.<\/p>\n \u00c9tape 3 : Surveiller depuis des emplacements pertinents.<\/strong> S\u00e9lectionner des emplacements de surveillance correspondant \u00e0 la g\u00e9ographie des clients de l\u2019entit\u00e9 dans le r\u00e9seau global, afin de d\u00e9tecter les pannes r\u00e9gionales.<\/p>\n \u00c9tape 4 : Surveiller les d\u00e9pendances tierces.<\/strong> Configurer des contr\u00f4les s\u00e9par\u00e9s pour les API tierces et applications h\u00e9berg\u00e9es sur lesquelles les fonctions critiques d\u00e9pendent, afin d\u2019attribuer la source d\u2019une panne \u00e0 l\u2019entit\u00e9 ou \u00e0 un fournisseur.<\/p>\n \u00c9tape 5 : D\u00e9finir les seuils et la routage des alertes.<\/strong> Fixer les seuils pour temps de r\u00e9ponse et conditions d\u2019erreur, et acheminer les alertes vers les r\u00e9pondants d\u00e9sign\u00e9s et les syst\u00e8mes de gestion d\u2019incidents. Configurer les alertes sur la d\u00e9gradation ainsi que sur la panne compl\u00e8te.<\/p>\n \u00c9tape 6 : Conserver les enregistrements de disponibilit\u00e9.<\/strong> Activer les rapports de disponibilit\u00e9 et SLA d\u00e8s le d\u00e9part, pour accumuler automatiquement l\u2019historique de disponibilit\u00e9 et disposer de preuves pour l\u2019audit et la revue post-incident.<\/p>\n \u00c9tape 7 : \u00c9tendre la couverture aux syst\u00e8mes internes.<\/strong> D\u00e9ployer des agents priv\u00e9s pour les applications internes supportant des fonctions critiques, afin que ces syst\u00e8mes re\u00e7oivent des contr\u00f4les continus \u00e9quivalents.<\/p>\n La surveillance synth\u00e9tique externe est un contr\u00f4le parmi un programme DORA et ne satisfait donc pas \u00e0 elle seule la r\u00e9glementation dans son int\u00e9gralit\u00e9. Elle fournit une validation de disponibilit\u00e9 et une d\u00e9tection rapide, mais pas la gouvernance des risques TIC, ni les proc\u00e9dures de classification et de notification des incidents, les tests de p\u00e9n\u00e9tration cibl\u00e9s par menace, les sauvegardes et la r\u00e9cup\u00e9ration, ni les arrangements contractuels pour les fournisseurs tiers que DORA exige \u00e9galement. Ces obligations sont remplies par d\u2019autres contr\u00f4les du programme de r\u00e9silience de l\u2019entit\u00e9.<\/p>\n La surveillance synth\u00e9tique v\u00e9rifie aussi uniquement les transactions script\u00e9es. Un parcours utilisateur non configur\u00e9 n\u2019est pas surveill\u00e9, donc la couverture doit \u00eatre maintenue au fil des \u00e9volutions des services. Dans cette port\u00e9e d\u00e9finie, la surveillance synth\u00e9tique externe fournit des preuves de d\u00e9tection et de disponibilit\u00e9 que peu d\u2019autres contr\u00f4les produisent.<\/p>\n DORA oblige les entit\u00e9s financi\u00e8res \u00e0 d\u00e9tecter rapidement les incidents TIC et \u00e0 maintenir, ainsi qu\u2019\u00e0 prouver, la disponibilit\u00e9 des services soutenant des fonctions critiques ou importantes. La surveillance interne rapporte l\u2019\u00e9tat de l\u2019infrastructure et ne d\u00e9tecte pas les d\u00e9faillances qui surviennent entre l\u2019utilisateur et les serveurs. La surveillance synth\u00e9tique externe v\u00e9rifie en continu la transaction compl\u00e8te utilisateur depuis l\u2019ext\u00e9rieur du r\u00e9seau et \u00e0 travers les r\u00e9gions pertinentes, y compris les d\u00e9pendances tierces, et conserve des enregistrements horodat\u00e9s des r\u00e9sultats.<\/p>\n Ces capacit\u00e9s correspondent directement \u00e0 l\u2019obligation de surveillance continue de l\u2019article 9, aux obligations de d\u00e9tection et d\u2019alerte de l\u2019article 10, \u00e0 la rapidit\u00e9 requise par les articles 17 et 19, et \u00e0 la supervision des tiers requise par l\u2019article 28. La surveillance synth\u00e9tique externe ne constitue pas \u00e0 elle seule la conformit\u00e9 DORA, mais elle est un moyen direct et document\u00e9 de satisfaire aux exigences de d\u00e9tection et de disponibilit\u00e9 pos\u00e9es par la r\u00e9glementation.<\/p>\n Comment la surveillance synth\u00e9tique externe r\u00e9pond aux obligations de d\u00e9tection et de disponibilit\u00e9 de DORA, exigence par exigence.<\/p>\n","protected":false},"author":39,"featured_media":34254,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34268","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34268","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=34268"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34268\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34254"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=34268"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=34268"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=34268"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Obligations de d\u00e9tection et de disponibilit\u00e9 selon DORA<\/h2>\n
\nDORA, Article 10 (D\u00e9tection)<\/cite><\/p><\/blockquote>\nLe r\u00f4le de la v\u00e9rification externe<\/h2>\n
\n

Cartographie des exigences DORA aux capacit\u00e9s de Dotcom-Monitor<\/h2>\n
Surveillance continue (Article 9)<\/h3>\n
D\u00e9tection rapide des activit\u00e9s anormales (Article 10)<\/h3>\n
Seuils d\u2019alerte et alertes automatiques (Article 10(2))<\/h3>\n
Validation de la disponibilit\u00e9 et preuves d\u2019audit<\/h3>\n
Supervision des tiers TIC (Article 28)<\/h3>\n
Alerte pr\u00e9coce et notification d\u2019incident (Articles 10, 17, 19)<\/h3>\n
Couverture des syst\u00e8mes internes<\/h3>\n
R\u00e9sum\u00e9 exigences-capacit\u00e9s<\/h2>\n
\n\n
\n \nDisposition DORA<\/th>\n Exigence<\/th>\n Capacit\u00e9 Dotcom-Monitor<\/th>\n<\/tr>\n<\/thead>\n \n Article 9<\/td>\n Surveillance continue des syst\u00e8mes TIC<\/td>\n Contr\u00f4les programm\u00e9s en vrai navigateur \u00e0 des intervalles aussi courts qu’une minute<\/td>\n<\/tr>\n \n Article 10(1)<\/td>\n D\u00e9tection rapide des activit\u00e9s anormales<\/td>\n Transactions synth\u00e9tiques signalant \u00e9checs et franchissements de seuil par cycle<\/td>\n<\/tr>\n \n Article 10(2)<\/td>\n Seuils d\u2019alerte et alertes automatiques<\/td>\n Alertes configurables vers r\u00e9pondants d\u00e9sign\u00e9s sur erreur ou d\u00e9gradation<\/td>\n<\/tr>\n \n Articles 17, 19<\/td>\n D\u00e9tection rapide des incidents pour notification<\/td>\n D\u00e9tection externe continue qui r\u00e9duit le temps d\u2019alerte<\/td>\n<\/tr>\n \n Article 28<\/td>\n Supervision des tiers TIC<\/td>\n Surveillance API et SaaS des d\u00e9pendances externes<\/td>\n<\/tr>\n \n Audit et revue<\/td>\n Preuve de disponibilit\u00e9<\/td>\n Rapports horaires et SLA horodat\u00e9s depuis l\u2019ext\u00e9rieur du r\u00e9seau<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Exemples de lacunes de d\u00e9tection<\/h3>\n
Configuration recommand\u00e9e pour la surveillance<\/h2>\n
Port\u00e9e et limites<\/h2>\n
Conclusion<\/h2>\n