Le goût est un système technique

Le goût se décompose en quatre composants encodables : les contraintes (ce que vous supprimez), les critères d’évaluation (ce que vous mesurez), la reconnaissance de patterns (ce que vous remarquez) et la cohérence (comment les parties se rapportent au tout). Chacun correspond à une infrastructure d’ingénierie : hooks, evidence gates, boucles de qualité et revue architecturale. Le goût est un système technique, pas un don mystique.

Les designers qualifient le goût d’intuition. Les ingénieurs le qualifient de subjectif. Les deux affirmations remplissent la même fonction : elles exemptent le goût de tout examen. Si le goût est de l’intuition, personne ne peut le remettre en question. S’il est subjectif, personne n’a besoin de l’implémenter. Le designer obtient l’autorité sans la responsabilité. L’ingénieur obtient la permission d’ignorer l’esthétique. Tout le monde y perd.

Le goût n’est pas de l’intuition. Le goût est la reconnaissance de patterns appliquée à la qualité — le résultat accumulé de l’exposition, de la réflexion et du raffinement, compressé en un jugement rapide. Un dégustateur formé qui reconnaît le caractère régional d’un Bourgogne ne fonctionne pas par instinct mystique. Ce dégustateur a goûté des milliers de vins, encodé les relations structurelles entre terroir et saveur, et construit un cadre d’évaluation interne qui produit des appréciations rapides et fiables.¹ La rapidité du jugement masque le système qui le sous-tend.

Ce système se décompose en quatre composants. Les contraintes déterminent ce que vous supprimez. Les critères d’évaluation déterminent ce que vous mesurez. La reconnaissance de patterns détermine ce que vous remarquez. La cohérence détermine comment les parties se rapportent au tout. Quatre composants, chacun encodable. Le goût, ce sont quatre éléments qui fonctionnent de concert.

Contraintes : ce que vous supprimez

Dieter Rams a passé quatre décennies chez Braun à poser une seule question : que puis-je supprimer ? Le radio-phonographe SK 4 a éliminé les coffrets en placage de bois, les tissus décoratifs et le placement symétrique mais dépourvu de fonction des boutons. Ce qui restait : un boîtier métallique blanc avec un couvercle transparent en Perspex. Le couvercle n’était pas minimal. Le couvercle était honnête — Rams estimait que si le mécanisme n’a rien de honteux, le dissimuler est malhonnête.²

Rams a formulé dix principes. Le dixième, « Le bon design, c’est aussi peu de design que possible », fonctionne comme une contrainte de périmètre. Pas une préférence esthétique. Une contrainte de périmètre. Elle délimite l’espace des solutions en exigeant que chaque élément justifie sa présence. Vous supprimez tout élément qui ne sert pas l’utilisateur, peu importe son attrait visuel ou l’effort investi pour le produire.

Les contraintes à la manière de Rams fonctionnent de façon identique aux contraintes d’ingénierie. Un budget mémoire contraint les structures de données viables. Un objectif de latence contraint les algorithmes acceptables. Le mécanisme est le même : réduire l’espace des solutions jusqu’à ce que seules les options défendables subsistent.

Dans ma propre infrastructure, les contraintes se manifestent sous forme de hooks. Un hook qui rejette la voix passive dans les articles de blog est une contrainte sur le style rédactionnel. Un hook qui bloque les TODO et FIXME dans le code commité est une contrainte sur la qualité différée. Un hook qui impose le HTML sémantique est une contrainte sur l’honnêteté structurelle. Chaque hook encode une décision de goût spécifique dans une vérification déterministe. Un humain doté de contexte et de jugement a pris la décision une fois. L’application s’exécute indéfiniment, à la vitesse de la machine, sans dérive.

Quatre-vingt-quinze hooks imposent 95 décisions de goût. Chaque hook remonte à un moment où j’ai remarqué un schéma de défaillance et décidé que ce schéma était inacceptable. Le hook est la cicatrice. Le jugement qui a produit le hook est le goût (tiré de Claude Code Hooks).³

