Dépasse ton taste, ne le défends pas

Idée centrale : Construire une solution logicielle, ce sont trois activités bien distinctes : comprendre une réalité, concevoir une machine générale, et encoder l'une dans l'autre. Chacune doit des comptes à quelque chose d'extérieur à toi. Le taste, lui, n'en doit qu'à toi, et aucune des trois n'en a besoin. C'est juste le nom qu'on met sur les trois tant qu'on ne sait pas encore les distinguer. Le taste, c'est fait pour ce qui ne se discute pas. Applique-le à quelque chose qui se discute, et tu l'emploies mal.

Temps de lecture : ~8 min

Le mot qui revient partout#

Demande pourquoi un logiciel est meilleur qu'un autre, ou un produit, ou un design : aujourd'hui, la réponse, c'est le taste. C'est devenu le plus grand compliment qu'on puisse faire à un maker. C'est ce sens rare qui, paraît-il, survit même maintenant qu'une machine produit quelque chose de crédible en quelques secondes. Sauf que c'est un mot esthétique, hérité de l'art et du style. Et on lui fait faire un travail qui n'a rien d'esthétique : décider si ce qu'on a construit fonctionne vraiment, pour les gens qui en ont besoin. Les défenseurs sérieux te diront que le taste n'a jamais été une affaire d'esthétique. Retiens-le. C'est ce qu'ils disent de plus révélateur, et j'y reviendrai.

Je ne me mets pas au-dessus de la mêlée. Ça fait des années que je me fie à mon taste, et je me surprends encore à le faire. Et quand je dis logiciel, je ne parle pas que du code. Je parle de tout le travail qui transforme un problème flou en une solution qui tourne. Ce travail est fait de morceaux qui n'ont presque rien à voir entre eux. Sépare-les, et le taste, ce truc dont on était si sûrs qu'il comptait plus que tout, n'est utile à aucun.

Les trois choses que tu fais vraiment#

Quand tu construis un logiciel, tu ne fais pas une seule chose. Tu en fais trois, et elles ne sont pas de même nature.

D'abord, tu comprends une réalité : comment le métier marche vraiment, ce que font concrètement les gens pour qui tu construis, les exceptions et les bidouilles que le process officiel passe sous silence. Ça, ce n'est pas de l'ingénierie logicielle. C'est plus proche du travail de terrain. Tu mènes l'enquête, tu ne la devines pas depuis ta chaise. Et tu ne captures pas toute la réalité, seulement la part qui sert ton objectif. C'est ce cadrage qui rend le travail faisable au lieu d'impossible : l'objectif te dit ce que tu as le droit d'ignorer.

Ensuite, tu conçois une machine générale : l'art, indépendant du domaine, de faire tenir un logiciel debout. Concurrency, gestion des erreurs, frontières entre modules, tous les patterns qui empêchent un système de s'écrouler sous son propre poids. Cette partie est la même que tu fasses un CRM ou un jeu, et elle est en gros résolue. Les outils existent. Ce qui manque, c'est de la rigueur, pas un secret.

Enfin, tu encodes la première dans la seconde : tu traduis ta compréhension de la réalité en types, en états, en frontières et en invariants que la machine va exécuter.

Trois activités. Une n'est même pas de l'ingénierie logicielle. Aucune n'est la même compétence. Et tu fais les trois dans la même heure : c'est exactement là que les ennuis commencent.

Le taste ne décide rien#

Reprends les trois, et cherche l'endroit où le taste décide.

Chacune doit des comptes à quelque chose d'extérieur à toi. La compréhension, c'est la réalité qui la juge : tu as raison ou tort sur la façon dont l'entrepôt gère vraiment ses stocks, et c'est l'entrepôt qui tranche, pas ta sensibilité. La machine générale, ce sont les conséquences qui la jugent : il y a un deadlock ou pas, une fuite ou pas. L'encodage, c'est la fidélité qui le juge : le code dit ce que le modèle veut dire, ou bien il ment. Le taste, lui, ne doit de comptes qu'à toi. Il n'a sa place à aucune des trois tables.

Alors il lui reste quoi ? Juste les cas où tout est à égalité, où la décision n'entraîne aucune conséquence. « C'est une question de taste » et « ça n'a aucune importance », au fond, c'est presque la même phrase. Le problème n'est pas que le taste soit mauvais. C'est que le jour où tu listes ce que tu fais vraiment, le taste n'en fait pas partie.

