Le stack d'agents du design engineer

Les design engineers ont besoin d’un stack d’agents différent de celui des ingénieurs purs. L’infrastructure d’agents standard optimise la correction : les tests passent, les types sont vérifiés, les règles de linting tiennent. Personne n’a construit l’équivalent pour la qualité du design — l’infrastructure qui garantit que les agents produisent un travail soigné, pas simplement fonctionnel. Les six composants du stack d’agents du design engineer sont les hooks typographiques, les hooks du système de couleurs, la validation de mise en page, les gates Lighthouse, le linting d’accessibilité et les tests de régression visuelle. Ensemble, ils encodent le savoir-faire dans le pipeline.

L’écart est visible dans chaque interface générée par l’IA. L’espacement est incohérent. Les tailles de police dérivent hors de l’échelle. Des valeurs hexadécimales codées en dur contournent le système de tokens. Des décalages de mise en page apparaissent sur mobile parce que personne n’a vérifié le CLS après que l’agent a modifié le CSS. L’agent a passé tous les tests, satisfait chaque vérification de type et produit une sortie qu’un réviseur de code approuverait — parce que les réviseurs de code évaluent la logique, pas la cohérence visuelle. Le design engineer remarque les problèmes immédiatement. L’infrastructure d’agents ne remarque rien, parce que personne ne lui a dit quoi chercher.

L’infrastructure d’agents pour les ingénieurs a mûri rapidement. Les hooks bloquent les commandes git dangereuses. Les evidence gates exigent des preuves avant de marquer un travail comme terminé. Les boucles de qualité imposent la relecture de chaque ligne. La qualité d’ingénierie se décompose en propriétés vérifiables (correction, performance, sécurité, sûreté des types), et chaque propriété correspond à un outil qui produit des résultats binaires.

La qualité du design se décompose aussi. Le goût est un système technique avec quatre composants encodables : les contraintes, les critères d’évaluation, la reconnaissance de patterns et la cohérence. Les trois premiers correspondent directement à une infrastructure automatisée. La cohérence nécessite un jugement humain, mais ces trois premiers couvrent suffisamment de terrain pour prévenir les défaillances de design les plus courantes qu’un agent produit. Les violations typographiques, la dérive des couleurs, l’instabilité de mise en page, les régressions de performance et les échecs d’accessibilité sont tous détectables par des machines. Le stack d’agents du design engineer les détecte.

Ce dont les design engineers ont besoin des agents

Un ingénieur pur demande : le code fonctionne-t-il ? Un design engineer pose six questions supplémentaires, chacune ciblant une dimension différente de la qualité visuelle.

Cohérence visuelle. Les valeurs d’espacement suivent la grille de 8 points ou l’échelle d’espacement définie. L’alignement respecte le rythme vertical. Les relations proportionnelles entre les éléments restent stables à travers les tailles de viewport. Un agent qui ajoute un nouveau composant carte en utilisant margin-top: 13px au lieu de var(--space-md) a introduit du bruit visuel qu’aucun test ne détectera.

Discipline typographique. Chaque taille de police dans la base de code correspond à un échelon de l’échelle typographique. Aucune taille parasite. Aucun remplacement inline qui contourne les propriétés personnalisées. L’utilisation des graisses suit la hiérarchie établie : 700 pour les titres, 400 pour le corps, 300 pour les métadonnées. Un agent qui définit un sous-titre à font-size: 19px a inventé un échelon qui n’existe pas dans l’échelle, et la hiérarchie visuelle se fracture.

Conformité du système de couleurs. Chaque valeur de couleur référence un token de design. Aucune valeur hexadécimale codée en dur en dehors de :root. Les ratios de contraste respectent au minimum le niveau AA de WCAG, AAA dans la mesure du possible. Le système zéro couleur de mon site utilise quatre niveaux d’opacité sur un noir absolu, et chaque niveau passe le AAA. Un agent qui introduit color: #cccccc a contourné le système de tokens et créé une relation de contraste que personne n’a validée.

Conscience de la performance. Aucun Cumulative Layout Shift. Le First Contentful Paint reste dans le budget. Le Total Blocking Time ne régresse pas. L’agent doit comprendre que les changements visuels ont des conséquences sur la performance. Un changement de CSS qui déclenche un recalcul de mise en page à chaque événement de défilement est un bug de performance, indépendamment de l’apparence du changement.

