Getting Real

Le principe qui donne son titre au livre est celui-là : construire « moins de logiciel ». Moins de fonctions, moins d'options, moins de code, moins de textes d'aide, moins d'écrans. À chaque carrefour de conception, 37signals cherche la version la plus dépouillée qui fasse quand même le travail. Non par pauvreté d'idées, mais parce que chaque ligne ajoutée devient une chose à écrire, à tester, à corriger, à maintenir, à documenter, et à faire comprendre à l'utilisateur. Le logiciel n'est pas gratuit une fois codé — il coûte tant qu'il existe.

De là découlent des choix concrets qui vont à rebours de l'usage. Plutôt que de laisser mille réglages à l'utilisateur, on décide à sa place des valeurs par défaut sensées, quitte à froisser les cas particuliers. Plutôt que de prévoir chaque situation, on traite le cas courant très bien et on assume que le reste attendra. Le livre parle de « conventions plutôt que configurations » : imposer des choix raisonnables évite à chacun de refaire les mêmes décisions, et allège d'autant l'interface. Un produit qui suppose moins de décisions de l'utilisateur est un produit plus facile à prendre en main.

Reste la question pratique : comment décide-t-on ce qu'on garde et ce qu'on jette ? La réponse de Getting Real est presque provocante. La position par défaut, face à toute demande de fonctionnalité, est non. Non par principe, quitte à revenir dessus si la demande insiste vraiment. Le raisonnement : une fonction ajoutée est presque impossible à retirer ensuite, parce que quelqu'un s'en sert et hurlera si elle disparaît. Le non est réversible, le oui beaucoup moins. Dire non coûte cher sur le moment, dire oui coûte cher pour toujours.

Le livre s'attaque directement à un réflexe sacré du secteur — écouter le client. 37signals répond qu'il faut écouter les clients sans faire tout ce qu'ils demandent. Les demandes affluent, contradictoires, portées par des cas particuliers, et si on les suivait toutes, le produit deviendrait le sac de toutes les exigences réunies : lourd, incohérent, illisible. Les auteurs racontent qu'ils ne tiennent même pas de liste exhaustive des demandes. Celles qui comptent vraiment reviennent d'elles-mêmes, encore et encore, sans qu'on ait besoin de les archiver. Les autres s'évaporent, et c'est très bien.

Si l'on prend un peu de hauteur, ce que Getting Real propose n'est pas d'abord une recette de logiciel, c'est une redéfinition de ce qu'est concevoir. Dans l'imaginaire courant, le concepteur est celui qui trouve des idées, qui ajoute, qui enrichit ; le bon produit serait celui qui contient le plus de pensée. 37signals renverse ça : concevoir, c'est décider de ce qui n'y sera pas. La valeur du travail se lit dans la pile des choses écartées autant que dans ce qui est livré. Le geste de design central n'est pas l'invention, c'est la coupe.

Ce déplacement rejoint une intuition ancienne, qu'on retrouve chez les architectes, les typographes ou les monteurs de films : la forme naît de la contrainte, et le vide fait partie de l'œuvre. Un espace bien conçu se remarque à ce qu'on y a renoncé. Mais le logiciel avait longtemps échappé à cette discipline, parce qu'ajouter une fonction ne coûte apparemment rien — pas de matière, pas de poids visible. Getting Real rappelle que ce coût existe, invisible mais réel, et qu'il finit par se payer en confusion, en bugs, en lourdeur.

Getting Real n'est pas un traité technique et vieillit sans trop de dommage précisément pour cette raison : il parle moins d'outils que d'un rapport au métier. Une équipe minuscule, à Chicago, a montré qu'on pouvait sortir des produits durables en résistant à presque tous les réflexes de son industrie — pas de grande équipe, pas de cahier des charges monumental, pas de course aux fonctions. Le fil qui relie tout, du recrutement retardé à la fonctionnalité refusée, tient dans un mot qu'on prononce rarement avec fierté : non.