Chapitre 4.3 — Techniques anti-dérive
⏱️ TL;DR — Tokens et primitives posent le système ; les techniques anti-dérive l’entretiennent dans la durée. Quatre gestes : le fichier-modèle (l’agent imite un exemple exemplaire), le chercher-avant-créer (déjà vu), la passe de cohérence (une revue ciblée « est-ce que ça respecte le système ? »), et la vérification visuelle (faire regarder le rendu à l’agent, via un navigateur piloté, plutôt que supposer). La dérive n’est pas un accident ponctuel : c’est une entropie qu’on combat par des rituels.
🎯 Objectifs
- Utiliser un fichier-modèle comme référence vivante.
- Lancer une passe de cohérence ciblée après une série d’écrans.
- Faire vérifier le rendu à l’agent (navigateur piloté / captures).
- Intégrer ces gestes comme des rituels, pas des exceptions.
1. Le fichier-modèle (la référence vivante)
On l’a introduit au kickoff (2.4/2.5) : un composant exemplaire que l’agent imite. C’est la technique anti-dérive la plus rentable, parce qu’un exemple concret transmet ce qu’aucune règle textuelle ne capture (structure des props, gestion des états, a11y, usage des tokens).
Bonne pratique : désigne-le explicitement au moment de créer du neuf.
« Crée le composant
Badgeen suivant exactement la structure et les conventions desrc/components/ui/button.tsx(props typées, variantes viavariant, tokens, focus visible). »
Un modèle vaut mieux que dix adjectifs. « Fais-le propre » ne dit rien ; « comme button.tsx » dit tout.
2. Chercher-avant-créer (rappel)
La règle de 4.2 est aussi une technique anti-dérive : réutiliser, c’est ne pas diverger. On ne la répète pas ici, mais elle fait partie du kit.
3. La passe de cohérence
Après avoir produit plusieurs écrans, la dérive s’est peut-être installée. Une passe de cohérence est une revue ciblée uniquement sur le système de design :
« Passe en revue
src/features/tasks/components/etsrc/app/projects/. Vérifie uniquement la cohérence de design : (1) des couleurs/espacements en dur au lieu de tokens ? (2) des composants qui réinventent une primitive de@/components/ui? (3) des écarts d’espacement/typo par rapport au modèle ? Liste les violations avec le fichier et la ligne, sans corriger tout de suite. »
Tu obtiens une liste actionnable. Tu tries, puis tu fais corriger. L’important : c’est une revue spécialisée (design only), pas une revue générale qui noierait ces points.
💡 Réflexe d’architecte — Planifie la passe de cohérence à intervalles réguliers (après chaque feature UI, par exemple), pas seulement « quand ça a l’air moche ». La dérive est graduelle : à l’œil nu, tu la vois trop tard. Une passe régulière l’attrape tant qu’elle est petite.
4. La vérification visuelle
Le point aveugle classique : l’agent écrit du JSX mais ne voit pas le résultat. Il peut produire un composant syntaxiquement parfait et visuellement cassé (contraste illisible, débordement, état survol oublié). Deux façons de lui rendre la vue :
- Un navigateur piloté : via un serveur MCP de navigateur (par ex. Playwright MCP, Partie 10), l’agent ouvre la page, prend une capture, la regarde, et corrige ce qu’il voit. C’est la boucle perçois → agis appliquée à l’UI.
- La skill de vérification : lui demander de lancer l’app et d’exercer réellement l’écran (voir la skill
/verifyet la Partie 11) plutôt que d’affirmer « ça devrait marcher ».
⚠️ Piège — « L’IA a fait l’UI, elle a l’air ok dans le code. » Le code n’est pas le rendu. Tant que l’agent (ou toi) n’a pas regardé la page dans un vrai navigateur, tu ne sais pas si c’est cohérent — tu l’espères. Rendre la vérification visuelle facile (un MCP navigateur configuré) transforme l’espoir en observation.
Ces gestes forment un rituel
Pris ensemble, ces quatre gestes composent une hygiène :
| Geste | Quand | Effet |
|---|---|---|
| Fichier-modèle désigné | à chaque création de composant | l’agent imite le bon |
| Chercher-avant-créer | à chaque besoin d’UI | pas de doublon |
| Passe de cohérence | après chaque feature UI | rattrape la dérive tôt |
| Vérification visuelle | avant de considérer un écran fini | attrape le cassé invisible |
Aucun n’est spectaculaire ; ensemble, ils font qu’une UI reste cohérente sur des mois, ce qu’aucune règle de CLAUDE.md seule ne garantit.
🧭 Sur TaskFlow — On configurera le MCP navigateur en Partie 10 pour que l’agent puisse voir les écrans de TaskFlow. Et on inscrira la passe de cohérence dans notre routine de fin de feature. La cohérence de TaskFlow ne reposera pas sur ma vigilance de tous les instants, mais sur ces rituels outillés.
✏️ Exercices
Exercice 1 — Passe de cohérence. Sur un projet existant, lance une passe de cohérence design only (le prompt ci-dessus). Combien de violations ? Range-les en « token en dur / doublon de composant / écart d’espacement ».
✅ Solution
La passe ciblée remonte typiquement une poignée de valeurs en dur et un ou deux composants réinventés. L’intérêt de la cibler « design only » : ces écarts ne se noient pas dans une revue générale. Corrige-les, puis programme la passe comme rituel de fin de feature.
Exercice 2 — Fais-lui voir. Si tu as un MCP navigateur (ou l’extension IDE), demande à l’agent d’ouvrir un écran, d’en prendre une capture et de la commenter. Note un défaut visuel qu’il n’aurait pas détecté « dans le code ».
✅ Solution
Les défauts « invisibles dans le code » typiques : contraste insuffisant, texte qui déborde, état survol/focus manquant, espacement incohérent au rendu. En voyant la page, l’agent les repère et les corrige — impossible en lisant seulement le JSX.
🧠 Quiz de révision
1. Pourquoi un fichier-modèle vaut-il mieux que des consignes textuelles ?
Parce qu’un exemple concret transmet ce que le texte ne capture pas : structure des props, états, a11y, usage des tokens. « Comme button.tsx » dit plus que « fais-le propre ».
2. Qu’est-ce qu’une « passe de cohérence » et pourquoi la cibler ?
Une revue uniquement sur le système de design (tokens en dur, doublons, écarts). Ciblée, ces points ne se noient pas dans une revue générale ; on obtient une liste actionnable.
3. Pourquoi programmer la passe régulièrement plutôt que « quand c’est moche » ?
Parce que la dérive est graduelle : à l’œil nu, on la voit trop tard. Une passe régulière l’attrape petite, donc bon marché à corriger.
4. Quel est l’angle mort de l’agent sur l’UI, et comment le lever ?
Il écrit le JSX mais ne voit pas le rendu. On lève l’angle mort en lui donnant un navigateur piloté (MCP) pour capturer et regarder la page, ou en lui faisant lancer et exercer l’écran.
5. « Le code de l’UI a l’air bon » suffit-il à conclure ?
Non : le code n’est pas le rendu. Tant que la page n’a pas été regardée dans un vrai navigateur, la cohérence visuelle est supposée, pas vérifiée.
Chapitre suivant : Les skills de design — quels outils spécialisés pour concevoir et itérer sur l’UI.