Accessibilité. Structure HTML sémantique. Hiérarchie de titres correcte. Attributs ARIA là où c’est nécessaire, absents là où ce ne l’est pas. Vérification du contraste des couleurs. Indicateurs de focus. Compatibilité avec les lecteurs d’écran. L’audit Lighthouse détecte le sous-ensemble mesurable, mais l’agent doit aussi maintenir la sémantique structurelle que les outils automatisés manquent.

Goût. Le plus difficile à encoder. Cohérence entre les éléments. Retenue dans la décoration. Espace blanc intentionnel plutôt que vide accidentel. Le goût est la qualité qui distingue une mise en page qui suit chaque règle mais semble fausse d’une mise en page qui suit chaque règle et semble juste. Les vérifications automatisées détectent les violations. La couche de goût détecte les non-violations qui manquent néanmoins de considération.

Six composants du stack du design engineer

Chaque composant correspond à un mode de défaillance spécifique que j’ai observé dans la production générée par les agents. Les composants ne sont pas théoriques. Chacun existe parce que quelque chose a mal tourné — la même genèse que chaque hook dans mon infrastructure de 95 hooks.

1. Hooks typographiques

Un hook typographique valide que chaque déclaration font-size dans un commit référence une propriété personnalisée CSS de l’échelle typographique. Le hook analyse les fichiers modifiés à la recherche de valeurs brutes en pixels ou rem qui ne correspondent pas à un échelon défini.

#!/bin/bash
INPUT=$(cat)
DIFF=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Catch font-size declarations that bypass the type scale
if echo "$DIFF" | grep -qE 'font-size:\s*[0-9]+(px|rem|em)'; then
  cat << EOF
{"decision": "block", "reason": "Font size must use a --font-size-* token"}
EOF
fi

Le hook est rudimentaire. Une version plus raffinée analyse la valeur et vérifie si l’équivalent en pixels correspond à un échelon de l’échelle à 13 niveaux. L’enjeu n’est pas la sophistication. L’enjeu est que l’agent ne peut pas introduire une taille de police parasite sans que l’infrastructure la signale. Le principe de Bringhurst sur les relations typographiques harmonieuses tient — non parce que l’agent comprend l’harmonie, mais parce que le hook impose l’échelle qui l’incarne.¹

La graisse de police mérite une validation séparée. Mon système utilise trois graisses : 700, 400 et 300. Un agent qui définit un titre de carte à font-weight: 600 a introduit une graisse qui contredit la hiérarchie établie. Un hook typographique détecte la déviation avant qu’elle n’atteigne la production.

2. Hooks du système de couleurs

La dérive des couleurs est la défaillance de design la plus courante dans le CSS généré par les agents. L’agent sait que le texte devrait être blanc sur un fond sombre. L’agent ne sait pas que #ffffff devrait être var(--color-text-primary), ou que le texte secondaire à 65 % d’opacité est var(--color-text-secondary) et non rgba(255,255,255,0.60).

Le hook de couleurs analyse les valeurs de couleurs codées en dur en dehors de :root et des définitions de tokens de design :

# Block hardcoded colors outside token definitions
if echo "$DIFF" | grep -vE '^\+.*:root' | \
   grep -qE '#[0-9a-fA-F]{3,8}|rgba?\('; then
  cat << EOF
{"decision": "block", "reason": "Use color tokens, not hardcoded values"}
EOF
fi

Le système de design zéro couleur, la même contrainte brutaliste qui pilote l’identité visuelle de l’ensemble du site, rend l’application straightforward parce que la palette comporte exactement dix tokens. Toute valeur de couleur qui ne correspond pas à l’un de ces tokens est fausse par définition. Une palette plus large nécessiterait une validation plus nuancée. L’approche par contraintes simplifie le hook parce que la contrainte simplifie le design.

3. Validation de mise en page

La validation de mise en page détecte deux catégories de défaillances : le Cumulative Layout Shift introduit par les changements CSS, et les régressions de points de rupture responsifs.

