Impeccable : un langage de design et des règles déterministes pour les agents de codage IA

Contexte et définition du problème

Pratiquement tous les grands modèles de langage utilisés pour écrire du code sont entraînés sur à peu près le même corpus de code web public : les mêmes bibliothèques de composants, les mêmes sites marketing SaaS, les mêmes maquettes Tailwind inspirées de Dribbble. Le résultat est prévisible : les interfaces générées par IA convergent vers un éventail restreint d'habitudes visuelles, quel que soit le modèle utilisé — Inter comme police par défaut, un héros en dégradé violet vers bleu, des cartes imbriquées dans d'autres cartes, du texte gris pâle sur fond coloré, et une tuile d'icône à coins arrondis flottant au-dessus de chaque titre de section.

Ce ne sont pas des défauts propres à un modèle en particulier, mais des artefacts statistiques des données d'entraînement, qu'aucune ingénierie de prompt ne parvient à éliminer de façon fiable, car le modèle ne garde aucune mémoire persistante de ce qu'il a livré la veille et ne dispose d'aucun mécanisme pour confronter sa propre production à un corpus de règles. La compétence frontend-design d'Anthropic a été la première tentative largement adoptée pour donner à un agent de codage des directives de design explicites plutôt que de laisser le jugement esthétique au hasard. Impeccable, créé par Paul Bakaus, part de cette base mais traite le problème sous-jacent comme une lacune de workflow et d'outillage plutôt que comme une simple question de fichier de compétence : les agents ont besoin d'un contexte produit durable qui persiste d'une session à l'autre, d'un vocabulaire partagé pour demander des modifications, et d'un moyen de vérifier le résultat sans dépendre de l'auto-évaluation du même modèle.

Architecture centrale et principes techniques

Impeccable s'installe comme une seule compétence invoquée via `/impeccable`, mais l'architecture réelle réside dans la séparation entre deux documents et deux couches de vérification. `PRODUCT.md`, rédigé une seule fois par `/impeccable init`, capture la vérité produit durable — audience, objectif, contexte d'exploitation, contraintes, ton et preuves — délibérément tenue à l'écart de l'orientation visuelle de surface, laquelle est choisie pour chaque interface et consignée séparément dans `DESIGN.md` une fois qu'un système visuel existe ou est construit.

Sur cette base reposent 24 commandes correspondant à des phases distinctes d'un workflow de design : `shape` et `craft` pour la planification et la construction, `critique` et `audit` pour la revue, `polish`, `harden` et `onboard` pour la préparation à la mise en production, et des commandes de dosage expressives — `bolder`, `quieter`, `distill`, `animate`, `colorize`, `overdrive` — pour ajuster l'intensité sans rouvrir le débat sur l'ensemble du design. La seconde couche comprend 61 règles de détection déterministes qui fonctionnent sans LLM et sans clé API, à la fois dans la CLI et dans une extension de navigateur compagnon, de sorte qu'une vérification du contraste, du rythme des espacements ou des associations de polices produit toujours la même réponse, au lieu d'un jugement probabiliste susceptible de varier d'une exécution ou d'un modèle à l'autre.

Évaluation pratique et applications

En pratique, un projet adopte Impeccable en exécutant une fois `npx impeccable install`, puis `/impeccable init` au début de chaque nouvel effort ; l'étape de configuration ne pose des questions que sur les lacunes du contexte produit durable, au lieu de réinterroger l'équipe sur des faits déjà consignés.

À partir de là, `/impeccable craft` exécute un cycle complet de conception puis de construction avec itération en direct dans le navigateur, ce qui permet à l'agent de voir son propre rendu et de le corriger avant de rendre la main. Les commandes de revue sont celles où les règles déterministes comptent le plus : `/impeccable audit` effectue la passe technique des 61 règles — accessibilité, performance, réactivité — tandis que `/impeccable critique` reste qualitative, jugeant la hiérarchie, la clarté et la résonance émotionnelle comme le ferait un responsable design lors d'une session de critique. `/impeccable document` et `/impeccable extract` referment la boucle en générant `DESIGN.md` à partir du code existant et en extrayant les composants et jetons réutilisables vers un système partagé, ce qui compte pour les équipes qui adoptent Impeccable sur une base de code dotée d'un langage visuel déjà établi, même non documenté.

Impact sur l'industrie et perspectives

Les plus de 74 000 étoiles obtenues par Impeccable en peu de temps montrent à quel point les équipes ressentent vivement le problème d'uniformité dès lors que les outils de codage agentique écrivent eux-mêmes l'essentiel du frontend. Sa véritable contribution tient moins aux commandes individuelles qu'à l'insistance sur le fait que le contrôle de la qualité du design pour les sorties d'IA doit bénéficier de la même rigueur que les suites de tests : déterministe, reproductible et exécutable sans modèle dans la boucle pour les parties qui ne requièrent pas de jugement.

Cette séparation — critique réservée au LLM pour la moitié subjective, règles déterministes pour la moitié vérifiable — est le modèle que la plupart des outils suivants dans ce domaine sont susceptibles de reproduire, car c'est la seule approche qui échappe à l'incohérence consistant à demander au modèle qui a écrit le code de noter aussi sa propre copie. La question ouverte est de savoir jusqu'où 61 règles peuvent tenir face à l'évolution des tendances de design ; un ensemble de règles calibré sur les « tics » actuels de l'IA exigera la même discipline de maintenance que toute configuration de linter, sous peine de ne poursuivre que le dégradé d'hier pendant que les agents adoptent déjà la valeur par défaut de demain.