Alors pourquoi ce mot ?#

Parce que tu fais les trois en même temps, et que tu les vis comme une seule.

En un après-midi, tu enquêtes sur le domaine, tu décides comment le modéliser, tu l'encodes. Et tout ça t'arrive comme une seule compétence indistincte : le sentiment que ça, c'est juste, et ça, c'est faux. Ce sentiment est réel. Mais le taste, c'est juste le nom qu'on donne aux trois activités tant qu'on ne les a pas séparées. C'est le brouillard, pas une quatrième compétence cachée en dessous. Du coup, dépasser son taste, ce n'est pas se doter d'une sensibilité plus rare. C'est un travail de décomposition : à chaque fois, se demander de laquelle des trois relève ce qu'on ressent, jusqu'à ce que le taste se dissolve dans la vraie chose qu'il masquait.

Le mot glisse, et c'est une question d'outillage#

Regarde le mot circuler d'un rôle à l'autre : c'est là qu'il dérape. Au départ, il sort de la bouche des makers, des fondateurs et des designers, ceux dont le travail est surtout la première activité, comprendre une réalité. Or cette activité n'a pas de juge immédiat. Un modèle du domaine, c'est le monde qui dit s'il est juste ou faux, lentement, dans le bruit, jamais un compiler à la seconde d'après. Dans leur bouche, « taste » est un nom pardonnable : il désigne une compréhension que rien n'a encore obligée à se mettre au clair. Puis le mot voyage. L'ingénieur qui ne fait qu'encoder, à qui on tend un modèle déjà ficelé, récupère le mot et l'applique à un travail où le compiler, les tests et la prod rendent un verdict tout de suite. Même mot, monde inverse. Il a glissé d'un travail sans juge immédiat vers un travail qu'une machine vérifie sur-le-champ. Et là, ce n'est plus qu'une façon de ne pas regarder la réponse qui est sous son nez.

Attention, aucun des deux instincts n'est plus valable que l'autre. Les deux mondes ne diffèrent que par leur outillage. L'ingénieur est entouré de juges, il ne peut pas se cacher longtemps. Le maker, lui, travaille là où il n'y en a presque aucun. Alors chez lui, le mot est moins un verdict qu'une dette : l'outillage qui forcerait la décomposition n'a tout simplement pas encore été construit. C'est un chantier, pas une excuse. On peut rendre la compréhension d'un domaine bien plus explicite et testable qu'on ne le fait d'habitude. On n'y arrive jamais complètement, parce que la réalité humaine répond lentement, et qu'aucune méthode ne rend le marché aussi net qu'un compiler. Mais pour les rôles les moins outillés, dépasser son taste, c'est en partie construire les outils qui le permettront.

Le taste est emprunté, et c'est un stade embryonnaire#

Ça aide de voir d'où vient le sentiment. La plupart du temps, il est emprunté. Le type checker qui a refusé ton union mal fichue, le linter qui a repéré ta branche morte : à chaque fois, c'est une pratique nommée que quelqu'un a formalisée et glissée dans un outil. Utilise de bons outils pendant des années, et tu absorbes la forme de ces pratiques sans jamais lire leur nom. Du coup, quand tu « sens » que quelque chose cloche, le plus souvent tu reconnais un pattern qui a déjà un nom, dans un bouquin que tu n'as pas ouvert.

C'est pour ça que le taste, au mieux, c'est un pré-apprentissage. Le stade d'avant les mots : l'intuition qui précède le nom, la structure, la capacité à dire pourquoi. Je dis ça en connaissance de cause : la moitié de mes idées, je les ai eues à l'instinct, et je n'ai trouvé leur vrai nom qu'en les écrivant. Tout le travail est là, transformer sans arrêt : le ressenti en nom, le nom en structure, la structure en quelque chose que tu pourrais défendre face à quelqu'un qui n'est pas d'accord. Je n'ai pas fini. Personne n'a fini.

Pourquoi l'ego s'y installe#

Donc si le taste est emprunté, embryonnaire, et ne tranche que quand rien n'est en jeu, pourquoi des gens compétents y accrochent-ils leur identité ?

