CONCEPTION ET RECHERCHE

Janvier 2003

(Cet article est tiré d’un discours prononcé lors de la réunion d’automne 2002 du NEPLS.)

Les visiteurs de ce pays sont souvent surpris de constater que les Américains aiment commencer une conversation en demandant « que faites-vous dans votre travail ? ». Je n'ai jamais aimé cette question. J'ai rarement eu une réponse claire à cette question. Mais je pense avoir enfin résolu le problème. Maintenant, quand quelqu'un me demande ce que je fais, je le regarde droit dans les yeux et je dis « je suis en train de concevoir un nouveau dialecte de Lisp ». Je recommande cette réponse à tous ceux qui n'aiment pas qu'on leur demande ce qu'ils font. La conversation se tournera immédiatement vers d'autres sujets.

Je ne considère pas que je fais de la recherche sur les langages de programmation. Je me contente d'en concevoir un, de la même manière que quelqu'un pourrait concevoir un bâtiment, une chaise ou une nouvelle police de caractères. Je n'essaie pas de découvrir quelque chose de nouveau. Je veux juste créer un langage dans lequel il sera agréable de programmer. D'une certaine manière, cette hypothèse rend la vie beaucoup plus facile.

La différence entre le design et la recherche semble être une question de nouveauté ou de bien. Le design n'a pas besoin d'être nouveau, mais il doit être bon. La recherche n'a pas besoin d'être bonne, mais elle doit être nouvelle. Je pense que ces deux chemins convergent vers le sommet : le meilleur design surpasse ses prédécesseurs en utilisant de nouvelles idées, et la meilleure recherche résout des problèmes qui sont non seulement nouveaux, mais qui méritent d'être résolus. En fin de compte, nous visons donc la même destination, mais nous l'abordons sous des angles différents.

Ce dont je vais parler aujourd'hui, c'est de ce à quoi ressemble votre cible vue de l'arrière. Que faites-vous différemment lorsque vous traitez les langages de programmation comme un problème de conception plutôt que comme un sujet de recherche ?

La principale différence est que l'on se concentre davantage sur l'utilisateur. La conception commence par se demander à qui est destiné le projet et quels sont ses besoins. Un bon architecte, par exemple, ne commence pas par créer un projet qu'il impose ensuite aux utilisateurs, mais par étudier les utilisateurs visés et déterminer leurs besoins.

Notez que j'ai dit « ce dont ils ont besoin » et non « ce qu'ils veulent ». Je ne veux pas donner l'impression que travailler comme designer revient à travailler comme une sorte de cuisinier de passage, qui prépare tout ce que le client lui demande. Cela varie d'un domaine à l'autre dans le domaine des arts, mais je ne pense pas qu'il existe un domaine dans lequel le meilleur travail soit fait par des gens qui font exactement ce que les clients leur demandent.

Le client a toujours raison dans le sens où la mesure d'un bon design est la façon dont il fonctionne pour l'utilisateur. Si vous faites un roman qui ennuie tout le monde ou une chaise dans laquelle il est horriblement inconfortable de s'asseoir, alors vous avez fait du mauvais travail, point final. On ne peut pas se défendre en disant que le roman ou la chaise sont conçus selon les principes théoriques les plus avancés.

Pourtant, faire ce qui fonctionne pour l'utilisateur ne signifie pas simplement faire ce que l'utilisateur vous dit de faire. Les utilisateurs ne savent pas quels sont les choix possibles et se trompent souvent sur ce qu'ils veulent vraiment.

La réponse au paradoxe, je pense, c'est qu'il faut concevoir pour l'utilisateur, mais il faut concevoir ce dont l'utilisateur a besoin, pas simplement ce qu'il dit vouloir. C'est un peu comme être médecin. On ne peut pas se contenter de traiter les symptômes d'un patient. Lorsqu'un patient vous parle de ses symptômes, il faut déterminer ce qui ne va pas chez lui et le traiter.

Cette focalisation sur l’utilisateur est une sorte d’axiome à partir duquel la plupart des pratiques de bon design peuvent être dérivées, et autour duquel se concentrent la plupart des problèmes de conception.

