Temps de lecture : 7 minutes

Nous avons tous·tes une image du Design System (DS) parfait en tête, mais ça ressemble rarement à ce que nous vivons vraiment à l'instant T.

Lors de mon dernier article je vous parlais de la « boîte de Pandore » qu'est la construction d'un DS et l'écart qu'il peut y avoir entre la vitrine des grands noms (Google, IBM, Salesforce, Shopify, Apple…) et la réalité des équipes.

Parce que derrière les difficultés du terrain, il y a souvent des croyances non questionnées qui orientent discrètement nos décisions. Il existe également une asymétrie de visibilité, mentionnée lors d'une table ronde organisée chez PayFit (2024) par Design Systems France : la majorité des personnes voient une documentation attractive mais peu de gens voient les discussions, les conflits de priorités et les arbitrages techniques qui ont mené aux décisions.

Dans cet article, nous revenons sur les 3 premières idées reçues (la suite arrivera dans l'article suivant). Pour illustrer mes propos, nous confrontons ma pratique de designer, à travers un exemple projet client d'Aktan, avec des articles sur cette thématique. Dans ce projet, le DS doit répondre à des enjeux d'homogénéisation, d'évolutivité et d'internationalisation de son écosystème digital.

Cet article n'a pas vocation à vous livrer une recette magique. Il s'agit plutôt de vous donner des pistes pour observer, accepter d'être surpris par la réalité de votre quotidien et construire quelque chose de suffisamment bon pour aujourd'hui et extensible pour demain !

Idée reçue n°1 — « Un design system doit être parfait avant d'être utilisé »

Mieux vaut 5 composants adoptés que 50 qui dorment dans Figma.

C'est l'un des pièges les plus classiques : attendre le « grand jour » avant de montrer quoi que ce soit aux équipes, et livrer trop tard ou ne jamais livrer.

Une analyse sur 5 ans de métriques d'adoption (Cervo, 2023) le confirme : les équipes qui attendent un système complet tombent souvent dans le même travers — mesurer sur un périmètre trop large, sans objectif central défini, ou sur des « vanity metrics » (Robin Cannon, 2022) qui n'ont aucune valeur réelle pour les équipes.

Ness Grixti le formule très bien dans The Hidden Work Behind Design System Adoption (2025) : le travail le plus précieux se fait en amont, dans la phase d'alignement et de cadrage, bien avant que la documentation soit présentable. Ce travail invisible de gouvernance et de conversations, où se joue vraiment l'adoption, est nommé le « hidden work » par Ness Grixti.

Sur notre projet client, au départ, nous avons eu deux flux directeurs :

• Échanger avec les utilisateurs directs du DS afin de comprendre leurs besoins prioritaires.

• Auditer les composants les plus utilisés sur deux produits digitaux selon des critères précis (fréquence d'utilisation, impact sur l'UX, homogénéité, impact business).

L'objectif était de prioriser les composants dont la documentation apporterait un gain immédiat aux équipes dans leur production.

Initialement, nous avions mis beaucoup d'énergie dans la documentation en pensant qu'elle constituait le socle d'un DS. Mais sans implémentation réelle, nous avons compris qu'une documentation parfaite n'est que partiellement exploitable. Il faut l'enrichir progressivement, au fur et à mesure que les composants prennent vie dans vos produits. Nous testons chaque composant dans un fichier isolé, le validons dans des prototypes avant de décider de l'intégrer dans le DS. C'est une approche qui évite de documenter des décisions encore instables.

Quelques réflexes utiles pour bien démarrer :

• Ne pas surdimensionner la documentation dès le départ.

• Rester sur un périmètre resserré afin d'avoir des fondations solides pour ensuite changer plus facilement d'échelle.

• Répondre à quelques pain points bien priorisés.

• Accepter que le système s'enrichisse au fil du temps.

Idée reçue n°2 — « Il existe un modèle universel à copier »

Copier Material Design sans copier Google, c'est l'échec assuré.

Nous sommes tous·tes tenté·es de s'inspirer des géants : Material Design (Google), Carbon (IBM), Atlassian Design System (Salesforce), Polaris (Shopify), HIG d'Apple… des DS impressionnants et bien documentés. Sauf qu'ils incarnent leur contexte, avec une culture d'organisation, des équipes dédiées et une maturité produit construite sur des années et qui leur sont propres.

Comme le rappelle Design Systems Collective (2025) : copier les artefacts sans copier les conditions qui les ont produits génère de la dette et de la frustration. Un peu comme si vous commandiez le menu d'un restaurant étoilé… et qu'on vous le servait dans de la vaisselle jetable.

Un DS universel n'existe pas. Il sert de base sur des éléments génériques afin de ne pas partir d'une feuille blanche. Il doit ensuite être réadapté à votre contexte, en prenant en compte vos contraintes métier et la maturité réelle de vos équipes.

Sur notre projet client, nous sommes partis du framework déjà utilisé par les développeurs pour avoir une base commune et limiter les risques d'adoption. Nous l'avons adapté progressivement à notre identité et à nos besoins spécifiques.

Deux questions à vous poser avant de vous inspirer d'une documentation existante :

• Quel design system mon organisation peut-elle réellement maintenir aujourd'hui ?

• Qu'est-ce que je peux garder et qu'est-ce que je dois reconcevoir selon mon contexte ?

Idée reçue n°3 — « Le designer design system ne fait que des composants »

C'est autant un projet humain que technique.

Quand nous imaginons le designer DS, on voit souvent quelqu'un penché sur Figma à crafter des variants de boutons à l'infini.

En réalité, nos missions sont très diverses : synchronisation avec les développeurs sur la nomenclature des tokens, priorisation des composants sur des critères objectifs (usage, impact business, accessibilité), documentation des décisions, récolte et traduction des besoins en patterns. Denis Bratchikov (2025) le résume bien : « Adoption is rarely a technical problem — it's a human one. » Les obstacles ne viennent pas du manque de qualité des composants, mais de la pression liée à la roadmap, des habitudes ancrées et de la courbe d'apprentissage.

L'article de Razorpay (2025) sur la maintenance décrit des rituels structurants : des office hours régulières, un canal de signalement des issues, un processus d'évaluation et de priorisation des demandes. C'est du design ops de proximité : collaborer avec les équipes pour faciliter et aligner.

Sans surprise, la communication est un chantier à part entière. Il peut y avoir des conflits d'agenda, des frictions politiques et des parties prenantes qui souhaitent prioriser selon des critères subjectifs. Il faut savoir garder les décisions ancrées dans l'usage réel et l'impact business pour qu'elles restent objectives. C'est exactement cette posture hybride qui définit un Product Designer : une vision stratégique + avoir les mains dans le concret.

Cette idée reçue nous pousse aussi à nous demander ce que signifie vraiment être Product Designer (encore plus à l'heure des outils génératifs). Nous réduisons parfois ce rôle à la production d'interfaces. Mais concevoir un produit ou une expérience, c'est aussi comprendre les usages, structurer un problème, définir des règles, créer des systèmes cohérents, aligner design, produit et tech. Les interfaces ne sont que la partie visible du travail. Exactement comme les composants pour un DS.

Et c'est fini pour aujourd'hui, la suite arrive bientôt !

Ces 3 premières idées reçues ont un point commun : elles nous poussent à traiter le Design System comme un système à faire vivre plutôt que comme un objet à livrer.

Dans la deuxième partie, nous irons plus loin avec les 3 autres croyances, en finissant par les questions à se poser avant de se lancer.

Références

• BEHERA, R. K. (2025) — Behind the Scenes of Maintaining a Design System Component.

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

• CANNON, R. (2022) — Design System Adoption Numbers… Just a Vanity Metric?

• CERVO, M. (2023) — The Challenge of Design Systems Adoption Metrics.

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

• DESIGN SYSTEMS FRANCE — Table ronde : Les Échecs d'un Design System.

• GRIXTI, N. (2025) — The Hidden Work Behind Design System Adoption.