Votre organisation a-t-elle besoin d’un Design System ?

Le design system s’est progressivement imposé comme une norme implicite des projets digitaux ambitieux.

Côté IT, on parle d’industrialisation et de réduction de la dette technique.

Côté Product, on imagine des releases plus fluides.

Côté Marketing, on espère une vraie cohérence UI et davantage d’autonomie.

Mais derrière cette demande se cachent des réalités très différentes. Un design system n’est pas un simple livrable graphique. C’est un produit interne, avec une gouvernance, un backlog et un coût d’exploitation.

Il est pertinent lorsqu’il répond à un enjeu d’échelle : homogénéiser un écosystème digital complexe, aligner plusieurs équipes, structurer une marque sur de multiples dispositifs….

En revanche, dans de nombreux contextes – un site unique, une équipe restreinte, un budget contraint – l’investissement peut s’avérer disproportionné.

La vraie question n’est donc pas : faut-il un design system ?

Mais bien : votre organisation a-t-elle la maturité et l’échelle pour l’amortir ?

Pourquoi cette question se pose (et pourquoi elle est stratégique)

Dans beaucoup d’organisations, le sujet émerge lorsque la complexité commence à peser concrètement sur les équipes.

La dette UI ralentit les développements. Plusieurs dispositifs digitaux coexistent sans cadre commun. Les contributions marketing deviennent difficiles à canaliser dans le CMS. Les régressions visuelles s’accumulent.

À ce stade, la tentation est forte de chercher une solution structurelle.

Le design system apparaît alors comme une réponse évidente, presque rassurante.

Il promet d’unifier, de rationaliser, d’accélérer.

Mais cette évidence repose souvent sur un raccourci : confondre besoin de cohérence et besoin d’industrialisation.

Or, industrialiser suppose une échelle suffisante – en surfaces, en équipes, en fréquence de livraison – ainsi qu’une capacité réelle à gouverner un produit interne dans la durée.

Avant d’investir, il devient essentiel d’objectiver la situation : quel niveau de structuration est réellemement pertinent pour votre contexte réel ?

Avant de décider : de quoi parle-t-on exactement ?

Dans de nombreux projets, les termes sont utilisés de façon interchangeable. C’est souvent là que les incompréhensions commencent.

Charte graphique : l’identité de marque (et ses limites côté produit)

La charte graphique définit le logo, les couleurs, les typographies, l’iconographie, les règles d’usage de la marque.

Par exemple :	En revanche, elle ne précise pas :
Les déclinaisons autorisées du logo	Comment structurer une page complexe
Les couleurs principales et secondaires de la marque	Comment gérer les variantes d’un composant
Les règles d’utilisation des typographies et de l’iconographie	Comment éviter les régressions UI à chaque sprint

Pour un CTO, la charte ne traite ni la dette technique ni la vélocité. Pour le Marketing, elle ne garantit pas la cohérence des blocs dans le CMS.

Elle pose une base identitaire. Elle ne structure pas un produit digital.

Style guide : des règles UI prêtes à appliquer

Le style guide va plus loin. Il formalise les règles d’interface : boutons, formulaires, tableaux, grilles, règles d’accessibilité de base, do/don’t.

On y trouve des guidelines concrètes : quand utiliser tel pattern, comment hiérarchiser les titres, quelles variantes sont autorisées.

Par exemple :

Quelle taille utiliser pour un titre H1, H2 ou H3 dans une page éditoriale

Dans quels cas afficher un bouton primaire ou secondaire

Comment structurer un formulaire pour rester lisible et accessible

Dans un contexte simple – une équipe, un site – c’est souvent largement suffisant pour aligner les pratiques sans complexifier l’organisation.

Il apporte du cadre, sans nécessiter une gouvernance lourde.

UI kit : des assets qui accélèrent… mais ne gouvernent rien

Un UI kit (souvent sous Figma) regroupe des composants dessinés avec leurs variantes.

C’est un accélérateur en phase de design et il facilite la transmission du travail entre designers et développeurs.

Par exemple :

Un bouton décliné en plusieurs états (normal, hover, disabled)

Une card produit avec différentes variantes

Un composant de navigation prêt à être réutilisé dans les maquettes.

En revanche, sans documentation d’usage, sans versioning et sans component library en code, il n’installe pas de gouvernance.

Chaque développeur peut interpréter différemment. L’outil aide. Il ne structure pas.

