Design System Bricks¶
Définition¶
Bibliothèque de composants UI réutilisables et tokens design qui alimente les surfaces produit Bricks (app investisseur, PDP, back-office, EF, outil d'analyse). Source de vérité visuelle et d'interaction au-dessus de laquelle se construisent les écrans.
Page concept stub à enrichir. Sans Product Designer en interne, l'état du DS est partiellement documenté. À reprendre avec le PD à son arrivée — V2 attendue à ce moment.
Pourquoi ce concept existe¶
Mentionné dans :
- areas/design/index.md § Design system — placeholders
- resources/career-path-product-designer.md § Conception UI & Design System — attendus par niveau PD1 → PD5
- concepts/product-design-bricks.md § Principe 11 — DS d'abord, one-off en dernier
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 :
- 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.
- Maquette = spec — un composant utilisé en high-fi doit être documenté dans le DS avec ses états et variants.
- 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-05-29
- V1 stub créée le 2026-05-29 dans le cadre de l'embarquement composante Design Phase 1.
- URL Figma DS :
[à renseigner Romain] - Conventions composants (naming, variants, tokens) :
[à documenter] - Composants critiques (ré-utilisés sur ≥ 3 surfaces) :
[à lister] - Fragmentation observée (one-off historiques, dette) :
[à documenter] - Gouvernance (qui peut ajouter / modifier un composant, cadence de review DS) :
[à définir avec PD] - Statut : page concept stub, à enrichir au fil des observations et de l'arrivée du PD.
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¶
- concepts/product-design-bricks.md — canon (principes 6, 7, 11)
- resources/career-path-product-designer.md — attendus DS par niveau
- concepts/handoff-design-dev.md — utilisation du DS au handoff
- concepts/qa-design.md — vérification utilisation DS en QA
- areas/design
- areas/tech
Sources¶
- log 2026-05-29 embarquement design Phase 1 — création stub