Sur cette page
Il est 02:40 UTC. Depuis Francfort, l’un des 11 types de checks régionaux de Perstat signale un échec sur votre API de paiement. D’autres régions incluses dans l’offre remontent le même résultat, et la politique régionale configurée confirme l’incident.
Cette confirmation crée un horodatage opérationnel. Elle ne classe pas l’incident au sens de DORA. Si votre organisation le classe comme incident majeur lié aux TIC, les délais de déclaration de DORA s’appliquent.
Le plus difficile n’est pas seulement de rédiger les rapports, mais d’en réunir les éléments pendant que le temps court. Un registre de monitoring peut fournir les heures de détection, de confirmation et de rétablissement. À lui seul, il ne fournit ni la classification juridique, ni l’impact sur les clients ou les transactions, ni la cause racine, ni la décision de déclarer.
Pour le volet disponibilité de ce travail, trois points comptent :
- ce qu’un registre de monitoring peut apporter
- pourquoi captures d’écran et fils Slack sont faibles comme source unique
- où s’arrête le rôle de Perstat
Il ne s’agit pas d’un conseil juridique, et la classification comme la déclaration restent sous votre responsabilité. Consultez les sources primaires : le règlement (UE) 2022/2554 et la norme technique sur le contenu et les délais des notifications.
Trois délais s’appliquent aux incidents majeurs
DORA s’applique depuis le 17 janvier 2025. Pour les incidents majeurs liés aux TIC, l’ article 5 du règlement délégué (UE) 2025/301 de la Commission fixe cette séquence ordinaire :
| Déclaration | Échéance | Contenu |
|---|---|---|
| Notification initiale | Dans les 4 heures après classification comme majeur | Champs initiaux du modèle de notification |
| Rapport intermédiaire | Dans les 72 heures après la notification initiale | Faits et statut actuels |
| Rapport final | Dans le mois suivant le dernier rapport intermédiaire | Évaluation finale et champs exigés du modèle |
La notification initiale est due dès que possible. Elle doit intervenir dans les 4 heures suivant la classification de l’incident comme majeur, et au plus tard 24 heures après en avoir pris connaissance.
Le rapport intermédiaire est dû au plus tard 72 heures après la soumission de la notification initiale. Mettez-le à jour sans retard injustifié dès que les activités normales reprennent. Le rapport final est dû au plus tard un mois après le rapport intermédiaire ou sa dernière mise à jour.
Le délai de 4 heures court à partir de la classification comme majeur, pas du début de la panne. La limite distincte de 24 heures court à partir de la prise de connaissance. Gardez trois horodatages séparés : la détection, la borne d’incident confirmée par la politique et la classification.
Le monitoring peut fournir les deux premiers selon sa politique documentée. La classification est un jugement juridique et opérationnel, extérieur au produit de monitoring. L’article 5 prévoit d’autres cas particuliers, et c’est le texte primaire qui fait foi.
Le monitoring éclaire quelques questions de la déclaration
La norme de déclaration de l’UE couvre bien plus que la disponibilité. Un registre de monitoring peut aider à répondre à quelques questions directes :
- Quand l’incident a-t-il été détecté, et quand a-t-il commencé ?
- Combien de temps les services ont-ils été indisponibles ?
- Quels services surveillés et quelles régions de sondes ont constaté un impact ?
- Quand le service a-t-il été rétabli, et comment le savez-vous ?
À lui seul, ce même registre ne dit pas combien de clients ou de transactions ont été touchés. Il ne peut pas non plus, sans autre source, chiffrer l’impact financier ou sur les données, établir l’étendue géographique au sens juridique ni déterminer la cause racine. Même l’indisponibilité mesurée dépend du type de monitor et de la politique d’incident documentés.
Une page de statut peut ajouter une version publique. Si sa publication ou ses annotations diffèrent du registre interne, cet écart doit être expliqué. Ne partez pas du principe qu’une divergence est impossible.
Captures et discussions seules restent des sources faibles
Une capture de tableau de bord et un retour dans l’historique Slack peuvent servir de point de départ pour reconstituer une panne après coup. Les deux peuvent ajouter du contexte. Aucun n’est une source unique solide pour les horodatages du monitoring.
Une capture montre en général un chiffre à un instant donné, pas les événements qui l’ont produit. Elle peut aussi omettre l’horloge, la politique ou la source.
Un fil de discussion retient le moment où les personnes ont parlé de l’incident, pas forcément celui où le monitoring l’a détecté ou confirmé. Messages et souvenirs restent utiles, mais ils doivent être rapprochés du registre système.
Un examinateur peut légitimement demander d’où vient un horodatage, quelle politique l’a produit et si la curation ultérieure reste visible. Un registre continu d’événements répond à ces questions plus directement qu’une image recadrée ou qu’une séquence reconstituée de mémoire.
Des bornes consultables rendent un registre vérifiable
Un registre de disponibilité peut contribuer au travail de déclaration DORA si ses bornes et sa curation ultérieure sont consultables. Cette contribution ne vaut pas constat de conformité.
Le système consigne les horodatages
Les heures de détection et de rétablissement viennent du monitoring lui-même. Elles sont consignées au moment où les événements se produisent, pas saisies après coup. Un horodatage ne vaut que ce que vaut l’horloge qui le produit.
La confirmation a un périmètre explicite
L’échec d’une seule sonde régionale peut signifier que la cible est indisponible. Il peut aussi signifier qu’un chemin réseau est instable. Pour les 11 types de checks régionaux de Perstat, Free utilise 2 régions, Pulse 3, et Sentinel et au-delà jusqu’à 6.
La politique régionale est configurable et utilise par défaut un quorum de 2 régions. Pour ces monitors, le début d’incident consigné est la confirmation par la politique configurée, pas le premier échec de sonde.
Les monitors agent et heartbeat n’utilisent ni régions ni quorum et suivent leurs propres règles de signal entrant. Il s’agit de la sémantique du produit, pas de la définition juridique d’un incident au sens de DORA.
Les exclusions arbitrées restent visibles
Perstat sépare l’indisponibilité mesurée du registre arbitré des pannes. Les fenêtres de maintenance et d’exclusion conservent leurs bornes réelles. Une exclusion arbitrée garde son motif et son auteur, et elle peut être annulée.
Le but est de rendre l’intervention visible, pas d’embellir le chiffre. Ce registre produit ne rend pas une exclusion automatiquement acceptable pour une autorité de surveillance ou une contrepartie.
Une page de statut peut partager ce registre
Un composant de page de statut lié peut utiliser le même registre de monitor et d’incident. La publication reste une action explicite, et les annotations publiques peuvent différer du registre interne.
Une source partagée réduit les reconstitutions en double. Elle ne garantit pas que chaque version publique et interne soit identique.
Un exemple éditorial montre le calcul
L’ exemple de rapport SLA public de Perstat est une illustration éditoriale et recalculable pour un service de démonstration. Ce n’est ni un rapport client généré ni un export en libre-service.
L’exemple suppose six régions sur un trimestre de 91 jours, soit 131 040 minutes. Sur ces régions, il compte 1 572 480 checks et un incident confirmé :
- 02:40:42 UTC : un check échoue depuis eu (Francfort)
- 02:41:12 UTC : le quorum confirme quand na (Newark) et as (Singapour) concordent
- 02:48:24 UTC : le rétablissement est confirmé entre les régions
La fenêtre SLA va de la confirmation au rétablissement confirmé, de 02:41:12 à 02:48:24 UTC, et dure 7 minutes 12 secondes. Les 30 secondes qui précèdent la confirmation restent visibles au registre. Elles ne sont ni étirées ni rognées en silence. Le monitor d’exemple applique une règle de 1 check en échec par région avec un quorum de 2 régions, et non la valeur par défaut de 2 checks consécutifs.
La disponibilité brute est de 99,925 %, et de 99,994 % après exclusion de l’unique fenêtre de maintenance annoncée. Vous pouvez recalculer chacun de ces chiffres d’exemple. Ils décrivent l’exemple éditorial, pas le déploiement d’un client.
Remonter aux sources depuis la déclaration
Prenez un champ de la déclaration et demandez-vous où se trouve sa réponse. Faites-le avant un incident, pas après :
| Besoin de déclaration | Source possible dans Perstat |
|---|---|
| Heure de détection | Horodatage du monitoring, consigné en direct |
| Début de l’incident | Confirmation par la politique configurée des monitors régionaux |
| Durée de l’indisponibilité | Fenêtre entre confirmation et rétablissement configurés |
| Panne du service ou d’une route observée | Résultats régionaux des 11 types de checks |
| Indisponibilité planifiée ou curation | Maintenance et exclusions avec bornes, motif et auteur |
| Rétablissement observé | Rétablissement selon la politique configurée du monitor |
Les monitors agent et heartbeat suivent leurs propres règles de signal entrant. Ne les faites donc pas entrer de force dans un modèle de quorum régional. Si un champ requis n’a pas de source aujourd’hui, comblez ce manque avant le prochain événement à déclarer.
Le monitoring couvre un volet des déclarations DORA
Un produit de monitoring ne suffit pas à vous préparer à DORA. Il ne classe pas l’incident et ne dépose pas de déclaration à votre place. Ces sujets restent de votre ressort :
- le périmètre
- la classification
- le registre des prestataires tiers de services TIC
- la procédure de déclaration
- l’appréciation juridique
Le monitoring peut apporter ces éléments au dossier plus large que constitue votre équipe :
- les horodatages système
- les mesures
- les incidents
- la maintenance
- la curation visible
Les 11 types de checks régionaux de Perstat comprennent HTTP, TCP et DNS. Selon l’offre, ils peuvent descendre à un intervalle de 10 secondes par MCP.
Ces types de checks utilisent jusqu’à six régions selon l’offre et la politique régionale configurée décrite plus haut. Agent et heartbeat n’utilisent ni l’une ni l’autre.
Le plan de contrôle se trouve dans l’UE, et l’entreprise qui l’exploite est allemande. Ces faits peuvent étayer un registre de disponibilité, pas une affirmation de conformité à DORA.
Aujourd’hui, le registre arbitré se trouve dans le produit, et l’exemple public est éditorial. Chaque vue de monitor propose un rapport PDF sur 7, 14, 30 ou 90 jours, dans toutes les offres. Le rapport n’est ni signé ni attesté. Un CSV à l’échelle de l’organisation, avec manifeste, est fourni manuellement sur demande.
Consultez la visite guidée ou l’ exemple éditorial sans inscription. Quand vous le souhaitez, lancez le monitoring gratuitement.