Idée principale
La chaîne habituelle de conception d'interface va dans un sens : on dessine un écran dans Figma, puis un développeur front-end le réimplémente. La maquette est une représentation — elle montre ce qu'on veut obtenir, et rien de ce qu'elle contient n'est directement réutilisable.
Le statut change quand le design system est reconstruit depuis le dépôt plutôt que maintenu à côté : composants réellement existants, états réellement gérés, conventions de développement de l'équipe, mises à jour à mesure que le dépôt évolue. La maquette n'exprime plus une intention dans un vocabulaire étranger au code, elle compose des éléments qui existent. Ce qu'elle produit devient une première base que le développement peut reprendre.
Le déplacement porte sur la position dans la chaîne, pas sur l'outil. Figma reste excellent pour concevoir des écrans ; ce qui bouge, c'est ce que sa sortie vaut en aval.
Pourquoi c'est important
C'est le cas le plus démonstratif du renversement : la conception est l'étape qu'on croit le plus éloignée du code, puisqu'elle le précède. Montrer qu'elle aussi peut se nourrir du dépôt indique que la frontière entre conception, implémentation et documentation se réduit par les deux bouts.
Cela déplace aussi le point d'attention d'une équipe design : maintenir la correspondance entre le design system et le code devient plus décisif que la qualité du dessin lui-même.
Nuances et limites
Un design system dérivé du code enferme la conception dans l'existant. Il rend fluide la composition d'écrans à partir de ce qui est déjà implémenté et hostile à ce qui n'existe pas encore — exactement là où la conception a le plus de valeur.
Et la reconstruction n'est utile que si elle est tenue : un design system dérivé une fois puis laissé en place redevient une représentation, avec un retard supplémentaire par rapport à une maquette assumée comme telle.
Questions ouvertes
- Comment une conception qui part de l'existant garde-t-elle la capacité de proposer ce que le produit ne sait pas encore faire ?