Impeccable : 62 règles déterministes contre le slop IA

Les pages produites par un modèle ont un air de famille reconnaissable entre tous. Vous l'avez vu : Inter partout, un dégradé violet vers bleu sur le hero, des cartes dans des cartes, du texte gris sur fond coloré, et une tuile d'icône en carré arrondi flottant au-dessus de chaque titre. Paul Bakaus a donné un nom à cet air de famille, puis il a écrit un linter pour le traquer.

Impeccable est une compétence de design pour agents de codage. Elle a récolté environ 6 700 étoiles cette semaine et en totalise à peu près 91 500. L'accroche — « le vocabulaire de design pour votre agent de codage » — sous-estime le point réellement inhabituel : 62 de ses contrôles tournent comme des règles déterministes, sans aucun modèle impliqué.

Ce que c'est, concrètement

Une compétence, 24 commandes et un détecteur. Le projet a démarré comme une extension de la compétence frontend-design d'Anthropic avant de grandir jusqu'à avoir ses propres partis pris.

L'installation tient en une commande, à la racine du projet :

npx impeccable install
/impeccable init

C'est la deuxième étape que les gens sautent. init vous interroge sur le produit — audience, objectif, contraintes, ton — et écrit les réponses dans PRODUCT.md. Une commande document distincte génère DESIGN.md à partir de votre code existant. La séparation compte : les faits produit et le système visuel sont deux artefacts différents, qui changent à des rythmes différents, et les fusionner dans un seul fichier est la meilleure façon de périmer une doc de design.

Viennent ensuite les 24 commandes. Davantage un vocabulaire qu'un workflow :

craft déroule la séquence complète forme puis construction, avec itération visuelle. critique examine hiérarchie, clarté et registre émotionnel. audit vérifie accessibilité, performance et responsive. polish aligne sur le design system avant la mise en ligne. bolder et quieter sont des ajustements directionnels — amplifier ou retenir. harden traite les états d'erreur, l'i18n, le débordement de texte et les cas limites. typeset et layout corrigent les deux choses que les interfaces générées par agent ratent le plus souvent. live ouvre un navigateur et génère sur place des variantes d'un élément nommé.

Chacune peut être épinglée en raccourci autonome :

/impeccable pin audit

Ce qui crée /audit comme commande de premier niveau. Petite fonctionnalité, grande différence sur l'usage réel du vocabulaire.

Le détecteur, c'est là qu'est l'ingénierie intéressante

Voilà ce qui sépare Impeccable du tas de dépôts qui ne sont que des collections de prompts : les 62 règles n'ont besoin ni d'un modèle, ni d'une clé API, ni d'un agent.

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

Autrement dit, ça tourne en CI. Une pull request qui réintroduit un easing rebond, ou un dégradé violet égaré, ou une légende grise en 14px sur fond turquoise, peut échouer au contrôle sans que personne ne paie de tokens. Un flag --github émet des annotations GitHub Actions, ce qui est le seul détail d'intégration qui compte pour la plupart des équipes.

Le jeu de règles est tranché au point d'en agacer certains, et la documentation l'assume. La liste des anti-patterns bannit Arial, Inter et les polices système par défaut ; bannit le noir pur et le gris pur (toujours teintés) ; bannit les cartes autour de tout et les cartes dans les cartes ; bannit les easings rebond et élastiques comme datés ; bannit le texte gris sur fond coloré.

Certains de ces points sont des arguments d'artisan défendables. Un texte de paragraphe au contraste insuffisant sur un fond saturé est un échec d'accessibilité qui se trouve aussi faire cheap. L'interdiction d'Inter relève de la mode, et les règles de mode vieillissent mal — le même document qui bannit Inter aura l'air d'une pièce d'époque dans trois ans. Mais un linter sans opinions n'est qu'un formateur, et l'intérêt de celui-ci est précisément d'avoir une position.

Parce qu'il est déterministe, il est aussi contournable. Une équipe qui tient à livrer son dégradé violet peut ajouter une exemption en ligne :

<!-- impeccable-disable overused-font: exported brand doc -->

