Dashboards

Principes de conception, métriques clés, dashboards opérationnels vs métier et comment construire des vues utiles.

À quoi servent les dashboards ?

Un dashboard est une vue consolidée de métriques qui permet de comprendre l’état d’un système en un coup d’œil. Mais tous les dashboards ne se valent pas — un dashboard mal conçu peut être tout aussi inutile que de ne pas en avoir du tout.

L’objectif d’un bon dashboard n’est pas d’afficher le plus grand nombre de données possible, mais de répondre à des questions précises de manière rapide et claire.

Principes de conception

1. Définissez l’audience

Avant de créer un dashboard, posez-vous la question : qui va l’utiliser et pour quoi faire ?

• Ingénieur d’astreinte (on-call) : Doit savoir rapidement s’il y a un problème et où il se situe.
• Tech lead : Doit comprendre les tendances de performance et de capacité.
• Product manager : A besoin de métriques métier et d’adoption.
• Cadre dirigeant : A besoin d’indicateurs de haut niveau sur la santé et la croissance.

Chaque audience a besoin d’un dashboard différent.

2. Hiérarchie visuelle

Organisez l’information de la plus importante à la moins importante, de haut en bas et de gauche à droite :

• Ligne supérieure : Indicateurs d’état global (feux tricolores, grands chiffres).
• Lignes intermédiaires : Graphiques de tendance des principales métriques.
• Lignes inférieures : Détail et métriques secondaires.

3. Moins, c’est plus

Un dashboard avec 30 panneaux n’est pas plus utile qu’un dashboard avec 8 panneaux bien choisis. Chaque panneau doit justifier sa présence en répondant à une question concrète.

Règle pratique : si un panneau n’a modifié la décision de personne au cours des 30 derniers jours, il n’a probablement pas besoin d’être là.

4. Contexte temporel

Incluez toujours :

• Sélecteur de plage temporelle : Permettre de basculer entre les 6 dernières heures, 24 heures, 7 jours.
• Comparaison temporelle : Afficher la même métrique une semaine plus tôt pour détecter les anomalies.
• Marqueurs de déploiements : Lignes verticales indiquant quand un déploiement a eu lieu.

5. Des couleurs porteuses de sens

Utilisez les couleurs de manière cohérente et intentionnelle :

• Vert : Tout est normal, dans les limites du SLO.
• Jaune/Orange : Dégradation, on approche du seuil.
• Rouge : Problème actif, hors SLO.

Évitez d’utiliser trop de couleurs décoratives — elles distraient et diluent les signaux importants.

Types de dashboards

Dashboard opérationnel

Conçu pour l’équipe d’ingénierie lors des opérations quotidiennes et de la réponse aux incidents.

Contenu typique :

• Métriques RED par service (rate, errors, duration).
• État des dépendances (bases de données, files d’attente, services externes).
• Ressources d’infrastructure (CPU, mémoire, disque).
• Alertes actives.
• Déploiements récents.

Caractéristiques :

• Actualisation en temps réel (rafraîchissement toutes les 10 à 30 secondes).
• Focus sur les dernières heures.
• Seuils visibles avec des couleurs de feu tricolore.

Dashboard de service

Un dashboard dédié à un microservice spécifique. Chaque équipe devrait en avoir un pour chaque service qu’elle maintient.

Contenu typique :

• Métriques RED du service.
• Latence par endpoint (p50, p95, p99).
• Taux d’erreurs par type d’erreur.
• Métriques des dépendances downstream.
• Utilisation des ressources (CPU, mémoire, connexions à la DB).
• File de messages (le cas échéant) : taille, lag, throughput.

Dashboard métier

Conçu pour les parties prenantes non techniques qui ont besoin de comprendre l’impact sur le métier.

Contenu typique :

• Commandes créées par heure/jour.
• Revenus traités.
• Taux de conversion du checkout.
• Utilisateurs actifs.
• Temps moyen pour accomplir une opération clé.

Caractéristiques :

• Actualisation moins fréquente (toutes les 5 à 15 minutes).
• Focus sur les tendances quotidiennes/hebdomadaires.
• Langage métier, pas technique.

Dashboard de SLO

Affiche le respect des Service Level Objectives de l’équipe.

Contenu typique :

