Forme DS

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

SurfaceRôleComposantsTokens
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 SideNavItem a 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.

  1. Repérer le composant maison (un <button className="…">, un menu popover fait main).
  2. Identifier la primitive DS qui porte l'intention (Button, DropdownMenu, IconButton…).
  3. Remplacer le balisage par le composant DS, en passant les props (dont label).
  4. Supprimer le CSS maison devenu mort — il ne doit plus rester de style de composant dans l'app.
  5. Si le DS a une lacune, on n'ajoute pas de CSS d'app : on enrichit le paquet, puis on consomme.
// Avant — composant maison, CSS d'app, diverge des autres surfaces.
<button className="fiche-menu__btn" onClick={openMenu}>⋮</button>

// Après — primitive partagée, a11y native, identique partout.
import { IconButton } from "@forme-ch/ui/controls";
<IconButton label="Actions" icon={<DotsThreeIcon />} variant="ghost" />
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.