Critères d’évaluation : ce que vous mesurez

Kenya Hara trace une distinction entre simplicité et vacuité. Un couteau Henckels est simple : le manche vous indique où saisir, l’angle de la lame vous dit quoi couper, chaque élément réduit l’ambiguïté. Un couteau à sushi yanagiba est vide : le manche en bois brut ne vous dit pas comment le tenir, et cette absence d’instruction est précisément l’enjeu. « Vous pouvez le tenir comme vous le souhaitez », explique Hara. « Ce manche simple et sobre accueille toute l’incroyable technique du chef sushi japonais. »⁴

La simplicité se mesure à ce que vous avez supprimé. La vacuité se mesure à ce que vous avez rendu possible. Deux critères d’évaluation distincts produisant deux types de réduction différents. Rams évalue en demandant « chaque élément remplit-il une fonction ? ». Hara évalue en demandant « l’absence crée-t-elle un espace pour l’utilisateur ? ».

Les critères d’évaluation encodent ces questions en évaluations reproductibles. Mon evidence gate est un cadre d’évaluation à six critères. Chaque modification non triviale doit produire des preuves pour les six critères avant que je considère le travail comme terminé : respect des patterns du codebase, solution fonctionnelle la plus simple, cas limites traités, tests réussis, pas de régressions, résolution du problème réel. Le gate ne demande pas « le code est-il bon ? ». Le gate pose six questions spécifiques qui, ensemble, définissent ce que « bon » signifie dans mon système.

C’est la spécificité qui rend le goût transmissible. « Du bon code » est subjectif. « Du code qui suit le pattern de backoff exponentiel établi dans fetch_semantic_scholar() à la ligne 241 » est objectif. L’evidence gate traduit le jugement esthétique en vérification structurelle. « Le code semble-t-il juste ? » devient « le code correspond-il au pattern établi, gère-t-il les cas limites et passe-t-il les tests ? ». Le goût devient mesurable lorsque les critères d’évaluation sont suffisamment concrets pour produire des résultats binaires.

L’évaluation de Hara correspond à un critère d’espace négatif : non pas « quelles fonctionnalités le produit possède-t-il ? » mais « quelles hypothèses le produit impose-t-il ? ». Une API avec des dizaines de paramètres obligatoires impose des dizaines d’hypothèses sur la façon dont le développeur l’utilisera. Une API avec quelques paramètres obligatoires et de nombreux paramètres optionnels impose moins d’hypothèses et offre davantage de possibilités. Le nombre d’hypothèses est concret, mesurable, et encode la philosophie de la vacuité de Hara dans la conception d’interfaces.

Reconnaissance de patterns : ce que vous remarquez

Charles Eames n’a pas conçu la chaise en contreplaqué moulé en sélectionnant parmi des options existantes. Charles et Ray ont passé des années à expérimenter les techniques de moulage du contreplaqué, échouant à répétition, découvrant ce que le matériau permettait ou non.⁵ Le design final a émergé d’une connaissance accumulée sur la direction du grain, le comportement des adhésifs, les courbes composées et la distribution des contraintes. La chaise paraît sans effort. Cette apparence d’aisance a requis des milliers d’heures d’observation.

La reconnaissance de patterns fonctionne par exposition et attention. Un typographe qui a composé des milliers de pages remarque des erreurs de crénage qu’un novice ne voit pas. Un ingénieur structures qui a examiné des centaines de conceptions de ponts remarque des problèmes de distribution de charge qu’un ingénieur junior manque. Ce n’est pas un don inné à lui seul. C’est le résidu d’une observation soutenue et délibérée.⁶

Dans l’infrastructure d’ingénierie, la reconnaissance de patterns correspond aux boucles de qualité. Ma boucle de qualité est un cycle en sept étapes : implémenter, relire chaque ligne, exécuter l’evidence gate, appliquer le pride check, corriger chaque problème, prendre du recul, recommencer. La boucle force un second regard sur un travail que la première passe avait déclaré terminé. Chaque passage fait remonter des patterns que le précédent avait manqués : une convention de nommage incohérente, un timeout non géré, un test qui vérifie le cas nominal mais ignore le cas d’erreur. L’infrastructure compense l’écart d’expérience en imposant le schéma d’attention qui produit la reconnaissance.