Si un bon design doit répondre aux besoins de l'utilisateur, qui est l'utilisateur ? Quand je dis que le design doit être destiné aux utilisateurs, je ne veux pas dire qu'un bon design vise un dénominateur commun. Vous pouvez choisir n'importe quel groupe d'utilisateurs. Si vous concevez un outil, par exemple, vous pouvez le concevoir pour n'importe qui, des débutants aux experts, et ce qui est bon pour un groupe peut être mauvais pour un autre. Le fait est que vous devez choisir un groupe d'utilisateurs. Je ne pense pas que l'on puisse même parler de bon ou de mauvais design si ce n'est en référence à un utilisateur visé.

Vous aurez plus de chances d'obtenir un bon design si le concepteur lui-même fait partie des utilisateurs visés. Lorsque vous concevez quelque chose pour un groupe qui ne vous inclut pas, c'est généralement pour des personnes que vous considérez comme moins sophistiquées que vous, et non plus sophistiquées.

C'est un problème, car mépriser l'utilisateur, même avec bienveillance, semble inévitablement corrompre le concepteur. Je soupçonne que très peu de projets immobiliers aux États-Unis ont été conçus par des architectes qui s'attendaient à y vivre. On peut observer la même chose dans les langages de programmation. C, Lisp et Smalltalk ont été créés pour être utilisés par leurs propres concepteurs. Cobol, Ada et Java ont été créés pour être utilisés par d'autres personnes.

Si vous pensez que vous concevez quelque chose pour des idiots, il y a de fortes chances que vous ne conceviez pas quelque chose de bien, même pour des idiots.

Même si vous concevez quelque chose pour les utilisateurs les plus sophistiqués, vous concevez toujours pour les humains. C'est différent dans la recherche. En mathématiques, vous ne choisissez pas des abstractions parce qu'elles sont faciles à comprendre pour les humains ; vous choisissez celles qui rendent la preuve plus courte. Je pense que c'est vrai pour les sciences en général. Les idées scientifiques ne sont pas censées être ergonomiques.

Dans le domaine des arts, les choses sont très différentes. Le design est avant tout une affaire d'humains. Le corps humain est une chose étrange, mais quand on conçoit une chaise, c'est pour cela qu'on conçoit, et il n'y a pas d'autre solution. Tous les arts doivent tenir compte des intérêts et des limites des humains. En peinture, par exemple, toutes choses égales par ailleurs, un tableau avec des personnages sera plus intéressant qu'un tableau sans personnages. Ce n'est pas un simple hasard de l'histoire si les grands tableaux de la Renaissance sont tous remplis de personnages. S'ils n'avaient pas été représentés, la peinture en tant que médium n'aurait pas le prestige qu'elle a.

Que cela nous plaise ou non, les langages de programmation sont aussi destinés aux humains, et je pense que le cerveau humain est tout aussi grumeleux et idiosyncratique que le corps humain. Certaines idées sont faciles à saisir pour les gens, d'autres non. Par exemple, nous semblons avoir une capacité très limitée à gérer les détails. C'est ce fait qui fait que les langages de programmation sont une bonne idée en premier lieu ; si nous pouvions gérer les détails, nous pourrions simplement programmer en langage machine.

N’oubliez pas non plus que les langages ne sont pas avant tout un support pour des programmes finis, mais un outil dans lequel les programmes doivent être développés. N’importe qui dans le domaine artistique pourrait vous dire que vous pourriez avoir besoin de supports différents pour les deux situations. Le marbre, par exemple, est un support agréable et durable pour les idées abouties, mais un support désespérément inflexible pour le développement de nouvelles idées.

Un programme, comme une preuve, est une version élaguée d'un arbre qui, dans le passé, a eu de faux départs qui se sont ramifiés un peu partout. Ainsi, le test d'un langage ne se limite pas à la propreté du programme fini, mais à la propreté du chemin qui y mène. Un choix de conception qui vous donne des programmes finis élégants peut ne pas vous donner un processus de conception élégant. Par exemple, j'ai écrit quelques macros de définition de macros pleines de guillemets imbriqués qui ressemblent maintenant à de petits bijoux, mais leur écriture a pris des heures d'essais et d'erreurs les plus laids, et franchement, je ne suis toujours pas entièrement sûr qu'elles soient correctes.

Nous nous comportons souvent comme si le test d'un langage se résumait à la qualité des programmes finis qu'il contient. Cela semble tellement convaincant lorsque vous voyez le même programme écrit dans deux langages, et que l'une des versions est beaucoup plus courte. Lorsque vous abordez le problème sous l'angle des arts, vous avez moins tendance à dépendre de ce type de test. Vous ne voulez pas vous retrouver avec un langage de programmation comme le marbre.

