Vous n'avez pas besoin d'un design system
La plupart des équipes qui livrent un design system jouent à la maturité. Le coût de maintenance dépasse le gain, la génération par IA fait s'effondrer le calcul, et une pile tokens + primitives + goût bat un système entièrement spécifié pour 95 % des organisations.
Vous n'avez probablement pas besoin d'un design system. Il vous faut quelques design tokens, une petite bibliothèque de composants, et quelqu'un dans l'équipe qui a du goût. Le truc dont votre compte Twitter design préféré nous rebat les oreilles, le fichier Figma avec 400 composants publiés et 12 thèmes, c'est un produit à plein temps que votre startup de huit personnes finance sans jamais en toucher les dividendes.
C'est le constat que tout le monde dans l'industrie sait vrai et que personne ne dit à voix haute. La facture de maintenance est bien réelle. Le gain est surtout imaginaire. La génération par IA vient d'élargir encore l'écart entre les deux.
Les 95 % d'équipes qui livrent un design system jouent à la maturité. Les 5 % qui en ont vraiment besoin ne sont généralement pas celles qui posent la question.
Un design system est un produit, pas une quête secondaire
Un vrai design system a sa propre roadmap, son propre changelog et ses propres clients. Ces clients, ce sont les ingénieurs et les designers qui livrent le produit réel. Si personne n'est affecté à la maintenance du système, ce n'est pas un système. C'est un instantané.
Regardez qui livre bien des design systems. Stripe a une équipe d'infra design dédiée. Shopify Polaris a sa propre organisation. GitHub Primer a un dépôt public avec des versions publiées.
Atlassian investit depuis des années dans un système dont la portée restera hors d'atteinte pour la plupart des équipes. Chacun est une équipe produit qui construit des outils pour une base de clients internes se comptant en milliers.
Maintenant, regardez la version typique. Un designer senior a passé six semaines dans Figma, publié 80 composants, rédigé une page Notion qu'aucun ingénieur ne lit, et livré deux thèmes. Six mois plus tard, la moitié des composants sont périmés, les tokens dérivent par rapport au code, et l'équipe est retournée à copier des classes Tailwind. Le système n'a pas échoué. L'équipe n'a pas su le staffer.
La facture de maintenance que personne ne met dans la présentation
Le discours sur le gain, c'est : on le construit une fois, on le réutilise pour toujours. Le vrai calcul : on le construit une fois, puis on le maintient pour toujours, et on en réutilise une partie de temps en temps.
Chaque design token existant doit rester synchronisé entre Figma et le code. Chaque variante de composant doit être testée à chaque mise à jour du framework. Chaque breaking change dans Radix, React ou Tailwind se répercute sur tous les produits dépendants. La documentation pourrit en un trimestre.
L'instance Storybook casse après une mise à jour de dépendance et personne ne s'en aperçoit pendant trois semaines. La bibliothèque Figma publiée a une version de retard sur le code. Les thèmes divergent. Les composants du système ne sont pas ceux du produit.
Le vrai décompte est le suivant. Un « système » de six composants peut faire gagner du temps pour de bon. Un système de 200 composants dans une entreprise de 12 personnes est une taxe. Les heures de gain sont linéaires, les heures de maintenance se cumulent, et à un moment les courbes se croisent. La plupart des équipes franchissent ce point sans le voir, parce que la maintenance se manifeste en messages Slack du vendredi après-midi plutôt qu'en ligne de compte de résultat.
La génération par IA vient de faire s'effondrer le calcul
Tout l'argumentaire du design system reposait sur un seul chiffre : le coût de production d'un nouveau composant bien stylé. Ce chiffre est désormais une erreur d'arrondi.
Un ingénieur junior peut taper « donne-moi une page de paramètres avec une barre latérale, trois sections et une barre d'enregistrement qui suit le pattern d'état de chargement » et livrer un composant fonctionnel en vingt minutes. v0 génère par défaut du code façon Shadcn. Cursor et Claude peuvent refactoriser tout un parcours à partir des primitives existantes. Le gain qu'offrait autrefois un design system, la génération rapide d'une UI d'apparence cohérente, est maintenant un service gratuit fourni par tous les IDE du marché.
La taxe du système n'a pas bougé. Le gain s'est effondré. Voilà toute l'histoire. Les équipes qui ont construit des design systems en 2022 pour produire plus vite sont désormais plus lentes que celles qui livrent Shadcn + Tailwind + un prompt, parce que tous les outils d'IA ont été entraînés sur le second et ignorent le premier.
Les 5 % qui ont vraiment besoin d'un design system
Un vrai design system ne s'amortit que lorsqu'un ensemble précis de conditions sont toutes réunies. Il en manque une et le calcul s'écroule.
- Plusieurs produits partageant une seule identité. Atlassian a Jira, Confluence, Trello et une douzaine d'autres. Une identité, de nombreuses surfaces. Le système est la couche d'unification.
- Des effectifs en centaines, pas en dizaines. En dessous de 50 ingénieurs produit, chaque composant est à un message Slack d'un correctif. Au-dessus de 200, cela ne passe plus à l'échelle et un système devient la seule voie.
- Une équipe design ops ou design infra staffée. Un design system sans responsable est un cimetière. Ce responsable doit être un vrai rôle, pas un projet à 20 % du temps.
- Des consommateurs externes. Les design systems open source comme GitHub Primer ou Shopify Polaris sont aussi des produits destinés aux développeurs. Le coût de maintenance est justifié par l'adoption externe.
- Un domaine réglementé ou très exigeant en accessibilité. Santé, finance, administration. Le système encode la conformité et la préparation aux audits, un gain qu'aucune équipe isolée ne peut reproduire.
Si une équipe coche les cinq cases, un design system est le bon choix. Si elle en coche une ou deux et livre un seul produit avec 40 ingénieurs, un design system relève du cosplay. L'article sur l'anti-dashboard traite d'un schéma voisin : construire l'infrastructure pour une taille d'organisation que vous n'avez pas encore.
Le système visuel minimum viable
Pour les 95 %, la réponse est une pile à trois couches qui ne coûte presque rien à maintenir et produit presque le même résultat.
| Couche | Ce que c'est | Outils | Coût de maintenance |
|---|---|---|---|
| Tokens | Couleur, typo, espacement, rayon, ombre sous forme de variables | Config Tailwind, variables CSS, variables Figma | Faible. Un seul fichier. Mis à jour chaque trimestre. |
| Primitives | Composants headless ou stylés, accessibles par défaut | Shadcn, Radix, Headless UI, primitives Cal.com | Faible. Vendorisées, pas maintenues. Mise à jour à la demande. |
| Goût | Une personne qui sait quand enfreindre les règles | Un designer senior ou un ingénieur cultivé en design | Gratuit si vous recrutez bien, infini sinon. |
Voilà toute la pile. Les tokens apportent la cohérence. Les primitives apportent l'accessibilité et le comportement. Le goût apporte la couche qu'aucun système ne sait encoder : le jugement sur le moment où les règles doivent plier.
Les équipes qui livrent les produits les plus propres en 2026 utilisent une version de ça. Linear tourne sur un minuscule jeu de tokens, des primitives maison et un goût obsessionnel. Vercel livre une grosse config Tailwind plus ses propres primitives.
Cal.com publie ses primitives publiquement. Resend et Loops livrent une UI façon Shadcn avec des tokens maison par-dessus.
Notion tourne sur un petit jeu de tokens et un vocabulaire de composants volontairement serré. Aucun d'eux n'a un « design system » au sens d'Atlassian. Tous ont une pile de site marketing plus cohérente que celle d'entreprises dix fois plus grandes.
Pourquoi Shadcn dévore la catégorie des design systems
Shadcn n'est pas une bibliothèque de composants. C'est un mécanisme de distribution pour le nouveau standard. Les primitives sont vendorisées dans le code, stylées avec Tailwind, et accessibles parce que Radix fait le gros du travail en dessous. L'utilisateur possède les composants, peut les modifier librement, et n'est jamais bloqué par des versions en amont.
C'est le coup fatal pour la plupart des design systems internes. Si les équipes construisaient les leurs, c'était pour le contrôle. Shadcn offre ce contrôle gratuitement. Si les équipes livraient des Storybooks, c'était pour la découvrabilité.
Shadcn publie sa doc publiquement et les outils d'IA l'indexent. Si les équipes publiaient des bibliothèques Figma, c'était pour la cohérence. Les primitives Shadcn sont assez cohérentes pour que tout prompt qui s'y appuie produise un résultat que l'équipe sait déjà évaluer.
Shadcn + Tailwind + un jeu de tokens, c'est la pile visuelle par défaut de 2026. C'est ce que produit par défaut chaque outil moderne de génération de code par IA. C'est ce que livre en premier toute nouvelle équipe produit. C'est le modèle primitives plus goût en deux dépôts et un fichier de config. Le design system comme artefact séparé, avec son propre pipeline de publication et sa propre équipe, est désormais le cas particulier.
Quand un vrai système finit par s'amortir
La version honnête de la question « a-t-on besoin d'un design system ? » est « a-t-on déjà franchi le seuil de maintenance ? »
| Signal | Besoin d'un système ? |
|---|---|
| Deux ingénieurs livrent des boutons incohérents la même semaine | Non. Ajoutez un fichier de tokens. |
| Trois produits partagent une marque et divergent visuellement | Peut-être. Commencez par des tokens partagés. |
| Plusieurs équipes livrent le même composant différemment chaque trimestre | Oui. C'est l'heure des primitives partagées. |
| Un composant précis est reconstruit par quatre équipes en six mois | Oui. Promouvez-le dans le système. |
| Intégrer un nouveau designer prend deux semaines car les conventions sont tribales | Oui. Le système devient un gain. |
| Des développeurs externes consomment vos composants | Oui. Le système est un produit. |
| Des audits de conformité ou d'accessibilité arrivent sur votre roadmap | Oui. Encodez-le une fois. |
Si une équipe coche trois signaux ou plus, un vrai système est justifié. Si elle en coche un, un fichier de tokens suffit. La même logique apparaît dans la façon dont le problème de la page de tarifs et l'onboarding sans onboarding résolvent la coordination au niveau de la surface plutôt qu'au niveau du système.
Le schéma, puis la chute
Le flex de maturité est à l'envers. Les équipes qui livrent les produits les plus cohérents en 2026 ne sont pas celles qui ont les plus gros design systems. Ce sont celles qui ont la plus petite dette visuelle. Un jeu de tokens serré, une couche de primitives fine, et un designer de goût qui dit souvent non.
Les vrais design systems sont l'infrastructure d'organisations qui ont dépassé l'alternative. Ce n'est pas une étape que chaque équipe devrait atteindre. Ce n'est pas un symbole de statut. Ce n'est pas la réponse à « on veut faire plus professionnel ».
Une équipe qui en construit un avant d'avoir gagné le budget de maintenance livre le même produit sur une horloge plus lente avec un fichier plus lourd. Celle qui livre tokens + Shadcn + goût livre le même produit sur une horloge plus rapide et utilise le temps gagné pour régler plutôt le problème de la page de paramètres.
La question n'est pas « avons-nous un design system ? ». C'est « payons-nous la maintenance au bon niveau d'abstraction ? »
FAQ
Quelle est la différence entre un design system et une bibliothèque de composants ?
Une bibliothèque de composants est un ensemble de pièces d'UI réutilisables. Un design system, c'est une bibliothèque de composants plus des tokens, plus de la documentation, plus de la gouvernance, plus un responsable, plus un rythme de releases. La plupart des équipes livrent une bibliothèque de composants et l'appellent système. Ce n'est pas la même chose, et le second a un coût de maintenance que la première n'a pas.
Shadcn est-il un design system ?
Non. Shadcn est un mécanisme de distribution de primitives. Les composants sont vendorisés dans le code et appartiennent à l'équipe. Il n'y a ni bibliothèque centrale, ni calendrier de releases en amont, ni gouvernance.
C'est tout l'intérêt. Il donne à l'équipe le gain d'un système sans la facture de maintenance.
Quand une startup doit-elle investir dans un design system ?
Quand au moins trois de ces conditions sont vraies : plusieurs produits partageant une identité, plus de cinquante ingénieurs qui livrent de l'UI, un rôle design ops staffé, des consommateurs externes des composants, ou un domaine réglementé. En dessous de ce seuil, livrez tokens + primitives + goût et investissez les heures économisées dans le produit lui-même.
CTA
Vous voulez un produit dont le système visuel correspond à la taille de l'équipe ? Brainy livre des piles tokens + primitives pour les 95 % et des design systems complets pour les 5 %, calibrés sur le budget de maintenance réel. Engagez Brainy. Nous vous dirons de quel côté de la ligne vous êtes avant que vous ne passiez un trimestre sur le mauvais artefact.
Want a product where the visual system matches the team size? Brainy ships tokens-plus-primitives stacks for the 95% and full design systems for the 5%, calibrated to the actual maintenance budget.
Get Started
