Un design system est un ensemble de standards partagés (règles visuelles, composants d’interface réutilisables et modèles d’écrans) qui permet de concevoir des interfaces cohérentes, plus vite. Pour des applications internes, il devient rentable dès que l’entreprise prévoit plusieurs outils ou plusieurs années d’évolution : les mêmes tableaux, formulaires, filtres et écrans de détail reviennent partout. Bien construit, il réduit le temps de conception de chaque écran, uniformise l’expérience des équipes et intègre l’accessibilité une fois pour toutes.
Ce guide explique ce que contient un design system, quand il se justifie pour une PME ou une ETI, et comment le démarrer sans en faire un projet à part entière.
Qu’est-ce qu’un design system, concrètement ?
Le Nielsen Norman Group le définit comme un ensemble complet de standards destiné à gérer la conception à grande échelle, en s’appuyant sur des éléments partagés et réutilisables. On y trouve trois choses :
- un guide de style : principes de conception, règles visuelles, ton des messages ;
- une bibliothèque de composants : boutons, champs, listes déroulantes, tableaux, chacun avec son nom, ses variantes, ses états et son code ;
- une bibliothèque de modèles : des assemblages récurrents (un formulaire de recherche, une page liste et détail, un tableau de bord).
La méthode Atomic Design de Brad Frost propose une façon claire de penser cet assemblage, en cinq niveaux : les atomes (un champ, un libellé, un bouton), les molécules (un champ de recherche avec son bouton), les organismes (un en-tête complet), les gabarits (la structure d’une page) et les pages (le gabarit rempli de contenus réels).
Un design system n’est pas une charte graphique. La charte définit une identité ; le design system la transforme en briques d’interface prêtes à l’emploi, codées et documentées.
Pourquoi c’est particulièrement utile pour les outils internes
On associe souvent les design systems aux grands produits grand public. Pourtant, les applications métier en tirent un bénéfice au moins aussi grand, pour trois raisons.
Les mêmes motifs reviennent partout. Un CRM, un back-office de commandes et une application de planification affichent tous des listes filtrables, des fiches détaillées, des formulaires de saisie et des actions groupées. Les concevoir une fois, bien, profite à tous les outils.
Les utilisateurs passent d’un outil à l’autre. Une assistante commerciale qui jongle entre trois applications perd du temps si le bouton « Enregistrer » change de place et de couleur à chaque fois. La cohérence réduit les erreurs et la formation.
Les outils internes vivent longtemps. Le NN/g précise qu’un design system est surtout pertinent quand l’entreprise prévoit des années de conception reproductible. C’est exactement le profil d’un parc d’applications internes, qui évolue pendant de longues années.
À l’inverse, pour un prototype jetable ou une application unique qui ne bougera plus, un design system complet ne se justifie pas. Une petite bibliothèque de composants suffit.
Les trois couches d’un design system
Les design tokens
Un design token est une décision de conception nommée : couleur-action-principale, espacement-moyen, rayon-bordure-carte. Plutôt que d’écrire une valeur en dur dans chaque écran, on y fait référence par son nom. Changer la couleur principale revient alors à modifier un seul token.
Le sujet a franchi une étape importante : le Design Tokens Community Group, hébergé par le W3C, a publié en octobre 2025 la première version stable de son format d’échange. Elle définit un token comme une information associée à un nom lisible, au minimum une paire nom et valeur, décrite dans un fichier JSON. Concrètement, les outils de maquette et le code peuvent désormais partager les mêmes décisions sans ressaisie.
Les tokens ont un intérêt particulier pour une ETI multi-marques ou un éditeur de SaaS : changer de jeu de tokens suffit à décliner les mêmes composants aux couleurs d’une filiale ou d’un client, comme dans un SaaS B2B multi-tenant.
La bibliothèque de composants
C’est le cœur du système : des composants codés, testés et documentés, que les développeurs assemblent au lieu de les réécrire. Pour chaque composant, la documentation précise :
- son rôle et quand l’utiliser (et quand ne pas l’utiliser) ;
- ses variantes (principal, secondaire, danger) ;
- ses états (normal, survol, focus, désactivé, chargement, erreur) ;
- ses règles d’accessibilité ;
- un exemple de code.
Les modèles d’écrans métier
C’est la couche la plus rentable pour des applications de gestion, et souvent la plus oubliée. Une « page liste » standard (recherche, filtres, tri, pagination, actions groupées, export), une « fiche détail » avec historique, un « assistant de saisie en plusieurs étapes » : ces modèles réutilisés d’outil en outil font gagner un temps considérable en conception comme en développement.
L’accessibilité intégrée une fois pour toutes
Un design system est le meilleur levier pour rendre un parc d’applications accessible. Si le composant « bouton » respecte les règles, tous les boutons de tous les outils les respectent. Quelques exigences des WCAG 2.2 se traitent naturellement au niveau des composants :
| Exigence WCAG 2.2 | Ce que le design system garantit |
|---|---|
| Contraste minimal du texte (critère 1.4.3, ratio 4,5:1 pour le texte courant) | Des tokens de couleur vérifiés, impossibles à combiner de façon illisible |
| Accessibilité au clavier (critère 2.1.1) | Chaque composant interactif utilisable sans souris |
| Focus visible (critère 2.4.7) | Un style de focus défini une fois pour tous les composants |
| Taille minimale des cibles (critère 2.5.8, 24 par 24 pixels CSS) | Des boutons et icônes cliquables suffisamment grands |
| Étiquettes et instructions (critère 3.3.2) | Des champs de formulaire toujours accompagnés d’un libellé |
C’est d’autant plus utile que les obligations progressent, comme l’explique notre article sur l'European Accessibility Act et le RGAA. En France, l’administration dispose d’ailleurs de son propre Système de design de l’État (DSFR) ; au Royaume-Uni, le GOV.UK Design System est une référence publique souvent citée pour la qualité de sa documentation et de ses modèles.
Construire, adopter ou adapter ?
Comme pour les applications elles-mêmes, trois options existent. Le choix dépend du nombre d’outils et de leur caractère stratégique.
| Option | Principe | Adaptée quand |
|---|---|---|
| Adopter une bibliothèque existante | Utiliser une bibliothèque open source reconnue, avec ses composants par défaut | Une ou deux applications internes, besoin d’aller vite |
| Adapter une bibliothèque existante | Partir d’une base éprouvée, la personnaliser via les tokens et ajouter des composants métier | Plusieurs applications internes, identité à respecter, cas le plus fréquent en PME et ETI |
| Construire le sien | Concevoir et coder tous les composants | Produit commercialisé à forte identité, besoins très spécifiques |
Pour la plupart des PME et ETI, la deuxième option offre le meilleur équilibre. La logique rejoint celle de notre grille construire, acheter ou assembler : on ne réinvente que ce qui différencie.
Comment démarrer petit
L’erreur classique consiste à lancer « le projet design system » avant tout projet applicatif. Quelques mois plus tard, la bibliothèque compte des dizaines de composants, dont beaucoup ne serviront jamais. La bonne approche part du besoin réel.
- Inventorier l’existant. Faire des captures des écrans de vos outils actuels et regrouper les éléments similaires. Le nombre de variantes de boutons ou de tableaux est souvent éloquent.
- Définir les tokens de base : une palette restreinte, une échelle d’espacements, deux ou trois tailles de texte.
- Construire les composants du premier projet, et seulement ceux-là, en les documentant au fil de l’eau.
- Valider sur un prototype interactif avec de vrais utilisateurs avant de figer les composants.
- Réutiliser et enrichir à chaque nouvel outil, en promouvant au rang de composant commun ce qui apparaît dans deux applications.
- Désigner un référent qui valide les ajouts et empêche la prolifération de variantes.
Un design system qui n’est pas maintenu se dégrade comme n’importe quel code : variantes ajoutées à la hâte, composants dupliqués, documentation obsolète. C’est une forme de dette technique, qui se prévient par une gouvernance légère mais réelle.
Ce qu’il faut exiger de votre prestataire
Si vous faites développer plusieurs applications, posez la question dès le premier projet : les composants seront-ils réutilisables, documentés et livrés comme un actif de l’entreprise ? Trois points à vérifier :
- les composants vivent dans un paquet ou un dépôt distinct, réutilisable par d’autres applications ;
- la documentation (usage, états, accessibilité) est livrée avec le code ;
- les design tokens sont partagés entre les maquettes et le code, sans ressaisie.
Chez nous, chaque projet d'application web sur mesure ou d'intranet s’appuie sur une base de composants cohérente, que le client possède et peut faire évoluer.
Vous avez plusieurs outils internes à faire évoluer et voulez savoir si une base commune est pertinente dans votre cas ? Décrivez votre contexte dans notre diagnostic de projet en ligne, et nous revenons vers vous avec une première analyse.
