16 avril 2025

Design System : les questions qu’on se pose en 2025

De l’adoption à la gouvernance, des tokens à l’IA, les design systems sont à un tournant de leur histoire. Plus qu’un outil, ils deviennent un indicateur de maturité produit.

Depuis quelques années, les design systems sont devenus un incontournable dans les organisations digitales. Outils de cohérence, de gain de temps, de qualité et de collaboration, ils structurent l’identité visuelle et fonctionnelle d’un produit.

Pourtant, derrière cette apparente maturité, le design system soulève encore aujourd’hui de nombreuses questions. En tant que praticien ou simple observateur de cette évolution, l’on se retrouve souvent face à un paradoxe : tout le monde en parle, beaucoup en ont, mais peu en tirent vraiment tout le potentiel. Alors, quelles sont les vraies questions du moment autour des design systems ?

 

Commençons par l’origine : pourquoi met-on en place un design system ?

Au départ, il s’agit généralement de résoudre un chaos visuel ou un manque de cohérence dans les produits. Multiplication des styles, composants dupliqués, interfaces incohérentes d’un projet à l’autre… le diagnostic est souvent facile à poser. Mais au moment de la mise en place, les choses se compliquent.

Qui pilote ? Que standardise-t-on ? Jusqu’à quel niveau ?

Le design system, pour être efficace, doit être pensé comme un produit à part entière. Cela implique des priorités, une roadmap, des contributeurs, une gouvernance. Et c’est souvent là que le bât blesse.

L’une des premières grandes questions du moment concerne donc la gouvernance. Faut-il une équipe centrale dédiée au design system, ou un modèle plus fédéré où chaque équipe produit a son mot à dire ? La tendance actuelle semble aller vers un modèle hybride : un noyau dur qui pose les principes fondamentaux, et une structure de contribution distribuée. Ce modèle permet de concilier cohérence globale et flexibilité locale.

Mais il demande aussi une organisation rigoureuse et une vraie stratégie de communication interne. Car un design system, ce n’est pas juste une librairie de composants, c’est un langage commun. Et comme tout langage, il faut l’apprendre, le pratiquer, le faire évoluer.

 

Ce qui nous amène à la deuxième grande interrogation : l’adoption.

Un design system non utilisé ne sert à rien. Et l’adoption ne se décrète pas. Elle se construit, se teste, se mesure. De nombreuses équipes racontent comment, malgré une belle documentation et des composants bien pensés, les produits continuent de déroger aux standards. Pourquoi ? Parce que le design system n’est pas toujours perçu comme une aide. Parfois, il est vu comme un frein, une contrainte, une ingérence.

Pour l’adoption, tout se joue donc dans la manière de positionner le design system : comme un facilitateur et non un gendarme. Cela passe par la pédagogie, des cas d’usage concrets, des réponses rapides aux besoins spécifiques. Certaines organisations vont même jusqu’à « marketer » leur design system en interne : newsletters, démos, formations, support… bref, le traiter comme un produit au service des autres produits.

Mais pour que l’adoption fonctionne, encore faut-il que le système soit pensé pour durer.

 

Comment maintenir un design system dans le temps ?

Beaucoup d’initiatives s’essoufflent faute de moyens, de vision, ou tout simplement d’équipe. Car un design system, ce n’est pas juste un projet à lancer, c’est un produit vivant. Il faut le maintenir, le faire évoluer, le documenter, le débuguer. C’est pourquoi de plus en plus d’organisations créent des équipes dédiées, avec un backlog, des rituels, des KPIs. On parle alors de DesignOps, un domaine en plein essor qui structure cette nouvelle façon de penser la production design à grande échelle.

Sur le plan technique, les design systems font aussi face à des défis de plus en plus complexes. L’interopérabilité entre plateformes est l’un d’eux. Comment s’assurer que les mêmes composants fonctionnent aussi bien dans une app web, mobile, ou même dans des environnements hybrides ? Certains parient sur les Web Components, d’autres créent des systèmes parallèles. Mais dans tous les cas, la question de la scalabilité technique reste centrale. Il ne suffit plus d’avoir des composants dans Figma et dans Storybook. Il faut les relier, les maintenir, les tester, les déployer, les faire évoluer ensemble.

 

C’est là qu’entrent en jeu les design tokens.

Ces variables définissant les couleurs, les espacements, les tailles de typographies, sont aujourd’hui au cœur de la stratégie de synchronisation entre design et code. Et les outils suivent : Figma introduit les variables, Tokens Studio se démocratise, les pipelines CI/CD s’adaptent (ça signifie qu’ils ne servent plus uniquement à livrer du code, mais deviennent aussi des gardiens automatiques de la cohérence visuelle, technique et fonctionnelle du design system).

Mais derrière l’engouement, une question persiste : où est la « source de vérité » ? Est-ce le fichier Figma ? Le fichier JSON dans GitHub ? Le code en production ? Chaque organisation cherche son modèle, entre centralisation du savoir et fluidité de la contribution.

 

Parlons aussi de documentation.

Trop souvent perçue comme une tâche ingrate, elle est pourtant essentielle. Un design system bien documenté est un système utilisable. L’émergence de plateformes comme Zeroheight ou Supernova montre bien que la documentation n’est plus une simple page wiki : elle devient un espace de dialogue entre les équipes, un point d’entrée, un outil de partage. La documentation n’est plus un livrable à part, elle est au cœur du produit design system.

 

L’accessibilité, un autre sujet qui prend de plus en plus de place !

Intégrer les règles d’accessibilité directement dans les composants du design system permet de démocratiser les bonnes pratiques. On passe d’un sujet « bonus » à une norme intégrée, testée, validée. C’est aussi une façon de responsabiliser l’ensemble des équipes : si le composant est accessible de base, on a déjà fait 80% du chemin.

 

Enfin, impossible de conclure sans parler d’intelligence artificielle.

L’IA commence à se glisser dans le design system, par petites touches : suggestion automatique de documentation, audit de conformité, génération de variantes, etc. Ce n’est encore qu’un début, mais les promesses sont là. L’IA ne remplacera pas les designers ou les devs, mais elle peut les aider à gagner du temps, à réduire les erreurs, à accélérer les workflows. Le design system pourrait ainsi devenir un terrain d’expérimentation privilégié pour ces nouvelles pratiques.

En somme, les questions autour des design systems ne cessent d’évoluer. Gouvernance, adoption, maintenance, technique, documentation, accessibilité, intelligence artificielle… tous ces sujets montrent qu’on ne fait plus un design system aujourd’hui comme on le faisait hier !

Et c’est tant mieux. Car plus qu’un outil, le design system est un miroir des ambitions et de la maturité d’une organisation. Le rendre vivant, pertinent, adopté, c’est aussi faire grandir l’ensemble des équipes qui le font vivre.

Et au fond, c’est bien cela l’objectif : créer des meilleurs produits, ensemble.

 

Sources : Rangle.io (retours d’expérience sur l’adoption et Dev Mode), UX Collective & Medium, chromatic, designsystems.com, Supernova.io (rapports 2024 sur tokens et IA)… Les discussions sur les réseaux LinkedIn ont également inspiré certaines thématiques émergentes de cet article. Ce panorama reflète l’état des questions au début de 2025, dans un domaine en constante évolution. Les design systems se trouvent à un carrefour passionnant entre structuration et adaptation, et les prochains mois/années verront sans doute ces interrogations se muer en bonnes pratiques à partager.

Articles associés