Par exemple, il est très avantageux de disposer d'un niveau supérieur interactif, ce que l'on appelle en Lisp une boucle lecture-évaluation-impression. Et lorsque vous en avez un, cela a de réels effets sur la conception du langage. Cela ne fonctionnerait pas bien pour un langage dans lequel vous devez déclarer des variables avant de les utiliser, par exemple. Lorsque vous tapez simplement des expressions dans le niveau supérieur, vous voulez pouvoir définir x sur une valeur donnée, puis commencer à faire des choses avec x. Vous ne voulez pas avoir à déclarer le type de x en premier. Vous pouvez contester l'une ou l'autre des prémisses, mais si un langage doit avoir un niveau supérieur pour être pratique, et que les déclarations de type obligatoires sont incompatibles avec un niveau supérieur, alors aucun langage qui rend les déclarations de type obligatoires ne pourrait être pratique pour programmer.

En pratique, pour obtenir un bon design, il faut être proche de ses utilisateurs et rester proche d'eux. Il faut constamment adapter ses idées aux utilisateurs réels, surtout au début. L'une des raisons pour lesquelles les romans de Jane Austen sont si bons, c'est qu'elle les lisait à voix haute à sa famille. C'est pourquoi elle ne sombre jamais dans des descriptions de paysages auto-complaisantes et artistiques, ni dans des discours philosophiques prétentieux. (La philosophie est là, mais elle est tissée dans l'histoire au lieu d'y être collée comme une étiquette.) Si vous ouvrez un roman « littéraire » moyen et que vous imaginez le lire à voix haute à vos amis comme quelque chose que vous avez écrit, vous ressentirez très vivement à quel point ce genre de chose est une imposition pour le lecteur.

Dans le monde du logiciel, cette idée est connue sous le nom de « pire, c'est mieux ». En fait, plusieurs idées se mélangent dans ce concept, ce qui explique pourquoi les gens se disputent encore pour savoir si le pire est réellement mieux ou non. Mais l'une des principales idées de ce mélange est que si vous créez quelque chose de nouveau, vous devez présenter un prototype aux utilisateurs dès que possible.

L'approche alternative pourrait être appelée la stratégie du « Hail Mary ». Au lieu de sortir rapidement un prototype et de l'affiner progressivement, on essaie de créer le produit fini et complet en une seule et longue passe. Autant que je sache, c'est la recette du désastre. D'innombrables startups se sont détruites de cette façon pendant la bulle Internet. Je n'ai jamais entendu parler d'un cas où cela ait fonctionné.

Ce que les gens extérieurs au monde des logiciels ne réalisent peut-être pas, c'est que le concept du pire est utilisé dans tous les domaines artistiques. En dessin, par exemple, cette idée a été découverte à la Renaissance. Aujourd'hui, presque tous les professeurs de dessin vous diront que la meilleure façon d'obtenir un dessin précis n'est pas de travailler lentement autour du contour d'un objet, car les erreurs s'accumulent et vous vous apercevrez à la fin que les lignes ne se rejoignent pas. Vous devez plutôt dessiner quelques lignes rapides à peu près au bon endroit, puis peaufiner progressivement ce croquis initial.

Dans la plupart des domaines, les prototypes sont traditionnellement réalisés à partir de matériaux différents. Les polices de caractères destinées à être découpées dans du métal sont d'abord conçues au pinceau sur du papier. Les statues destinées à être coulées en bronze sont modelées à la cire. Les motifs destinés à être brodés sur des tapisseries sont dessinés sur du papier avec un lavis d'encre. Les bâtiments à construire en pierre sont testés à plus petite échelle sur du bois.

Ce qui rendit la peinture à l'huile si passionnante, lorsqu'elle devint populaire au XVe siècle, c'était qu'on pouvait réellement réaliser l'œuvre finie à partir du prototype. On pouvait faire un dessin préliminaire si on le voulait, mais on n'était pas obligé de s'y tenir ; on pouvait travailler tous les détails, et même faire des changements majeurs, au fur et à mesure que l'on terminait le tableau.

Vous pouvez faire cela aussi dans le domaine des logiciels. Un prototype ne doit pas nécessairement être un simple modèle ; vous pouvez l'affiner pour en faire un produit fini. Je pense que vous devriez toujours le faire lorsque vous le pouvez. Cela vous permet de tirer parti des nouvelles connaissances que vous avez acquises en cours de route. Mais peut-être plus important encore, c'est bon pour le moral.

