Aller au contenu

Design System Uimmo

Définition

Bibliothèque de composants UI réutilisables et tokens design qui alimente les surfaces produit Bricks. Uimmo est le Design System canonique. Les bibliothèques propres à un produit ne deviennent pas une seconde source de vérité.

La cartographie technique et les identifiants Figma vivent dans le mapping Figma.

Pourquoi ce concept existe

Mentionné dans :

Sans page dédiée, impossible d'extraire les conventions tacites (naming, variants, fragmentation observée) ni de tracer les évolutions au fil des ingests.

Principes opérationnels (V1, extraits canon)

Extraits du canon design :

  1. DS d'abord, one-off en dernier — si un besoin n'est pas couvert, faire évoluer le DS plutôt que créer une variante locale.
  2. Maquette = spec — un composant utilisé en high-fi doit être documenté dans le DS avec ses états et variants.
  3. Couverture des états — tout composant DS doit décliner ses états (vide, chargement, erreur, désactivé, hover, focus).

État actuel

Dernière mise à jour : 2026-10-26

  • Journal des modifications d'Uimmo (2026-10-22) : page Changelog dans Storybook (section Uimmo) ; chaque évolution d'Uimmo (token, composant, règle d'usage) laisse trois traces qui se citent : ticket Linear, PR et ligne du journal ajoutée dans la même PR ; la CI vérifie la présence de la ligne — #tech-front 2026-10-22 · BRI-2537.
  • Règle « Essayer ou livrer » (2026-10-22) : encadré en tête du Changelog ; essayer (proto IA, maquette, branche de test) n'engage rien ; seul ce qui est mergé dans Uimmo via une PR relue par le Front fait foi ; PR en draft = le design itère, PR ouverte = un dev reprend la main ; formulation jugée peu claire par Hugo dans le fil [à vérifier] — #tech-front 2026-10-23 · BRI-2569.
  • Source de vérité et accès des agents (2026-10-22) : convergence vers Storybook comme source de vérité du DS, documentation Markdown (usages, règles, anti-patterns) de préférence dans le monorepo près du code, MCP Storybook évoqué pour exposer composants, props, tokens et doc aux agents ; emplacement exact non tranché [outcome non formulé] — présentation découpage Uimmo 2026-10-22.
  • Pilote Uimmo (2026-10-22) : périmètre d'environ cinq écrans à choisir pendant le cadrage, piste d'un flow roadmap avec webviews (carte cadeau) ; constat partagé : l'agent réussit mieux en adaptant un écran existant qu'en partant de zéro — présentation découpage Uimmo 2026-10-22.
  • Inventaire DS 2.0 (2026-10-20) : état des lieux des composants par produit, doublons et éléments non mutualisables, puis tri (garder, fusionner, écarter) ; Romain recommande de tester tôt l'approche sur un projet plutôt que d'attendre un système complet — synchro hebdo Product 2026-10-20. Analyse des composants Uimmo (BRI-2565) faite par Pierre et relue par Rémy le 2026-10-23 (désaccords ponctuels, par ex. NumberStepper et NumberInputWithControllers à garder séparés) [non sourcé : DM Slack, lien non relevé].

  • DS comme produit (2026-10-23) : recentrage du DS au service des autres produits ; Pierre ajoute que le DS inclura des skills et des MCP (wording, tone of voice) pour nourrir l'IA, son nettoyage étant un prérequis — Leexi Point d'étape Build IA 2026-10-23 · Leexi NEW Standup 2026-10-23.

  • Surfaces hors DS assumées (2026-10-16) : la page « Notre histoire » (actionnariat) sort avec un style spécifique (sombre) non intégré au DS ; rétro-ingénierie vers le DS seulement si la direction est réutilisée ailleurs — [source locale non partagée].

  • Build en code repositionné (2026-10-16) : passage à l'échelle après le go du pilote ; les PM buildent en code de vrais flows de la roadmap, binôme PM + Front, PD en QA design, Hugo garde la mise en prod — P-BRI-519 · ADR proposed.

  • Gouvernance des évolutions du DS (2026-10-16) : un PM ne crée pas de composant dans l'écran ; il le demande (PR, piste Figma ou message), le designer valide, puis le Front — P-BRI-519 § Garde-fous · BRI-2544.
  • Pas d'outil maison de gestion du DS pour l'instant : à réévaluer une fois le DS en code installé [source locale non partagée].
  • Structure d'Uimmo par usage (2026-10-15) : tokens (nommés par rôle), composants, patterns (= organismes), templates ; pas d'atomic design strict ; doc d'usage sur chaque élément ; ordre du plus petit au plus gros ; designers = PR, Front = merge — P-BRI-518 · ADR proposed.

  • Découpage en 3 milestones Cadrer / Pilote sur un parcours / Généraliser ; Figma hors pilote ; mapping des tokens dans BRI-2559 ; « notre goût » = BRI-2567 en Pilote (Linear au 2026-10-19) ; aucune date — P-BRI-518.

  • Revoir le DS = premier volet, quel que soit le modèle d'organisation design retenu [source locale non partagée].

  • Chantier à rendre visible dans Linear : issue générale puis actions de base (réorganisation du Storybook, renommage des tokens sémantiques), affinées ensuite [source locale non partagée].
  • Fait le 2026-10-15 : projets Uimmo AI+Human Ready et Build en code avec Uimmo (Backlog), 1re issue BRI-2556 Rendre Storybook lisible — DM groupe 2026-10-15. Détail : note Storybook / uimmo.
  • Constat IA : génération from scratch (Figma, dev) peu concluante ; meilleurs résultats à partir de l'existant [source locale non partagée].

  • DS comme plateforme à maintenir : composer avec des blocs sans casser le système ; évolutions via requêtes au système ; maintenance continue à ne pas sous-estimer [source locale non partagée].

  • Fichier canonique : 🎨 Uimmo — clé Figma yEPrXyd3donmRXv4K7kHtN.

  • Périmètre : composants et tokens communs. Les composants propres à une surface restent locaux jusqu'à ce qu'un second usage justifie leur promotion.
  • Gouvernance : Rémy et Pierre sont co-owners. Les deux peuvent proposer et modifier le DS. En cas de désaccord non résolu, Rémy tranche.
  • Implémentation : Hugo est consulté sur les contraintes techniques et review le code.
  • État détaillé : conventions, composants critiques et dette sont suivis dans le mapping versionné, pour éviter une seconde liste qui dérive.

Anti-patterns observés (V1)

Anti-pattern Signal Correction
One-off à côté du DS Variante créée localement par feature Faire évoluer le DS, signaler la fragmentation
Composant DS sans états Card / Button / Input qui n'a que l'état "normal" Décliner vide / chargement / erreur / désactivé avant de marquer "done"
Fork silencieux Dev qui réimplémente un composant DS au lieu de le réutiliser Cadrer en handoff, ping dev en amont
DS comme styleguide passif Figma jamais mis à jour Imposer la mise à jour du DS dans le workflow de toute feature qui touche un composant

Pages liées

Sources