Concevoir un tableau de bord qui se lit

Jour 1 · Concevoir et construire · 30 min

Grafana s'apprend en une heure. Produire un écran qu'un exploitant lit en trois secondes demande davantage — et c'est là que se joue l'utilité de tout ce que vous avez construit depuis M1.

La règle d'ordre : la forme d'abord, la couleur en dernier

La plupart des mauvais tableaux de bord commencent par le choix des couleurs. C'est l'inverse qu'il faut faire.

1. Quel est le travail de la donnée ? Montrer une grandeur, distinguer des identités, signaler une polarité, donner un chiffre unique, montrer une évolution.
2. La forme découle du travail. Une évolution appelle une courbe ; un état courant appelle un chiffre, pas un graphique.
3. La couleur vient ensuite, et seulement pour le travail qu'elle fait.

La hiérarchie de lecture

Trois niveaux, du plus rapide au plus détaillé. L'exploitant descend seulement s'il a une raison de le faire.

L'erreur numéro un : le double axe

Tracer la température et l'humidité sur un même graphique avec deux échelles verticales est tentant — Grafana le propose. C'est pourtant faux : l'alignement des deux échelles est arbitraire, donc le graphique invente une corrélation qui n'est pas dans les données. Changez une borne, la corrélation disparaît.

La parade : deux graphiques superposés partageant l'axe du temps, ou deux grandeurs ramenées à une base commune sur un seul axe.

La couleur, par le travail qu'elle fait

La palette du parcours

Quatre teintes, dans cet ordre. Elle a été vérifiée : bande de luminosité, saturation suffisante, et surtout séparation sous déficience visuelle — la paire la plus proche reste distinguable pour un daltonien de type protanope.

série 1  #2a78d6   bleu
série 2  #eb6834   orange
série 3  #1baf7a   vert d'eau
série 4  #eda100   jaune

Ce qui reste discret

• Traits fins. 2 px pour une courbe, pas davantage.
• Grille en filet léger, jamais en pointillés — le pointillé ajoute du bruit et se confond avec une série.
• Pas de valeur sur chaque point. Étiqueter le dernier point, ou les extrêmes, suffit.
• Le texte garde sa couleur de texte. Une valeur écrite dans la couleur de sa série devient illisible et redondante avec la pastille de légende.

Grafana en pratique

Jour 1 · Concevoir et construire · 20 min

Grafana lit des sources de données et affiche des panneaux. Trois notions suffisent à en faire le tour.

Les types de panneaux utiles en supervision

Une requête Flux dans Grafana

C'est exactement le Flux de M3, avec les variables injectées par ${...} :

from(bucket: "releves")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "temperature")
  |> filter(fn: (r) => r.site == "${{site}}")
  |> aggregateWindow(every: v.windowPeriod, fn: mean)

Quiz — Conception et Grafana

Jour 1 · Concevoir et construire · 8 min

TP 1 — Premiers panneaux

Jour 1 · Concevoir et construire · 1 h

Brancher Grafana sur InfluxDB et construire les quatre chiffres d'état.

1. Ajoutez Grafana à votre docker-compose.yml plutôt que de le lancer à part — la pile doit rester reproductible :
   copier

     grafana:
       image: grafana/grafana:11.1.0
       ports: ["3000:3000"]
       environment:
         - GF_SECURITY_ADMIN_PASSWORD=thermeo2026
       volumes:
         - grafana-data:/var/lib/grafana

2. Ouvrez http://localhost:3000. Dans Connections → Data sources, ajoutez InfluxDB en choisissant le langage de requête Flux, l'URL de votre conteneur, l'organisation thermeo et votre jeton.
3. Cliquez sur Save & test : la connexion doit être confirmée avant d'aller plus loin.
4. Créez un tableau de bord et, avant de toucher à Grafana, écrivez sur papier les quatre chiffres qu'un exploitant de Thermeo doit voir en trois secondes. Justifiez chacun.
5. Construisez le premier panneau Stat : moyenne du parc sur la dernière heure.
   copier

   from(bucket: "releves")
     |> range(start: -1h)
     |> filter(fn: (r) => r._measurement == "temperature")
     |> mean()

