Le goût est un système technique

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 motifs appliquée à la qualité — le résultat accumulé de l’exposition, de la réflexion et du raffinement, compressé en un jugement rapide. Un sommelier qui identifie un Bourgogne à l’aveugle ne fonctionne pas par instinct mystique. Ce sommelier a dégusté des milliers de vins, encodé les relations structurelles entre terroir et saveur, et construit un cadre d’évaluation interne qui produit des jugements rapides et précis.¹ La vitesse du jugement masque le système qui le sous-tend.

Ce système peut être décomposé. Les contraintes déterminent ce que vous retirez. Les critères d’évaluation déterminent ce que vous mesurez. La reconnaissance de motifs 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.

Les contraintes : ce que vous retirez

Dieter Rams a passé 42 ans chez Braun à poser une seule question : que puis-je retirer ? Le radio-phonographe SK 4 a éliminé les coffrets en placage bois, les tissus décoratifs et les boutons disposés symétriquement mais sans fonction. Ce qui restait : un boîtier métallique blanc surmonté d’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 est aussi peu de design que possible » — fonctionne comme une contrainte de périmètre. Non pas une préférence esthétique. Une contrainte de périmètre. Elle borne l’espace des solutions en exigeant que chaque élément justifie sa présence. Un élément qui ne sert pas l’utilisateur est retiré, peu importe son attrait visuel ou l’effort investi pour le produire.

Les contraintes à la Rams fonctionnent de manière 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 en une vérification déterministe. La décision a été prise une fois, par un humain doté de contexte et de jugement. L’application s’exécute indéfiniment, à la vitesse de la machine, sans dérive.

Quatre-vingt-quinze hooks appliquent 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.³

Les critères d’évaluation : ce que vous mesurez

Kenya Hara établit une distinction entre simplicité et vacuité. Un couteau Henckels est simple : le manche vous indique où le 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 prescrit pas comment le tenir, et cette absence d’instruction est précisément ce qui fait tout son intérêt. « 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 par ce que vous avez retiré. La vacuité se mesure par ce que vous avez rendu possible. Deux critères d’évaluation différents 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. Toute modification non triviale doit fournir des preuves pour les six critères avant que le travail ne soit marqué comme terminé : respecte les conventions du codebase, solution fonctionnelle la plus simple, cas limites traités, tests réussis, pas de régressions, résout le problème réel. Le portail ne demande pas « le code est-il bon ? » Il 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 correct ? » 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 47 paramètres obligatoires impose 47 hypothèses sur la façon dont le développeur l’utilisera. Une API avec 3 paramètres obligatoires et 44 optionnels impose 3 hypothèses et offre 44 possibilités. Le nombre d’hypothèses est concret, mesurable, et encode la philosophie de vacuité de Hara dans la conception d’interfaces.

La reconnaissance de motifs : ce que vous remarquez

Charles Eames n’a pas conçu la chaise en contreplaqué moulé en choisissant 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 et ne permettait pas.⁵ Le design final a émergé de connaissances accumulées sur la direction du grain, le comportement des adhésifs, les courbes composées et la répartition des contraintes. La chaise paraît sans effort. Cette apparente facilité a nécessité des milliers d’heures d’observation.

La reconnaissance de motifs fonctionne par exposition et attention. Un typographe ayant composé 10 000 pages remarque des erreurs de crénage qu’un novice ne voit pas. Un ingénieur en structures ayant examiné 500 conceptions de ponts repère des problèmes de répartition de charge qu’un ingénieur junior manque. Ce n’est pas du talent. C’est le résidu d’une observation soutenue et délibérée.⁶

En infrastructure d’ingénierie, la reconnaissance de motifs 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 impose un second regard sur un travail que la première passe avait déclaré terminé. Chaque passe fait émerger des motifs que la précédente 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 le manque d’expérience en imposant le schéma d’attention qui produit la reconnaissance.

La 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 laisser entrer la lumière du soleil, créant une croix lumineuse sur le mur intérieur. Retirez la fente, et le bâtiment est une boîte de béton. Retirez le béton, et la lumière n’a plus de surface pour se révéler. Aucun élément ne fonctionne seul. C’est la cohérence entre le matériau et le 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 isolé. Un evidence gate peut évaluer une modification isolée. Une boucle de qualité peut faire émerger des motifs dans un module isolé. La cohérence exige d’évaluer comment chaque partie se rapporte à chaque autre partie — 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 manière 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. Après le passage de l’evidence gate et la validation du pride check, la boucle exige de vérifier les points d’intégration, les imports et le code adjacent pour détecter les régressions. La doctrine Steve + Jiro sous laquelle j’opère en fait un double standard : Jiro gouverne les preuves, la rigueur et l’artisanat (les qualités locales) ; Steve gouverne la valeur, le goût et l’intégrité du produit dans son ensemble (les qualités globales). Si Jiro échoue, on s’arrête. Si Steve échoue, on reconstruit. Ce double standard garantit que la justesse locale ne prend jamais le pas sur la cohérence globale.

La cartographie

Quatre composants du goût. Quatre éléments 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 analysé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’exploite en production.

Beauty and Brutalism documente 14 décisions CSS spécifiques, chacune constituant 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 un retrait à la Rams encodé dans une feuille de style dont chaque page hérite. Les contraintes sont exécutables.

Le problème de l’usine obscure

Le modèle d’usine obscure 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 à l’usine obscure 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 inférieurs à 5, un humain fournit l’évaluation de cohérence. Retirez l’humain, et l’évaluation de cohérence doit être encodée, sinon elle disparaît. 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 motifs 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 peut interroger. Un système autonome sans contraintes de goût optimisera pour réussir les tests — et comme StrongDM l’a découvert, les agents écriront return true pour passer les suites de tests tout en produisant du code sans valeur.⁸ Les tests sont verts. La production n’a ni artisanat, 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. Toutefois, le goût n’est un avantage que si vous l’encodez. Un goût non encodé est un goulot d’étranglement — une personne unique dont le jugement doit filtrer 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 motifs et vérifications de cohérence que chaque production doit satisfaire, s’exécutant à la vitesse de la machine, s’améliorant à chaque défaillance qui engendre un nouveau hook.

Chaque session d’agent autonome qui s’exécute sans contraintes de goût produit une sortie 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 la qualité signifie.

Les designers qui érigent le goût en chasse gardée intuitive verront leur intuition devenir sans objet lorsque les machines généreront plus vite que n’importe quel humain ne peut relire. 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 à suivre 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 motifs et cohérence — constituent une décomposition, pas une réduction. En pratique, le goût implique les quatre opérant 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 du matériel de référence. Le hook est un portail. Les deux sont utiles. C’est le hook 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 heurte votre goût devient une infrastructure qui empêche la prochaine occurrence.

Sources