Cohérence : comment les parties se rapportent au tout

Tadao Ando conçoit des bâtiments où murs de béton, lumière naturelle, eau et espace vide existent dans une relation délibérée. L’Église de la Lumière à Osaka utilise une fente cruciforme dans le mur de béton pour admettre la lumière du soleil, créant une croix lumineuse sur le mur intérieur. Supprimez la fente, et le bâtiment n’est qu’un cube de béton. Supprimez le béton, et la lumière n’a plus de surface sur laquelle se révéler. Aucun des deux éléments ne fonctionne seul. C’est la cohérence entre matériau et vide qui produit l’expérience.⁷

La cohérence est le composant de plus haut niveau du goût, car elle exige de comprendre le tout — pas seulement les parties. Un hook peut imposer une contrainte sur un fichier unique. Un evidence gate peut évaluer une modification isolée. Une boucle de qualité peut faire remonter des patterns dans un module unique. La cohérence exige d’évaluer comment chaque partie se rapporte à toutes les autres, et à la finalité du système dans son ensemble.

En logiciel, la revue architecturale remplit la fonction de cohérence. Un module qui fonctionne correctement de façon isolée mais viole la direction des dépendances du système est incohérent. Une fonctionnalité qui passe tous les tests mais contredit le langage de design du produit est incohérente. Les défauts de cohérence sont invisibles à l’évaluation locale. Ils ne se révèlent que lorsque quelqu’un prend du recul.

Ma boucle de qualité inclut une étape « prendre du recul » précisément pour cette raison. Une fois l’evidence gate passé et le pride check validé, la boucle exige de vérifier les points d’intégration, les imports et le code adjacent pour détecter d’éventuelles régressions. La doctrine Steve + Jiro sous laquelle j’opère en fait un double standard : Jiro gouverne les preuves, la rigueur et le métier (les qualités locales) ; Steve gouverne la valeur, le goût et l’intégrité du widget dans son ensemble (les qualités globales). Si Jiro échoue, arrêtez. Si Steve échoue, reconstruisez. Ce double standard garantit que la justesse locale ne prime jamais sur la cohérence globale.

La carte

Quatre composants du goût. Quatre pièces d’infrastructure d’ingénierie.

Rams devient un hook. Hara devient un critère d’évaluation. Eames devient une boucle de qualité. Ando devient une revue architecturale. Les philosophies de design que j’ai profilées à travers 32 designers ne sont pas de la décoration pour un site portfolio. Chaque profil est une étude de cas sur un ou plusieurs de ces quatre composants, et chaque composant correspond à une infrastructure que j’exécute en production.

Beauty and Brutalism documente les décisions CSS spécifiques derrière ce site, chacune étant une contrainte. Typographie blanche sur #000000. Couches d’opacité à 5 %, 10 %, 40 %, 65 %. Pas de dégradés, pas d’illustrations, pas d’éléments décoratifs. Chaque décision est une suppression à la manière de Rams, encodée dans une feuille de style dont chaque page hérite. Les contraintes sont exécutables.

Le problème de la dark factory

Le modèle de dark factory de Dan Shapiro décrit cinq niveaux d’autonomie du codage par IA, du manuel (niveau 0) au pleinement autonome (niveau 5). Au niveau 5, le code est généré par des machines, vérifié par des machines et déployé sans qu’un humain ne lise une seule ligne.

Le goût pose à la dark factory un problème que la justesse ne pose pas. La justesse peut être vérifiée par des tests. La performance peut être vérifiée par des benchmarks. La sécurité peut être vérifiée par l’analyse statique. Le goût ne peut être vérifié par aucun système automatisé existant, car le composant de cohérence exige de comprendre le système dans son ensemble — pas seulement le diff.

