L'uniformité est héritée, pas inventée
Il est tentant de décrire cela comme un problème de goût. Le modèle a vu un milliard de landing pages et régresse vers leur moyenne. Cela joue un rôle, mais ce n'est pas le mécanisme, et cela pousse les utilisateurs vers la mauvaise solution (de meilleurs prompts). Le mécanisme est plus banal et bien plus concret : un agent de code à qui l'on demande de construire une UI se tourne vers une bibliothèque de composants, et cette bibliothèque livre des valeurs par défaut. Ces valeurs ont été conçues pour être consensuelles, ce qui est précisément ce qui les rend universelles.
Demandez un tableau de bord à cinq outils différents (Claude Code, Cursor, v0, Lovable, Bolt), sans autre instruction. Vous obtiendrez cinq mises en page et une seule identité visuelle. Ils ne se copient pas les uns les autres. Ils font chacun, indépendamment, le choix le plus rationnel avec le même matériau de départ.
Voici la preuve par l'image plutôt que par le discours. Le premier onglet représente la moyenne statistique : indigo-500, un dégradé violet, Inter, cartes rounded-xl. Les autres onglets sont la *même page*, re-rendue via un véritable design system. Rien ne change dans la mise en page ; chaque différence que vous voyez provient du système.
Same app · different design system
The Default AI Look
Live renderIndigo-500, a purple gradient, Inter, rounded-xl cards. Nobody chose this: it's the statistical average of the training data, which is why everyone gets it.
Les quatre indices et leur origine
1. La rampe neutre
Le thème par défaut de shadcn/ui est basé sur l'échelle zinc de Tailwind, avec slate et gray comme alternatives courantes. C'est un gris froid, légèrement teinté de bleu. Une fois qu'on l'a remarqué, on ne voit plus que ça : c'est le fond de la plupart des produits créés par IA et lancés ces deux dernières années. C'est un neutre réellement efficace, et c'est là le problème. Il est assez bon pour que personne ne le remplace.
L'indice n'est pas le gris en soi, mais son *uniformité*. Une interface travaillée oriente généralement ses neutres légèrement vers la teinte de la marque, pour que les gris semblent liés à la couleur d'accentuation. Une interface par défaut utilise une rampe pure juxtaposée à un accent sans rapport, et les deux ne semblent jamais vraiment appartenir au même ensemble.
2. Inter, ou une police indiscernable
Inter est une excellente police pour l'UI, c'est pourquoi elle est partout et pourquoi elle est désormais perçue comme un défaut plutôt que comme un choix. Quand ce n'est pas littéralement Inter, c'est la pile système font-sans, qui aboutit à une grotesque quasi identique sur la plupart des machines. Dans les deux cas, la page utilise une seule famille pour tout : titres, corps de texte, labels, chiffres.
L'indice réside dans l'utilisation d'une seule famille, plus que dans la famille choisie. Un système conçu associe presque toujours : une police d'affichage avec du caractère pour les titres et une police utilitaire pour le corps, ou au minimum un contraste délibéré de graisse et de largeur au sein d'une même superfamille. Les pages à famille unique paraissent plates, même quand toutes les autres décisions sont justes.
3. `0.5rem` partout
Le --radius par défaut de shadcn est 0.5rem, et il se propage aux boutons, aux champs de saisie, aux cartes, aux dialogues et aux popovers. Un rayon uniforme pour toutes les tailles d'éléments n'est pas le comportement d'un système designé : un bouton de 44px et une carte de 400px avec le même rayon de coin rendent la carte trop douce et le bouton trop « bulbeux », car le rayon est perçu relativement à l'élément sur lequel il se trouve.
:root {
/* The line most AI-built projects never touch */
--radius: 0.5rem;
}4. La grille de trois cartes
Une section Hero, puis trois cartes égales, puis une bande de témoignages, puis un CTA. Ici, il s'agit d'une véritable force d'attraction des données d'entraînement plutôt que d'un défaut de configuration. C'est la structure de page marketing la plus courante sur le web, c'est donc la forme qu'un modèle produit quand le brief n'en suggère pas une autre. Ce n'est pas faux. C'est simplement la mise en page qui ne donne aucune information sur votre produit.
Pourquoi l'amélioration des prompts finit par échouer
La réponse courante est d'écrire un prompt plus long : *utilise une palette chaude, associe une police serif pour les titres et une grotesque pour le corps, varie le rayon.* Cela fonctionne. Cela fonctionne pour un écran, et généralement pour le deuxième et le troisième.
Ensuite, le résultat se dégrade, et d'une manière spécifique. L'agent n'ignore pas vos instructions. Il mène une conversation de plus en plus longue dans laquelle votre paragraphe de style entre en compétition avec tout ce qui a suivi. Au cinquième écran, il se souvient de *chaud* mais a perdu les valeurs hexadécimales, alors il improvise. L'improvisation donne un chaud légèrement différent. Le sixième écran improvise sur l'improvisation.
La dérive n'est pas l'oubli de l'instruction par l'agent. C'est l'agent qui s'en souvient approximativement, six fois de suite.
Ceux qui se trouvent dans cette situation appellent cela le *design drift* (dérive du design). C'est la raison pour laquelle une application codée « au feeling », qui semblait impeccable le vendredi, donne l'impression d'avoir été assemblée par un comité le lundi. L'instruction résidait dans la conversation, et les conversations s'estompent.
Le test pour distinguer ces deux modes de défaillance : ouvrez l'écran 1 et l'écran 8 côte à côte. S'ils divergent sur l'espacement et la couleur, mais que chacun est cohérent en interne, il s'agit d'une dérive. Si les deux sont incohérents en interne, c'est que le système n'a jamais été spécifié.
La solution est un fichier que l'agent relit, et non un paragraphe dont il se souvient.
Un design system stoppe la dérive pour la même raison qu'il la stoppe au sein d'équipes humaines : les valeurs résident dans un support durable et sont consultées, plutôt que d'être mémorisées par quelqu'un. Pour un agent de code, ce support est un fichier DESIGN.md associé à un ensemble de tokens dans le repo. Les deux sont relus au début de chaque session ; ainsi, l'écran 20 résout la même valeur --primary que l'écran 1, et non une valeur similaire.
| Dans le prompt | Dans les tokens + DESIGN.md | |
|---|---|---|
| Survit à une nouvelle session | Non : réinitialisation du contexte | Oui : relu depuis le repo |
| Précision après 10 écrans | Approximative (« plutôt chaud ») | Hex exact, à chaque fois |
| Revue possible via PR | Non | Oui. C'est un fichier qui permet le diff |
| Fonctionne entre les outils | À réécrire pour chaque outil | Même fichier pour Claude Code, Cursor, v0 |
C'est tout l'intérêt de fournir à un agent un véritable système plutôt qu'une meilleure description de celui-ci. La couche de tokens sémantiques importe plus que la palette : --primary et --muted-foreground survivent à un redesign, contrairement à un blue-600 dispersé dans le markup.
Token specimen · real values
Terrain Vivant
Live renderTerrain Vivant's actual tokens — the same values its exports use.
Ceux qui documentent leur système parviennent-ils réellement à échapper aux réglages par défaut ?
La plupart du temps non, et c'est le constat le plus dérangeant. Nous avons analysé 299 fichiers DESIGN.md publics sur GitHub — le fichier dont le rôle unique est d'empêcher cela — et mesuré leur contenu.
Parmi les 72 qui décrivent un design system visuel, 21 % spécifient une échelle de radius et 26 % spécifient l'élévation. Ce sont deux des quatre indicateurs mentionnés plus haut, laissés par défaut par trois quarts des personnes s'étant spécifiquement donné la peine d'écrire un contrat de design. 69 % omettent totalement le mode sombre, laissant l'agent inventer l'intégralité du second thème. Enfin, 86 % nomment les couleurs par leur teinte ou listent des hex bruts plutôt que d'utiliser des rôles sémantiques, ce qui signifie que le fichier ne peut être appliqué à aucun composant qu'il n'a pas explicitement décrit.
Les réglages par défaut survivent aux tentatives de remplacement
La typographie est couverte dans 83 % des fichiers et la couleur dans 67 %, car ce sont les deux éléments que l'on associe instinctivement au « design ». Le radius, l'élévation et le mode sombre restent discrètement génériques. Les quatre indicateurs persistent non pas parce que personne n'a essayé, mais parce que la plupart des tentatives ne couvrent que la partie visible.
Il existe une version dérivée du même problème : 54 % des fichiers contiennent au moins un adjectif vague pour remplacer une valeur, en tête desquels *clean* (39 %) et *modern* (36 %). Un adjectif ne remplace pas un réglage par défaut. Il demande à l'agent d'en choisir un.
Un audit de cinq minutes
- 1
Analyser l'arrière-plan
Récupérez l'hex de l'arrière-plan de votre page. S'il s'agit de
#09090b,#18181b,#0f172aou#020617, vous utilisez une palette zinc ou slate non modifiée. - 2
Compter les familles typographiques
Ouvrez les styles calculés d'un H1 et d'un paragraphe de corps de texte. Si la
font-familyest identique, cela signifie qu'une seule famille remplit toutes les fonctions. - 3
Comparer deux radius
Mesurez le radius des coins d'un bouton et de votre plus grande carte. Des valeurs identiques signifient que personne n'a adapté le radius à la taille de l'élément.
- 4
Comparer votre premier et dernier écran
Placez le tout premier écran créé à côté du plus récent. Listez chaque valeur divergente : cette liste constitue votre dérive.
- 5
Décider où réside la réponse
Pour chaque divergence, demandez-vous si la valeur correcte existe quelque part de manière durable. Si la réponse honnête est « dans le prompt que j'ai écrit en mars », c'est précisément ce qu'il faut corriger.
Si vous développez avec Lovable, v0, Bolt ou Replit
Tout ce qui précède s'applique doublement aux constructeurs basés sur le chat, car vous ne pouvez même pas y éditer la configuration manuellement en cours de flux : la conversation est l'interface. La solution durable est identique, adaptée à la manière dont chaque outil gère le contexte : collez un design system complet comme premier message (ou dans la base de connaissances du projet), puis construisez par-dessus. Nous maintenons une version prête à être collée de chaque kit par constructeur : thèmes pour Lovable, pour v0, pour Bolt, pour Replit et pour Base44.
Ignorer complètement les quatre valeurs par défaut
Chaque kit Identity Forge inclut un ensemble complet de design tokens (neutres ajustés à la couleur d'accentuation, un véritable appairage de polices, un rayon d'arrondi proportionnel à chaque élément) ainsi que le fichier DESIGN.md que votre agent lit avant d'écrire le balisage. Les kits gratuits ne nécessitent aucun compte.
S'agit-il d'un problème lié au modèle ou aux outils qui l'entourent ?
Principalement aux outils. Un même modèle produit une UI distinctive lorsqu'on lui fournit un ensemble de tokens et un brief, et une UI générique lorsqu'il n'a ni l'un ni l'autre. C'est le matériau de départ qui varie, pas la capacité.
Le fait de changer la couleur d'accentuation règle-t-il le problème ?
Non, et c'est l'erreur la plus courante qui gâche un après-midi. Changer l'accent tout en conservant les neutres par défaut, une seule famille typographique et un rayon d'arrondi uniforme produit la même page dans une teinte différente. La typographie et la structure portent davantage l'identité que la couleur d'accentuation.
Puis-je simplement demander à l'agent d'éviter Inter et zinc ?
Pour une seule session, oui. L'instruction réside dans le contexte, elle se dégrade donc à mesure que la conversation s'allonge et disparaît complètement lorsque vous en ouvrez une nouvelle. Un fichier dans le repo n'a pas cette propriété.
Est-ce shadcn/ui le problème ?
Non. shadcn propose des valeurs par défaut cohérentes précisément pour que vous puissiez commencer sans tout décider, et sa couche de thémisation est ce qui rend la correction simple. Le problème est que les valeurs par défaut sont traitées comme un résultat final plutôt que comme un point de départ.
Comment rendre mon application Lovable ou v0 unique ?
Fournissez au tool un design system complet avant de construire, et non des adjectifs pendant le processus. Collez le prompt complet d'un kit (tokens, polices, échelle typographique, motifs, règles) comme premier message ou dans la base de connaissances du projet, puis promptz les fonctionnalités normalement. Les adjectifs (« rends-le moderne, moins générique ») déplacent un écran d'un pas par rapport au défaut ; un système collé déplace chaque écran et reste stable d'une session à l'autre.
Combien d'écrans avant que le drift ne devienne visible ?
Dans nos propres tests, cela apparaît vers le cinquième ou sixième écran d'une session continue, et bien plus tôt si vous changez d'outil en cours de route. Il n'y a pas de nombre fixe : cela dépend de la longueur de la conversation, pas du nombre d'écrans.