Un tableau de bord analytique destiné à la direction doit présenter cinq à huit KPI orientés résultats, et non de la télémétrie brute : la disponibilité par rapport au SLA ou au SLO pour chaque service exposé aux clients, le budget d'erreur restant, les incidents ayant affecté les clients par niveau de gravité, la tendance du MTTR, le temps de réponse p95 sur les parcours clés, le risque d'expiration des certificats et des domaines, ainsi que la tendance du trafic et des pages d'erreur. Chaque KPI a besoin d'un objectif, d'une tendance et d'une ligne de commentaire ; tout le reste relève des tableaux de bord techniques.
Pourquoi la direction a besoin de résultats, pas de métriques
Les dirigeants arbitrent les investissements, les risques et les engagements envers les clients. Un graphique CPU ou 400 alertes ne leur disent pas s'il faut financer un projet de fiabilité ou reporter un lancement. Les KPI de résultat répondent à trois questions : les clients obtiennent-ils ce que nous avons promis, la tendance s'améliore-t-elle, et où se situe le risque ?
Un test utile : si un chiffre peut varier sans qu'aucun client ne s'en aperçoive, il n'a pas sa place ici.
L'ensemble de KPI recommandé
| KPI | Définition | Exemple d'objectif | Pourquoi la direction s'y intéresse |
|---|---|---|---|
| Disponibilité vs SLO | Part des vérifications réussies par service exposé aux clients | 99,9 % par mois pour le paiement et l'API | Reflète les SLA contractuels |
| Budget d'erreur restant | Indisponibilité autorisée moins indisponibilité consommée | Plus de 50 % restant à mi-mois | Indique quand ralentir les mises en production |
| Incidents affectant les clients | Incidents ressentis par les utilisateurs, par gravité | Aucun Sev-1, au plus deux Sev-2 | L'impact réel, pas le bruit des alertes |
| Tendance du MTTR | Temps moyen entre la détection et le rétablissement | Moins de 30 minutes et en baisse | Reflète la maturité opérationnelle |
| Temps de réponse p95 | Latence pour 95 % des requêtes sur la connexion et le paiement | Moins de 800 ms | La lenteur coûte des conversions |
| Risque d'expiration | Certificats et domaines expirant sous 30 jours | Zéro élément | Des pannes évitables et embarrassantes |
| Tendance du trafic et des pages d'erreur | Visiteurs et part des réponses 4xx/5xx | 5xx sous 0,1 % des pages vues | Relie la fiabilité à l'exposition des utilisateurs |
| Évolution d'un mois sur l'autre | Sens et ampleur de la variation par KPI | Flèche et pourcentage sur chaque tuile | Montre où concentrer l'attention |
Calculer correctement le budget d'erreur
Le budget d'erreur correspond au niveau d'indisponibilité que votre SLO autorise. Un mois de 30 jours compte 43 200 minutes, donc :
- 99,9 % autorise 0,1 %, soit environ 43,2 minutes d'indisponibilité
- 99,95 % autorise environ 21,6 minutes
- 99,99 % autorise environ 4,3 minutes
Un seul incident de 30 minutes face à un objectif de 99,9 % consomme environ 70 % du budget mensuel. « Il reste 13 minutes » est plus parlant pour la direction que « 99,93 % de disponibilité ». Pour approfondir la conception des SLO, consultez notre guide du monitoring des SLO d'API.
Ce qu'il faut laisser de côté
Gardez ces éléments sur les vues techniques :
- Utilisation du CPU, de la mémoire et du disque. Ce sont des causes, pas des résultats, et elles fluctuent en permanence.
- Nombre brut d'alertes. Davantage d'alertes peut signifier une meilleure couverture ou un réglage moins bon ; aucune des deux lectures n'aide un dirigeant.
- Résultats de ping et de ports par hôte. La latence d'un nœud intéresse l'équipe réseau, pas le conseil d'administration.
- Disponibilité moyenne de tous les moniteurs. Faire la moyenne d'une API de paiement et d'un microsite marketing masque le chiffre qui compte.
Une présentation qui sera lue
Les dirigeants consacrent souvent moins d'une minute à une synthèse de fiabilité ; concevez-la donc pour une lecture rapide :
- Affichez un objectif à côté de chaque valeur. « 99,87 % pour un objectif de 99,9 % » a du sens ; « 99,87 % » seul n'en a pas.
- Utilisez les flèches de tendance et les couleurs avec parcimonie. Le vert, l'orange et le rouge doivent refléter l'objectif.
- Ajoutez une ligne de commentaire par KPI. « Deux incidents Sev-2, tous deux liés à une passerelle de paiement tierce ; travaux de bascule prévus au T4 » transforme les données en décision.
- Tenez un rythme fixe. Une revue mensuelle accompagnée de mises à jour hebdomadaires par e-mail convient à la plupart des organisations.
Rédiger ce commentaire à la main est fastidieux, et c'est là que les rapports IA sont utiles. Les rapports IA d'UpScanX résument les anomalies, corrèlent les alertes liées en incidents, proposent des pistes de cause racine et des prévisions de tendance, et peuvent être planifiés par e-mail : la direction reçoit ainsi un récit clair plutôt qu'un export brut.
D'où viennent les données
La plupart de ces KPI proviennent d'une surveillance que vous effectuez déjà. La disponibilité, le nombre d'incidents et les temps de réponse sont issus de vérifications HTTP et API exécutées depuis plusieurs régions. Le risque d'expiration provient de la surveillance SSL et des domaines. Les tendances du trafic et des pages d'erreur viennent de l'analyse web : le tableau de bord analytique UpScanX est gratuit dans toutes les offres et affiche les pages vues, les visiteurs, les sources de trafic et la répartition des codes de statut HTTP, ce qui permet de voir si un pic de 5xx a touché de vrais utilisateurs.
Points clés
- Limitez la vue direction à cinq à huit KPI de résultat liés aux services exposés aux clients.
- Exprimez la fiabilité en budget d'erreur restant ; 99,9 % sur 30 jours équivaut à environ 43,2 minutes.
- Comptez les incidents affectant les clients par gravité et suivez le MTTR comme une tendance.
- Laissez les métriques d'infrastructure, les volumes d'alertes et les données par hôte sur les tableaux de bord techniques.
- Associez à chaque KPI un objectif, une flèche de tendance et une phrase de contexte.