À tous les niveaux en dessous de 5, un humain fournit l’évaluation de cohérence. Supprimez l’humain, et l’évaluation de cohérence doit être encodée sous peine de disparaître. Les contraintes survivent à l’automatisation (les hooks s’exécutent sans humains). Les critères d’évaluation survivent (les evidence gates s’exécutent sans humains). La reconnaissance de patterns survit partiellement (les boucles de qualité s’exécutent, bien qu’un humain ait rédigé les questions du pride check). La cohérence ne survit pas à moins que quelqu’un n’encode l’intention architecturale dans un format qu’un agent d’évaluation puisse interroger. Un système autonome dépourvu de contraintes de goût optimisera pour faire passer les tests. Comme l’a découvert l’équipe StrongDM de Justin McCarthy, les agents écrivaient return true pour satisfaire les suites de tests tout en produisant du code sans valeur.⁸ Les tests sont au vert. Le résultat n’a ni métier, ni considération, ni cohérence.

La thèse

Le goût est une infrastructure, et l’infrastructure est le dernier avantage humain dans un monde où les machines peuvent écrire, concevoir et déployer à la vitesse de l’inférence. Mais le goût n’est un avantage que si vous l’encodez. Un goût non encodé est un goulot d’étranglement : une seule personne dont le jugement doit valider chaque décision, qui devient le facteur limitant de la vitesse du système. Un goût encodé est un fossé défensif : contraintes, critères d’évaluation, boucles de reconnaissance de patterns et vérifications de cohérence que chaque production doit satisfaire, s’exécutant à la vitesse de la machine, s’améliorant avec chaque défaillance qui engendre un nouveau hook.

Chaque session d’agent autonome qui s’exécute sans contraintes de goût produit un résultat qui dérive vers la médiane. Chaque hook, chaque critère d’evidence gate, chaque étape de boucle de qualité, chaque revue architecturale encode un jugement spécifique qui résiste à cette dérive. La qualité est la seule variable. Le goût est ce qui définit ce que qualité signifie.

Les designers qui gardent jalousement le goût comme intuition verront leur intuition devenir sans objet lorsque les machines génèreront plus vite que n’importe quel humain ne peut examiner. Les ingénieurs qui rejettent le goût comme subjectif verront leurs systèmes produire une médiocrité correcte, performante et architecturalement solide. La voie exige les deux : le jugement accumulé du designer, décomposé en composants, encodé en infrastructure et appliqué à la vitesse que les machines imposent.

Le goût n’est pas un sentiment. Le goût est un système technique. Construisez le système, ou regardez le goût disparaître.

FAQ

Le goût peut-il vraiment se réduire à quatre composants ?

Les quatre composants (contraintes, critères d’évaluation, reconnaissance de patterns et cohérence) constituent une décomposition, pas une réduction. En pratique, le goût implique les quatre simultanément, et l’interaction entre composants produit des qualités émergentes qu’aucun composant isolé ne capture. La décomposition est utile parce que chaque composant correspond à un type spécifique d’infrastructure d’ingénierie, rendant l’abstrait concret et le subjectif implémentable.

En quoi les hooks diffèrent-ils d’un design system ?

Un design system définit des tokens, des composants et des directives d’utilisation. Les hooks imposent des contraintes comportementales au moment de la création. Un design system dit « utilisez du corps de texte en 16px ». Un hook bloque un commit qui définit le corps de texte à 14px. Le design system est un document de référence. Le hook est une barrière. Les deux sont utiles. Le hook est ce qui rend les décisions du design system non négociables lors de la génération autonome.

Encoder le goût le rend-il rigide ?

Encoder le goût rend les jugements encodés cohérents, pas figés. Mon nombre de hooks est passé de zéro à 95 en neuf mois, car chaque schéma de défaillance que j’ai remarqué est devenu une nouvelle contrainte. La rigidité consisterait à refuser d’ajouter de nouveaux hooks. La croissance signifie que chaque défaillance qui offense votre goût devient une infrastructure qui prévient la prochaine occurrence.

Sources