Design system : un produit complet

Un design system change d’échelle.

Il inclut généralement :

• une component library en code (souvent documentée dans Storybook),
• des design tokens (couleurs, typographies, spacing centralisés),
• des UI patterns formalisés,
• une documentation d’usage détaillée,
• une gouvernance claire (ownership, backlog dédié, versioning).

Dans les organisations les plus matures, le design system peut également intégrer des exigences transverses comme l’accessibilité ou la webperformance, directement dans les composants.

Par exemple :

Un composant bouton accessible et déjà testé sur tous les supports

Un système de grille et de spacing partagé entre design et développement

Un composant formulaire intégrant directement les bonnes pratiques d’accessibilité

C’est un produit vivant, avec une roadmap et des rituels d’évolution.

C’est un levier d’industrialisation, un accélérateur de time-to-market et un cadre d’autonomie – à condition qu’il soit réellement intégré au CMS.

“Un design system dépasse le site. C’est l’ADN visuel de l’entreprise.”

Construire un design system à partir du réel : une approche inversée

Un design system efficace ne se décrète pas, mais se construit à partir d’usages réels.

Dans de nombreuses organisations, la démarche consiste à définir en amont un système complet, pour créer un cadre clair avant que les besoins ne se multiplient.

Pourtant, cette approche peut s’avérer contre-productive lorsqu’elle reste trop théorique.

Nous l’avons expérimenté lors d’un projet mené à l’agence pour un grand acteur du logement. Au moment de notre intervention, le design system groupe était en cours de construction. De notre côté, nous étions en charge de la refonte technique d’un site existant : rationalisation UX, regroupement de blocs, structuration Gutenberg et formalisation d’un guide de style WordPress.

Le contexte pouvait sembler complexe : un système en construction, un site en refonte, plusieurs équipes impliquées…

C’est pourtant cette configuration qui a donné sa cohérence à l’ensemble.

Plutôt que d’imposer un cadre théorique au site, le design system groupe s’est nourri des usages réellement observés : composants utilisés, variantes éprouvées, contraintes techniques identifiées, nomenclature déjà alignée entre design et intégration.

Autrement dit, le site a alimenté le design system – et non l’inverse.

Cette approche ancre le système dans des besoins validés, facilite son adoption et limite l’écart entre documentation et réalité opérationnelle.

Un design system gagne en pertinence lorsqu’il formalise une maturité existante plutôt que lorsqu’il tente de l’anticiper dès le premier jour.

Les signaux qui indiquent qu’un design system peut être pertinent

• Lorsque plusieurs surfaces doivent être homogénéisées – site corporate, intranet, application, parcours transactionnels – la duplication devient visible. Nous avons par exemple observé des contextes avec plus de vingt variantes de boutons et une dizaine de types de cards pour un même groupe. À cette échelle, chaque évolution produit se transforme en audit transversal. Un design system peut alors structurer durablement l’ensemble.
• La multiplication des équipes est un autre indicateur. À partir de trois ou quatre équipes travaillant en parallèle, le design–dev handoff devient un point de friction récurrent. Un langage commun — tokens partagés, composants versionnés, documentation centralisée — sécurise les livraisons et réduit les interprétations.
• Le rythme de livraison compte également. Lorsque les releases sont hebdomadaires ou quotidiennes, la réutilisation devient stratégique. Assembler plutôt que recréer, tester une fois pour déployer partout : le ROI devient plus tangible.
• Autre signal : l’incohérence coûte déjà du temps. Sur un projet e-commerce, près de 30 % du temps front était absorbé par la correction de divergences de styles. La mise en place d’une librairie commune a permis de réduire ces corrections de moitié en quelques mois.

Un design system devient rationnel lorsque l’incohérence coûte déjà de l’argent.

Enfin, un design system suppose d’être prêt à le faire vivre. Un owner identifié, un backlog dédié, des règles d’ajout de composants : sans cela, l’initiative s’essouffle. Le sujet n’est pas seulement technique, il est organisationnel.

Les signaux qui invitent à temporiser

À l’inverse, certains contextes appellent plus de pragmatisme.

• Un projet one-shot ou un budget serré peut rendre l’investissement disproportionné. Dans ce cas, un style guide clair et quelques composants robustes couvrent souvent l’essentiel.

“Si vous avez un projet one shot et un seul site, un design system n’est tout simplement pas amortissable.”

