Un design system pour la data viz

Standardiser les couleurs, les types de graphs et les composants évite la cacophonie. On gagne en lisibilité, en vitesse de livraison et en accessibilité. Le but n’est pas de figer la création, mais d’éliminer le bruit pour laisser parler les données. Un design system léger suffit s’il est clair, testé et facile à appliquer.

prérequis

Palette accessible avec contrastes AA au minimum.
Typographies et tailles définies (titres, textes, labels).
Bibliothèque de composants réutilisables dans votre outil (Power BI, Tableau, Looker, web).
Règles d’axes, d’unités et de formats de date partagées.

aperçu rapide

Limiter les types de graphs par usage (tendance, comparaison, part).
Définir 6 à 8 composants de base et leurs variantes.
Fixer une palette et ses usages (primaire, alerte, neutre).
Règles d’axes et d’unités identiques partout.
Blocs d’annotation standards pour expliquer les ruptures.
Linting de dashboards avant publication.
Mode clair/sombre prévu dès le départ.

tutoriel pas-à-pas

étape 1: définir les composants essentiels

Liste courte, noms explicites, doc de 1 à 2 lignes par composant.

components:
- kpi-card        # un nombre, une unité, une tendance
- line-chart      # tendance avec objectif optionnel
- bar-chart       # comparaisons triées
- stacked-bar     # part sur total si lecture évidente
- table           # détails alignés, unités dans l'en-tête
- filter-chip     # filtres visibles, état actif clair
- annotation      # zone standard pour contexte et limites

étape 2: décider des graphs autorisés par usage

Réduire le choix accélère la production et clarifie la lecture.

usage -> graph
tendance -> line-chart
comparaison -> bar-chart
part -> stacked-bar
distribution -> histogramme ou percentiles

étape 3: poser palette et contrastes

Associer sémantique et couleurs, vérifier l’accessibilité.

:root {
  --primary: #1f77b4;
  --ok: #2ca02c;
  --warn: #ff7f0e;
  --danger: #d62728;
  --muted: #6b7280;
}
.kpi-card .value { color: var(--primary); }
.kpi-card.ok .value { color: var(--ok); }
.kpi-card.warn .value { color: var(--warn); }
.kpi-card.danger .value { color: var(--danger); }

étape 4: normaliser axes, unités et formats

Les mêmes règles partout: unités visibles, dates et séparateurs cohérents.

règles:
- milliers avec espace insécable, millions avec "M"
- pourcentages avec 1 décimale par défaut
- dates "YYYY-MM" pour les mois, "YYYY-MM-DD" pour les jours
- axes numériques: commencer à 0 quand pertinent; sinon indiquer la rupture

étape 5: automatiser un linting minimal

Vérifier titres, unités et annotations avant publication.

# lint_dashboard.py
required = ["title","unit","source","annotations"]
def lint(viz):
    missing = [k for k in required if not viz.get(k)]
    return {"ok": not missing, "missing": missing}
print(lint({"title":"CPA quotidien","unit":"€","source":"ads.campaigns","annotations":["objectif 45"]}))

exemples complets

cas: fiche “kpi-card” et “line-chart” prêtes à l’emploi

{
  "kpi-card": {
    "props": ["label","value","unit","delta","period"],
    "rules": [
      "label court et orienté action",
      "value formatée avec unit visible",
      "delta sur la même période que le label period"
    ]
  },
  "line-chart": {
    "props": ["series","x","y","goal","notes"],
    "rules": [
      "axe X = temps, axe Y = unité lisible",
      "goal en ligne pointillée",
      "notes: 1 à 3 annotations max"
    ]
  }
}

/* styles minimaux réutilisables */
.chart-title { font-weight: 600; margin: 8px 0; }
.x-axis .tick, .y-axis .tick { font-size: 12px; fill: #374151; }
.note { font-size: 12px; color: var(--muted); }

explications brèves: décrire props et règles évite les variations inutiles et réduit le temps de revue.

erreurs courantes et solutions

12 palettes différentes -> confusion -> une palette par défaut, exceptions documentées
axes incohérents -> erreurs -> même format pour chiffres, dates, séparateurs
annotations absentes -> malentendus -> bloc standard d’annotation sous le graph
empilement de graphes -> surcharge -> une idée par écran
charts exotiques -> lenteur et incompréhension -> limiter aux types approuvés
dark mode ajouté après coup -> contrastes ratés -> penser les deux modes dès le départ

faq

faut-il un outil spécifique pour le design system ? Non. L’important est la clarté des règles et leur application dans vos outils existants.
comment gérer les exceptions légitimes ? Une fiche “exception” courte: pourquoi, durée, date de retrait prévue.
comment faire adhérer les équipes ? Montrer avant/après, réduire le temps de revue, fournir des exemples prêts à copier.

Menu