Tu n'as probablement pas besoin de D3.js — voici les 20 % de cas où il est irremplaçable

Les données brutes sont muettes

Un tableau de chiffres ne raconte jamais une histoire tout seul. Les données brutes sont objectives et muettes ; c'est la visualisation qui leur donne une voix, qui révèle les tendances cachées, les anomalies et les corrélations inattendues. Après des années à transformer des jeux de données complexes en récits visuels, j'ai une conviction qui va à contre-courant du réflexe de beaucoup de développeurs : la plupart du temps, quand quelqu'un ouvre D3.js, il se trompe d'outil. Pas parce que D3 est mauvais — c'est l'inverse, c'est l'outil le plus puissant du domaine — mais parce que sa puissance se paie en complexité, et que dans huit cas sur dix une bibliothèque plus simple aurait livré le même résultat en un quart du temps.

La vraie compétence en datavisualisation n'est pas de connaître l'API de D3 par cœur. C'est de savoir quelle question poser aux données, et quel outil convoquer pour y répondre. Alors commençons par là.

La question n'est pas « comment D3 » mais « ai-je besoin de D3 »

D3.js, en version 7.9, reste la référence pour les visualisations sur mesure. Entièrement restructurée en modules ES, la bibliothèque est tree-shakeable : on n'importe que les sous-modules utiles parmi la trentaine disponibles — d3-scale, d3-shape, d3-selection, d3-transition, d3-geo, d3-hierarchy, d3-force, d3-zoom. Mais cette puissance vient avec une courbe d'apprentissage réelle, et la produire pour un simple graphique en barres est du gaspillage.

Pour la majorité des besoins, l'écosystème offre mieux adapté. Voici comment je tranche.

Observable Plot mérite une mention spéciale : développée par l'équipe derrière D3, son API basée sur des marks (Plot.barY, Plot.line, Plot.dot) gère automatiquement les échelles, les axes et les légendes. C'est devenu mon outil de prototypage par défaut — je dégrossis dans Plot, et je ne bascule en D3 pur que si le résultat final l'exige. Aucune de ces bibliothèques ne remplace D3 pour le sur-mesure, mais ensemble elles couvrent environ 80 % des cas d'usage courants.

Quand D3 reste irremplaçable — sans coder du spaghetti

Les 20 % qui restent justifient pleinement D3 : une visualisation dont la forme n'existe dans aucune bibliothèque, une interaction inédite, un layout de force ou une projection géographique particulière. Le piège, à ce niveau, c'est le code spaghetti — D3 étant bas niveau, il est facile de tout mélanger. La règle qui m'a sauvé : en contexte React, D3 ne touche jamais le DOM. Il fait les mathématiques — échelles, layouts, générateurs de formes — et React fait le rendu en JSX. Cette séparation est devenue la bonne pratique consensuelle.

import { scaleLinear } from "d3-scale";
import { line } from "d3-shape";

function useLinePath(data, width, height) {
  const x = scaleLinear().domain([0, data.length - 1]).range([0, width]);
  const y = scaleLinear().domain([0, Math.max(...data)]).range([height, 0]);
  const path = line()((d, i) => [x(i), y(d)]);
  return path(data);
}

// Le composant ne fait que rendre — D3 a fait le calcul
function Sparkline({ data, width = 240, height = 60 }) {
  const d = useLinePath(data, width, height);
  return (
    <svg width={width} height={height} role="img" aria-label="Tendance">
      <path d={d} fill="none" stroke="currentColor" strokeWidth={2} />
    </svg>
  );
}

J'encapsule les échelles et les layouts dans des hooks dédiés (useScale, useLayout), et le composant reste déclaratif. On garde la réactivité de React et la puissance mathématique de D3, sans sacrifier la lisibilité.

SVG, Canvas, WebGPU : le bon moteur selon l'échelle

Le choix du moteur de rendu n'est pas un détail, et c'est ici que 2026 a vraiment changé la donne. En dessous d'environ 1000 éléments, le SVG est idéal : interactivité native, accessibilité, débogage facile. Entre 1000 et environ 100 000, le Canvas devient nécessaire pour garder un rendu fluide — au-delà, Canvas 2D commence à caler. Et c'est là qu'arrive la nouveauté : WebGPU est passé Baseline en janvier 2026, supporté par tous les navigateurs majeurs, avec une couverture d'environ 87 % sur desktop et 71 % sur mobile. Concrètement, WebGPU rend des nuages de plus de 10 millions de points de façon interactive, là où Canvas 2D s'étouffe au-delà de 100 000 ; des démos comme ChartGPU affichent un million de points à 60 images par seconde.

Ce que ça change pour moi : je ne traite plus le rendu de gros volumes comme un problème exotique réservé à WebGL bricolé. Pour un dataset massif — capteurs, logs, géospatial dense — WebGPU est désormais une option de production, pas un pari. Le seuil de bascule reste le même principe qu'avant, mais le plafond a explosé.

L'animation comme outil narratif

L'animation n'est pas un embellissement, c'est un outil de narration. Une transition animée entre deux états d'un graphique permet au cerveau de suivre la transformation des données, au lieu de comparer mentalement deux images figées. D3 offre un système de transitions solide via d3-transition, avec interpolation automatique des valeurs, des couleurs et des chemins SVG. Pour des séquences plus complexes, GSAP reste la référence en contrôle et en performance ; en React, Framer Motion gère nativement le SVG avec son composant motion.path.

Le scrollytelling est la technique narrative la plus efficace pour une infographie longue. Je structure ces visualisations comme un article : une accroche qui pose le contexte, des sections qui révèlent les couches de données une à une, une conclusion qui synthétise l'insight. Chaque palier de scroll déclenche une transition qui recontextualise le graphique. Et comme pour toute animation, je respecte prefers-reduced-motion : un mouvement qui aide la lecture pour la plupart peut être un obstacle pour d'autres.

L'accessibilité n'est pas optionnelle

C'est l'angle mort le plus fréquent de la datavisualisation. Un graphique SVG doit porter un role="img" et un aria-label qui synthétise l'information clé. Pour les visualisations interactives, j'ajoute des régions aria-live qui annoncent les changements de données aux lecteurs d'écran, et je fournis systématiquement un tableau de données structuré en fallback — masqué visuellement mais accessible — pour ceux qui ne peuvent pas interpréter le graphique. Le choix des couleurs compte autant : je m'appuie sur des palettes au contraste suffisant et distinguables en cas de daltonisme, et je ne fais jamais reposer une information sur la seule couleur — toujours couleur plus forme, ou couleur plus label direct.

Au fond, la datavisualisation est un point de rencontre entre design, développement et journalisme. Maîtriser D3.js n'est que la dimension technique, et souvent la moins importante. Savoir quand ne pas l'utiliser, choisir le bon moteur de rendu, et communiquer une vérité de manière claire, honnête et accessible : voilà le vrai métier.