Structurer un design system dans un groupe multi-apps : master, déclinaisons et réalité terrain

Quand une organisation grandit, la question finit toujours par arriver :

Comment structurer un design system quand on a plusieurs applications
(outils métier, app mobile, site web, back-office, produits B2B/B2C…) ?

Faut-il :

• un seul design system global ?
  
• un master et des déclinaisons ?
  
• un design system par produit ?
  
• ou laisser chaque équipe se débrouiller ?
  
  

Dans la réalité, le problème n’est pas technique.
Il est organisationnel, produit et politique.

‍

Le mythe du design system unique pour tout le groupe

‍

Sur le papier, l’idée est séduisante :

• une seule source de vérité,
  
• une cohérence totale,
  
• une maintenance centralisée.
  
  

Dans les faits, c’est rarement viable.

Pourquoi ?
Parce que :

• les usages sont différents,
  
• les contraintes sont différentes,
  
• les cycles de vie sont différents,
  
• les équipes n’ont pas le même niveau de maturité.
  
  

Un site marketing, une app mobile grand public et un outil métier interne n’ont pas les mêmes besoins, ni les mêmes priorités.

Forcer une homogénéité totale mène souvent à :

• un design system trop générique,
  
• des contournements locaux,
  
• des forks non assumés,
  
• et au final… de la dette.
  
  

La bonne approche : un design system “en couches”

‍

Dans les groupes qui s’en sortent bien, on retrouve presque toujours la même structure :‍

- un socle commun (master)
- des déclinaisons maîtrisées

Pas un design system unique.
Pas une explosion anarchique.
Un système hiérarchisé.

‍

Le rôle du design system master

‍

Le design system master n’a pas vocation à tout couvrir.
Son rôle est de poser les invariants du groupe.

On y retrouve généralement :

‍

1. Les fondations

• couleurs de base (tokens, pas composants),
  
• typographies,
  
• grilles,
  
• espacements,
  
• principes d’iconographie,
  
• règles d’accessibilité communes.
  
  

Ces éléments ne dépendent pas des usages, mais de l’identité et des standards du groupe.

‍

2. Les principes transverses

• règles d’accessibilité minimales,
  
• principes d’éco-conception,
  
• guidelines d’ergonomie globales,
  
• ton, lisibilité, hiérarchie de l’information.
  
  

On parle ici de doctrines, pas de composants figés.

‍

3. Les briques vraiment universelles

Typiquement :

• boutons (au sens contractuel, pas visuel),
  
• champs de formulaire de base,
  
• états (loading, erreur, vide),
  
• feedbacks utilisateur.
  
  

Peu de composants.
Mais des composants ultra stables.

‍

Ce que le master ne doit surtout pas faire

‍

Un design system master ne doit pas :

• imposer des patterns métier,
  
• couvrir tous les cas d’usage,
  
• dicter des comportements spécifiques à un produit,
  
• ralentir les équipes avec des validations lourdes.
  
  

Dès qu’un master devient trop prescriptif, il est contourné.
Toujours.

‍

Les déclinaisons : là où le design devient utile

‍

Les déclinaisons sont là où le design system prend réellement de la valeur.

On parle par exemple de :

• un design system “outil métier”,
  
• un design system “mobile”,
  
• un design system “site web / marketing”.
  
  

Chacune de ces déclinaisons :

• hérite du master,
  
• adapte les composants aux usages réels,
  
• introduit des patterns spécifiques.
  
  

Exemple : outil métier

Dans une déclinaison outil métier, on va retrouver :

• des tableaux complexes,
  
• des filtres avancés,
  
• des formulaires longs,
  
• des états d’erreur très explicites,
  
• une densité d’information élevée.
  
  

Ces patterns n’ont rien à faire dans un master, mais sont essentiels ici.

‍

Exemple : mobile

Côté mobile :

• contraintes fortes de performance,
  
• interactions tactiles,
  
• patterns OS natifs,
  
• composants spécifiques (gestures, navigation).
  
  

Forcer ces choix dans un système global serait contre-productif.

‍

Master et déclinaisons : qui décide quoi ?

‍

C’est souvent là que tout se joue.

Une règle simple fonctionne bien :

• le master fixe le cadre
  
• les déclinaisons décident de l’usage
  
  

Concrètement :

• le master définit les tokens, principes et garde-fous,
  
• les équipes produit déclinent selon leurs contraintes,
  
• les écarts sont visibles, documentés, assumés.
  
  

Le pire scénario étant :

• des écarts cachés,
  
• des hacks silencieux,
  
• des divergences non documentées.
  
  

Gouvernance : légère mais explicite

‍

Un design system multi-apps ne survit pas sans gouvernance.
Mais cette gouvernance doit être simple.

Quelques principes efficaces :

• un petit noyau responsable du master,
  
• des référents design par déclinaison,
  
• des points réguliers de synchronisation,
  
• des décisions tracées (même imparfaites).
  
  

Pas besoin d’un comité de validation à rallonge.
Mais besoin de clarté.

‍

Le vrai enjeu : servir les produits, pas l’inverse

‍

Un design system n’est pas un objectif.
C’est un outil.

S’il :

• ralentit les équipes,
  
• empêche l’adaptation aux usages,
  
• génère plus de friction que de valeur,
  
  

alors il échoue, peu importe sa qualité théorique.

Un bon design system dans un groupe :

• accepte la diversité,
  
• cadre sans enfermer,
  
• évolue avec les produits.
  
  

Conclusion

‍

Dans un groupe avec de nombreuses applications, la bonne structure n’est ni :

• un design system unique et rigide,
  
• ni une jungle de systèmes indépendants.
  
  

C’est un socle commun clair,
et des déclinaisons assumées, proches des usages réels.

Master et déclinaisons ne s’opposent pas.
Ils se complètent.

Et quand c’est bien fait, le design system devient un accélérateur, pas un frein.

‍