Adoption
Parité inter-apps
Une fonctionnalité livrée dans le DS apparaît identique partout. Un bouton, un menu, une nav latérale se comportent et se ressemblent d'une app à l'autre — non par discipline, mais parce que c'est littéralement le même code. Voici ce que la parité garantit, et comment on migre une app pour l'obtenir.
Les quatre surfaces, un seul DS
| Surface | Rôle | Composants | Tokens |
|---|---|---|---|
| Admin | Back-office ERP : fiches, tables denses, formulaires. | @forme-ch/ui | @forme-ch/design-system |
| AI | Surface conversationnelle et outils assistés. | @forme-ch/ui | @forme-ch/design-system |
| Space | Espace client / projet partagé. | @forme-ch/ui | @forme-ch/design-system |
| Frame | Éditeur d'écrans et de composition. | @forme-ch/ui | @forme-ch/design-system |
Les deux dernières colonnes sont identiques ligne après ligne : c'est ça, la parité. Aucune surface ne possède sa propre version d'un composant ou d'un token.
Ce qui garantit la cohérence
- Source unique. Un composant existe une fois, dans le paquet. Une correction ou un enrichissement bénéficie aux quatre surfaces à la mise à jour — jamais une seule.
- Tokens partagés. Couleurs, typo, espacement et rayons viennent tous de
@forme-ch/design-system. La même variable rend la même valeur partout, et s'adapte au thème clair/sombre de la même manière. - Contrat d'API commun. L'API
label, les variants, les tailles sont les mêmes sur toutes les surfaces. Ce qu'on apprend sur une app se transpose à l'identique sur les autres. - Parité vérifiée. Exemple mesuré : un
SideNavItema la même hauteur, le même rayon, la même taille de police côté Admin et côté AI — parce que c'est le même composant, pas deux implémentations qu'on aurait alignées à la main.
Migrer une app vers le DS
Migrer, c'est remplacer chaque composant maison par celui du DS et supprimer le CSS qui le soutenait. La règle : ne pas migrer pour migrer — un composant de patron propre et tokenisé peut rester ; c'est le bricolage divergent qu'on retire.
- Repérer le composant maison (un
<button className="…">, un menu popover fait main). - Identifier la primitive DS qui porte l'intention (Button, DropdownMenu, IconButton…).
- Remplacer le balisage par le composant DS, en passant les props (dont
label). - Supprimer le CSS maison devenu mort — il ne doit plus rester de style de composant dans l'app.
- Si le DS a une lacune, on n'ajoute pas de CSS d'app : on enrichit le paquet, puis on consomme.
La parité est un effet, pas une corvée. Tant qu'on consomme le paquet et les
tokens sans les contourner, les quatre surfaces restent cohérentes gratuitement. On ne la
maintient pas — on évite juste de la casser.