Mise en place d’un design system : la moitié du travail n'est pas dans Figma

Sur le papier, un design system, c'est limpide : une bibliothèque de composants, quelques tokens, un peu de doc, et des équipes qui arrêtent de redessiner le bouton « Valider » tous les mardis. C'est cette promesse qui pousse de plus en plus d'organisations à en lancer un.

Dans les faits, beaucoup de ces projets s'essoufflent au bout de quelques mois. Presque jamais parce que le Figma était raté. Presque toujours parce qu'on a traité le design system comme un livrable technique, alors que c'est d'abord un sujet d'organisation.

La partie qu'on ouvre dans Figma pèse au mieux la moitié du projet. L'autre moitié ne rentre dans aucun écran : qui décide, qui contribue, comment on publie une évolution, comment on la fait adopter. C'est cette moitié-là qui décide si le système vit ou meurt, et c'est celle qu'on regarde en premier chez Jujotte.

Designer, développeur, PM ou porteur du projet : peu importe la casquette, l'objectif est le même. Sortir un système que les équipes utilisent vraiment, pas un bel objet que personne n'ouvre.

À retenir

• Un design system, ce n'est pas un UI kit. C'est un UI kit plus une gouvernance qui le fait vivre.
• Environ la moitié du travail est invisible : décisions, contribution, adoption. C'est là que ça casse.
• Tout le monde n'en a pas besoin. Sous un certain seuil, un bon UI kit suffit.
• Un lancement réussi ne prouve rien. Le seul indicateur qui compte, c'est le taux d'adoption.

Design system, UI kit, librairie : de quoi parle-t-on ?

Un malentendu revient sans cesse, et c'est lui qui fait sous-dimensionner les projets.

Un design system repose sur trois briques visibles :

• L'UI kit : les composants, les styles (couleurs, typographies) et les tokens (espacements, radius, couleurs sémantiques). Il vit dans un fichier de design (Figma, Penpot, Sketch) et se consomme sous forme de librairies.
• La documentation : l'usage précis de chaque élément. Présentation de la marque, prise en main, fondations, description des composants, ressources pour aller plus loin.
• Les composants développés : les mêmes composants et tokens, disponibles dans l'environnement de dev selon la stack utilisée.

Voilà pour ce qu'on montre en réunion. Sauf que ces trois briques ne sont que des artefacts.

