Un design system, pour ne pas vous attacher au hasard

Un client nous envoie, une par une, les nouvelles maquettes de son formulaire d'onboarding. Cinq étapes, générées avec une IA, reçues au compte-goutte sur deux semaines. Chaque écran est propre, chaque écran a l'air fini, et chacun ressemble au précédent.

Puis on les pose côte à côte. Cinq nuances de bleu. Deux façons de faire une carte : avec un bandeau foncé en en-tête, ou sans aucune séparation entre le titre et le contenu. Trois arrondis différents. Des badges tantôt pleins, tantôt pastel. Le client voit une famille d'écrans. Nous, on voit cinq systèmes incompatibles, et une question qu'on n'ose pas trop poser : laquelle des cinq est la bonne ?

Ce que vous avez décidé, ce que l'IA a comblé

En mars, j'écrivais sur LinkedIn que l'IA avait fait tomber le principal risque du sur-mesure : on co-crée des maquettes interactives en direct avec nos clients, la boucle de feedback est immédiate, on se comprend enfin. Je le pense toujours. Mais je découvre l'effet secondaire.

Quand vous demandez à ChatGPT ou à Lovable une carte avec un titre, un badge et un bouton, vous avez décidé trois choses. L'outil, lui, en a décidé trente : l'ombre, l'arrondi, l'espacement, la nuance exacte du bleu, le fond de l'en-tête, la taille du badge. Il a comblé les blancs, et proprement.

Le problème, c'est que dans la maquette, rien ne distingue vos trois décisions de ses trente inventions. Et comme le modèle n'a aucune mémoire d'une conversation à l'autre, il comble les blancs autrement à chaque fois. Cinq conversations, cinq versions. La cohérence était impossible dès le départ.

Le dessin au marqueur protégeait la conversation

Il y a cinq ans, ce même client nous aurait envoyé une description, ou un croquis. Quelque chose d'assez éloigné du résultat pour que personne n'imagine le suivre à la lettre. Le développeur « intégrait » la demande dans l'application existante, comme on dit dans le métier.

Chez Basecamp, ils ont un nom pour ça : les fat marker sketches, dessinés au marqueur épais exprès pour qu'on ne puisse pas y mettre de détails. Leur raisonnement est celui-ci : les gens prendront chaque détail de la maquette comme une consigne, même si ce n'était pas votre intention.

Ce flou-là a disparu. La haute fidélité ne coûte plus rien, et le vernis n'est plus le signe d'un choix réfléchi. Résultat paradoxal : plus la maquette est précise, plus on discute de détails que personne n'a choisis.

- « Tu peux mettre l'ombre exactement comme sur la maquette ? »

On peut, oui. Mais est-ce vraiment nécessaire ? 

Ajoutez-y un biais bien documenté, l'effet IKEA : on surévalue ce qu'on a assemblé soi-même, et vingt prompts itérés un dimanche soir, c'est de l'assemblage. C'est humain. Mais c'est là que renaissent les allers-retours qu'on croyait avoir supprimés. Parce qu'on s'attache à des détails avec peu d'importance.

Un design system, c'est des décisions prises une fois

La définition la plus simple que je connaisse : un design system, c'est la liste des décisions visuelles prises une fois pour toutes, pour qu'il ne reste plus de blancs à combler. Quelle nuance de bleu, une seule. Quel arrondi pour une carte. Est-ce qu'un en-tête de carte a un fond de couleur. Comment s'écrit un badge « en attente ». Les designers d'Airbnb parlaient d'un langage visuel : et s'il n'est pas partagé par tous ceux qui l'utilisent, il crée des malentendus. Le design system, c'est ce langage, ce référentiel commun.

Le développeur, lui, n'a jamais été libre, même si le client ne le voyait pas. Quand il intégrait votre croquis, il le traduisait dans un système qui existait déjà. Cette contrainte invisible, c'est ce qui rendait vos écrans cohérents sans que vous ayez à y penser. Aujourd'hui, vos maquettes arrivent dans une autre langue, avec un accent différent à chaque conversation.

La démonstration

Pour illustrer le problème, j'ai fait générer un parcours d'onboarding en trois étapes, dans trois conversations séparées, avec le même brief fonctionnel et une seule description du style, en quatre lignes : marine, turquoise, fonds clairs, coins arrondis, ombres douces.

Résultat : deux bleus marine différents, trois arrondis différents, des badges pleins sur un écran et pastel sur les deux autres, un indicateur d'étapes redessiné à chaque fois. Mon client, reproduit en laboratoire.

Puis j'ai recommencé en fournissant un design system à chaque conversation : la liste des couleurs, espacements et arrondis autorisés, le catalogue des composants, un document de règles, et une consigne. N'invente rien ; si quelque chose manque, signale-le. Trois conversations, trois écrans qui se ressemblent comme des frères. Et les manques listés en fin de page au lieu d'être improvisés. C'est cette conversation-là qu'on veut avoir avec un client : « il vous manque un composant, on le décide ensemble ».

Ce que vous pouvez demander à votre prestataire

Si vous travaillez avec une agence ou un développeur, demandez le design system dès les premières semaines du projet. Chez Sparkle.tech, on le remet au client pour qu'il le donne à son IA. Une maquette générée dans le système est une proposition qu'on peut intégrer le jour même. Une maquette générée en dehors est une liste de questions.

Si vous n'avez pas de prestataire, vous pouvez dès maintenant créer votre propre design system. Trois conseils :

• Demandez à votre IA une maquette en HTML (une vraie page web) plutôt qu'une image. Une image, la conversation suivante ne peut que l'imiter de loin. Une page web contient les valeurs exactes de chaque couleur et de chaque espacement, et la prochaine pourra les réutiliser telles quelles.
• Faites-lui écrire deux documents que vous garderez : un texte lisible (vos couleurs, vos règles, ce qu'on fait et ce qu'on ne fait pas) et le fichier de style qui va avec. Déposez-les dans un Projet ChatGPT ou Claude : ils seront présents dans chaque nouvelle conversation, sans que vous ayez à les recoller.
• Ajoutez une règle à vos demandes : « N'invente aucune couleur, ombre ou espacement. Si un besoin n'est pas couvert, ne l'improvise pas, liste-le dans une section Hors système en fin de page. » Cette liste, c'est ce que vous enverrez à votre développeur.

Ce ne sera pas top du premier coup. Itérez, donnez des références comme inspiration. Mais continuez à faire évoluer cette même documentation de référence.

Vous pouvez également utiliser des skills dédiés à la création de design systems (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill)

Vibe coder avec un cadre

Vous avez raison de vibe-coder vos maquettes. Elles nous font gagner des semaines sur le quoi. Mais avant de les envoyer, demandez-vous ce que vous avez réellement décidé dedans. Défendez ça. Le reste, c'est l'affaire du design system.

La prochaine fois qu'un client voudra m'envoyer cinq écrans, je lui enverrai d'abord un design system.

Sources :
Basecamp, Shape Up — Find the Elements ·
Norton, Mochon & Ariely, The IKEA effect: When labor leads to love, Journal of Consumer Psychology, 2012 ·
Karri Saarinen, Building a Visual Language, Airbnb Design, 2016 ·
ACM Interactions, Rethinking Prototype Fidelity in the Age of Generative AI, juillet-août 2026 ·
Brad Frost, Design systems in the time of AI, 2023.