La stack d'agents du design engineer

Les design engineers ont besoin d’une stack d’agents différente de celle 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 encore construit l’équivalent pour la qualité du design — une infrastructure qui garantit que les agents produisent un travail qui semble réfléchi, et non simplement fonctionnel. Les six composants de la stack d’agents du design engineer sont les hooks typographiques, les hooks de système de couleurs, la validation de mise en page, les portes 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é chaque test, satisfait chaque vérification de type, et produit un résultat 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 portes d’évidence 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é de typage — 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 motifs et la cohérence. Les trois premiers correspondent directement à une infrastructure automatisée. La cohérence nécessite le jugement humain, mais les trois premiers couvrent suffisamment de terrain pour prévenir les défaillances de design les plus courantes produites par un agent. Les violations typographiques, la dérive des couleurs, l’instabilité de mise en page, les régressions de performance et les défaillances d’accessibilité sont toutes détectables par les machines. La 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 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 palier de l’échelle typographique. Aucune taille non prévue. 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 palier qui n’existe pas dans l’échelle, et la hiérarchie visuelle se fracture.

Conformité du système de couleurs. Chaque valeur de couleur fait référence à un token de design. Aucune valeur hexadécimale codée en dur en dehors de :root. Les ratios de contraste atteignent au minimum le niveau AA de WCAG, AAA dans la mesure du possible. Le système zéro-couleur de mon site utilise quatre paliers d’opacité sur du noir absolu, et chaque palier atteint le niveau 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 — une modification de CSS qui déclenche un recalcul de mise en page à chaque événement de défilement est un bug de performance, peu importe l’apparence du changement.

Accessibilité. Structure HTML sémantique. Hiérarchie correcte des titres. Attributs ARIA là où c’est nécessaire, absents là où ça 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 également maintenir la sémantique structurelle que les outils automatisés manquent.

Le goût. Le plus difficile à encoder. La cohérence entre les éléments. La retenue dans la décoration. L’espace blanc intentionnel plutôt que le vide accidentel. Le goût est la qualité qui distingue une mise en page qui suit chaque règle mais sonne faux d’une mise en page qui suit chaque règle et sonne 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 de la stack du design engineer

Chaque composant correspond à un mode de défaillance spécifique que j’ai observé dans les productions générées par des 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 fait 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 palier 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 palier de l’échelle à 13 paliers. L’essentiel n’est pas la sophistication. L’essentiel est que l’agent ne peut pas introduire une taille de police non prévue sans que l’infrastructure ne le signale. Le principe de Bringhurst sur les relations typographiques harmonieuses tient non pas 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 de 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 des agents. L’agent sait que le texte doit être blanc sur 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 couleur analyse les valeurs de couleur 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 anime toute l’identité visuelle du site — rend l’application des règles simple parce que la palette compte exactement dix tokens. Toute valeur de couleur qui ne correspond pas à l’un de ces tokens est erronée par définition. Une palette plus large nécessiterait une validation plus nuancée. L’approche fondée sur les 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éfaillance : le Cumulative Layout Shift introduit par les modifications CSS, et les régressions aux points de rupture responsive.

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 Chrome headless contre le déploiement de staging, compare les valeurs de CLS avec le build précédent, et bloque le merge si le delta dépasse 0,01. Google considère un CLS inférieur à 0,1 comme « bon ». Mon seuil est 10 fois plus strict parce que j’ai vu ce que donne un CLS de 0,493 et 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 (desktop), 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îtra dans la comparaison mobile. L’agent qui a modifié une propriété max-width sans tester le comportement responsive est détecté par l’infrastructure qui teste automatiquement le comportement responsive.

4. Portes Lighthouse

Une porte Lighthouse exécute un audit complet avant chaque merge vers la branche principale. La porte impose quatre seuils :

Les seuils ne sont pas des aspirations. Ils reflètent les scores de production actuels. Tout commit qui fait baisser un score en dessous de 100 est bloqué. La porte s’exécute en CI via lighthouse-ci, et les résultats sont renvoyés dans la pull request sous forme de status check.

# 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 }]