Ou gérer les ignorés globalement avec npx impeccable ignores add-value overused-font Inter --reason "Brand font". Le flag --reason fait un discret travail social : il rend l'exception visible dans un diff.

Comment ça s'accroche à l'agent

Le mode d'installation choisi détermine le degré d'intrusion. Pour Claude Code, Copilot, Codex, Cursor et Grok Build, install écrit un manifeste de hooks natif au fournisseur. Dans Claude Code, c'est .claude/settings.local.json, ignoré par git et local à la machine. Dans Copilot, c'est .github/hooks/impeccable.json, commité et partagé avec les agents cloud. Dans Cursor, c'est .cursor/hooks.json, déclenché sur postToolUse à l'écriture d'un fichier.

L'effet : le détecteur tourne sur les modifications de l'agent lui-même et renvoie ses constats dans sa boucle. Le mécanisme diffère sensiblement de « lancer la commande audit quand on y pense ». Il attrape la soupe au moment de la génération, pas au moment de la relecture.

Le compromis est classique : des hooks qui écrivent dans la config de votre dépôt sont des hooks qui apparaissent en revue de code, et les utilisateurs de Codex doivent approuver explicitement les hooks du projet via /hooks après l'installation. Si votre équipe a des opinions fermes sur la config d'outillage commitée, la voie du submodule existe exactement pour ça — git submodule add plus npx impeccable link --source=.impeccable --providers=claude,cursor garde l'outil versionné aux côtés du code qu'il gouverne.

Ce qu'il ne corrigera pas

Trois limites à nommer.

Il ne peut pas vous dire si la page est bonne. Les 62 règles attrapent des signaux de surface. Une page peut les passer toutes et n'avoir aucun point de vue, ce qui est la version profonde du problème du slop IA et celle qu'aucun linter n'a résolue.

Le mode live ne fonctionne que sur un checkout local. Il ne s'injecte pas dans un site en production, HTTPS ou non. C'est raisonnable, mais cela signifie que la boucle d'itération visuelle est un outil de développement, pas de revue.

Et le vocabulaire ne sert que si l'agent le lit. La formulation d'Impeccable est honnête là-dessus : si tous les modèles produisent le même design, c'est que tous ont été entraînés sur les mêmes templates SaaS. Un fichier de compétence est une pichenette contre une distribution d'entraînement, et les pichenettes perdent contre les distributions plus souvent qu'on ne le voudrait.

Pourquoi pas simplement une checklist ?

Question légitime. Un guide de style en markdown ne coûte rien et fait à peu près le même travail.

La différence, c'est l'application. Une checklist dans un prompt est une suggestion : le modèle la lit, approuve, puis produit un dégradé violet parce que ce dégradé figurait quarante mille fois dans ses données d'entraînement. Une règle déterministe fait échouer un build. Ce n'est pas la même catégorie de pression, et c'est la seule qui survive à une deadline.

La deuxième différence est la granularité. Une checklist dit « utilisez une bonne typographie ». La commande typeset d'Impeccable traite spécifiquement hiérarchie, échelle et appairage, et le détecteur a des règles individuelles pour des échecs individuels, ce qui permet à la boucle de retour de pointer une ligne de CSS au lieu de faire un geste vers le goût. C'est tout l'argument de l'outillage contre la documentation, et il vaut ici pour la même raison qu'il valait pour les linters il y a vingt ans.

Troisième différence : le vocabulaire est partagé. bolder, quieter, distill, harden — un designer et un agent peuvent agir sur ces mots. « Fais plus pop » non.

Pourquoi ça cartonne maintenant

Parce que le problème de volume est arrivé. Il y a un an, un agent générait une landing page à l'occasion. Aujourd'hui une équipe en produit quarante avant le déjeuner, et le goulot est passé de « peut-on le construire » à « peut-on dire lesquelles sont bonnes, assez vite ».

Un vérificateur déterministe des échecs bon marché est la seule partie de ce problème qui passe à l'échelle. Le goût, non. Soixante-deux règles en forme d'expressions régulières sur les polices et les easings, oui — et les livrer comme une chose qui tourne en CI sans appel de modèle est la décision la moins glamour et la plus utile du dépôt.