Parce que c'est le seul coin du métier où on ne peut pas te donner tort. Sur un domaine, une frontière, un invariant, un modèle, tu peux te tromper, et la réalité, la prod ou le prochain dev finiront par te le dire. Le taste, lui, ne te le dira jamais. Une préférence, ça ne se discute pas. Et l'ego ne veut qu'une chose : être à l'abri de l'erreur. Alors il fait le choix rationnel. Il fuit les trois activités qui rendent des comptes, là où l'échec se voit, et il va se poser sur la seule colline où il ne sera jamais pris en faute. Les grands discours sur le taste, c'est souvent ça. Pas de l'expertise : le bruit de quelqu'un qui adosse son identité à la seule chose du métier qu'on ne peut pas vérifier.

D'où la distinction qui vaut le coup d'être gardée. Le problème n'a jamais été d'avoir du taste. Tout le monde en a. Le problème, c'est le taste qui refuse de se décomposer, l'instinct figé en galon au lieu d'être ramené à l'une des trois vraies choses. Ce n'est pas un type de personne, le problème. C'est le choix d'arrêter de défaire le brouillard.

Ce qu'ils visent vraiment#

Voici la partie généreuse, et elle est vraie. Les gens qui parlent de taste visent quelque chose de réel. À l'heure où une machine sort du code plausible à l'infini, il y a bien une compétence humaine rare qui sépare le bon du slop. Ils la sentent. Ils ont raison, elle existe. Ils l'ont juste mal nommée.

Prends leur meilleur argument. Pas la nuance d'un bouton, non : le taste comme jugement fiable et reproductible dans l'incertitude, voir ce qui est bon avant les autres, et avoir raison quand ils finissent par comprendre. Écoute ce que ça concède. « Avoir raison quand ils comprennent », ça veut dire que le jugement répond de quelque chose d'extérieur à toi, quelque chose qui le confirmera ou l'enverra au tapis. Or à la seconde où il répond de ça, ce n'est plus du taste, c'est de la compréhension. Leur meilleur argument pour le taste, c'est de la compréhension habillée du mot, parce que le mot sonne comme un don de naissance plutôt que comme un travail qu'on est allé faire. Ce qui reste, la pure préférence qui ne répond de rien, c'est précisément la part qui ne tranche que les cas sans importance. Pousse le raisonnement aussi loin que tu veux : le taste se coupe en deux. Là où il est bon, c'est de la compréhension. Là où ce n'est que du taste, ça n'a pas d'importance.

Au fond, toute la différence tient à la direction du regard. Le taste regarde vers l'intérieur, vers ta propre sensibilité. La compréhension regarde vers l'extérieur, vers un monde qu'il faut aller arpenter pour s'en faire une théorie qui marche. L'un se consulte, l'autre se découvre. C'est pour ça qu'aucun outil ne te le donnera jamais. Même la part irréductible, ce résidu tacite qu'un expert n'arrive pas à mettre en mots, pointe encore vers l'extérieur, vers la réalité, au service des autres. C'est de la compréhension qui n'a pas fini de parler, pas une préférence déguisée en autorité.

Une porte, pas une pièce#

Rien de tout ça n'est une raison d'avoir honte de ce sentiment. C'est par là que tout le monde commence, et les meilleurs ingénieurs que je connaisse ne le perdent jamais : cette sensation vive et tenace que quelque chose cloche, bien avant de pouvoir le prouver. Cette intuition est précieuse. C'est le point de départ de chacune de leurs bonnes décisions.

Mais c'est un point de départ. Une porte, pas une pièce où l'on s'installe avec ses meubles. La franchir, c'est un geste tout simple et qu'on répète : chaque « ça me chiffonne », traite-le comme une dette. Trouve de laquelle des trois il relève, et rends-le assez explicite pour le défendre ou te le faire corriger, au nom des gens qui ne verront jamais ton taste et n'en ont jamais eu besoin. C'est la discipline que je prêche pour le code lui-même : ne laisse pas implicite ce qui compte, encode-le. Là, tu la retournes vers toi, vers ton propre savoir. Encode ton taste, ne lui fais pas confiance. Défends-le, et tu restes sur le pas de la porte. Décompose-le, encore et encore, et tu as le droit d'entrer.