• SLO actuel vs objectif (ex : 99,92 % vs 99,9 %).
• Error budget restant (en minutes ou en pourcentage).
• Tendance de l’error budget sur les 30 derniers jours.
• Incidents ayant consommé de l’error budget.

Ce dashboard est essentiel pour prendre des décisions de priorisation : si l’error budget s’épuise, l’équipe devrait privilégier la stabilité plutôt que les fonctionnalités.

Métriques clés par type de composant

Pour une API Gateway

• Requêtes par seconde (total et par route).
• Latence par route (p50, p95, p99).
• Taux d’erreurs 4xx et 5xx.
• Rate limiting activé.
• Connexions actives.

Pour une base de données

• Requêtes par seconde.
• Latence des requêtes (p50, p95, p99).
• Connexions actives vs pool maximum.
• Lag de réplication (le cas échéant).
• Utilisation du disque et croissance.

Pour une file de messages

• Messages publiés par seconde.
• Messages consommés par seconde.
• Consumer lag (messages en attente).
• Taille de la file.
• Erreurs de traitement (dead letter queue).

Pour un service HTTP

• Métriques RED (rate, errors, duration).
• Distribution des status codes.
• Latence par endpoint.
• Erreurs par type (timeout, 500, 503).
• Saturation (requêtes en file d’attente, threads actifs).

Anti-patterns

Dashboard « wall of text »

Trop de petits panneaux affichant des chiffres que personne ne peut lire. Privilégiez un petit nombre de panneaux grands et clairs.

Dashboard « vanity metrics »

Des métriques qui font joli mais qui ne sont pas actionnables : « total de requêtes depuis la nuit des temps ». Affichez des taux et des tendances, pas des cumuls.

Dashboard sans contexte

Des graphiques sans seuils, sans comparaison temporelle, sans indication de ce qui est « normal ». Sans contexte, un graphique n’est qu’une jolie ligne.

Dashboard obsolète

Un dashboard qui ne reflète pas l’architecture actuelle est pire que pas de dashboard du tout — il génère une fausse confiance. Maintenez les dashboards à jour dans le cadre du cycle de développement.

Un seul dashboard pour tout

Tenter de faire tenir des métriques opérationnelles, métier et d’infrastructure dans un seul dashboard. Chaque audience a besoin de sa propre vue.

Outils

Grafana

L’outil le plus populaire pour les dashboards d’observabilité :

• Prend en charge plusieurs data sources (Prometheus, Elasticsearch, CloudWatch, etc.).
• Templates et variables pour des dashboards dynamiques.
• Alertes intégrées.
• Communauté active avec des dashboards partagés.

Datadog

Plateforme SaaS qui intègre métriques, logs, traces et dashboards :

• Dashboards prêts à l’emploi pour les technologies populaires.
• Corrélation automatique entre les signaux.
• Notebooks pour l’investigation d’incidents.

Kibana

Fait partie de la stack ELK, spécialisée dans la visualisation de logs :

• Dashboards basés sur les données d’Elasticsearch.
• Idéal pour l’analyse de logs et la recherche.
• Lens pour créer des visualisations sans code.

Bonnes pratiques

Dashboard as code

Définissez les dashboards en code (JSON, Terraform, Jsonnet) et versionnez-les dans Git :

• Reproductibilité : vous pouvez recréer les dashboards dans n’importe quel environnement.
• Revue : les modifications de dashboards passent par une code review.
• Historique : vous savez qui a changé quoi et quand.

Onboarding avec les dashboards

Lorsqu’un nouveau membre rejoint l’équipe, les dashboards devraient faire partie de l’onboarding :

• « Voici le dashboard principal du service X. »
• « Voici les indicateurs que nous regardons en premier lors d’un incident. »
• « Voici le dashboard de SLO de l’équipe. »

Itération continue

Les dashboards ne sont pas statiques. Après chaque incident, posez-vous la question :

• Le dashboard m’a-t-il aidé à diagnostiquer le problème ?
• A-t-il manqué une métrique qui aurait été utile ?
• Y avait-il des panneaux qui n’apportent pas de valeur ?

Résumé

Les dashboards sont l’interface humaine de l’observabilité. Un bon dashboard répond à des questions précises pour une audience définie, utilise la hiérarchie visuelle pour prioriser l’information et reste à jour avec l’architecture. En combinant des dashboards opérationnels, de service, métier et de SLO, l’équipe dispose d’une visibilité complète sur la santé du système sous de multiples perspectives.