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 — aucune dose supplémentaire de goût ne permettra à deux jugements indépendants de tomber sur le 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 alors 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, mais pas le ratio entre les paliers.
- 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 souvent 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 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 résultat sur six est votre score 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 permet de savoir si la dérive est progressive ou si elle s'est produite à un moment précis — généralement lors d'un changement d'outil ou après un long intervalle entre deux sessions.
| Dérive du design | Jamais spécifié | |
|---|---|---|
| N'importe quel écran | Cohérent en interne | Incohérent en interne |
| Premier écran vs dernier écran | Divergence | Les deux divergent 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 au préalable |
Pourquoi les solutions de contournement habituelles déçoivent
- Redéfinir la palette tous les quelques prompts. Cela fonctionne, mais c'est vous qui devenez la mémoire, et vous oublierez avant l'agent.
- Un seul prompt système très long. Utile au début, puis contribue à la pression sur le contexte, ce qui cause le problème.
- Demander à l'agent de s'aligner sur un écran existant. Il doit déduire des valeurs à partir d'un balisage qu'il n'a peut-être plus en contexte, et l'inférence introduit ses propres erreurs.
- Refactoriser à la fin. L'option la plus coûteuse : vous payez pour créer de l'incohérence, puis vous payez à nouveau pour la supprimer.
Ces quatre approches se ressemblent. Elles tentent de maintenir les valeurs en vie au sein de la conversation, or la conversation est précisément l'élément qui se dégrade.
La solution, et pourquoi elle fonctionne
Sortez les invariants de la conversation pour les placer dans le dépôt : des tokens sémantiques plus un fichier DESIGN.md. L'agent les lit au début de chaque session, ainsi l'écran vingt résout le même --primary que l'écran un, plutôt qu'une valeur approximative.
Le nommage sémantique apporte ici une réelle valeur ajoutée, au-delà de la simple propreté. --primary et --muted-foreground décrivent des rôles, permettant à 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 doit simplement être recherché. C'est là tout l'intérêt d'une couche de 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 suivies plus rigoureusement que les préférences.
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Mesurer à nouveau
Relancez le diff des six valeurs après les deux écrans suivants. Un score de dérive de zéro est le résultat attendu ; si ce n'est pas le cas, c'est que des décisions sont encore prises en dehors de la couche de tokens.
Un design system résout-il la dérive par lui-même ?
En partie, et la partie qu'il ne traite pas est celle qui pose problème. Une bibliothèque de composants règle la cohérence au niveau du composant : 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 réside réellement la dérive.
Ce problème est encore plus marqué pour les équipes qui possèdent déjà un système. La question la plus fréquente concernant les compétences en design et les outils d'agents est de savoir si un agent *respectera* un thème existant ou s'il en inventera un discrètement en parallèle. La réponse dépend entièrement de si le thème existe sous forme de valeurs lisibles par l'agent, ou seulement sous forme de bibliothèque Figma et d'une compréhension commune.
| Corrigé par une bibliothèque de composants | Dérive toujours présente | |
|---|---|---|
| Internes du composant | Oui — un Button est un Button | — |
| Valeurs de thème lues par les composants | Non | Primary, background, radius, spacing |
| Composition entre les composants | Non | Rythme des sections, hiérarchie, choix de la 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 réside dans Figma et dans l'esprit des utilisateurs, un agent de code ne peut pas le lire. Il produira des composants qui semblent plausibles et utiliseront des valeurs que personne n'a choisies. Un design system ne limite 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 plutôt que d'un défaut d'un outil en particulier. Ce qui diffère, c'est la quantité d'état durable que chaque outil peut lire, ce qui change l'endroit où la dérive devient critique.
- Agents basés sur le dépôt (Claude Code, Cursor). Ils peuvent lire des fichiers, donc un
DESIGN.mdplus des tokens corrigent réellement le problème. Leur faiblesse est que rien ne les oblige à regarder, c'est pourquoi l'instruction doit figurer dansAGENTS.mdsous forme d'interdiction. - Constructeurs basés sur le prompt (v0, Lovable, Bolt). Moins de contenu à lire dans le dépôt, donc une plus grande partie de l'identité doit être restatée. Copiez-collez le bloc de tokens plutôt que de le décrire.
- Passage de l'un à l'autre. La rupture la plus nette, car le second outil n'a pas accès à la conversation du premier et repart des paramètres par défaut de la bibliothèque.
C'est pourquoi la solution est un fichier plutôt qu'un choix d'outil. Un fichier est la seule chose que tous peuvent consommer, et la seule chose qui survit à votre changement d'outil.
Là où la dérive cause le plus de dégâts : le mode sombre
Nous avons échantillonné 299 fichiers DESIGN.md publics sur GitHub et mesuré leur contenu. Sur les 72 qui décrivent un design system visuel, 69 % ne contiennent aucun mode sombre — pas de second ensemble de valeurs, pas de prefers-color-scheme, rien.
Cela est crucial ici. Lorsqu'une valeur est absente de l'état durable, l'agent l'invente, et les valeurs inventées constituent précisément la dérive. Un fichier qui couvre entièrement le mode clair et omet le mode sombre n'est pas à moitié protégé ; il est totalement protégé sur un thème et complètement sans défense sur l'autre. Votre score de dérive peut être de zéro en mode clair et de quatre en mode sombre.
Lorsque vous lancez le diff sur six valeurs, lancez-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 les gens sautent parce que les écrans en mode clair semblent corrects.
Ce qu'il faut remarquer, c'est à quel point le côté en dérive semble *raisonnable* de manière isolée. La dérive n'est jamais manifestement erronée au niveau du composant ; elle n'est visible que lorsque deux écrans sont mis côte à côte, ce qui est précisément la comparaison que personne ne fait pendant le développement.
Arrêtez de payer la dérive deux fois
Installez un kit avant l'écran suivant plutôt que de refactoriser après le vingtième. Des design tokens, DESIGN.md et un élément de registre shadcn/ui, 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 chaque agent car la cause est la dégradation du contexte plutôt que la capacité. 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 corrige pas les valeurs du thème lues par ces composants, là où se situe réellement le drift.
Mon score de drift est à zéro, mais l'application semble toujours incohérente. Que faire ?
Vous faites alors face à l'autre mode 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.
Comment le mesurer