Design system : est-ce que ça vous concerne vraiment ?

Dans la plupart des PME, non. Et cette réponse mérite d’être posée d’emblée, parce que tous les contenus consacrés au sujet expliquent comment construire un design system, jamais s’il faut le faire.

Le cas de référence cité partout est celui d’une grande entreprise avec une équipe dédiée : chef de produit, spécialistes de l’expérience, développeurs, concepteurs d’interface. Ce n’est pas votre situation, et transposer leur solution à votre échelle revient à financer une organisation que vous n’avez pas.

Cette page ne vous apprendra donc pas à en créer un. Elle pose la question préalable : à partir de quel moment le besoin existe, ce que coûte la maintenance, et ce dont vous avez besoin à la place quand la réponse est non.

Ce qu’est réellement un design system

Un design system est un ensemble de composants d’interface réutilisables, avec leurs règles d’emploi et leur documentation, maintenu comme un produit à part entière.

Les contenus du sujet le distinguent d’une charte graphique en expliquant que l’une est statique et l’autre vivante. C’est un slogan, pas une différence opérante.

La vraie différence est le lieu d’exécution.

Une charte se lit et s’applique à la main. Quelqu’un ouvre le document, relève une valeur de couleur, la reporte dans son outil. Si la valeur change, il faut reprendre chaque support un par un.

Un design system s’exécute. Les valeurs sont centralisées et compilées, les composants sont versionnés, et une modification se propage partout où le composant est employé. C’est un objet technique autant que graphique.

La conséquence de cette définition est immédiate. Un fichier de maquettes, aussi bien rangé soit-il, sans chaîne de compilation ni composants intégrés au site, reste une charte graphique dans un autre outil. Beaucoup de ce qui se vend sous le nom de design system s’arrête exactement là.

La distinction entre charte, identité et plateforme est traitée séparément dans charte graphique et identité visuelle, les différences.

Le seuil de déclenchement, que personne ne formule

Aucune des pages consultées ne dit à partir de quand le besoin existe. Certaines l’esquivent explicitement, une autre affirme qu’un design system se justifie « dès que deux personnes travaillent ensemble », sans le moindre argument.

Le seuil ne se mesure pas en taille d’entreprise. Il se mesure au produit de trois facteurs.

Le nombre de surfaces à maintenir. Un site vitrine compte pour une. Un site plus une application, plus un espace client, plus un outil interne : quatre. C’est la multiplication des surfaces qui crée le besoin de cohérence, pas le nombre de pages.

La fréquence de modification. Un site refait tous les cinq ans ne pose aucun problème de cohérence. Un site modifié chaque semaine par plusieurs personnes en pose un.

Le nombre de mains. Une personne qui produit tout applique naturellement les mêmes règles. Cinq personnes réparties entre deux prestataires et une équipe interne divergent en trois mois.

Le test tient en une phrase. Si vous avez une surface, modifiée rarement, par une seule personne ou un seul prestataire, le besoin est nul et l’investissement serait une dépense pure. Il faut au minimum plusieurs surfaces, ou une fréquence élevée, ou plusieurs intervenants, et de préférence deux des trois.

Le coût que personne ne pose

Les contenus du sujet énumèrent les bénéfices et passent la maintenance sous silence, ou la mentionnent en une ligne. C’est pourtant là que se joue l’échec.

Un design system est un produit, pas un livrable. Il a des utilisateurs internes, des versions, des composants qui vieillissent, une documentation qui se périme. Sans quelqu’un pour le tenir, il devient en dix-huit mois un ensemble de composants dont personne ne sait lesquels sont encore valides.

Ce que montre la seule enquête sérieuse du domaine. L’enquête publiée par Sparkbox en 2022, sur 219 répondants dont 183 mainteneurs de systèmes, indique que 16 % seulement des organisations mesurent l’usage réel de leur système, que 39 % des utilisateurs jugent la documentation insuffisante, et que le manque de personnel dédié figure parmi les difficultés les plus citées. L’échantillon est auto-sélectionné, ce sont des organisations suffisamment structurées pour répondre à une enquête sur le sujet, et le tableau reste celui-là.

