Temps de lecture : 7 minutes

Lors du dernier article, nous avions abordé les 3 premières idées reçues sur un Design System (DS). Aujourd'hui, c'est le moment de clôturer le sujet avec les dernières croyances.

Idée reçue n°4 — « Un design system est une bibliothèque figée »

Ce n'est pas un livrable terminé, c'est un produit vivant.

Cette idée reçue découle souvent de la n°1 (« Un design system doit être parfait avant d'être utilisé »). Nous avons tellement attendu que le DS soit complet avant de le lancer que nous le traitons ensuite comme un livrable terminé, à maintenir « en plus » du reste, sans vraiment y revenir.

Denis Bratchikov (2025) le formule très clairement : certaines décisions qui semblent parfaitement raisonnables au départ se révèlent incomplètes ou inexactes, non seulement lorsqu'elles rencontrent l'usage réel, mais aussi parce que le monde évolue plus vite que prévu.

Un composant validé dans un contexte peut se révéler inadapté dans un autre. À titre d'exemple, nous avions mis en place un composant « button » pour le site internet d'un client, conçu à partir de sa charte graphique. À l'usage, nous avons découvert que sa couleur générait un effet d'alerte involontaire lorsqu'il était placé sur un autre produit ; sa couleur, pourtant conforme à l'identité visuelle de la marque, changeait de sens selon l'environnement. La décision de le retirer s'est imposée. Savoir revenir sur une décision initiale fait partie du processus : c'est une marque de maturité (pas d'échec) et c'est même ce qui distingue un DS vivant d'un livrable figé.

C'est une réalité du travail sur un DS multi-produits : un composant ne vit pas en isolation, et sa validité se mesure dans tous les contextes où il apparaît.

Traiter un DS comme un produit, c'est appliquer les principes de l'expérience utilisateur à la documentation elle-même : discovery, test, apprentissage et implémentation. Chez Aktan, cette approche centrée utilisateur s'étend au DS lui-même. Nous prenons en compte à la fois les besoins et usages des utilisateurs finaux du service ainsi que ceux des utilisateurs directs (designers, développeurs, équipes marketing…).

Un DS doit être conçu comme un produit à part entière et non comme un « projet one-shot », comme l'explique Samuel Abada (2026). Cela implique une logique de backlog, de priorités et de releases, sans jamais viser une livraison finale. Il est pertinent de construire les tokens en parallèle des composants, car ils ont besoin d'usages réels derrière pour prendre du sens.

Pour faire vivre une roadmap plutôt que de la laisser se figer, nous pouvons recueillir régulièrement les retours des personnes qui utilisent le DS, pour comprendre ce qui fonctionne et ce qui freine.

Un Design System ressemble à un jardin : il demande une attention continue. Croire qu'il sera terminé un jour, c'est se préparer à la frustration.

Idée reçue n°5 — « Le design system tue la créativité »

Moins de temps sur les boutons, plus de temps sur les vrais problèmes utilisateurs.

Cette idée reçue tient davantage à la façon dont le DS a été introduit qu'au système lui-même. S'il est imposé sans pédagogie, il crée de la résistance, et cette dernière finit par être confondue avec une limite créative. Un DS bien intégré, au contraire, libère l'énergie créative.

Cet article de GeekyAnts (2022) le résume bien : un DS augmente la créativité en fournissant une fondation pour l'expression visuelle, en libérant du temps pour les vrais enjeux de chaque cycle produit. Tom et David Kelley (2013, p.126) vont dans le même sens dans leur ouvrage Creative Confidence. Ils expliquent que lorsque les contraintes sont bien utilisées, elles ne brident pas la créativité mais la canalisent et l'alimentent. Une contrainte bien posée force à chercher des solutions plus ingénieuses, non pas à se résigner.

C'est ce que nous avons vécu en questionnant un composant en apparence anodin : la sélection de langue sur le site internet de notre client. Ce qui semblait être un détail d'affichage à régler en 20 minutes dans Figma a révélé des enjeux bien plus larges. Il a fallu réfléchir à la gestion des pays, des services associés à chaque territoire et à une logique de localisation IP. Une question business, UX et technique à part entière. C'est précisément parce que nous avions déjà des éléments documentés dans le DS que nous avons pu nous questionner et faire remonter des décisions vers les vrais enjeux.

Voilà le gain réel d'un DS en termes de créativité : quand il prend en charge les décisions répétitives (la couleur d'un bouton, l'espacement d'un composant, le style d'une icône…) pour que l'équipe n'ait plus à les reconsidérer à chaque projet ou chaque sprint. Le temps, l'énergie mentale et créative habituellement dépensés sur ces micro-décisions se libèrent pour des questions plus complexes : les parcours utilisateurs, les arbitrages business et les problèmes stratégiques.

Idée reçue n°6 — « Un UI kit et une charte suffisent »

Un design system va bien au-delà : c'est de la gouvernance, de la pédagogie, de l'alignement humain.

Un fichier Figma propre et une charte graphique, c'est un bon début. C'est même essentiel pour construire les tokens et s'assurer que tout le monde part sur la même base. Mais il ne faut pas confondre ce kit avec un DS.

