Trois questions pour examiner un rapport SLA

Un pourcentage reste une simple affirmation. Un examinateur peut aussi demander quelles fenêtres l’ont produit, quelles modifications ont été faites et d’où viennent les horodatages.

Sur cette page

Le chiffre en tête d’un rapport SLA est une affirmation : 99,95 %, ce trimestre, consigné au registre. Un client, un acheteur, un auditeur ou un régulateur peut poser une question plus difficile : comment le savez-vous ? Les preuves qu’ils exigent et leur conclusion dépendent de leur périmètre.

Cette question compte dans les secteurs réglementés. DORA s’applique depuis le 17 janvier 2025, et NIS2 impose des obligations de déclaration d’incidents aux entités qui entrent dans son champ.

Savoir si l’un ou l’autre cadre s’applique, comment un incident est classé et quel délai court relève de décisions juridiques et opérationnelles. Ces décisions se prennent en dehors d’un outil de monitoring. Les examinateurs ont tout de même besoin de preuves qu’ils peuvent vérifier.

Trois lacunes servent de points de contrôle utiles, et voici comment les repérer dans votre propre rapport. Ce sont des questions d’examen, pas une prédiction du résultat d’un audit.

Remonter depuis le pourcentage

Posez trois questions au pourcentage :

  • Quelles fenêtres ont compté comme indisponibilité ?
  • Quelles fenêtres ont été exclues, et pourquoi ?
  • Qu’est-ce qui a consigné les horodatages ?

Un rapport qui ne répond pas à ces trois questions est plus difficile à recalculer. C’est le test limité retenu ici, et il ne suppose aucun comportement universel des auditeurs.

Les fenêtres arrondies sont la première lacune

Beaucoup de rapports ramènent les pannes à des chiffres ronds. Une fenêtre devient « environ 15 minutes », ou tout ce qui dure moins de 10 minutes est écarté comme du bruit.

Le résultat se lit bien, mais il ne se reconstruit pas. Un auditeur ne peut pas recalculer un pourcentage à partir d’une fenêtre lissée.

L’enjeu est arithmétique. Un objectif de 99,95 % sur un trimestre de 91 jours laisse environ 65 minutes de budget d’indisponibilité sur 131 040 minutes. Une seule fenêtre arrondie du mauvais côté peut masquer un vrai dépassement ou en inventer un.

Si un incident de 7 minutes et 12 secondes est consigné comme « à peu près 15 minutes », vous avez surévalué votre propre indisponibilité de près de 8 minutes sans raison. Arrondissez-le à zéro, et vous avez effacé sans bruit une preuve qu’un régulateur pourra plus tard rapprocher d’une réclamation client.

Comment la combler. Consignez les bornes réelles à la seconde près, et laissez le pourcentage en découler. Une fenêtre arrondie à 15 minutes n’a pas meilleure allure, et elle ne se défend pas.

Les exclusions silencieuses sont la deuxième lacune

Distinguez deux chemins. La maintenance annoncée a un calendrier et une annonce avant la fenêtre. La curation d’un faux positif intervient après la mesure et exige son propre auteur, un motif, un effet avant et après, et une annulation possible.

Aucun des deux chemins ne décide de ce qu’un contrat ou un examinateur doit accepter.

Comment la combler. Montrez les bornes réelles et la provenance de chaque chemin. Étiquetez la maintenance annoncée comme planifiée, et une correction ultérieure comme curation. Ne présentez pas l’une comme l’autre, et ne retirez aucune des deux en silence du registre vérifiable.

La mesure autodéclarée est la troisième lacune

C’est la lacune à laquelle les équipes s’attendent le moins, car elle porte sur le point d’observation, pas sur le calcul.

Si vos données de disponibilité viennent d’une seule sonde, ou pire de l’infrastructure même qui est tombée en panne, un auditeur a une objection légitime. Vous ne pouvez pas distinguer votre propre problème réseau d’une vraie panne de service. La personne qui reconstitue la chronologie après coup ne peut pas non plus prouver que les horodatages n’ont pas été ajustés.

Comment la combler. Mesurez depuis l’extérieur du système surveillé. Consignez les observations de plusieurs chemins choisis selon l’offre avant de compter un incident.

L’accord entre sites est une preuve corrélée issue de plusieurs chemins. Il réduit la dépendance à une seule route, mais ne prouve ni la cause racine ni l’origine juridique.

Laissez le système de monitoring horodater les événements au moment où ils surviennent. Documentez la politique qui a transformé ces observations en incident.

Un rapport qui tient a trois propriétés

Ces trois propriétés n’ont rien de spectaculaire :

  • des bornes de fenêtre réelles
  • des chemins de maintenance et de curation visibles et clairement étiquetés
  • une mesure prise depuis l’extérieur du système et confirmée entre les régions

Rien de tout cela ne fait monter votre uptime. Cela le rend vérifiable et donne à l’examinateur une base qu’il peut contrôler. Un chiffre flatteur que vous ne pouvez pas défendre vaut moins qu’un chiffre honnête que vous pouvez défendre.

Lire une ligne du rapport d’exemple

Un registre se comprend mieux en le voyant qu’en le décrivant, c’est pourquoi Perstat publie un exemple éditorial. L’ exemple de rapport SLA illustre un trimestre pour un service de démonstration, et chaque chiffre y tombe juste. Ce n’est pas un rapport client généré automatiquement.

Un check échoue à Francfort à 02:40:42 UTC, mais l’incident ne s’ouvre pas à ce moment-là. Trente secondes plus tard, des sondes à Newark et à Singapour concordent : le service est injoignable. Le quorum confirme, et l’incident s’ouvre à 02:41:12 UTC. 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.

Cette confirmation marque le début de la fenêtre comptée, de 02:41:12 à 02:48:24 UTC. La fenêtre ne commence ni au premier check en échec ni à une minute ronde.

La fenêtre de maintenance de 90 minutes, plus tard dans le mois, est exclue, mais elle reste au rapport avec l’horodatage de son annonce. La disponibilité brute est de 99,925 %. Après exclusion de cette maintenance annoncée, elle est de 99,994 %.

Le calcul de cet exemple éditorial peut être refait. L’exemple n’est ni un rapport d’assurance ni une déclaration réglementaire.

Classification et déclaration relèvent de votre équipe

Un produit de monitoring n’établit pour personne la conformité à DORA ou à NIS2. La classification, la déclaration et les délais restent sous votre responsabilité. Un outil peut apporter des horodatages système, des mesures, des registres de maintenance et une curation visible à l’ensemble de preuves que constitue votre équipe.

Si votre rapport actuel ne répond pas aux trois questions ci-dessus, mieux vaut le savoir maintenant. À ce stade, le seul prix à payer est un chiffre un peu moins flatteur.

Vous pouvez lancer le monitoring gratuitement ou d’abord parcourir le produit. Aucun rendez-vous commercial n’est nécessaire pour voir comment le registre est tenu.