6. Construisez les trois autres : nombre de capteurs ayant émis dans les dix dernières minutes, nombre d'alertes actives, âge du dernier relevé reçu.
7. Disposez-les en une seule rangée en haut de l'écran, comme dans le schéma de la leçon.
8. Vérifiez la lisibilité : demandez à quelqu'un de regarder l'écran trois secondes, puis de dire si tout va bien. S'il hésite, la disposition est à revoir.

TP 2 — Le tableau de bord de supervision

Jour 1 · Concevoir et construire · 1 h 30

Assembler un écran complet, avec variables et palette maîtrisée.

1. Ajoutez sous vos chiffres d'état un panneau Time series des températures sur 24 heures, une courbe par site.
2. Appliquez la palette de la leçon. Dans Panel → Overrides, fixez la couleur par série nommée, jamais par ordre d'affichage :
   copier

   Lyon    -> #2a78d6
   Paris   -> #eb6834
   Nantes  -> #1baf7a
   Lille   -> #eda100

3. Vérifiez la règle : filtrez pour masquer Lyon, et confirmez que Paris reste orange au lieu de devenir bleu.
4. Réglez l'épaisseur des traits à 2 px, retirez le remplissage sous les courbes, et passez la grille en filet léger — jamais en pointillés.
5. Activez la légende et le libellé de la dernière valeur. C'est ce qu'impose l'avertissement de contraste signalé dans la leçon : l'identité ne doit pas reposer sur la seule couleur.
6. Créez une variable site alimentée par la base, dans Dashboard settings → Variables, de type Query :
   copier

   import "influxdata/influxdb/schema"
   schema.tagValues(bucket: "releves", tag: "site")

7. Injectez-la dans vos requêtes avec ${{site}} et vérifiez que le sélecteur apparaît en haut de l'écran. Ajoutez un nouveau capteur sur un nouveau site : il doit apparaître dans la liste sans rien modifier.
8. Ajoutez en bas un panneau Table avec la dernière valeur de chaque capteur et son ancienneté. Au-delà de sept séries, c'est la table qui reste lisible, pas le graphique.
9. Faites délibérément l'erreur : ajoutez un panneau où la température et l'humidité partagent un graphique à deux axes. Regardez-le, puis remplacez-le par deux panneaux empilés. Conservez une capture des deux pour votre rendu.
   copier

   # a produire puis remplacer : le double axe est l'anti-patron le plus courant

10. Exportez le tableau de bord en JSON et versionnez-le.

Point de contrôle — fin du jour 1

Jour 1 · Concevoir et construire · 15 min

Alerter sans noyer

Jour 2 · Alerter et sortir du cadre · 20 min

Vous savez déjà déclencher une alerte : en M2 dans l'objet, en M3 dans Node-RED. Grafana en propose une troisième, et il faut savoir laquelle choisir.

Les états d'une alerte

Ce qui rend une alerte utile

• Elle est actionnable. Si personne ne peut rien faire en la recevant, elle ne doit pas exister.
• Elle dit où et quoi. « Alerte température » ne vaut rien ; « capt-07, étage 2, Lyon : 26,3 °C depuis 20 min » se traite.
• Elle se referme. Une alerte qui ne signale jamais son retour à la normale laisse croire au problème permanent.

TP 3 — Des alertes qu'on peut suivre

Jour 2 · Alerter et sortir du cadre · 1 h

Créer des règles d'alerte durables et annoter les incidents.

1. Créez une première règle dans Alerting → Alert rules : température moyenne supérieure à 24 °C.
   copier

   from(bucket: "releves")
     |> range(start: -15m)
     |> filter(fn: (r) => r._measurement == "temperature")
     |> group(columns: ["capteur"])
     |> mean()

2. Réglez la condition sur IS ABOVE 24, l'évaluation toutes les minutes, et surtout « for » à 15 minutes — c'est ce délai qui joue le rôle de l'hystérésis.
3. Rédigez le résumé de l'alerte avec les étiquettes, pour qu'elle soit actionnable :
   copier

   Capteur {{{{ $labels.capteur }}}} — {{{{ $values.B }}}} °C depuis 15 min

