Ce qu'est réellement le drift
Le drift n'est pas l'agent qui vous ignore, ni un problème de qualité sur un écran isolé. Chaque écran est généralement correct en soi. La défaillance est *relationnelle* : l'écran huit est en contradiction avec l'écran un sur des valeurs qui devraient être constantes.
Cette distinction est cruciale car elle détermine la solution. Un problème de qualité se règle avec de meilleures directives. Un problème de cohérence se règle avec des valeurs durables : aucun surplus de goût ne permettra à deux jugements indépendants d'aboutir au même code hexadécimal.
Chaque écran est correct. Le produit ne l'est pas. Cet écart constitue l'intégralité du design drift.
Pourquoi cela commence vers le cinquième écran
Le chiffre cinq n'a rien de magique ; la véritable variable est la longueur de la conversation plutôt que le nombre d'écrans. Les sessions longues créent un contexte volumineux, et votre paragraphe de style du début doit rivaliser avec tout ce qui a été dit depuis.
Ce qui se dégrade est spécifique et prévisible. Les valeurs précises partent en premier, car ce sont des chaînes arbitraires sans ancrage sémantique : oklch(0.55 0.19 45) est bien plus difficile à retenir qu'un *orange chaud*. L'agent conserve donc l'adjectif, rejette la valeur, et redéduit un orange chaud la fois suivante. Cette nouvelle valeur devient alors la référence pour l'écran suivant.
- L'espacement et le rayon partent en premier. Personne ne les nomme dans le brief, ils sont donc redéduits de zéro à chaque fois.
- L'échelle typographique suit. La taille de base a tendance à survivre ; le ratio entre les paliers, non.
- La couleur d'accentuation part en dernier. Elle est généralement mentionnée dans le brief, ce qui l'ancre. C'est pourquoi on sous-estime le drift en ne vérifiant que la couleur.
- Les conventions de mise en page dérivent à peine, c'est pourquoi l'application semble toujours cohérente alors que ses détails divergent.
Le changement d'outil court-circuite la progression
Passez de Cursor à Claude Code en milieu de projet et chaque valeur non écrite dans un fichier est réinitialisée instantanément. Le second outil n'a pas accès à la conversation du premier ; il repart donc des valeurs par défaut, c'est pourquoi le drift apparaît souvent comme une rupture brutale plutôt que comme une pente.
Le mesurer
Le drift est inhabituel parmi les griefs liés à l'UI car il est simple à quantifier. Choisissez les valeurs qui devraient être invariantes, échantillonnez-les sur vos écrans le plus ancien et le plus récent, et comptez les divergences.
- 1
Choisissez vos invariants
Six suffisent : la couleur primaire, le fond de page, la taille de police de base, le ratio de l'échelle typographique, le rayon des cartes et l'écart standard entre un label et son contrôle.
- 2
Échantillonnez le premier écran
Utilisez les styles calculés plutôt que la source, afin de capturer ce qui est réellement rendu après la cascade CSS.
getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor - 3
Échantillonnez le dernier écran
Les six mêmes valeurs, de la même manière.
- 4
Comptez les divergences
Ce score sur six est votre indice de drift. Zéro signifie que les valeurs proviennent d'une source durable ; quatre ou plus signifie qu'elles sont redécidées à chaque écran.
- 5
Répéter sur un écran intermédiaire
Cela vous indique si la dérive est progressive ou si elle s'est produite brutalement, généralement lors d'un changement d'outil ou d'une longue interruption entre deux sessions.
| Design drift | Jamais spécifié | |
|---|---|---|
| N'importe quel écran | Cohérence interne | Incohérence interne |
| Premier écran vs dernier écran | Désaccord | Les deux sont en désaccord avec eux-mêmes |
| Cause | Dégradation des valeurs due au contexte | Aucune valeur n'a jamais existé |
| Correction | Déplacer les valeurs dans des fichiers | Définir le système d'abord |
Pourquoi les solutions de contournement habituelles sont décevantes
- Redéfinir la palette à chaque nouveau prompt. Cela fonctionne, mais c'est vous qui devenez la mémoire, et vous finirez par oublier avant l'agent.
- Un prompt système très long. Utile au début, puis contribue à la saturation du contexte qui cause le problème.
- Demander à l'agent de reproduire un écran existant. Il doit déduire des valeurs à partir d'un markup qu'il n'a peut-être pas en contexte, et l'inférence introduit sa propre erreur.
- Refactoriser à la fin. L'option la plus coûteuse : vous payez pour créer l'incohérence, puis vous payez de nouveau pour la supprimer.
Les quatre partagent une caractéristique commune. Ils tentent de maintenir les valeurs en vie au sein de la conversation, et la conversation est ce qui se dégrade.
La solution, et pourquoi elle fonctionne
Sortez les invariants de la conversation pour les intégrer au dépôt : des design tokens sémantiques plus un fichier DESIGN.md. L'agent les lit au début de chaque session ; l'écran vingt résoudra donc le même --primary que l'écran un, plutôt qu'un équivalent approximatif.
La nomenclature sémantique joue ici un rôle crucial qui dépasse la simple organisation. --primary et --muted-foreground décrivent des rôles, ce qui permet à l'agent de les appliquer correctement dans des situations imprévues. Un code hexadécimal brut doit être mémorisé *et* placé correctement ; un rôle n'a qu'à être consulté. C'est l'argument en faveur d'une couche de design tokens sémantiques plutôt que d'une simple palette.
- 1
Installer le contrat
npx --yes identityforge@latest install --client claude-code - 2
Appliquer un kit
Écrit le fichier DESIGN.md ainsi que les tokens light et dark dans le dépôt.
identityforge apply quiet-matter - 3
Transformer la règle en interdiction
Les interdictions sont respectées plus fidèlement que les préférences.
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Mesurer à nouveau
Relancez le diff sur six valeurs après les deux prochains écrans. Un score de dérive de zéro est le résultat attendu ; si ce n'est pas le cas, quelque chose est encore décidé en dehors de la couche des tokens.
Un design system résout-il le design drift à lui seul?
Partiellement, et la part qu'il néglige est celle qui fait mal. Une bibliothèque de composants corrige la cohérence au niveau des composants : un Button est un Button sur chaque écran. Elle ne fait rien pour les valeurs de thème que ces composants lisent, et c'est là que la dérive se loge réellement.
Il existe une version plus aiguë de ce problème pour les équipes qui possèdent déjà un système. La question la plus fréquente concernant les compétences de design et les outils d'agent est de savoir si un agent va *respecter* un thème existant ou l'inventer discrètement à côté. La réponse dépend entièrement de l'existence du thème sous forme de valeurs lisibles par l'agent, ou seulement sous forme de bibliothèque Figma et de compréhension partagée.
| Corrigé par une bibliothèque de composants | Présente toujours une dérive | |
|---|---|---|
| Internals des composants | Oui. Un bouton reste un bouton | — |
| Valeurs de thème lues par les composants | Non | Primaire, arrière-plan, rayon, espacement |
| Composition entre les composants | Non | Rythme des sections, hiérarchie, choix de grille |
| Tout ce que la bibliothèque ne couvre pas | Non | Inventé par écran, différemment à chaque fois |
L'échec qu'une bibliothèque Figma ne peut empêcher
Si votre système ne vit que dans Figma et dans la tête des gens, un agent de code ne peut pas le lire. Il produira des composants qui semblent plausibles mais utilisent des valeurs que personne n'a choisies. Un design system n'arrête la dérive que dans la mesure où il existe sous forme de texte dans le dépôt.
La dérive diffère-t-elle entre Cursor, Claude Code, v0 et Lovable ?
Le mécanisme est le même partout, car il s'agit d'une dégradation du contexte et non d'un défaut propre à un outil. Ce qui diffère, c'est la quantité d'état durable que chaque outil peut lire, et c'est là que la dérive s'installe.
- Agents basés sur le dépôt (Claude Code, Cursor). Ils peuvent lire des fichiers, donc un
DESIGN.mdassocié à des tokens règle réellement le problème. Leur faiblesse est que rien ne les oblige à consulter ces fichiers, c'est pourquoi l'instruction doit figurer dansAGENTS.mdsous forme d'interdiction. - Builders basés sur le prompt (v0, Lovable, Bolt). Ils ont moins de dépôt à lire, une plus grande partie de l'identité doit donc être réaffirmée. Collez le bloc de tokens plutôt que de le décrire.
- Passage d'un outil à un autre. C'est la rupture la plus brutale, car le second outil n'a pas accès à la conversation du premier et repart des valeurs par défaut de la bibliothèque.
C'est pourquoi la solution est un fichier et non le choix d'un outil. Un fichier est la seule chose que tous peuvent consommer, et la seule chose qui subsiste lorsque vous changez d'avis sur l'outil à utiliser.
Là où la dérive fait le plus de dégâts : le mode sombre
Nous avons analysé 299 fichiers DESIGN.md publics sur GitHub. Parmi les 72 décrivant un design system visuel, 69 % ne contiennent aucun mode sombre. Pas de second jeu de valeurs, pas de prefers-color-scheme, rien.
C'est précisément là que cela pose problème. Lorsqu'une valeur est absente de l'état durable, l'agent l'invente, et les valeurs inventées sont précisément ce qui constitue la dérive. Un fichier qui couvre entièrement le mode clair mais omet le mode sombre n'est pas protégé à moitié ; il est totalement protégé pour un thème et complètement sans défense pour l'autre. Votre score de dérive peut être de zéro en mode clair et de quatre en mode sombre.
Lorsque vous effectuez le diff des six valeurs, faites-le deux fois : une fois par thème. Le mode sombre est l'endroit où les chiffres divergent généralement, et c'est la mesure que l'on néglige parce que les écrans en mode clair semblent corrects.
Ce qu'il faut remarquer, c'est à quel point le côté dérivé semble *raisonnable* isolément. La dérive n'est jamais manifestement erronée au niveau du composant ; elle n'est visible que lorsque deux écrans sont placés côte à côte, ce qui est précisément la comparaison que personne ne fait pendant un build.
Arrêtez de payer deux fois pour la dérive
Installez un kit avant l'écran suivant plutôt que de refactoriser après le vingtième. Tokens, DESIGN.md et un élément de registre shadcn, en une seule commande. Les kits gratuits ne nécessitent aucun compte.
La dérive est-elle le signe que j'ai choisi le mauvais modèle ?
Non. Elle apparaît avec tous les agents car la cause est la dégradation du contexte et non la capacité du modèle. Un modèle plus puissant conserve les valeurs légèrement plus longtemps, puis dérive de la même manière.
Puis-je l'éviter en limitant la durée des sessions ?
Cela aide au sein d'une même session, mais aggrave le problème entre les sessions. Chaque nouvelle session repart des valeurs par défaut ; ainsi, des sessions courtes sans valeurs persistantes entraînent des ruptures visuelles plus fréquentes et plus marquées.
L'utilisation d'une bibliothèque de composants règle-t-elle le problème ?
En partie. Cela garantit la cohérence au niveau des composants, car un Button reste un Button. En revanche, cela ne règle pas le problème des valeurs de thème lues par ces composants, là où se situe réellement le drift.
Mon score de drift est à zéro, mais l'application manque toujours de cohérence. Que faire ?
Vous faites alors face à un autre type de défaillance : les valeurs sont stables, mais le système est trop succinct. Analysez la hiérarchie, le rythme des espacements au sein d'un écran et vérifiez si une seule famille typographique n'est pas utilisée pour toutes les fonctions.
À quelle fréquence dois-je effectuer une nouvelle mesure ?
Après chaque changement d'outil, après toute interruption de plus de quelques jours et avant la mise en production. Ce sont les trois moments où les valeurs non documentées sont les plus susceptibles d'avoir été réinitialisées.