Audit d'UI de template
Les interfaces générées et celles issues de kits de démarrage partagent un look reconnaissable : un accent indigo ou violet, un dégradé héroïque violet-bleu, Inter partout, des cartes givrées, des emoji dans la navigation. Aucun de ces éléments n'est mauvais en soi. Le problème est un choix venu du template plutôt que du produit. Cette compétence détecte ces choix avec un scanner statique, puis les trie par jugement. Le scanner produit des candidats ; seul le tri produit des constats.
Cette compétence supprime les valeurs par défaut non choisies. Elle n'invente pas de marque. Si le produit n'a pas encore de direction visuelle, dites-le et demandez-en une plutôt que de remplacer une valeur par défaut par une autre.
Avant de scanner
- Lisez le brief, les tokens de design et la configuration du thème ou de la bibliothèque de composants. Notez chaque couleur, police et composant demandé par le produit. Ceux-ci restent, même si le scanner les signale.
- Déterminez le mode à partir de la demande :
- Review : signalez uniquement les constats. Ne modifiez rien.
- Cleanup : corrigez les constats confirmés, et uniquement dans la zone nommée par l'utilisateur (une page, un dossier de composants, toute l'application). Signalez tout ce que vous remarquez en dehors sans le corriger.
- Choisissez la portée du scan : les dossiers sources qui rendent l'UI, pas tout le dépôt.
Exécuter le scanner
bun <ce dossier de compétence>/scripts/scan.mjs [--json] [--fail-on high|medium|low] <chemins>...
Node 22 ou ultérieur fonctionne aussi. Il parcourt les répertoires, ignore les dépendances, la construction, la couverture et les fichiers minifiés, et lit .html .css .scss .js .ts .jsx .tsx .vue .svelte .astro. Il affiche le nombre de fichiers scannés. Le code de sortie 0 signifie qu'aucun élément n'a atteint la sévérité d'échec (élevée par défaut), 1 signifie qu'un élément a échoué, 2 signifie une mauvaise utilisation ou zéro fichier scanné. Un 2 n'est jamais un résultat propre. Passez --fail-on medium lorsque les accents violets, une police par défaut unique ou des icônes emoji doivent faire échouer l'exécution. N'ajoutez pas le scanner comme porte CI sauf demande explicite.
| Règle | Sévérité | Détection |
|---|---|---|
purple-blue-gradient | haute | dégradés dont les arrêts sont tous des teintes froides avec au moins un violet, en CSS ou classes Tailwind from-/to- |
violet-accent | moyenne | tout token hex, rgb, hsl, oklch ou HSL nu dont la teinte calculée se situe dans la bande indigo-violet, plus les classes Tailwind indigo/violet/purple |
gradient-text | moyenne | background-clip: text et bg-clip-text |
single-stock-font | moyenne | une seule police par défaut (Inter, Roboto, Poppins et similaires) comme seul nom de police dans deux déclarations ou plus sur l'ensemble scanné |
emoji-icon | moyenne | emoji dans les titres, boutons, liens, éléments de navigation ou champs icon/label/title |
neon-glow | moyenne | ombres avec décalage nul et large flou dans une couleur saturée, et ombres colorées Tailwind |
frosted-glass | faible | backdrop-filter: blur() et backdrop-blur |
library-default-token | faible | primaires par défaut non modifiées de Bootstrap, Material, MUI, Ant Design, Chakra, shadcn/ui et le starter Vite |
tracked-caps | faible | texte en majuscules avec un grand espacement entre les lettres |
La règle de police examine tous les fichiers en une seule exécution, alors scannez toute l'UI ensemble ; scanner un fichier à la fois la cache.
Trier chaque correspondance
Ouvrez chaque ligne signalée et lisez suffisamment autour pour comprendre à quoi sert l'élément. Donnez à chaque correspondance exactement un verdict :
- Défaut non choisi : rien dans le brief, les tokens ou l'historique ne le demande, et cela ressemble à un modèle de démarrage. C'est un constat.
- Choix délibéré : le brief, un fichier de token, un guide de marque ou un message de commit montre que quelqu'un l'a choisi. Gardez-le et nommez la preuve.
- Faux positif : la correspondance ne fait pas ce que la règle suppose, comme une teinte violette dans un thème de coloration syntaxique, un flou sur un arrière-plan modal au-dessus d'un contenu chargé, ou un emoji dans des données d'exemple générées par l'utilisateur. Laissez-le et dites pourquoi.
- Non résolu : vous ne pouvez pas dire si quelqu'un l'a choisi. Ce n'est pas un constat et vous ne changez rien. Signalez ce qui manque et la question qui le résoudrait.
Corriger ce qui est réel
- Corrigez la cause, pas la ligne. Cinq hexagones violets signifient généralement un token d'accent manquant ; définissez la palette et les polices du produit une fois et pointez les composants vers elles.
- Choisissez des remplacements qui servent le contenu : un contraste qui tient, un accent qui marque la seule action importante, une police adaptée à la charge de lecture.
- Ne modifiez jamais une valeur juste pour sortir de la portée du scanner, comme décaler une teinte de quelques degrés ou remplacer un hex par un
oklch()équivalent. Si la couleur est mauvaise, changez-la ; si elle est bonne, gardez-la et enregistrez pourquoi. - Ne modifiez jamais une couleur de marque, une couleur d'état (succès, avertissement, erreur) ou un indicateur de focus pour faire passer le scan. Ceux-ci ont un sens ; enregistrez-les comme délibérés.
- Remplacez les icônes emoji par le jeu d'icônes existant du projet. N'ajoutez une nouvelle dépendance d'icônes que si l'utilisateur est d'accord.
Ce que le scanner ne voit pas
Vérifiez ces éléments en lisant la page rendue, car aucune correspondance de motif ne les trouve :
- chaque section construite à partir du même titre centré, sous-titre et deux boutons
- une grille de trois fonctionnalités avec une icône, un titre et une ligne de texte dans chaque carte
- un petit badge ou pastille au-dessus du titre principal
- des cartes marquées par une épaisse bordure gauche colorée
- un bandeau de statistiques avec de grands nombres ("10k+ utilisateurs", "99,9% de disponibilité")
- des sections numérotées "1, 2, 3"
- un thème sombre imposé sans option claire demandée dans le brief
- le même grand rayon de coin et la même ombre douce sur chaque surface
- des espacements et tailles de police qui ignorent l'échelle du projet
- un copier-coller qui pourrait décrire n'importe quel produit
Vérifier
- Relancez le scanner sur la même portée et confirmez que chaque correspondance restante a un verdict enregistré.
- Regardez l'UI rendue aux tailles importantes (une largeur de téléphone étroite et une largeur de bureau au moins), dans chaque thème fourni par le produit.
- Un scan propre ne dit rien sur l'accessibilité, la mise en page ou la qualité générale. Vérifiez le contraste et les états de focus sur tout ce que vous avez modifié.
Si vous n'avez pas pu rendre l'UI, dites que la revue était statique uniquement.
Rapport
Rédigez le rapport dans cet ordre :
- Portée scannée, fichiers scannés, mode et code de sortie du scanner.
- Constats corrigés (ou, en mode review, proposés), chacun avec
fichier:ligne, la règle et ce qui l'a remplacé. - Correspondances conservées comme délibérées, chacune avec sa preuve.
- Correspondances non résolues, chacune avec ce qui manque et la question qui la résoudrait.
- Faux positifs, chacun avec une ligne expliquant pourquoi.
- Problèmes que le scanner ne peut pas voir, si vous en avez trouvé.
- Comment vous avez vérifié : résultat de la relance, tailles et thèmes visualisés, ou "statique uniquement".