Ce que cela implique concrètement. Un système non maintenu n’est pas neutre, il est négatif : vos équipes hésitent devant des composants au statut incertain, et finissent par en créer de nouveaux à côté. Vous avez alors payé un système pour aggraver l’incohérence qu’il devait résoudre.

Aucune source indépendante ne publie de coût en France, et nous ne fabriquerons pas de fourchette pour combler ce vide. Ce qui est certain, c’est que la maintenance est un poste récurrent, à provisionner comme un abonnement plutôt que comme un projet.

Ce dont vous avez besoin à la place

Quand le seuil n’est pas franchi, trois éléments suffisent et coûtent une fraction du prix.

Une charte graphique orientée web. Pas un document de marque de quarante pages, mais les valeurs exactes dont un intégrateur a besoin : couleurs, échelle typographique, espacements, états d’interaction. Le cadrage de cette commande est traité dans faire faire sa charte graphique.

Un jeu de gabarits dans votre outil de publication. Trois à six modèles de pages réellement utilisés, verrouillés sur les bons styles. C’est ce qui empêche la dérive au quotidien, et cela vit dans l’outil où les gens travaillent plutôt que dans un document qu’ils n’ouvrent pas.

Une demi-journée de passation. La partie que tout le monde saute. Montrer aux personnes qui publieront comment employer les gabarits, et ce qu’il ne faut pas faire. Sans elle, vos commerciaux refont leurs présentations à leur façon en quelques semaines.

Un quatrième élément, si vous publiez souvent. Un jeu de composants réutilisables dans votre outil de publication, ce que la plupart des systèmes de gestion de contenu appellent des blocs. Ce n’est pas un design system au sens technique, puisque rien n’est compilé, mais cela couvre l’essentiel du besoin quotidien : la personne qui rédige assemble des blocs déjà conformes plutôt que de reconstruire une mise en page. C’est l’investissement au meilleur rendement pour une PME, et il se fait une fois.

Ce que cela ne vous donnera pas. La propagation automatique d’un changement. Si vous modifiez votre couleur principale, quelqu’un devra la reporter. À une surface et une refonte tous les cinq ans, c’est une heure de travail tous les cinq ans, à comparer au coût de maintenance permanent d’un système.

Le mot employé pour autre chose

Une difficulté pratique mérite d’être signalée, parce qu’elle fausse beaucoup de conversations avec les prestataires.

Le terme recouvre au moins trois objets différents selon qui l’emploie.

Un fichier de maquettes organisé. C’est le sens le plus courant chez les studios graphiques : une bibliothèque de symboles rangée, avec des styles nommés. Utile pour le travail de conception, sans effet sur le site tant que rien n’est compilé.

Une bibliothèque de composants intégrée au site. Le sens technique : des composants réels, versionnés, employés par le code qui produit vos pages. C’est ce qui procure la propagation, et c’est ce qui coûte cher à maintenir.

Une documentation de marque étendue au numérique. Le sens le plus large : un document qui décrit les principes, les composants et les usages, sans que rien ne soit exécutable.

Ce que cela implique pour votre devis. Demandez laquelle de ces trois choses vous est proposée, en la faisant décrire plutôt qu’en la faisant nommer. Les trois ont une valeur, les trois n’ont pas le même prix, et seule la deuxième mérite le budget de maintenance dont il est question plus haut. Une proposition qui ne permet pas de trancher entre les trois est une proposition à faire préciser.

Adopter plutôt que créer

Une option est presque toujours absente des discussions, et elle mérite d’être posée : reprendre un système existant au lieu d’en concevoir un.

Le système de design de l’État français est librement consultable, son code est publié en accès ouvert, et il est conçu pour des sites d’information et de service. Il apporte des composants testés, une documentation entretenue par une équipe permanente, et un traitement sérieux de l’accessibilité.

Ce que vous y gagnez. La conception, une partie de la maintenance, et la garantie que les composants ont été éprouvés ailleurs que chez vous.

Ce que vous y perdez. La distinction visuelle. Un site bâti sur un système public ressemble à d’autres sites bâtis dessus, ce qui est acceptable pour un service et discutable pour une marque qui vend sur sa différence.