Design Systems Collective (2025) l'évoque : un DS inclut des composants réutilisables, des patterns, de la documentation d'usage, mais aussi et surtout des guidelines de contribution, des processus de review, du support, des métriques et une gouvernance. La différence se joue sur ces processus.

Au départ, avoir un UI kit ou une charte permet d'anticiper les prochaines étapes, de rester générique et de gagner en précision progressivement. La priorité n'est pas d'avoir tout du premier coup, c'est de ne pas avoir de composants divergents entre produits, ni de décisions arbitraires prises individuellement.

Tout dépend de la taille de l'entreprise et de sa maturité, mais un UI kit seul ne résoudra jamais un problème d'alignement humain. Car un DS, ce n'est pas juste un fichier de documentation.

Le fil qui relie ces 6 idées reçues

En prenant du recul, une même erreur de lecture traverse toutes ces croyances. Elle consiste à voir le Design System comme un objet fini. C'est un système socio-technique qu'il convient de piloter avec une communication adaptée. Les meilleurs composants du monde ne servent à rien si les équipes ne se parlent pas.

L'idée reçue n°1 (il faut être parfait) nourrit la n°2 (il existe un modèle idéal à copier). Ces deux croyances invisibilisent le travail humain réel (n°3) et encouragent une vision statique du DS (n°4). Cette perception de rigidité engendre la résistance créative (n°5), souvent parce que le DS a été réduit à un simple kit graphique (n°6).

Cette quête de perfection nous empêche d'avancer : un Design System en version 0.1 qui sert réellement les équipes aujourd'hui vaut infiniment mieux qu'un système « parfait » qui attend depuis 6 mois.

Alors, par où commencer ?

Avant de vous lancer, vous pouvez vous poser ces questions :

• Avez-vous identifié un problème concret que le DS doit résoudre ? Pas « avoir un DS », mais quelle(s) friction(s) spécifique(s) il élimine ?

• Comment les équipes contribuent-elles et remettent-elles en question les règles ? Existe-t-il un canal, un rituel, un process visible ?

• Qu'allez-vous mesurer : la quantité de composants livrés, ou la qualité des conversations et des livrables ? (l'article de Cervo (2023) est une bonne entrée pour cadrer ces métriques d'adoption.)

Commencez petit, mais commencez. Lancez une version minimale ciblée sur un ou deux pain points clés. Mettez en place un rituel de gouvernance simple (temps de travail collectif, canal de demandes, décisions documentées). Pas besoin d'un plan parfait : un DS qui bouge vaut mieux qu'un DS qui attend.

Ce qui reste vrai, même avec l'IA

Après cette série d'articles, nous pouvons identifier les problématiques récurrentes que nous retrouvons sur le terrain :

• absence de vision produit claire

• manque de sponsor

• gouvernance floue

• promesse trop large par rapport à la capacité réelle des équipes

Ce ne sont pas des fatalités ou des échecs, mais des apprentissages et des signaux à lire tôt.

Un bon Design System n'impressionne pas par sa perfection mais par son rôle dans le quotidien de vos équipes. Ce qui semble faire vraiment la différence, c'est la qualité des rituels qui entourent le DS : des synchronisations régulières design/dev, une communication continue plutôt que des annonces descendantes, et l'acceptation que chaque équipe avance à son propre rythme.

Depuis quelques mois, nous voyons fleurir des approches pour automatiser des pans entiers du travail DS avec l'IA (migrations de composants, vérifications de conformité, documentation accélérée…). Noé Chagué en témoigne : plutôt que de subir un problème répétitif, il l'a résolu en automatisant une partie de son travail avec Claude Code. C'est une direction que nous explorons également chez Aktan : automatiser ce qui peut l'être pour libérer du temps sur les enjeux stratégiques — observer, écouter, aligner et décider.

Parce qu'un DS, aussi outillé soit-il, reste un projet humain. Il progresse à travers les erreurs, les faux départs et les composants jamais adoptés. Il vit dans les conversations difficiles, les arbitrages assumés et les décisions documentées pour ceux et celles qui arriveront après nous.

Pas de recette magique. Il faut observer et accepter d'être surpris, pour construire quelque chose de suffisamment bon pour aujourd'hui et extensible pour demain.

Et vous : laquelle de ces 6 idées reçues vous a le plus pénalisé ?

Références

• ABADA, S. (2026) — Your Design System Is Not a Project. Stop Treating It Like One.

• BRATCHIKOV, D. (2025) — Design System: Governance and Adoption.

• CERVO, M. (2023) — Design Systems Adoption Metrics Over the Past 5 Years.

• CHAYAN (2022) — 5 Design System Myths / Misconceptions Answered.

• DESIGN SYSTEMS COLLECTIVE (2025) — Mastering Design Systems: Best Practices and Misconceptions.

• CHAGUÉ, N. & PODGORSKI, M. (2026) — Design @ Finary : Automatiser son Design System avec Claude Code.

• KELLEY, Tom & David (2013) — Creative Confidence, chap. « Use Constraint to Fuel Creative Action », p.126. HarperCollins.