Ce qui fait tenir un design system dans la durée, aucun fichier ne le contient : des règles (qui tranche, qui contribue, comment on publie) et des gens (une équipe responsable, une communauté qui s'en sert).

C'est d’ailleurs, et vous l’avez compris, la différence majeure avec un simple UI kit.
Un UI kit est une bibliothèque de composants réutilisables : précieuse, mais figée, sans mécanique de décision ni de mise à jour.
Un design system, c'est ce même UI kit doublé d'une gouvernance qui le fait évoluer. La différence ne tient pas au nombre de composants.

Elle tient à une seule question : y a-t-il quelqu'un pour trancher ?

L'audit : regarder d'où l'on part

Avant de savoir où l'on va, on regarde d'où l'on part. Et ça pique souvent un peu.

Auditer son écosystème, ce n'est pas inventorier ses composants. C'est enquêter sur trois fronts.

La santé des fichiers. Un fichier est-il identifiable en trois secondes ? Les librairies sont-elles partagées, ou chacun bricole dans son coin ?

La cohérence UX/UI. Combien de nuances de bleu cohabitent sur vos produits ? Pourquoi une modale ne réagit-elle pas pareil entre l'app web et l'espace client ? Trouve-t-on des mises en page différentes pour le même usage ?

L'état réel des composants. Y en a-t-il assez, sont-ils pertinents, combien de doublons d'un produit à l'autre ? Et surtout : à quelle fréquence les designers détachent-ils un composant pour gérer un cas particulier ? C'est le meilleur indicateur de santé qui soit. Un composant qu'on détache souvent est un composant qui ne fait pas son travail.

Mais l'audit le plus utile déborde des écrans. Le point vraiment révélateur, c'est l'acculturation des équipes : leur rapport au design, leur façon de collaborer, ce qu'elles attendent, ou redoutent, d'un système commun. C'est ça qui dira si le projet sera adopté ou boudé.

🐙 Chez Jujotte.
On nous a récemment demandé un accompagnement sur la mise en place d’un design system dans une structure interne. Notre première étape a donc été d’effectuer un audit pour comprendre la philosophie, l’organisation et l’acculturation design présente dans l’entreprise.

Spoiler : la partie “synthèse des observations” comprenait essentiellement des constats organisationnels.

La vraie question : en avez-vous besoin ?

À la sortie de l'audit, une question mérite d'être posée franchement : le design system est-il la bonne réponse ? Parce qu'il n'est ni obligatoire, ni gratuit à entretenir.

Un produit unique, deux designers, trois devs ? Un UI kit propre et bien documenté suffit largement. Le design system ne devient rentable qu'au moment où le coût de coordination (allers-retours, doublons de code, incohérences à rattraper) dépasse le coût de maintenance du système lui-même. Avant ce point de bascule, on ajoute de la lourdeur sans gagner en vitesse.

Rien n'impose non plus de modèle type. Un design system commence petit, se nourrit du terrain et grandit avec vos ambitions. Vouloir viser large dès le premier jour, c'est le meilleur moyen de ne jamais sortir.

💡 À garder en tête. Un design system est un organisme vivant. Il est souvent plus malin d'en maintenir plusieurs déclinaisons selon les besoins métiers que d'imposer un système unique qui contente tout le monde à moitié.

Objectifs et indicateurs : à quoi verra-t-on que ça marche ?

Un design system répond à des enjeux d’optimisation… mais de quoi au juste ? Et bien c’est à vous de le dire ! Construire sans objectifs, c'est dépenser à l'aveugle. Et pour durer, un design system doit se justifier devant ceux qui le financent.

Trois questions à trancher avant de produire quoi que ce soit.

1. Pourquoi le construit-on ?
   Les raisons sont multiples (rapidité de production, cohérence d'expérience, avantage commercial) mais il faut les prioriser. Cette hiérarchie, c'est elle qui tranchera les arbitrages du futur, quand deux besoins s'opposeront.
2. Quel problème résout-on en premier ?
   L'audit en a remonté plusieurs. On ne les traite pas tous d'un coup : on en choisit un ou deux, alignés sur l'objectif prioritaire, comme point de départ.
3. Comment mesure-t-on la réussite ?
   Ici, on relie le design system à des indicateurs concrets, ceux qui parlent autant à un designer qu'à un CTO ou à un porteur de projet :

• Time-to-market. Combien une équipe gagne-t-elle à intégrer une page avec des composants prêts à l'emploi plutôt que de repartir de zéro ?
• Dette design et technique. Le nombre de variations de composants et de CSS redondante baisse-t-il vraiment ?
• Onboarding. Un nouveau designer ou dev devient-il autonome en deux jours, ou en trois semaines ?
• Taux d'adoption. Le plus parlant, et le plus honnête : quelle part des composants réellement utilisés en production vient du design system, plutôt que d'être détachée ou recréée à la main ? Un système à 30 % d'adoption, c'est un système qu'on a construit mais qu'on n'a pas réussi à faire adopter.

La gouvernance : les 50 % qui ne sont pas des écrans

C'est ici que se jouent les design systems. C'est aussi ici qu'ils meurent, et presque jamais pour une raison technique. Personne n'en est clairement responsable, personne ne sait comment proposer une évolution, le système se fige, puis se périme.

La gouvernance, c'est l'ensemble des règles qui répondent à quatre questions très terre-à-terre : qui décide, qui contribue, comment on publie une évolution, comment on la fait adopter. Aucune ne se règle dans Figma. Voilà pourquoi elle pèse la moitié du projet.

Cette moitié invisible, la voici en clair :

• les droits de décision : qui valide un nouveau composant, qui refuse un cas particulier ;
• le modèle de contribution : comment une équipe propose une évolution sans tout casser ;
• le versioning et les releases : comment on publie, on numérote, on communique un changement ;
• la documentation : sans elle, un composant parfait reste inutilisable ;
• l'onboarding et le support : comment un nouvel arrivant devient autonome ;
• les rituels d'adoption : ce qui fait que les équipes s'en servent, semaine après semaine.

Rien de tout ça n'est un pixel.
Et pourtant, c'est ça qui fait la différence entre un système vivant et un fichier orphelin.

Les rôles. Même à petite échelle, quelques rôles doivent exister, quitte à ce qu'une personne en cumule plusieurs :

• Porteur de projet / Product Owner : définit les objectifs et pilote.
• Designer UI/UX : conçoit les fondations et les composants.
• Développeur front : implémente les composants.
• Référent design system : tranche, garantit la cohérence, anime la communauté, priorise les évolutions.
• Contributeurs : les équipes produit, qui utilisent le système au quotidien et remontent les besoins.

Le rôle pivot, c'est le référent. C'est lui qui empêche le système de partir dans tous les sens au premier cas particulier. Sans arbitre, un design system redevient en quelques mois la collection de fichiers hétéroclites qu'il était censé remplacer.

Le modèle de contribution. La vraie décision de gouvernance. Elle arbitre une tension permanente entre cohérence et autonomie :

• Centralisé : une seule équipe conçoit et valide tout. Cohérence maximale, mais goulot d'étranglement dès que la demande grimpe.
• Fédéré : chaque équipe contribue selon des règles communes, le référent arbitre. Ça passe à l'échelle, mais ça exige une gouvernance solide pour ne pas déraper.
• Hybride : un noyau tient les fondations, les équipes contribuent sur les composants métiers. Le compromis qui convient à la plupart des organisations une fois le système lancé.

Aucun modèle n'est bon dans l'absolu. Le bon, c'est celui qui colle à votre taille et à votre culture. Mais le choisir explicitement, c'est déjà ce qui sépare un design system vivant d'un Figma abandonné.

🐙 Chez Jujotte.
Sur un accompagnement récent, on a conseillé à un client de fusionner le rôle de Lead Designer et de référent design system. Résultat : décisions en circuit court, cohérence totale, et une communauté interne qui reste animée sans process lourd.

À qui parle le design system ?

Un design system a des utilisateurs, et ils ne lisent pas le même chapitre. Préciser la cible, c'est fixer le ton, le niveau de détail et le format. La plupart du temps, il y a trois publics à servir en parallèle. L'enjeu n'est pas d'en sacrifier deux, mais de savoir par où chacun entre.

• Les designers veulent des guidelines d'usage et un fichier de production impeccable (Figma, Penpot). C'est leur source de vérité quotidienne.
• Les développeurs attendent des tokens clairs et des composants documentés, prêts à intégrer (Storybook, Zeroheight, Supernova). Pour eux, tout se juge à la doc et au code.
• Les PM et porteurs de projet ont besoin de la logique d'ensemble : ce que le système couvre, ce qu'il permet de chiffrer, ce qu'il fait gagner. Un ton plus explicatif, quelques tutoriels, et l'essentiel passe.

Un même système peut, et doit souvent, parler à ces trois publics sans diluer son propos. Identifier la cible ne sert pas à trier. Ça sert à repérer d'avance les points qui risquent de coincer.

Le périmètre de la V1 : sortir quelque chose, plutôt que tout

Viser l'exhaustivité dès le premier jour, c'est la garantie de ne jamais rien livrer. On cadre donc un périmètre de lancement pragmatique, sur quatre axes.

• Le scope. Qu'est-ce qui entre dans la mission ? La charte est-elle à revoir ? L'organisation des fichiers est-elle incluse ? On pose tout noir sur blanc, pour éviter le périmètre qui gonfle en silence.
• Les composants prioritaires. Une vingtaine (boutons, champs, modales, en-têtes) qui couvrent 80 % des besoins immédiats. C'est ce qui rend le système utile dès la première semaine, au lieu de dans six mois.
• La technonologie et l'écosystème. On valide la stack de dev, l'outil de design (Figma, Penpot…) et l'outil de doc (Zeroheight, Supernova…). On décide aussi si l'on part d'une base open source ou de zéro.
• Les principes. Souvent liés aux objectifs : accessibilité (RGAA), performance, logique de conversion, niveau de détail attendu. Les lignes directrices que toute l'équipe garde en tête.

Comment aligner tout le monde là-dessus sans y passer des mois ? Le format atelier reste le plus efficace, à condition de ne pas en faire des fourre-tout. Mieux vaut des sessions courtes et récurrentes, un sujet par atelier :

Faire vivre le système : l'adoption est un produit

Le lancement n'est pas la fin du projet. C'est le début du seul indicateur qui compte : est-ce que les équipes s'en servent ? Un design system dont on ne parle plus est un design system mort, aussi soigné soit-il.

Le bon réflexe : le traiter comme un produit. Il a des utilisateurs, donc il lui faut de l'onboarding, du support, des releases et une boucle de feedback. En pratique :

• Un canal dédié pour annoncer les versions, répondre en direct et centraliser les retours. Ça remet de l'humain dans un sujet technique, et c'est souvent là que naissent les meilleures idées d'évolution.
• Une plateforme de tickets, plus formelle que le canal, pour tracer les demandes et les traiter dans l'ordre.
• Des ateliers d'acculturation. Le premier frein à l'adoption n'est pas la qualité du système, c'est le changement d'habitudes. On n'envoie pas un lien Figma en lançant « débrouillez-vous » : on accompagne, en petit comité.
• Des revues régulières auprès des équipes métiers, pour vérifier que les composants sont bien utilisés et repérer les frictions avant qu'elles ne deviennent des contournements.
• Des mises à jour fréquentes et communiquées. Corriger vite plutôt que d'attendre un gros lancement, et le faire savoir. C'est ce qui garde le système présent dans les têtes.

🐙 Chez Jujotte.
Chez un client, on a mis en place un point d'étape toutes les deux semaines sur son espace collaboratif. Aujourd'hui, les équipes ne se contentent plus de recevoir les mises à jour : elles s'approprient l'outil, posent leurs questions d'interface, co-conçoivent le produit. Le design system est devenu le premier levier de leur culture produit.

Design system : les questions fréquentes

Qu'est-ce qu'un design system ?
Un outil qui garantit l'unité entre les produits d'une même organisation. Il réunit des artefacts (UI kit, documentation, composants développés) et une gouvernance qui les fait évoluer. Sans cette seconde partie, on a un UI kit, pas un design system.

Design system ou UI kit : quelle différence ?
Un UI kit est une bibliothèque de composants réutilisables, mais figée. Un design system, c'est ce même UI kit assorti d'une documentation et, surtout, d'une gouvernance : quelqu'un en est responsable, décide des évolutions et les publie. Pour une petite équipe avec un seul produit, un bon UI kit suffit souvent.

Combien de temps pour mettre en place un design system ?
Une V1 utile, une vingtaine de composants couvrant l'essentiel, avec sa gouvernance, se cadre en quelques semaines. Mais un design system ne se « termine » pas : il évolue en continu avec les produits qu'il sert.

Qui doit gérer un design system ?
Une équipe cœur (PO, designer, développeur front) et surtout un référent qui tranche les décisions et anime la communauté. C'est le rôle le plus important : sans arbitre, le système se disperse et se périme.

Le cadrage amont, et le véritable adressage de la gouvernance, c'est la moitié du travail que la plupart des projets sautent. L'autre moitié, concevoir la bibliothèque, poser les tokens, industrialiser le pont entre design et développement c'est la phase visible de l’iceberg. De manière générale, ce type d’accompagement c’est ce que nos 15 experts font depuis 2018 pour des organisations comme celles de Veolia ou de la MAIF.
On détaille tout ça, chiffres de ROI à l'appui, sur notre accompagnement design system.