Chroma

Les décisions de couleur ouvrent presque tous les projets de design ⁠— présentations clients, audits de marque, UI produit, 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 les développeurs avaient besoin. Chroma rassemble tout cela dans une seule interface.

chroma.ontwrpn.com en 2026 ⁠— la refonte en imprimante, au repos, prête à recevoir une photo

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

La découverte avant le code : un auto-audit de 12 projets livrés (moyenne 3,1 h), des entretiens de 20 minutes avec trois personnes qui travaillent à partir de mes palettes, et des walkthroughs structurés de 8 outils concurrents. Un coût caché a émergé ⁠— les personnes en aval 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 ⁠→ bêta ⁠→ production ⁠— pour que le lancement soit déjà éprouvé sur des projets réels.

Imprimé : le ticket s’ouvre sur le scan, puis la palette selon la part réelle de pixels

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.

▶Démo en ligne

chroma.ontwrpn.com

Ouvrir

Live ⁠— glissez une photo ou une URL de site dans l’imprimante

Chaque étape du flux couleur disposait déjà d’un outil autonome plus fort que ce que j’allais construire : Coolors pour les palettes, Adobe Color pour l’harmonie, des vérificateurs de contraste dédiés, des plugins Figma pour l’application. Assembler le meilleur de chaque était le geste évident. C’était aussi exactement ce que je remplaçais, puisque le travail vivait sur cinq ou six onglets dont les sorties ne s’alignaient jamais, avec un exporteur qui ne produisait jamais le format attendu par les développeurs.

L’arbitrage était donc explicite. Chaque fonction est individuellement plus faible que l’outil spécialisé, en échange d’une surface unique couvrant tout le cycle de vie et dont les sorties concordent entre elles. L’extraction lit les proportions réelles de pixels plutôt que des échantillons générés, pour la même raison : une palette qui trahit l’image source est plus rapide et inutile.

Le test, c’était la passation et non la liste de fonctions : les palettes devaient arriver dans les présentations et dans le code sans être recalculées, précisément les deux endroits où l’ancien flux à cinq onglets fuyait toujours.

Deux premières semaines sur mes propres projets (petit échantillon précoce, n = 3, comparé à une base de 12 projets) : temps de travail couleur 3,1 h ⁠→ 1,0 h (−68 %), €0 d’hébergement. Lecture honnête ⁠— un petit échantillon précoce, sans nouvelle mesure depuis. 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.

En octobre 2026, j’ai repensé tout le produit autour d’une seule métaphore : une imprimante et son ticket. On glisse une photo dans la fente supérieure d’une imprimante 3D claire, un laser rouge la scanne, et un long ticket thermique sort par la fente avant avec l’analyse complète ⁠— la palette selon la part réelle de pixels, un donut, l’harmonie, les teintes, la matrice de contraste WCAG, la simulation de vision des couleurs et un coupon d’export détachable. Le moteur reste le même ; c’est la sensation d’usage qui a changé.

D’abord le processus. J’ai rassemblé dans Figma des références de tickets de caisse et d’imprimantes thermiques à côté d’une capture du site en ligne, puis dessiné des wireframes en niveaux de gris sur un petit design system de wireframes dont les variables Figma font basculer chaque frame entre un mode Wireframe et un mode Hi-fi. Par-dessus, j’ai dessiné trois concepts : A « Lab » ⁠— béton chaud #CFCBC4, imprimante blanc cassé, papier #FBFAF7, encre #141414, laser de scan rouge #FF4D2E, composé en Archivo et JetBrains Mono ; B « Transmission » ; et C « Cobalt ». J’ai choisi A, le plus sobre des trois, pour que la couleur à l’écran appartienne à la photo.

Scan : la photo se tient dans la fente supérieure, le laser la parcourt pas à pas

Impression : le ticket sort par la fente avant

J’ai construit l’imprimante 3D dans Cinema 4D et je l’ai rendue avec Redshift : une coque arrondie avec un panneau découpé, des pieds et deux fentes, éclairée par une softbox principale, un fill, un rim et un dôme. La page, c’est le rendu. Les commandes DOM ⁠— source, couleurs, mode, tolérance, alpha ⁠— s’y superposent sur des points d’ancrage mesurés sur le rendu, si bien qu’elles tombent exactement sur le panneau de l’imprimante et restent du vrai HTML, accessible au clavier.

L’imprimante, construite dans Cinema 4D

…et rendue dans Redshift

Le mouvement est mécanique plutôt que décoratif : le scan avance par pas de rouleau, le papier sort ligne par ligne comme sur une imprimante thermique, la coque bourdonne pendant le travail et se pose quand elle s’arrête. Les détails sont petits et tactiles ⁠— les étapes du scan sur la LED, un brouillage HEX pendant que les valeurs arrivent, des boutons qui s’enfoncent, une fente qui s’allume au survol d’un glisser-déposer, un tampon COPIED, un coupon d’export qui se détache avec un ressort, et des tickets partageables par lien.

Mobile : le panneau se replie sur une seule ligne

Mobile : le même ticket, en pleine largeur

Même la 404 reste dans le rôle : l’imprimante signale un bourrage papier et imprime un VOID RECEIPT pour la page introuvable. Sous la métaphore, tout reste construit selon WCAG 2.2 AA, avec un plancher typographique de 14px, une CSP stricte et une imprimante dimensionnée sur le viewport pour que toute la machine tienne dans le premier écran.

404 sur desktop : un VOID RECEIPT

404 sur mobile