L’arbitrage dépend donc de ce que vous vendez. Une entreprise dont l’offre se juge sur la précision technique perd peu à ressembler à un service public. Une entreprise dont l’offre se juge sur le soin apporté aux détails perd beaucoup. C’est une décision de positionnement, pas une décision technique, et elle rejoint ce qu’un dirigeant doit valider en direction artistique.

Si le seuil est franchi, par quoi commencer

Supposons que vous ayez plusieurs surfaces, des modifications fréquentes et plusieurs intervenants. Le besoin existe. Reste à ne pas le traiter comme un projet de refonte.

Commencez par ce qui casse le plus souvent. Pas par les couleurs et la typographie, qui sont les éléments les plus stables, mais par les composants où les divergences apparaissent : les boutons, les champs de formulaire, les cartes, les messages d’erreur. Ce sont eux que chacun redessine à sa façon.

Trois à cinq composants suffisent pour commencer. Un système qui démarre avec quarante composants n’est pas un système, c’est une bibliothèque que personne n’adoptera. Un système qui démarre avec cinq composants réellement employés partout crée l’habitude, et le reste suit.

Installez la propagation avant d’enrichir. Le test décisif : changez une valeur, et vérifiez qu’elle se répercute partout sans intervention manuelle. Tant que cette chaîne n’existe pas, ajouter des composants ne fait que grossir un document.

Nommez un responsable, une personne. Pas une équipe, pas un comité. Quelqu’un qui arbitre les ajouts et qui a le droit de refuser. Sans arbitre, le système se remplit par accumulation, exactement comme un plan de mesure ou une grille de benchmark.

Écrivez le statut de chaque composant. Actif, à remplacer, retiré. C’est l’information la plus utile et la plus souvent absente : une équipe qui ignore si un composant est encore valide en fabrique un nouveau à côté.

Prévoyez le budget de maintenance dès la première année, pas à partir de la deuxième. Un système livré sans ligne budgétaire pour son entretien est un système déjà condamné, et le moment où cela se voit est celui où plus personne ne sait à qui poser une question.

L’atomic design, cité de travers partout

Un mot sur la méthode que toutes les pages françaises invoquent, parce qu’elles la présentent à l’envers.

Elle est systématiquement décrite comme une séquence en cinq étapes : d’abord les atomes, puis les molécules, puis les organismes, puis les gabarits, puis les pages.

Son auteur écrit précisément le contraire. Brad Frost note que « atomic design is not a linear process, but rather a mental model », et demande explicitement de ne pas interpréter les cinq niveaux comme une suite numérotée d’étapes. Il ajoute que « atomic design is not rigid dogma ».

La nuance n’est pas académique. Appliquée comme une séquence, la méthode conduit à dessiner des boutons isolément en espérant que l’ensemble tienne à la fin, ce que Frost qualifie lui-même d’imprudent. Employée comme un modèle mental, elle sert à raisonner simultanément sur les parties et sur le tout.

Ce que cela vous dit d’un prestataire. Celui qui vous vend une méthode en cinq étapes numérotées n’a pas lu la source qu’il cite. Ce n’est pas disqualifiant en soi, c’est un signal sur la profondeur du travail.

Les trois façons dont un design system meurt

Elles sont documentées par l’expérience des équipes qui en maintiennent, et elles ne tiennent pas à la qualité du travail initial.

Il meurt d’un statut illisible. Les composants vieillissent, certains sont remplacés, d’autres abandonnés en cours de route. Si rien n’indique lesquels sont encore valides, chacun choisit par précaution de recréer le sien. C’est la mort la plus fréquente, et elle survient sans qu’aucune décision n’ait été prise.

Il meurt d’un écart entre la maquette et le code. Le fichier de conception évolue, le site ne suit pas, et au bout de quelques mois les deux décrivent des interfaces différentes. Les développeurs cessent alors de consulter la maquette, ce qui est rationnel puisqu’elle ment.

Il meurt d’une adoption jamais vérifiée. Personne ne mesure si les composants sont réellement employés. L’enquête déjà citée indique que 16 % seulement des organisations suivent l’usage de leur système. Sans cette mesure, un système peut être ignoré pendant un an sans que quiconque s’en aperçoive, jusqu’à la refonte suivante où l’on découvre que rien n’était appliqué.