La détection du CLS nécessite de mesurer la page avant et après le changement. Un hook pre-commit ne peut pas lancer un navigateur, mais un pipeline CI le peut. L’infrastructure exécute Lighthouse dans un Chrome headless contre le déploiement de staging, compare les valeurs de CLS à la build précédente et bloque le merge si le delta dépasse 0,01. Google considère un CLS en dessous de 0,1 comme « bon ». Mon seuil est 10 fois plus strict parce que j’ai vu à quoi ressemble un CLS de 0,493 et je refuse de régresser.

La validation responsive nécessite de vérifier la mise en page aux points de rupture définis. Un outil de régression visuelle capture des captures d’écran à 375px (mobile), 768px (tablette) et 1440px (bureau), puis les compare aux images de référence. Un décalage de cinq pixels dans l’en-tête à 375px qui semble correct à 1440px apparaît dans la comparaison mobile. L’agent qui a modifié une propriété max-width sans tester le comportement responsif est détecté par l’infrastructure qui teste automatiquement le comportement responsif.

4. Gates Lighthouse

Un gate Lighthouse exécute un audit complet avant chaque merge vers la branche principale. Le gate impose quatre seuils :

Les seuils ne sont pas aspirationnels. Ils reflètent les scores de production actuels. Tout commit qui fait baisser un score en dessous de 100 est bloqué. Le gate s’exécute en CI à l’aide de lighthouse-ci, et les résultats sont renvoyés dans la pull request comme vérification de statut.

# lighthouse-ci configuration
assertions:
  performance: ["error", { minScore: 1 }]
  accessibility: ["error", { minScore: 1 }]
  best-practices: ["error", { minScore: 1 }]
  seo: ["error", { minScore: 1 }]
  cumulative-layout-shift: ["error", { maxNumericValue: 0.01 }]

Le gate Lighthouse détecte les régressions de performance qu’aucun réviseur humain ne remarquerait. Un agent qui ajoute une image non optimisée, un script bloquant le rendu ou un fichier CSS qui déclenche un flash de contenu non stylisé échoue au gate avant que le changement n’atteigne la production. Le gate ne comprend pas pourquoi le changement a causé une régression. Le gate n’a pas besoin de comprendre. Il bloque la régression, et l’agent reçoit la raison de l’échec dans son contexte pour la tentative suivante.

5. Linting d’accessibilité

La validation d’accessibilité se divise en deux couches : l’analyse statique et l’évaluation à l’exécution.

L’analyse statique exécute axe-core contre le HTML rendu. Le jeu de règles WCAG 2.1 AA détecte les textes alternatifs manquants, la hiérarchie de titres incorrecte, le contraste de couleurs insuffisant, les labels de formulaires manquants et les mauvais usages d’ARIA. La vérification s’exécute dans la même instance de Chrome headless que le gate Lighthouse et n’ajoute qu’un surcoût négligeable.

// axe-core integration in CI
const { AxeBuilder } = require('@axe-core/playwright');
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
  .analyze();

if (results.violations.length > 0) {
  process.exit(1); // Block the merge
}

La couche d’exécution détecte les problèmes que l’analyse statique manque : la gestion du focus après les échanges HTMX, la navigation au clavier dans le contenu dynamique, les annonces de lecteur d’écran pour les changements d’état. Ces vérifications nécessitent une interaction scriptée, pas seulement une inspection du DOM. L’approche sans build garde la page suffisamment simple pour que la surface d’accessibilité reste gérable.

Le linting d’accessibilité est le composant que la plupart des ingénieurs comprennent déjà. L’apport du design engineer n’est pas l’outillage mais le seuil : zéro violation, pas des violations « acceptables ». La même philosophie anime les scores Lighthouse 100/100/100/100 : la perfection comme référence, pas comme aspiration.

6. Tests de régression visuelle

Les tests de régression visuelle comparent des captures d’écran de la build actuelle aux références approuvées. La comparaison utilise des algorithmes de différence perceptuelle qui détectent les changements qu’un humain remarquerait tout en ignorant ceux qu’il ne remarquerait pas (différences de rendu sous-pixel, variations d’anticrénelage).

Des outils comme Percy, Chromatic et BackstopJS automatisent la comparaison. Le pipeline capture des captures d’écran à chaque point de rupture défini, exécute la différence perceptuelle contre la référence et signale toute page où la différence dépasse le seuil. Une différence de 0,1 % en pixels dans un pied de page est du bruit. Un décalage de 2 % dans la section héro est une régression.

