Le problème se produit un lundi matin : toutes les tuiles sont vertes, la latence moyenne reste basse et la base consomme peu. Pourtant, 140 dossiers attendent depuis vendredi dans une file secondaire. Le tableau décrit des composants en bonne santé tout en cachant la promesse que les utilisateurs ne reçoivent plus.
Le vrai enjeu est de montrer assez de contexte pour prendre une action sûre, sans transformer la vue en console d’exploration universelle. Chaque panneau doit répondre à une question, rendre la population visible et conduire à un owner, un seuil ou une investigation bornée.
Contre-intuitivement, un tableau moins dense peut révéler davantage. Une moyenne, douze jauges et trente couleurs rassurent jusqu’au jour où une cohorte extrême disparaît dans l’agrégation. Une distribution, un âge maximal et une annotation de déploiement racontent souvent mieux le risque.
Pour une application métier web sur mesure, le dashboard fait partie du run. Ce guide relie parcours, signaux techniques, effets métier et règles d’action, puis vérifie fraîcheur, reprise et coût avant de généraliser les écrans.
Commencer par la décision à prendre
Écrire la question dans le titre
« Les commandes peuvent-elles encore être confirmées ? », « les exports finiront-ils avant l’ouverture ? » ou « le dernier déploiement dégrade-t-il un tenant ? » guident le choix des séries. « Dashboard API » ne dit ni population, ni promesse, ni action.
La fiche du panneau précise owner, source, calcul, fenêtre, unités, exclusions et lien de diagnostic. Elle indique aussi ce que la mesure ne prouve pas. Une disponibilité HTTP ne garantit pas qu’un dossier atteint son état métier.
Limiter les décisions par vue
Une vue de pilotage tient sur un écran et couvre quelques décisions fréquentes. L’exploration détaillée reste accessible par lien. Cette séparation garde le tableau stable pendant l’incident et évite que chacun ajoute sa courbe préférée.
Mesurer un parcours plutôt qu’un composant
Le parcours commence à l’intention et finit au résultat utile. Pour une commande, il traverse API, transaction, message, ERP et statut visible. Son indicateur peut mesurer proportion terminée dans une durée, âge des dossiers ouverts ou erreurs définitives.
Les composants gardent des vues de diagnostic, mais le premier écran suit la promesse. Un broker disponible avec un consommateur arrêté ne rend pas le parcours disponible. Une base saine avec un contrat externe refusé ne clôt pas le dossier.
Définir numérateur et dénominateur
« 98 % réussis » exige population, fenêtre et exclusions. Les demandes annulées par l’utilisateur, les doublons et les résultats encore inconnus sont classés explicitement. Changer cette définition crée une nouvelle série ou une annotation.
Combiner résultat, trafic, erreur et saturation
Les quatre signaux proposés dans le chapitre Google SRE sur le monitoring — latence, trafic, erreurs et saturation — donnent une grille technique utile. Le produit les relie à un résultat et à une file de travail.
La latence sépare succès et échecs ; le trafic distingue demande et travail réellement consommé ; les erreurs sont classées par action ; la saturation observe la ressource qui borne le débit. Aucun signal isolé ne prouve une causalité.
Afficher la capacité restante
Le CPU moyen peut rester bas quand le pool de connexions est plein. Le dashboard suit attente du pool, mémoire utile, quota partenaire ou workers disponibles selon le goulot plausible. La capacité est locale à l’architecture.
Afficher cohortes et distributions
Médiane, percentiles et histogramme révèlent la queue de distribution. Le percentile choisi correspond à une promesse et à un volume suffisant. Sur peu d’événements, comptes et cas individuels sont plus honnêtes qu’un percentile instable.
Tenant, type de dossier, route normalisée, version et région peuvent former des cohortes, mais leur cardinalité est contrôlée. Les identifiants uniques ne deviennent pas des labels de métrique. Le drill-down vers logs ou traces prend le relais.
Comparer sans masquer les petits groupes
Une cohorte à faible volume peut subir un incident total sans changer la moyenne globale. La vue expose nombre de cas et taux. Un seuil absolu complète le ratio pour éviter des alertes sur un seul événement non critique.
Montrer l’âge avant la profondeur des files
Une profondeur stable peut contenir un dossier bloqué depuis deux jours et des milliers de messages récents. L’âge du plus ancien, le temps jusqu’au résultat, le débit entrant/sortant, les retries et les erreurs définitives décrivent mieux la promesse.
Les files sont séparées par priorité ou type de travail lorsqu’elles ont des engagements différents. Une file de notifications ne doit pas masquer une révocation urgente. Le dashboard montre aussi les messages en traitement et les réservations expirées.
Relier l’âge à une action
Si l’âge d’une commande dépasse la fenêtre locale de dix minutes pendant deux mesures, le runbook examine consommateurs, dépendance et messages bloquants. Ajouter des workers n’est autorisé qu’après vérification de la base et des quotas.
Rendre la fraîcheur des données visible
Chaque vue affiche dernière collecte, retard d’ingestion et trous. Un « zéro erreur » avec une collecte arrêtée devient « donnée inconnue », jamais vert. Les requêtes longues indiquent leur fenêtre et l’instant de calcul.
Le pipeline de télémétrie possède ses propres métriques : refus, échantillonnage, queue, mémoire et export. L’absence de signaux sur une version nouvellement déployée déclenche un contrôle d’instrumentation avant une conclusion sur l’application.
Relier technique et conséquence métier
Le nombre de dossiers bloqués, l’âge, la valeur ou la fonction touchée qualifient l’impact. La valeur financière est utilisée seulement si correcte, autorisée et utile. Une approximation présentée comme chiffre exact peut orienter une mauvaise priorité.
Le lien reste prudent : une hausse SQL et des commandes lentes sont corrélées ; une trace ou une expérience bornée recherche la causalité. Le dashboard ne doit pas écrire « cause base » parce que deux courbes montent ensemble.
Conserver le statut métier
Les états reçu, en cours, réussi, refusé et résultat inconnu permettent de compter la cohorte. Un statut générique « traité » empêche de distinguer succès et abandon. Le modèle de données précède souvent le bon tableau.
Annoter déploiements et changements
Versions, flags, migrations, bascules de partenaire et changements de capacité apparaissent sur la fenêtre. L’annotation cite l’événement et permet de filtrer avant/après. Elle n’affirme pas que le changement a causé la variation.
Les canaries affichent ancienne et nouvelle version sur populations comparables. Si le trafic ou les tenants diffèrent, la conclusion garde cette limite. Un rollback qui rétablit le signal renforce l’hypothèse mais ne remplace pas l’analyse.
Associer chaque seuil à une action
Un seuil vient d’une promesse, d’une capacité ou d’un délai de récupération. Il possède fenêtre, tolérance, owner et runbook. Une alerte sans action fatigue le run et apprend à ignorer le rouge.
Les bonnes pratiques d’alerte Prometheus recommandent notamment des symptômes utiles et une tolérance aux petits écarts. Le projet adapte les règles à son trafic. Il évite un seuil universel copié d’un autre système.
Tester le seuil avant l’incident
Une simulation ou un replay historique vérifie déclenchement et volume. Le runbook est exécuté par une personne non auteure. Le seuil change si l’action arrive trop tôt, trop tard ou ne réduit aucun risque.
Séparer surveillance et exploration
Le dashboard stable sert astreinte, revue quotidienne ou produit. Les notebooks et vues temporaires servent une hypothèse. Une exploration utile peut devenir panneau après plusieurs usages, avec propriétaire et définition.
Les liens ouvrent la requête détaillée en conservant fenêtre, cohorte et version. L’opérateur ne reconstruit pas quinze filtres sous pression. Les permissions restent cohérentes entre la vue et les données liées.
Cas concret : un export vert mais en retard
Cas concret hypothétique. Un tableau affiche 100 % de jobs réussis. Pourtant, l’export comptable du vendredi termine lundi. La mesure compte seulement les jobs finis et ignore ceux en attente. Le support découvre le retard après un appel métier.
La correction ajoute âge du prochain export dû, durée par volume, file en attente et statut métier « disponible avant ouverture ». Une annotation montre l’arrivée d’un import plus lourd. La trace révèle que l’export attend le pool SQL ; augmenter les workers aurait aggravé le goulot.
Le seuil local alerte si l’âge compromet 7 h 30. Le runbook suspend un import non critique, vérifie pool et plan SQL, puis relance seulement les étapes idempotentes. La réussite se mesure au fichier disponible, pas au processus sorti sans erreur.
Vérifier le signal sur plusieurs fenêtres
Le dashboard compare ensuite trois vendredis. La durée brute augmente avec le volume, mais le temps d’attente du pool représente la majorité de la dérive. Une optimisation de requête seule aurait produit un gain faible. L’équipe décale l’import, réduit sa concurrence et conserve une alerte sur la marge avant l’heure métier.
La vue affiche aussi la fraîcheur de sa propre collecte. Pendant l’exercice, l’arrêt de l’exporteur de métriques transforme les panneaux en « inconnu » et ouvre un diagnostic de télémétrie. Le système ne déclare jamais l’export sain parce qu’aucune erreur récente n’a été reçue.
Le support peut partir d’un export précis et rejoindre sa trace, sans transformer son identifiant en label de métrique. La distribution de durée reste agrégée ; le drill-down conserve les droits et la fenêtre. Cette séparation maintient le coût et la confidentialité tout en donnant un dossier vérifiable.
L’équipe teste enfin la restauration du tableau. Les définitions et alertes sont versionnées, les sources documentées et une vue minimale reste disponible si l’outil principal tombe. Le mode dégradé n’invente pas une valeur : il indique les signaux absents et les vérifications manuelles autorisées.
Adapter la vue au rôle et à la cadence
L’astreinte a besoin de symptômes et d’actions ; le produit regarde promesses et cohortes ; la plateforme explore ressources ; le support part d’un dossier. Une vue unique pour tous devient soit trop abstraite, soit trop dense.
La cadence suit la décision : temps réel pour une action immédiate, revue quotidienne pour les accumulations, hebdomadaire pour capacité et dette. Rafraîchir chaque seconde une décision mensuelle augmente le coût sans valeur.
Partager la définition, différencier la vue
Le support part d’un identifiant et rejoint la cohorte sans exposer cet identifiant dans les labels. Le produit voit promesse et impact, tandis que la plateforme reçoit pools, saturation et liens vers les traces. Les trois vues partagent la définition du statut ; elles ne recalculent pas chacune leur propre vérité.
Une revue hebdomadaire repère les panneaux non consultés, les seuils sans action et les requêtes coûteuses. Le propriétaire justifie leur maintien ou les retire. Cette hygiène évite que le dashboard devienne un musée d’incidents passés et réduit le coût de stockage comme la charge cognitive.
Dans un contexte multi-tenant, les cohortes sont définies avec le produit et la sécurité. Un petit tenant critique ne disparaît pas dans la moyenne ; un filtre ne permet pas d’accéder à une donnée interdite. La vue montre volume, taux et âge afin que la priorité ne soit pas déterminée uniquement par la taille.
Les revues de capacité utilisent une fenêtre plus longue et les mêmes définitions. Elles comparent croissance du trafic, marge, coût et temps de récupération. Une extrapolation reste une hypothèse accompagnée de ses limites ; elle ne devient pas une promesse commerciale sans test représentatif.
Éviter les erreurs fréquentes de dashboard
Afficher seulement des moyennes
La moyenne masque queues et cohortes. Elle est complétée par distribution, volume et cas extrêmes. Sur faible volume, les comptes et dossiers restent visibles.
Utiliser rouge, orange et vert sans contrat
La couleur doit correspondre à une condition et une action. Une donnée absente est grise ou inconnue. Le seuil garde unités, fenêtre et propriétaire.
Ajouter un panneau après chaque incident
Sans retrait, l’écran devient illisible. L’action peut être un meilleur statut, une alerte ou un runbook. Un panneau n’est ajouté que s’il soutient une décision répétée.
Arbitrer réparation, capacité et limitation
Une saturation peut mener à optimiser la requête, augmenter une ressource, réduire la concurrence ou limiter le producteur. Le dashboard apporte pression, débit et impact ; il ne choisit pas automatiquement. L’équipe compare délai, coût et risque déplacé.
Si le pool SQL est saturé, alors multiplier les workers est refusé. Si une file non critique retarde un flux urgent, le routage ou la priorité est corrigé. Une augmentation de capacité reste réversible et surveillée ; elle n’efface pas la cause.
- D’abord, qualifier la promesse et la cohorte touchée.
- Ensuite, confirmer le goulot avec saturation et traces.
- Puis, choisir optimisation, capacité ou limitation avec un repli.
- Enfin, retirer le panneau ou le seuil qui ne conduit plus à une action.
Fermer le contrat du tableau de bord
Les entrées sont métriques versionnées, statuts métier et événements de changement. Les sorties sont vue, cohorte, seuil et lien de diagnostic. Les responsabilités couvrent définition, collecte, action et revue. La journalisation garde corrélation ; le monitoring vérifie la collecte elle-même.
Les dépendances, rétentions, cardinalité et fraîcheur sont visibles. Le rollback restaure requêtes et alertes précédentes. Le runbook associe symptômes, vérifications et repli. Aucun label ne contient d’identifiant unique ou de donnée personnelle.
La recette coupe une source, crée un dossier ancien et sature une dépendance. Le tableau doit montrer inconnu, cohorte et capacité au bon endroit. Une personne non auteure suit les liens et choisit l’action prévue.
Plan d’action sur six semaines
Semaines 1 et 2 : supprimer le bruit
L’équipe inventorie vues, décisions, owners et usage réel. Elle choisit trois parcours, définit succès, erreur, attente et résultat inconnu. Elle retire les panneaux sans lecteur et mesure coût des requêtes. Les sources et fenêtres sont documentées.
Semaines 3 et 4 : construire les vues de décision
Chaque parcours reçoit résultat, trafic, erreur, saturation, âge et cohorte. Déploiements et flags sont annotés. La collecte expose sa fraîcheur. Des seuils locaux sont reliés aux runbooks, puis testés sur historique et scénarios synthétiques.
Semaines 5 et 6 : exercer et réviser
Le pilote injecte message ancien, collecte coupée, pool saturé et partenaire lent. Support, produit et exploitation utilisent leurs vues sans auteur. Ils mesurent temps jusqu’à la décision, fausses alertes et recherches manuelles, puis corrigent définition ou lien.
La revue finale compare valeur et coût. Elle conserve les panneaux utilisés, automatise les annotations et attribue les séries orphelines. Une nouvelle équipe n’est ajoutée que si elle sait expliquer le vert, l’inconnu et le repli.
Clore le pilote par une décision collective
La quatrième semaine documente aussi conventions de nommage, unités et changements de définition. Un contrôle vérifie qu’un nouveau label ne porte pas une cardinalité non bornée. Les requêtes sont évaluées sur la fenêtre maximale réellement utilisée afin de prévenir un tableau qui ralentit précisément pendant l’incident.
À la sixième semaine, astreinte, support et produit prennent chacun une décision à partir de leur vue. Ils expliquent ce qui manque et ce que le signal ne prouve pas. Le pilote est étendu seulement si ces limites restent comprises sans intervention de l’auteur.
Le budget couvre collecte, stockage, requêtes et maintenance. Un panneau coûteux peut rester pertinent pour un flux critique ; une courbe décorative est retirée même si son coût unitaire paraît faible. L’arbitrage conserve la valeur de décision plutôt qu’un quota uniforme.
Le compte rendu liste enfin les définitions modifiées et leurs ruptures de comparabilité. Il précise quelles séries anciennes restent consultables, quels seuils ont été recalibrés et pourquoi. Cette histoire permet de relire un incident passé sans appliquer silencieusement la formule d’aujourd’hui à la population d’hier.
Relier dashboard, workflow et support
Les statuts viennent de l’observabilité des workflows métier, tandis que les tests de workflows à exceptions fournissent les scénarios qui vérifient le tableau.
Le guide performance et monitoring aide à qualifier saturation et latence. Les migrations suivent un run Symfony compatible pour garder les séries comparables.
- Afficher résultat, population, fraîcheur et capacité.
- Relier chaque seuil à un owner et une action testée.
- Réviser les panneaux selon décisions réelles et coût.
Conclusion : rendre le vert réfutable
Un tableau utile ne cherche pas à résumer tout le système. Il montre si une promesse tient, quelle population dérive et quelle ressource ou dépendance mérite une enquête.
Moyennes, couleurs et profondeur de file sont insuffisantes sans distribution, âge, fraîcheur et définition. Le vert doit pouvoir être contesté par un dossier ancien ou une collecte arrêtée.
La qualité se mesure au temps jusqu’à une décision sûre et à la suppression des recherches manuelles, pas au nombre de panneaux. Chaque vue garde une responsabilité et une date de revue.
Dawap peut construire ces vues et éprouver leurs seuils dans une mission de développement web et d’exploitation, avec un accompagnement expert jusqu’au run réel.
