Le sens avant le reste : de l'importance de définir les mots avant de construire

Il y a quelque chose d'ironique à écrire une introduction sur l'importance des débuts. C'est admettre d'emblée que ce qui suit ne peut pas se suffire à lui-même, en ce sens qu'il faut un seuil, un cadre, quelques mots posés avant les autres pour que les autres aient un sens. C'est reconnaître que le commencement n'est pas une formalité qu'on expédie pour arriver plus vite à "l'essentiel", mais qu'il est lui-même une décision, peut-être la plus structurante de toutes.

Nous vivons dans un monde qui a largement renoncé aux seuils. On n'étudie plus les sujets, on les traverse. On ne les approfondit pas, on les commente... La vitesse est une valeur, l'immédiateté une promesse, et la capacité à produire vite un texte, une analyse, une décision, une architecture, est devenue une forme de compétence à part entière (presque dissociée de ce qu'elle produit). Ce qui compte, c'est le rythme. L'output.

Dans ce contexte, prendre le temps de définir ce dont on parle avant de parler ressemble de plus en plus à un luxe anachronique, voire à une forme d'hésitation coupable. Les outils d'intelligence artificielle ont achevé d'installer cette logique : pourquoi passer une heure à poser les bons termes quand on peut obtenir en trente secondes une réponse structurée et formulée avec assurance ? La question elle-même semble rhétorique. L'efficacité a gagné.

Et que l'on soit clair : ce n'est pas un éloge de la lenteur. La lenteur n'a rien de vertueux par nature, elle peut tout autant être de l'indécision déguisée (l'un de mes passe-temps favoris). Ce qui m'intéresse, c'est quelque chose de beaucoup plus agaçant à défendre : l'idée que la précision préalable n'est pas du luxe.

Ce texte est donc une introduction. Mais il est aussi, en lui-même, une démonstration de ce qu'il défend : qu'on ne commence jamais vraiment au hasard, et que la façon dont on pose les premiers mots détermine tout ce qui peut être pensé ensuite.

Prenez n'importe quel mot central d'un projet. "Qualité." "Performance." "Satisfaction." "Compétence." Dans un groupe de travail, tout le monde sait ce que ces mots veulent dire (ou croit le savoir). Posez la question explicitement, demandez à chacun d'en donner une définition précise : vous obtiendrez des réponses qui se ressemblent en surface et qui divergent profondément dans leurs implications. Pour l'un, la "qualité" d'un travail rendu, c'est l'absence de défaut. Pour un autre, c'est l'adéquation aux attentes du destinataire. Pour un troisième, c'est quelque chose de plus difficile à saisir, comme , une forme d'exigence intérieure qui ne se laisse pas réduire à une liste de critères. Ces trois visions ne sont pas incompatibles, elles sont, pour moi, même complémentaires. Mais si elles coexistent silencieusement, sans jamais avoir été nommées ni confrontées, alors le groupe travaille avec l'illusion d'un accord qu'il n'a pas réellement formé.

Le langage naturel est ainsi fait : il tolère l'ambiguïté, il s'en nourrit même. La métaphore, le sous-entendu, le glissement de sens, ce sont des ressources dans nos échanges. Ils permettent la nuance, la diplomatie, la poésie. Ils permettent de se comprendre suffisamment bien pour continuer à avancer ensemble sans avoir résolu tous les désaccords de fond.

Il faut ici dissiper un malentendu fréquent. Quand on parle de "définir les termes" dans un projet, on pense souvent à un glossaire (un document annexe), écrit après coup, destiné à figer ce que les décisions ont déjà produit sans le dire. Ce n'est pas de cela qu'il s'agit. Définir un concept, au sens fort, ce n'est pas nommer quelque chose: c'est décider ce qui ne rentrera pas dedans. Et c'est là que ça devient inconfortable. Parce que tout le monde aime les définitions larges : elles ne froissent personne. Une définition précise, elle, froisse toujours quelqu'un.

Tant que "compétence" peut signifier aussi bien une connaissance déclarable qu'un comportement observable dans un contexte donné, on ne peut pas construire un système d'évaluation sérieux (qu'il soit humain ou automatisé d'ailleurs). On peut construire quelque chose qui ressemble à un système d'évaluation, qui en a la forme et le vocabulaire, mais dont les résultats ne seront jamais vraiment comparables entre eux, ni défendables face à un tiers, ni utiles pour décider. C'est pourquoi la définition n'est pas un préambule qu'on règle avant de commencer le vrai travail: Elle est le vrai travail. Ou du moins, elle en est la première couche, celle sur laquelle tout le reste repose. En architecture logicielle, ce principe prend le nom de domain-driven design : la structure du système doit refléter fidèlement la structure du domaine qu'il modélise, et cette structure commence par un langage précis, partagé, délibérément construit.

Mais il y a quelque chose de plus difficile à admettre. C'est que cette façon de travailler: s'arrêter, définir, questionner les évidences, refuser d'avancer tant que les fondations conceptuelles ne sont pas stables, va à rebours de presque tout ce que l'époque valorise. Les méthodologies de projet ont popularisé l'idée du livrer vite, apprendre vite — itérer plutôt que planifier, tester plutôt que prévoir. Et pour certains problèmes, cette vélocité est exactement ce qu'il faut.

Il y a un autre phénomène qui mérite d'être nommé, et qui touche directement à la façon dont les décisions sont prises aujourd'hui dans la plupart des domaines. C'est ce qu'on pourrait appeler la confiance par consensus apparent. C'est la tendance à adopter une position non pas parce qu'on en a vérifié le fondement, mais parce qu'elle est répandue, endossée par des voix qui semblent faire autorité, et suffisamment partagée pour que la contester paraisse excentrique. "C'est une bonne pratique." "Tout le monde le fait comme ça maintenant." "Les experts s'accordent à dire que…" Ces formulations ont en commun de déplacer l'autorité de l'argument vers la source ou vers la masse. Elles demandent non pas d'évaluer une idée, mais de faire confiance à ceux qui la portent. Ce mécanisme n'est pas irrationnel en soi. Dans des domaines où l'information est vaste et le temps limité, il est nécessaire de s'appuyer sur l'expérience des autres. Personne ne peut tout vérifier par lui-même.

Le problème n'est pas de faire confiance. C'est de le faire sans chercher à comprendre. Parce que les bonnes pratiques ne sont presque jamais universelles. Elles sont contextuelles. Ce qui est pertinent dans un contexte donné peut être contre-productif dans un autre. Et pour savoir si une pratique est adaptée à sa situation, il faut avoir compris pourquoi elle existe, quel problème elle résout, quelles hypothèses elle fait sur le contexte, à partir de quand elle devient inadaptée. Cette compréhension là ne vient pas de la confiance par consensus. Elle vient d'une démarche : questionner, confronter, et surtout argumenter. C'est-à-dire être capable d'expliquer ses décisions avec des raisons, pas avec des références d'autorité. C'est une forme de courage intellectuel, d'une certaine façon. Parce que l'argumentation expose. Elle dit : voici ce que je pense, voici pourquoi, voici ce que j'ai considéré et écarté. Elle invite la contradiction.

Ce que l'argumentation produit, en réalité, c'est quelque chose de rare et de précieux : de la traçabilité décisionnelle. Non pas seulement "qu'est-ce qu'on a décidé", mais "pourquoi on a décidé ça", "qu'est-ce qu'on a considéré d'autre", "dans quelles conditions cette décision serait à revoir". Cette traçabilité a une valeur immédiate : elle permet à quelqu'un qui arrive plus tard de comprendre non seulement l'état des choses, mais leur logique. De ne pas défaire sans le savoir quelque chose qui avait été construit délibérément. Mais elle a aussi une valeur plus personnelle, souvent sous-estimée : elle oblige celui qui raisonne à tenir sa pensée sous tension. Car expliquer une décision, c'est la mettre à l'épreuve. Et souvent, dans cet exercice, on découvre que ce qu'on croyait être une décision solide était en réalité une intuition confortable.

Ce qui suit est un journal de conception. Il documente, épisode après épisode, les décisions prises dans le cadre d'un projet technique: ses arbitrages, ses renoncements, les chemins envisagés et abandonnés, et les raisons qui ont conduit à chaque choix. Mais avant d'être cela, c'est le récit d'une démarche. Une démarche qui commence précisément par refuser la commodité des mots flous, qui préfère la définition à l'approximation, et qui considère que nommer correctement les choses est la première des décisions que l'on prend quand on construit quelque chose.

Ce n'est pas un tutoriel. Ça ne pourrait pas l'être, un tutoriel suppose qu'on sait où on va au moment où on écrit. Ici, certaines décisions seront probablement contredites par la suite du journal. C'est prévisible, et ça ne me pose pas de problème particulier.

Ce qu'il cherche à faire, en revanche, c'est rendre visible le raisonnement. Pas seulement ce qui a été construit, mais ce qui a été envisagé et écarté, pourquoi, et à quelles conditions la décision aurait pu être différente.