La régression visuelle est l’approximation automatisée la plus proche de « la page a-t-elle l’air correcte ? » La différence perceptuelle ne peut pas évaluer si un changement de mise en page est une amélioration ou une dégradation — seulement qu’un changement s’est produit. L’humain examine les différences signalées et les approuve ou les rejette. La valeur de l’automatisation réside dans la couverture : tester chaque page à chaque point de rupture à chaque commit, une tâche qu’aucun humain n’effectue manuellement.

Comment le stack s’articule avec mon infrastructure

Les six composants se connectent à des décisions déjà documentées à travers le contenu sur le design engineering de ce site.

Les hooks typographiques imposent l’échelle typographique à 13 niveaux, une progression guidée par le contenu où l’échelle existe sous forme de propriétés personnalisées CSS et les hooks garantissent que ces propriétés sont les seules tailles de police dans la base de code. Les hooks du système de couleurs imposent le système de design zéro couleur : dix tokens, quatre niveaux d’opacité, aucune couleur de marque, non négociable. Les gates Lighthouse maintiennent le score 100/100/100/100 et empêchent tout commit d’annuler l’extraction CSS et l’élimination du blocage de rendu qui ont permis d’atteindre ces chiffres.

L’approche sans build simplifie l’ensemble du stack. Aucun source map à réconcilier. Aucune ambiguïté de tree-shaking. Aucune couche de transpilation entre le CSS écrit et celui livré. Ce que l’agent écrit est ce qui est livré, ce qui signifie que ce que les hooks valident est ce que l’utilisateur voit.

L’evidence gate s’applique aux revues de design de la même manière qu’il s’applique aux revues d’ingénierie. « La typographie semble correcte » n’est pas une preuve. « Chaque déclaration font-size dans le diff correspond à un token --font-size-*, vérifié par le hook typographique » est une preuve. Le système de design fournit les tokens que les hooks imposent. Sans tokens, il n’y a rien à valider. Sans hooks, les tokens ne sont que des suggestions. Nathan Curtis a identifié la dynamique : un système sans gouvernance se dégrade en documentation que personne ne lit.²

La couche de goût

Les six composants détectent les violations. Les hooks typographiques détectent les mauvaises tailles de police. Les hooks de couleurs détectent les valeurs codées en dur. La validation de mise en page détecte le CLS. Les gates Lighthouse détectent les régressions de performance. Le linting d’accessibilité détecte les défaillances WCAG. La régression visuelle détecte les changements non intentionnels.

Aucun de ces composants ne détecte la production qui suit chaque règle mais semble néanmoins fausse.

Un composant carte avec des tailles de police correctes, des tokens appropriés, zéro CLS, des scores Lighthouse parfaits, une conformité WCAG complète et aucune régression visuelle — mais avec un espacement qui fait que le titre écrase l’image, une longueur de ligne qui fatigue la lecture, et un état de survol qui semble abrupt plutôt que considéré. Chaque vérification automatisée passe. La carte est correcte. La carte n’est pas bonne.

Le goût opère au-dessus de la couche de règles. Les contraintes détectent ce qui viole les règles. Les critères d’évaluation détectent ce qui échoue aux métriques. La reconnaissance de patterns détecte ce que le second regard révèle. La cohérence détecte ce que seule la vision d’ensemble expose. Les six composants automatisés gèrent les contraintes et les critères d’évaluation. La reconnaissance de patterns et la cohérence nécessitent la boucle de qualité : le second (puis le troisième, puis le quatrième) passage obligatoire à travers le travail, vérifiant à chaque fois non pas si les règles tiennent, mais si le résultat mérite d’être livré.

La boucle de qualité est l’endroit où le design engineer gagne la moitié « engineer » de son titre. Un ingénieur qui livre du code qui passe les tests fait le minimum. Un design engineer qui livre des interfaces qui passent les vérifications automatisées et survivent à la boucle de qualité maintient un standard que les machines ne peuvent pas encore évaluer. Le pride check pose cinq questions, et la dernière (« l’ai-je laissé en meilleur état ? ») n’a pas d’équivalent automatisé. Pas plus que le critère Steve : Blake signerait-il son nom sur ce travail ?