La porte 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 provoque un flash de contenu non stylisé échouera à la porte avant que le changement n’atteigne la production. La porte ne comprend pas pourquoi le changement a causé une régression. La porte n’a pas besoin de comprendre. La porte 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 AA de WCAG 2.1 détecte les textes alternatifs manquants, la hiérarchie incorrecte des titres, le contraste de couleurs insuffisant, les labels de formulaire manquants et l’utilisation incorrecte d’ARIA. La vérification s’exécute dans la même instance de Chrome headless que la porte Lighthouse, ajoutant une charge 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 du lecteur d’écran pour les changements d’état. Ces vérifications nécessitent une interaction scriptée, pas une simple inspection du DOM. L’approche sans build maintient 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 derrière 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 du build actuel à des références approuvées. La comparaison utilise des algorithmes de diffing perceptuel 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’anti-aliasing).

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 le diffing perceptuel contre la référence, et signale toute page où la différence dépasse le seuil. Une différence de 0,1 % des pixels dans un pied de page est du bruit. Un décalage de 2 % dans la section hero 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 ? » Le diffing perceptuel 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 la stack s’articule avec mon infrastructure

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

Les hooks typographiques imposent l’échelle typographique à 13 paliers — une progression orientée 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 de système de couleurs imposent le système de design zéro-couleur : dix tokens, quatre paliers d’opacité, aucune couleur de marque, non optionnel. Les portes 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 de la stack. Pas de source maps à réconcilier. Pas d’ambiguïté de tree-shaking. Pas de 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.

La porte d’évidence s’applique aux revues de design de la même manière qu’aux revues d’ingénierie. « La typographie a l’air 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 sont des suggestions. Nathan Curtis a identifié cette 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 couleur détectent les valeurs codées en dur. La validation de mise en page détecte le CLS. Les portes 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 le résultat qui suit chaque règle mais sonne faux.

Un composant carte avec des tailles de police correctes, des tokens appropriés, zéro CLS, des scores Lighthouse parfaits, une conformité WCAG totale, et aucune régression visuelle — mais avec un espacement qui fait que le titre s’écrase contre l’image, une longueur de ligne qui fatigue la lecture, et un état hover qui semble brusque plutôt que réfléchi. 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 motifs 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 motifs et la cohérence nécessitent la boucle de qualité — les passes obligatoires, deuxième (et troisième, et quatrième) à 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à où le design engineer mérite 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 apposerait-il sa signature sur ceci ?

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 la stack produit un résultat qui dérive. Les tailles de police s’accumulent en dehors de l’échelle. Les valeurs de couleur sont codées en dur au lieu d’être tokenisées. La performance régresse par petits incréments qu’aucun commit individuel ne déclenche mais qui s’accumulent sur des semaines. La dérive est invisible dans n’importe quel diff individuel et évidente dans l’agrégat.

Une session d’agent avec la stack ne peut pas dériver. Chaque déviation de l’échelle typographique est bloquée. Chaque couleur codée en dur est rejetée. Chaque régression de performance est détectée. L’agent hérite des standards du design engineer non pas parce que l’agent 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é.³ La stack d’agents du design engineer opérationnalise la même idée. Les principes sont fixés dans des tokens, des échelles et des seuils. Le raffinement est implacable parce que l’automatisation s’exécute à chaque commit.

Le design engineer qui encode des standards dans la stack d’agents ne fait pas que maintenir la qualité pendant la génération autonome. Il 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 le résultat mérite d’être livré. Mais l’humain ne détecte plus les violations de taille de police, les couleurs codées en dur ou les régressions CLS. La stack les a détectées en premier. L’attention de l’humain se porte entièrement sur les questions auxquelles les machines ne peuvent pas répondre.

FAQ

Ai-je besoin des six composants pour commencer ?

Non. Commencez par le composant qui traite votre mode de défaillance le plus courant. Les hooks typographiques et les hooks de système de couleurs offrent le meilleur retour car ils détectent les défauts de design générés par les agents les plus fréquents. Ajoutez ensuite les portes 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.

La stack fonctionne-t-elle avec des outils de build ?

La 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 sources 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 la stack ?

Les modèles de langage actuels n’ont pas de goût. Les modèles produisent des résultats statistiquement probables, et les résultats statistiquement probables tendent vers la médiane des données d’entraînement. La stack n’enseigne pas le goût aux agents. La stack contraint les agents de sorte que les résultats sans goût soient rejetés avant d’être livrés. La distinction est importante : encoder le goût sous forme d’infrastructure est 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 remonter le changement non intentionnel. Un agent qui modifie la couleur d’un bouton décale également 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