Chroma
Un outil interne de système de couleurs qui a réduit un flux de travail éclaté sur 5–6 outils à une seule interface — et fait passer le travail couleur de 3,1 à 1,0 heure par projet (−68 %), aujourd’hui utilisé sur 100 % des projets SVP
- Problème — Chez SVP, mon travail couleur était éparpillé sur 5–6 outils déconnectés et coûtait 3,1 heures par projet
- Insight — Le point de friction ne venait pas d’un manque d’outils, mais des coutures entre eux — une interface unique et assumée, calée sur ma façon de travailler réelle
- Solution — J’ai construit Chroma seule de A à Z (recherche, design, frontend React/TS, backend FastAPI, DevOps) : extraction depuis image & site live, matrice WCAG, gammes OKLCh, 8 formats d’export, 25 jours
- Résultat — Travail couleur ramené à 1,0 h/projet (−68 %), 6 outils → 1, utilisé sur 100 % des projets, €0 d’hébergement — petit échantillon n=3 ; revue complète à 3 mois
Une seule interface pour toute la chaîne couleur
Les décisions de couleur ouvrent presque tous les projets SVP — présentations clients, audits de marque, UI de produits IA internes, marketing. Le travail correspondant vivait dans 5–6 onglets de navigateur : une pipette, un extracteur d’image, un vérificateur de contraste, un exportateur qui ne sortait jamais le format dont mes collègues avaient besoin. Chroma rassemble tout cela dans une seule interface.
chroma.ontwrpn.com — après une révision complète du design visuel, UX/UI, mise en page responsive, WCAG 2.2 AA et sécurité
Les coutures entre les outils
Une mission type : rassembler des références, extraire des palettes, tester le contraste WCAG, construire des gammes tonales de 50 à 950, livrer dans le format que le destinataire utilise vraiment. Chaque étape vivait dans un outil différent — Coolors, Adobe Color, vérificateurs de contraste, plugins Figma — et les sorties ne s’alignaient jamais. L’accessibilité n’était vérifiée qu’en toute fin de parcours. Point de départ : 3,1 heures de travail couleur par projet, mesuré sur 12 projets livrés.
Le point de friction ne vient pas de l’absence d’outils — il vient des coutures entre eux
Valider d’abord, construire ensuite en 25 jours
La découverte avant le code : un auto-audit de 12 projets livrés (moyenne 3,1 h), des entretiens de 20 minutes avec le CEO, l’ingénieur IA et le junior, et des walkthroughs structurés de 8 outils concurrents. Un coût caché a émergé — mes collègues re-dérivaient mes palettes parce que le format de livraison ne collait pas à leurs outils. J’ai ensuite construit en solo par phases fermées — alpha interne → bêta interne → production — pour que le lancement soit déjà éprouvé sur des projets réels.
Résultats : palette par proportion de pixels réels, donut, harmonie, teintes tonales et export de tokens
Extraire → équilibrer → vérifier → exporter
Un outil web qui couvre tout le cycle de vie couleur : extraction depuis image et site live (proportions de pixels réels, pas d’échantillons générés), une matrice WCAG en direct avec simulation de daltonisme, des gammes tonales OKLCh et huit formats d’export, dont les design tokens W3C. Construit avec Vite + React + TypeScript + Tailwind par-dessus FastAPI / Python.
Live — collez une image ou une URL de site et essayez
Desktop
Mobile
Livré, adopté, mesuré
Deux premières semaines (petit échantillon précoce, n = 3, comparé à une base de 12 projets) : temps de travail couleur 3,1 h → 1,0 h (−68 %), outils par mission 6 → 1, utilisé sur 100 % des projets, €0 d’hébergement. Le premier deck client après le lancement a été bouclé sans une seule révision de couleur ; les tokens W3C se sont glissés directement dans la config Tailwind du développeur. Lecture honnête — un petit échantillon précoce ; la revue d’impact complète aura lieu à trois mois. Le seul point de friction : l’extraction de site web (vs. l’import d’image) prend 10–12 s sans indicateur de progression visible — un état de chargement est dans le backlog.