L’effet composé

Chaque composant prévient une catégorie spécifique de défaillance de design. Ensemble, les composants produisent un effet composé qui dépasse la somme des vérifications individuelles.

Une session d’agent sans le stack produit une sortie qui dérive. Les tailles de police s’accumulent hors de l’échelle. Les valeurs de couleur se codent en dur au lieu de se tokeniser. La performance régresse par petits incréments qu’aucun commit individuel ne déclenche mais qui s’accumulent au fil des semaines. La dérive est invisible dans n’importe quel diff individuel et évidente dans l’agrégat.

Une session d’agent avec le stack ne peut pas dériver. Les hooks bloquent chaque déviation de l’échelle typographique. Le système de couleurs rejette chaque valeur codée en dur. Le gate Lighthouse détecte chaque régression de performance. L’agent hérite des standards du design engineer non parce qu’il comprend ces standards, mais parce que l’infrastructure les impose. L’agent n’a pas besoin de goût. L’agent a besoin de contraintes, et les contraintes incarnent le goût.

Jony Ive a décrit le processus de design d’Apple comme un « raffinement implacable » : la qualité par l’itération sur un ensemble fixe de principes, pas l’innovation par la nouveauté.³ Le stack d’agents du design engineer opérationnalise la même idée. Les principes sont fixés dans les tokens, les échelles et les seuils. Le raffinement est implacable parce que l’automatisation s’exécute à chaque commit.

Le design engineer qui encode ses standards dans le stack d’agents fait plus que maintenir la qualité pendant la génération autonome. Cet ingénieur met la qualité à l’échelle. Chaque session, chaque agent, chaque commit hérite des mêmes contraintes. L’humain évalue toujours la cohérence, exécute toujours la boucle de qualité, se demande toujours si la production mérite d’être livrée. Mais l’humain ne détecte plus les violations de tailles de police, les couleurs codées en dur ou les régressions CLS. Le stack les a détectées en premier. L’attention de l’humain se consacre entièrement aux questions auxquelles les machines ne peuvent pas répondre.

FAQ

Faut-il les six composants pour commencer ?

Non. Commencez par le composant qui répond à votre mode de défaillance le plus courant. Les hooks typographiques et les hooks du système de couleurs offrent le meilleur retour parce qu’ils détectent les défauts de design générés par les agents les plus fréquents. Ajoutez ensuite les gates Lighthouse et le linting d’accessibilité. La régression visuelle et la validation de mise en page sont les composants les plus lourds en infrastructure et appartiennent à une phase ultérieure de la séquence d’adoption.

Le stack fonctionne-t-il avec des outils de build ?

Le stack fonctionne avec n’importe quelle architecture frontend. L’approche sans build simplifie l’implémentation parce qu’il n’y a pas de couche de transformation entre le code écrit et le code livré. Avec des outils de build, les hooks doivent valider les fichiers source tandis que Lighthouse et la régression visuelle valident la sortie compilée. Les composants restent les mêmes. Les points d’intégration changent.

Les agents peuvent-ils apprendre le goût sans le stack ?

Les modèles de langage actuels n’ont pas de goût. Les modèles produisent une sortie statistiquement probable, et une sortie statistiquement probable tend vers la médiane des données d’entraînement. Le stack n’enseigne pas le goût aux agents. Le stack contraint les agents de sorte que le pipeline rejette la production sans goût avant qu’elle ne soit livrée. La distinction compte : encoder le goût en tant qu’infrastructure s’avère plus fiable qu’espérer que le modèle l’intériorise à partir du prompt.

Comment les tests de régression visuelle gèrent-ils les changements intentionnels ?

Les changements intentionnels produisent des différences visuelles attendues. Le workflow signale les différences, et l’humain les examine et les approuve, mettant à jour la référence. La valeur de la régression visuelle n’est pas d’empêcher le changement, mais de faire apparaître le changement non intentionnel. Un agent qui modifie la couleur d’un bouton décale aussi la mise en page de la carte de trois pixels. Le changement de couleur est intentionnel, le décalage de mise en page ne l’est pas, et le test de régression visuelle détecte l’effet de bord.

Sources