Contour Dashboard — Sam Studio

Contour est un tableau de bord analytique complet — le genre d’outil qu’un produit SaaS construirait pour ses propres clients. Vue d’ensemble, analytique, clients, transactions, rapports, paramètres : six vraies vues, construites de zéro, avec rien d’autre que la plateforme du navigateur. Le brief était de prouver que je peux construire une application, pas seulement une page.

Ce qui fonctionne bien

Le graphique n’est jamais la seule façon de lire les données. Chaque graphique est accompagné d’un vrai tableau de données toujours présent à côté, et d’infobulles utilisables au clavier sur le graphique lui-même — personne qui ne peut pas lire facilement une courbe n’est privé des chiffres.
Ce que vous exportez est exactement ce que vous regardiez. Les rapports réutilisent la métrique, la période et les filtres déjà sélectionnés ailleurs dans l’application, au lieu de puiser dans un jeu de données séparé — l’export CSV ne peut jamais silencieusement contredire l’écran.
Un vrai thème à trois modes, pas un basculement rajouté. Clair, sombre et système — avec mise à jour en direct quand le thème de l’OS change — construit sur un seul système de tokens dès le départ, pas une seconde feuille de style rajoutée après coup.

Le design en un coup d’œil

fond · #f5f6f4
accent · #8a4a2b
encre · #1b211c
bordure · #e1e4df
fond sombre · #14181f
accent sombre · #c97a4a

Deux jeux de tokens complets, pas un filtre inversé — le mode sombre ci-dessus est une vraie couleur ajustée, tout comme le mode clair.

Tiroir client — capture en attente

Conçu pour durer

Entièrement responsive, testé de 320px à 1440px et plus
Zéro dépendance à mettre à jour ou à casser — aucun framework, aucun outillage de build
Chaque statut et tendance se lit clairement sans jamais reposer sur la couleur seule
Un vrai piège de focus clavier dans le tiroir de détail client

Vous voulez un outil aussi soigné construit pour vos propres données ?

Voir en ligne Démarrer un projet

Pour les développeurs — le détail technique complet

01. Un tableau accessible à côté de chaque graphique

Problème: Un graphique seul exclut quiconque ne peut pas lire facilement une courbe — basse vision, daltonisme, ou simplement quelqu’un qui veut le chiffre exact.
Choix: Chaque graphique est accompagné d’un vrai tableau de données toujours présent à côté, plus des infobulles utilisables au clavier sur le graphique lui-même.
Résultat: La même information est disponible de deux façons, aucune n’étant secondaire.

02. Les rapports lisent l’état vivant de l’application, pas un jeu de données séparé

Problème: Les tableaux de bord laissent souvent un rapport exporté contredire silencieusement ce qui est à l’écran.
Choix: Les rapports réutilisent la métrique, la période et les filtres déjà sélectionnés ailleurs dans l’application.
Résultat: Un export CSV correspond toujours exactement à ce qui était à l’écran au moment de l’export.

03. Un store centralisé plutôt qu’un framework

Problème: KPI, graphique, tableaux, tiroir et paramètres avaient tous besoin d’un état prévisible et synchronisé sans faire appel à un framework.
Choix: Un petit store centralisé avec un modèle subscribe/notify — pas de DOM virtuel.
Résultat: Un flux de données à sens unique et zéro dépendance à un framework, pour environ le code que le boilerplate d’un framework aurait coûté de toute façon.

Accessibilité et performance

Ce que je ferais différemment

Pas de suite de tests automatisés — la qualité a été vérifiée via un audit manuel structuré avant chaque livraison plutôt que des tests unitaires ou d’intégration. Pour une application aussi chargée en données et en interactions (tableaux triables, filtres, tiroir avec piège de focus, graphique en direct), encoder une partie de cet audit en tests automatisés permettrait de détecter les régressions plus vite la prochaine fois.

Stack

JavaScript vanilla (modules ES)
Graphiques SVG faits main
Store d’état centralisé
JSON statique via fetch()