Le moral est la clé du design. Je suis étonné que les gens n'en parlent pas plus. Un de mes premiers professeurs de dessin m'a dit : si tu t'ennuies en dessinant quelque chose, le dessin aura l'air ennuyeux. Par exemple, suppose que tu doives dessiner un bâtiment et que tu décides de dessiner chaque brique individuellement. Tu peux le faire si tu le souhaites, mais si tu t'ennuies à mi-chemin et que tu commences à fabriquer les briques mécaniquement au lieu d'observer chacune d'elles, le dessin aura l'air pire que si tu avais simplement suggéré les briques.

Construire quelque chose en peaufinant progressivement un prototype est bon pour le moral car cela vous permet de rester motivé. En informatique, ma règle est la suivante : ayez toujours du code fonctionnel. Si vous écrivez quelque chose que vous pourrez tester en une heure, vous avez alors la perspective d'une récompense immédiate pour vous motiver. Il en va de même dans les arts, et particulièrement dans la peinture à l'huile. La plupart des peintres commencent avec une esquisse floue et l'affine progressivement. Si vous travaillez de cette manière, vous n'aurez en principe jamais à terminer la journée avec quelque chose qui semble réellement inachevé. En fait, il existe même un dicton parmi les peintres : « Un tableau n'est jamais terminé, on arrête simplement de travailler dessus. » Cette idée sera familière à tous ceux qui ont travaillé sur des logiciels.

Le moral est une autre raison pour laquelle il est difficile de concevoir quelque chose pour un utilisateur peu averti. Il est difficile de rester intéressé par quelque chose que vous n'aimez pas vous-même. Pour créer quelque chose de bien, vous devez penser : « Wow, c'est vraiment génial », et non pas « Quelle merde ! Ces imbéciles vont adorer ».

Le design consiste à créer des objets pour les humains. Mais l'utilisateur n'est pas le seul à être humain. Le designer est humain aussi.

Notez que j'ai parlé tout au long de ce discours du « designer ». Le design doit généralement être sous le contrôle d'une seule personne pour être efficace. Et pourtant, il semble possible que plusieurs personnes collaborent à un projet de recherche. C'est là, à mon avis, l'une des différences les plus intéressantes entre la recherche et le design.

Il existe des exemples célèbres de collaboration dans le domaine des arts, mais la plupart semblent avoir été des cas de liaison moléculaire plutôt que de fusion nucléaire. Dans un opéra, il est courant qu'une personne rédige le livret et une autre la musique. Et pendant la Renaissance, des ouvriers du nord de l'Europe étaient souvent employés pour réaliser les paysages en arrière-plan des peintures italiennes. Mais il ne s'agit pas de véritables collaborations. Il s'agit plutôt d'exemples de ce que Robert Frost écrivait : « Les bonnes clôtures font les bons voisins ». On peut regrouper des exemples de bonne conception, mais dans chaque projet individuel, une personne doit être aux commandes.

Je ne dis pas qu'un bon design nécessite qu'une seule personne pense à tout. Rien n'est plus précieux que les conseils de quelqu'un dont on a confiance dans le jugement. Mais une fois les discussions terminées, la décision sur ce qu'il faut faire doit être prise par une seule personne.

Pourquoi la recherche peut-elle être effectuée par des collaborateurs, alors que le design ne le peut pas ? C'est une question intéressante. Je ne connais pas la réponse. Peut-être que si le design et la recherche convergent, la meilleure recherche est aussi une bonne conception, et en fait, elle ne peut pas être effectuée par des collaborateurs. Beaucoup des scientifiques les plus célèbres semblent avoir travaillé seuls. Mais je n'en sais pas assez pour dire s'il existe une tendance. Il se pourrait simplement que de nombreux scientifiques célèbres aient travaillé à une époque où la collaboration était moins courante.

Quelle que soit la situation dans le domaine des sciences, la véritable collaboration semble être extrêmement rare dans le domaine des arts. La conception par comité est synonyme de mauvaise conception. Pourquoi en est-il ainsi ? Existe-t-il un moyen de contourner cette limitation ?

Je suis enclin à penser que non, qu'un bon design nécessite un dictateur. L'une des raisons est qu'un bon design doit être d'un seul tenant. Le design n'est pas seulement destiné aux humains, mais à chaque individu. Si un design représente une idée qui convient à une personne, alors cette idée conviendra également à l'utilisateur.