Le point commun des trois. Aucune ne se produit le jour de la livraison. Elles s’installent en dix-huit à vingt-quatre mois, c’est-à-dire après le départ du prestataire qui a construit le système et souvent après le changement de la personne qui en avait la charge. C’est la raison pour laquelle la question de la maintenance doit être réglée au moment de la commande, quand vous avez encore un rapport de force.

Les chiffres qu’on vous montrera, et qui ne tiennent pas

Ce sujet est vendu à coups de gains de productivité. Nous avons cherché les sources, sans les trouver.

« 20 à 30 % d’économies sur les coûts de conception et de développement. » Attribué à un grand cabinet de conseil. Le rapport de ce cabinet que l’on peut consulter porte sur la valeur du design en général, pas sur les systèmes de conception, et ne contient pas ce chiffre.

« 42 % de productivité en plus pour les concepteurs », « 30 % de temps développeur économisé », « des cycles 40 % plus rapides. » Ces trois valeurs circulent ensemble, attribuées à un cas d’entreprise anonyme, sans méthode ni échantillon.

« Un retour sur investissement de 200 à 400 % la première année. » Attribué à des « études sectorielles » jamais identifiées.

« Un design system se justifie dès que deux personnes travaillent ensemble. » Assertion reprise en boucle, sans le moindre argument, et contredite par le simple bon sens : deux personnes qui publient trois pages par an n’ont aucun problème de cohérence.

Le point commun de ces chiffres. Ils décrivent tous des gains, jamais des coûts, et ils sont produits par des acteurs qui vendent la prestation. Cela ne les rend pas faux, cela les rend invérifiables, ce qui revient au même quand il faut décider.

Les trois questions à poser à un prestataire

Si l’on vous propose un design system, trois questions suffisent à savoir si la proposition tient.

À combien de surfaces s’appliquera-t-il ? Si la réponse est « votre site », le besoin ne justifie pas l’investissement, et un jeu de gabarits fera le travail.

Qui le maintiendra après la mission ? Si la réponse est vous, demandez avec quelles compétences et sur quel temps. Si la réponse est le prestataire, demandez à quel coût annuel, car c’est un abonnement.

Que se passe-t-il si nous arrêtons de le maintenir ? La bonne réponse est franche : il se dégrade et devient une gêne. Un prestataire qui répond qu’il n’y a pas de risque n’a pas d’expérience du sujet, ou ne dit pas tout.

Une quatrième question, plus générale, vaut pour toute proposition de ce type : qu’est-ce que je ne pourrai plus faire sans vous ? Un système de conception crée une dépendance, ce qui est acceptable quand le besoin existe et coûteux quand il n’existe pas. La question de la propriété des fichiers, elle, est traitée dans faire faire sa charte graphique.

Par où continuer, selon votre situation

Vous commandez une identité. Le cadrage, les livrables et la propriété : faire faire sa charte graphique.

Vous ne savez pas ce que recouvrent ces termes. Charte, identité, plateforme : les différences.

Vous préparez une refonte. Le bon moment, et les signaux qui le disent : quand refondre un site B2B.

Vous choisissez une technologie. Ce que chaque option implique pour la suite : quelle technologie pour un site B2B.

En bref

• Dans la plupart des PME, un design system ne se justifie pas. Le cas de référence cité partout suppose une équipe dédiée.
• Le seuil se mesure en surfaces, fréquence et nombre d’intervenants, pas en taille d’entreprise. Une surface, modifiée rarement, par une main : besoin nul.
• La différence avec une charte est le lieu d’exécution. Un fichier de maquettes sans chaîne de compilation reste une charte dans un autre outil.
• La maintenance est le point de rupture. Seules 16 % des organisations mesurent l’usage réel de leur système, et 39 % des utilisateurs jugent la documentation insuffisante.
• Un système non maintenu est négatif, pas neutre. Vos équipes créent de nouveaux composants à côté de ceux dont elles doutent.
• Trois éléments suffisent quand le seuil n’est pas franchi : une charte orientée web, des gabarits dans l’outil de publication, une passation.
• Les gains de productivité annoncés sont invérifiables. Aucun des chiffres qui circulent n’a de source consultable.

Si un prestataire vous propose un système de conception, commencez par compter vos surfaces. Parlons de votre projet, ou découvrez notre approche de la création de site web B2B.