• Une seule surface digitale, animée par une équipe unique, ne justifie pas toujours une gouvernance lourde. Un thème WordPress bien structuré peut répondre efficacement au besoin.
• Des besoins très instables constituent également un frein. Documenter des patterns qui disparaîtront dans trois mois génère un “effet musée” difficile à maintenir.
• L’absence d’ownership clair est un autre signal d’alerte. Sans responsabilité identifiée, les variantes “hors système” se multiplient et la source de vérité se brouille progressivement.
• Enfin, la stack doit être alignée. Si le front ne consomme pas correctement les design tokens ou si le CMS ne permet pas d’encadrer l’édition (blocs, gabarits, variantes), le système sera contourné — parfois dès les premières semaines.

Le compromis pertinent : le thème avec garde-fous

Dans 80 % des cas, la voiture fiable reste plus adaptée que le char d’assaut.

Dans ces contextes, la question n’est pas de reproduire les standards des grands groupes, mais d’adapter le niveau de structuration à la réalité opérationnelle.

Concrètement, cela signifie standardiser les fondations : couleurs, typographies, grille, spacing…. Puis formaliser 10 à 20 composants clés – boutons, formulaires, cards, navigation, tableaux – réellement utilisés dans le projet.

Chaque composant dispose de variantes clairement encadrées.

Créer une nouvelle variante suit une règle explicite.

La liberté existe, mais elle est cadrée.

Dans nos projets WordPress, cette approche prend la forme d’un thème structuré reposant sur Gutenberg et le Full Site Editing (FSE) :

• styles globaux cohérents,
• blocs personnalisés utiles,
• gabarits éditoriaux robustes,
• patterns réutilisables,
• encadrement des options d’édition pour limiter les dérives.

Ce cadre permet de garantir une cohérence UI durable, de sécuriser l’autonomie marketing et de maîtriser la dette technique, sans introduire une gouvernance lourde ni créer un produit interne à maintenir indépendamment.

Il ne s’agit pas de renoncer à structurer, mais d’industrialiser à la mesure du besoin réel.

Dans de nombreuses organisations, cette approche intermédiaire génère plus de valeur qu’un design system complet difficile à faire vivre.

Si vous partez sur un design system : quelques règles de survie

Avant même de définir les premiers composants, une condition doit être réunie : la décision doit être organisationnelle.

Un design system devient réellement pertinent lorsque plusieurs facteurs convergent – multiplication des surfaces, équipes travaillant en parallèle, rythme de livraison soutenu, coût déjà mesurable de l’incohérence – et lorsqu’une gouvernance explicite peut être mise en place.

Sans cette convergence, le risque n’est pas l’échec technique, mais l’essoufflement progressif. Pour maximiser les chances d’adoption et de durabilité :

1. Commencez par un audit UI réel pour ancrer la démarche dans l’existant plutôt que dans un idéal théorique.
2. Définissez un scope MVP clair (10 à 15 composants couvrant 80 % des usages) afin d’éviter l’effet catalogue.
3. Centralisez des design tokens utiles et pragmatiques, sans surcomplexifier la structure.
4. Documentez pour aider à décider, pas seulement pour décrire : quand utiliser un composant, quand l’éviter, quelles règles d’accessibilité et de QA appliquer.
5. Clarifiez l’ownership et les règles de contribution : backlog dédié, arbitrages formalisés, source de vérité unique.

Ne cherchez pas l’exhaustivité initiale. Même les design systems matures évoluent en permanence.

Sur un projet multi-équipes, le principal blocage n’était pas la qualité des composants, mais un handoff flou. La clarification des responsabilités et des règles de contribution a suffi à faire chuter significativement les créations hors-système en quelques mois.

Le bon choix est celui que vous pouvez maintenir

Le design system n’est ni un standard obligatoire, ni une lubie de designers. C’est un outil stratégique. Mais comme tout outil stratégique, il n’a de valeur que s’il est aligné avec la réalité organisationnelle.

Dans le bon contexte, il génère un réel effet de levier.

Dans d’autres cas, un thème WordPress structuré ou un style guide bien pensé apporte plus de valeur avec moins de complexité.

Si vous hésitez entre design system et thème structuré, le plus simple reste souvent d’objectiver la situation. L’objectif n’est pas de pousser vers la solution la plus ambitieuse, mais vers celle qui servira réellement votre organisation sur la durée.