4. Faites monter un capteur au-dessus du seuil et observez la bascule Normal → Pending → Alerting. Chronométrez : la notification ne doit pas partir avant les quinze minutes.
5. Créez une seconde règle sur l'absence de données : configurez le comportement No Data en Alerting, puis coupez un capteur et vérifiez le déclenchement.
6. Comparez avec les deux autres mécanismes que vous connaissez : le testament MQTT de M1 et la requête de détection de M3. Chronométrez les trois sur la même coupure et consignez les délais.
7. Configurez un point de contact — un webhook vers un service de test suffit — et vérifiez qu'une notification part réellement.
8. Ajoutez enfin une annotation automatique : les périodes d'alerte doivent apparaître en surbrillance sur vos graphiques, pour relire un incident après coup.

Quand Grafana ne suffit plus

Jour 2 · Alerter et sortir du cadre · 20 min

Grafana est excellent pour superviser. Il l'est beaucoup moins dès qu'on sort de ce cadre.

L'architecture minimale

Trois pièces, pas davantage :

1. Une API qui interroge InfluxDB et expose des données prêtes à afficher. Elle ne renvoie jamais la base brute au navigateur.
2. Une page web qui les affiche.
3. Un canal temps réel pour que la page se mette à jour sans rechargement.

Interrogation périodique ou WebSocket

Quiz — Alertes et interfaces

Jour 2 · Alerter et sortir du cadre · 7 min

TP 4 — Une interface sur mesure

Jour 2 · Alerter et sortir du cadre · 1 h 30

Construire l'API et la page temps réel, et savoir quand cela se justifie.

1. Écrivez l'API avec FastAPI. Elle interroge InfluxDB et n'expose que le nécessaire :
   copier

   from fastapi import FastAPI
   from fastapi.middleware.cors import CORSMiddleware
   from influxdb_client import InfluxDBClient
   import os
   
   app = FastAPI()
   app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"])
   
   cli = InfluxDBClient(url="http://localhost:8086",
                        token=os.environ["INFLUX_TOKEN"],   # jamais en dur
                        org="thermeo")
   
   FLUX = '''
   from(bucket: "releves")
     |> range(start: -10m)
     |> filter(fn: (r) => r._measurement == "temperature")
     |> group(columns: ["capteur"])
     |> last()
   '''
   
   @app.get("/api/etat")
   def etat():
       tables = cli.query_api().query(FLUX)
       return [{"capteur": r.values["capteur"],
                "valeur": r.get_value(),
                "instant": r.get_time().isoformat()}
               for t in tables for r in t.records]

2. Lancez et vérifiez :
   copier

   INFLUX_TOKEN="<jeton>" uvicorn api:app --reload --port 8000
   curl -s http://localhost:8000/api/etat | python3 -m json.tool

3. Écrivez une page HTML autonome qui interroge cette API toutes les cinq secondes et affiche une tuile par capteur : nom, valeur, ancienneté. Reprenez la palette et la hiérarchie de la leçon du jour 1.
4. Traitez le cas de l'erreur : si l'API ne répond pas, la page doit le dire clairement plutôt que d'afficher des valeurs périmées comme si elles étaient fraîches. C'est le défaut le plus dangereux d'un écran de supervision.
5. Grisez toute tuile dont la dernière valeur date de plus de deux minutes : une donnée périmée affichée comme actuelle vaut moins que pas de donnée.
6. Ajoutez un endpoint POST /api/consigne qui publie une consigne en message MQTT retenu — le motif du jumeau vu en M3 — et un bouton dans la page. C'est ce que Grafana ne sait pas faire.
7. Ajoutez l'API et la page à votre docker-compose.yml.
8. Rédigez une note d'une page : ce que vous mettez dans Grafana, ce que vous mettez dans l'interface sur mesure, et pourquoi. Chiffrez la charge de développement de chaque option.

Point de contrôle — fin du module M4

Jour 2 · Alerter et sortir du cadre · 20 min