Trois semaines à monter le design system d'Alivia from scratch. Toujours les mêmes étapes, toujours les mêmes décisions refaites à zéro. J'ai codé l'outil que j'aurais voulu avoir.
Beaucoup d'équipes se lancent avec un design.md : quelques couleurs, une typo, un border-radius. Ce n'est pas un design system, c'est une liste d'intentions sans structure. Résultat : une interface à cohérence aléatoire dès le troisième sprint.
Défi : Comment permettre à n'importe quelle équipe de partir d'un design system structuré, accessible et adapté à sa stack, sans 3 jours de setup ni expertise tokens ?
Chez Polycea, la question revenait à chaque projet. On reconduisait le même template parce que le dev le connaissait, pas parce qu'il était bon. Pas de tokens, pas de pipeline, pas d'accessibilité vérifiée. Des habitudes reconduites par défaut.
Objectif : Passer d'une couleur hex à un design system complet, accessible et adapté à la stack exacte du projet.
DS Factory est construit avec son propre design system. Il mange sa propre cuisine : chaque mauvaise décision d'architecture, je la voyais immédiatement dans mon propre outil.
Utilisateurs cibles : Designers, développeurs front-end et builders solo qui démarrent un produit
Pas "créer un design system prend du temps". Tout le monde le sait. Le vrai problème : chaque équipe refait les mêmes arbitrages, avec les mêmes erreurs.
Ce n'est pas un problème de temps. C'est un problème de décision. Un configurateur peut prendre ces décisions une fois, correctement, pour tout le monde.
L'utilisateur entre un hex. DS Factory génère une palette 10 tons calibrée en HSL (50 à 900), suggère une couleur accent par théorie des complémentaires, et calcule le ratio de contraste en direct. Si ça ne passe pas WCAG AA (4.5:1), l'alerte s'affiche avant l'export.
Six frameworks, douze librairies de composants, cinq sets d'icônes. Une matrice de compatibilité bloque les combinaisons impossibles : shadcn/ui sans Tailwind est grisé, avec une explication. Les options invalides ne peuvent pas être sélectionnées.
Un bouton. Un .zip. Dedans : tokens au format choisi (W3C DTCG, Style Dictionary, Figma Variables, CSS custom properties), config Tailwind générée depuis les tokens, globals.css avec dark mode, et 50+ composants adaptés à la stack exacte.
Méthodes : Design Tokens, Théorie des couleurs, Accessibilité by design, Dogfooding, Vibecoding (AI-assisted dev)
Quatre choix structurants font l'outil.
Exemple : hex → generateScale() → CSS custom properties sur :root → Tailwind lit à runtime
Impact : Modifier une couleur dans le store met à jour tout le preview instantanément, sans rechargement
Exemple : COMP_COMPAT et CSS_COMPAT dans le store Zustand : setFw() désélectionne les libs bloquées
Impact : Impossible de créer une combinaison invalide, même sans connaître les contraintes d'interopérabilité
Exemple : Focus ring WCAG 2.2 AA, aria-invalid et aria-describedby sur les champs, aria-busy sur les boutons en loading
Impact : Écrites une fois, appliquées à chaque composant généré. L'équipe n'a pas à les retravailler
Exemple : Chaque variante est du React réel, pas un screenshot : palette, radius et typo réels
Impact : Changer la couleur brand montre immédiatement comment Button et Table réagissent
Une v1 en 3 semaines, en beta privée limitée à 100 places.
Ce projet dit moins "je sais coder" que "je pense en systèmes".
Rôle : Founding Designer + dev solo, 3 semaines (v1)
Outils : React 18, Vite, TypeScript, Tailwind CSS, Zustand, Radix UI
Thématiques : Design System, Tooling, Side Project, Tokens, Accessibilité
Je simplifie l'IA et la tech pour en faire des outils que leurs utilisateurs adoptent vraiment. Designer de métier. Builder par conviction.