Un bouton bleu sur la page d’accueil, le même bouton devenu vert trois clics plus loin. Un champ de formulaire qui accepte les espaces d’un côté du site et les rejette de l’autre. Vous avez probablement déjà vécu ça, en tant qu’utilisateur ou en tant que personne qui construit le produit. Ce n’est pas un détail cosmétique, c’est le symptôme d’une interface qui n’a jamais eu de colonne vertébrale. Et cette colonne vertébrale, beaucoup d’équipes pensent qu’elle ne concerne que les grandes structures avec cinquante développeurs et un budget UX à sept chiffres. C’est faux. Dès que deux personnes touchent la même interface sans se parler, le problème apparaît. Nous allons voir pourquoi, et surtout comment on y remédie sans y passer un an.
Qu’est-ce qu’un design system, au-delà du buzzword
Un design system n’est ni une charte graphique, ni une simple bibliothèque de boutons Figma. C’est un référentiel vivant qui combine trois éléments : des règles visuelles précises (couleurs, typographies, espacements), des composants réutilisables prêts à l’emploi, et une documentation qui explique quand et comment les utiliser. Retirez l’un des trois, et le système boite.
La confusion vient souvent d’un raccourci mental : on pense qu’avoir un fichier Figma bien rangé suffit. Or une charte graphique dit à quoi ça doit ressembler, un kit UI donne des briques, mais seul le design system explique le pourquoi et le comment d’utilisation dans le contexte réel du produit. C’est cette dimension d’usage qui manque dans neuf projets sur dix, et c’est précisément elle qui évite les dérives observées un peu partout dans les interfaces mal maintenues.
Les symptômes d’une interface qui part dans tous les sens
Certains signes ne trompent pas, et ils apparaissent bien avant que quelqu’un ose prononcer les mots design system en réunion. Voici les plus fréquents, ceux qu’on retrouve dans la quasi-totalité des audits d’interface :
- Des boutons, couleurs ou espacements qui varient d’une page à l’autre sans raison fonctionnelle
- Un temps de développement qui explose sur des tâches censées être répétitives
- Un écart flagrant entre la maquette validée et ce qui atterrit réellement en production
- Des frictions récurrentes entre l’équipe design et l’équipe technique sur ce qui est « correct »
- Des nouveaux arrivants perdus pendant des semaines dans une base de code sans logique visible
Sur le terrain, le signal le plus révélateur reste le dernier point. Quand on demande à un développeur qui arrive depuis un mois pourquoi il a créé un nouveau composant de carte plutôt que de réutiliser celui qui existe déjà, la réponse typique est « je ne savais pas qu’il existait ». Ce n’est pas un problème de compétence, c’est un problème d’organisation de l’information. Et ce genre de symptôme coûte bien plus cher en temps de correction qu’en temps de prévention.
Les fondations à poser avant de dessiner le premier composant
La tentation classique consiste à se jeter directement sur les composants : on dessine un bouton, puis un autre, puis une carte. Grosse erreur. Sans fondations posées avant, chaque composant devient une décision isolée qui contredira la suivante. Les design tokens, ces variables qui centralisent couleurs, typographies, espacements et ombres, doivent exister en premier. Ils forment le vocabulaire commun sur lequel tout le reste s’appuie.
Une fois ces tokens en place, la logique d’atomic design prend tout son sens : on assemble des atomes (un bouton, un label) en molécules (un champ de recherche complet), puis en organismes plus complexes (un formulaire entier). Sauter cette étape structurante, c’est construire un système qui semble tenir debout pendant trois mois avant de s’effondrer à la première refonte. Quand les ressources internes manquent de recul ou de temps pour poser ces bases correctement, faire appel à un accompagnement spécialisé pour créer un design system permet souvent d’éviter des mois de rattrapage.
Faire travailler ensemble design, dev et produit sans grippage
Un design system qui échoue n’échoue presque jamais pour des raisons esthétiques. Il échoue parce que personne ne sait qui décide. Qui valide un nouveau composant ? Qui peut le modifier sans casser la production ailleurs ? Sans réponse claire, chaque équipe finit par bricoler sa propre variante, et on retombe exactement dans le problème que le système devait résoudre.
Répartir les rôles dès le départ change tout, comme le montre ce découpage minimal qui fonctionne dans la plupart des organisations :
| Rôle | Responsabilité principale |
|---|---|
| Équipe cœur (design + dev) | Valide, versionne et documente chaque composant ajouté ou modifié |
| Contributeurs (équipes produit) | Proposent des besoins, signalent les incohérences, testent les nouveautés |
| Sponsor ou référent | Arbitre les priorités et défend le budget de maintenance auprès de la direction |
Sans ce dernier rôle en particulier, le système survit rarement à son premier trimestre difficile. La gouvernance humaine pèse autant, sinon plus, que la qualité graphique des composants eux-mêmes.
Les erreurs qui font échouer un design system avant même son lancement
La première erreur, et la plus répandue, consiste à vouloir tout documenter avant de livrer le moindre composant. On connaît des équipes qui ont passé six mois à peaufiner une documentation exhaustive sans qu’un seul bouton n’ait été utilisé en production. Le résultat ? Un projet jugé « trop lourd » et abandonné avant même d’avoir servi une fois. Un système vivant avec dix composants utilisés vaut mieux qu’un système parfait resté sur l’étagère.
Deuxième piège fréquent : copier tel quel le design system d’une autre entreprise, souvent une référence comme celle d’un géant du secteur, sans l’adapter au contexte réel du produit. Ce qui fonctionne pour une application bancaire ne convient pas forcément à un site e-commerce local. Troisième erreur, plus insidieuse : traiter l’accessibilité comme un sujet « à voir plus tard ». Ce plus tard n’arrive presque jamais, et le rattrapage coûte trois à quatre fois plus cher qu’une intégration dès la conception des composants de base.
Faire vivre le design system une fois lancé
Livrer le design system n’est pas la fin du travail, c’est le début d’une autre phase, souvent négligée. Sans versionnage clair des composants, chaque mise à jour risque de casser silencieusement une interface ailleurs dans le produit. Adopter une numérotation type majeure, mineure, correctif permet à toutes les équipes de savoir immédiatement si un changement va tout casser ou simplement ajouter une option.
Organiser des points de synthèse réguliers entre équipes design et technique, tous les mois ou tous les deux mois, évite que le système ne devienne un musée poussiéreux rempli de composants que plus personne n’ose toucher. Nettoyer ce qui est obsolète demande du courage, mais c’est ce nettoyage régulier qui distingue un design system encore utile d’un système mort qu’on garde par habitude. La cohérence n’est jamais un acquis définitif, elle se défend chaque semaine, sinon elle s’efface aussi vite qu’elle est apparue.
