Chez ExpertItLab, on a consacré plus de six mois de travail intensif en 2023 à concevoir ce qu'on croyait être le design system modèle. On avait modélisé près de quatre-vingts composants modulaires dans Figma, documenté chaque comportement dans Storybook, et mis en place une taxonomie très stricte de variables et de design tokens pour harmoniser nos typographies, espacements, bordures et états de surface. On était fiers de notre cathédrale visuelle. On promettait aux développeurs comme aux designers qu'à partir de ce jour, assembler une nouvelle interface ne prendrait plus que quelques minutes d'assemblage harmonieux.
Un an plus tard, l'équipe produit a voulu tester une nouvelle approche pour simplifier radicalement l'accueil de nos utilisateurs sur smartphone. L'objectif était de tester en conditions réelles un sélecteur interactif inédit permettant de filtrer les devises et les moyens de paiement locaux d'un seul geste du pouce.
Ce qui aurait dû être esquissé en un après-midi et codé en deux jours s'est transformé en un calvaire de trois semaines. Pourquoi ? Parce que ce sélecteur n'existait pas dans notre bibliothèque officielle de composants.
Deux designers et un développeur front-end chevronné ont passé huit réunions formelles à débattre de la manière d'intégrer ce nouvel élément dans l'arbre hiérarchique des composants, de son nommage officiel et de son impact sur la grille responsive globale. Pendant ces trois semaines de discussions internes stériles, aucun utilisateur réel n'a pu poser les yeux sur notre idée.
C'est là qu'on a pris conscience de la dérive : quand le maintien minutieux d'un design system devient-il plus lourd et bureaucratique que la création des parcours utilisateurs qu'il est censé accélérer ?
La tentation de la perfection abstraite contre le pragmatisme produit
Le design system attire naturellement les esprits rigoureux. C'est un terrain de jeu intellectuel fascinant où l'on range, aligne, structure et élimine toute ambiguïté visuelle. Mais ce goût de l'ordre parfait engendre un piège insidieux : on finit par concevoir pour le système lui-même, plutôt que pour les personnes qui utilisent le produit fini.
Au fil des mois, notre équipe de design s'est mise à consacrer 40 % de son temps hebdomadaire à des tâches de jardinage interne : renommer des calques Figma, harmoniser des micro-variations de gris entre trois boutons d'action secondaire, et arbitrer des querelles de clocher sur la sémantique d'un token de marge interne. Pendant que nos designers peaufinaient l'architecture de leurs composants à huis clos, des problèmes d'expérience bien plus urgents restaient en souffrance sur le terrain : des formulaires d'inscription confus, des messages d'erreur incompréhensibles pour nos clients et des taux d'abandon élevés sur les étapes de paiement.
Le design system est devenu une fin en soi. Une équipe qui produit des composants parfaits mais ne résout pas les frictions de ses utilisateurs est comme une usine qui fabrique de magnifiques boulons standardisés sans jamais construire la moindre machine utile.
L'asphyxie de l'exploration rapide et la peur de dévier de la norme
La créativité en matière d'interface utilisateur naît de l'itération rapide, du brouillon jetable et de la friction avec la réalité. Pour trouver la meilleure manière de présenter une information complexe à un utilisateur, un designer doit pouvoir dessiner dix variantes imparfaites, les confronter à cinq personnes dans un couloir ou lors d'un test rapide, et jeter neuf d'entre elles sans remords.
Dès lors qu'un design system devient la norme incontournable et obligatoire pour toute maquette, ce processus exploratoire est tué dans l'œuf. Nos designers n'osaient plus sortir des sentiers battus. Face à un problème nouveau, leur premier réflexe n'était plus de se demander "quelle est l'interface la plus claire pour l'utilisateur ?", mais "quel composant préexistant de notre catalogue peut-on recycler pour ne pas avoir à créer un nouvel élément ?".
Cette contrainte psychologique a appauvri nos interfaces. On a forcé des parcours métiers spécifiques à entrer dans des moules génériques inadaptés, sous prétexte d'homogénéité visuelle. Pire encore, dès qu'une entorse semblait nécessaire, la charge administrative requise pour faire valider une exception décourageait les initiatives. Les équipes préféraient livrer une solution médiocre mais conforme au catalogue plutôt qu'une excellente solution nécessitant de faire évoluer le système.
Le gouffre de synchronisation entre l'outil de design et la réalité du code
L'autre grande désillusion réside dans le fantasme de la synchronisation parfaite entre Figma et le code source de production. Même avec les meilleurs outils de documentation contemporains, maintenir deux représentations vivantes d'une même interface réclame une énergie monumentale.
Dans la pratique quotidienne, un composant codé en React, Vue ou Flutter subit des ajustements constants pour répondre à des contraintes techniques imprévues : gestion du rendu côté serveur, prise en compte des polices système sur les appareils d'entrée de gamme, gestion des textes traduits qui débordent, ou gestion des états de chargement dégradés sur un réseau mobile instable. Très vite, le composant Figma et le composant en production divergent.
On s'est retrouvés à devoir consacrer un temps fou à des séances de rattrapage où les designers demandaient aux développeurs d'ajuster des bordures de deux pixels, pendant que les développeurs reprochaient aux designers de concevoir des maquettes idéalisées ne tenant pas compte des contraintes réelles du DOM ou des navigateurs mobiles anciens. Cette friction permanente a usé la complicité naturelle qui doit exister entre développeurs et designers.
La règle salutaire des trois occurrences : décentraliser le design system
La solution n'est pas de jeter le design system aux orties, mais de lui redonner sa juste place d'outil de commodité au service de la vitesse, et non de douane préalable.
Pour sortir de cette paralysie, nous avons adopté une règle empirique qui a tout transformé chez nous : la règle des trois occurrences. Un composant n'a pas le droit d'entrer dans notre design system central tant qu'il n'a pas été conçu, testé et validé avec succès dans au moins trois écrans ou fonctionnalités métier distinctes en production.
Tant qu'une idée est jeune, elle appartient au projet local. Les designers sont libres de créer des éléments sur mesure, de casser les codes existants, de tester des agencements surprenants avec du code rapide et jetable. Ce n'est que lorsqu'une solution graphique prouve son efficacité durable et récurrente qu'elle est raffinée, documentée et intégrée dans la bibliothèque partagée. On est ainsi passés d'un modèle prescriptif descendant à un modèle descriptif ascendant. Le design system redevient la conséquence heureuse d'un produit qui marche, au lieu d'en être le préalable obligatoire qui ralentit tout.
Chez ExpertItLab, on a changé d'avis sur la valeur réelle d'un design system. On a cessé de mesurer sa réussite au nombre de composants documentés sur nos plateformes ou à la complétude esthétique de notre fichier Figma principal.
Aujourd'hui, notre bibliothèque centrale a été réduite de moitié. On a supprimé des dizaines d'organismes complexes et de variations théoriques pour ne conserver qu'un socle compact d'éléments essentiels : notre grille typographique, notre palette de couleurs fondamentales, nos champs de saisie élémentaires et nos boutons d'action. Tout le reste est géré au plus près des besoins du produit, dans des bacs à sable d'équipe où la vitesse d'expérimentation prime sur l'uniformité rigide.
Depuis cette cure d'amaigrissement, le délai nécessaire pour concevoir et mettre en ligne une nouvelle expérience utilisateur a été divisé par deux. Nos designers ont retrouvé le plaisir d'inventer des solutions vivantes au lieu de gérer un catalogue de pièces détachées, et nos développeurs ne perdent plus leurs journées à débattre du nommage de tokens invisibles pour l'utilisateur final.
Voici la question qu'on soumet à chaque équipe de design : votre système est-il aujourd'hui un tremplin qui propulse la mise sur le marché de vos idées, ou est-il devenu une armure si lourde et étouffante que vos créatifs ne peuvent plus courir ?
