Le rasoir de Feynman
(defenderofthebasic.substack.com)- Même lorsqu’une explication technique tient compte des débutants, elle doit laisser des indices précis permettant à quelqu’un qui en a les capacités de comprendre l’état réel des choses
- Le message d’erreur d’Outlook fournit à l’utilisateur un modèle contradictoire en affirmant qu’il peut copier le contenu d’un « message qui n’existe plus »
- Si l’on ne masque pas des mots comme
serveretcache, les utilisateurs intéressés peuvent chercher et apprendre, et ceux qui les connaissent déjà comprennent le problème plus vite - Des indications d’état familières mais imprécises comme
loading…masquent ce que le système fait réellement ; il vaut mieux dire directement « en attente de la fin de la saisie » - Une simplification excessive empêche l’utilisateur de raisonner ; il faut donc laisser au minimum des pistes menant à la vérité, comme un code d’erreur et les actions possibles
Une explication simple ne doit pas être fausse
- Le « rasoir de Feynman » est l’idée que, lorsqu’on explique un sujet technique à des utilisateurs ordinaires, si une personne capable de le comprendre ne peut pas y parvenir, alors ce n’est pas une bonne explication
- Richard Feynman disait qu’en lisant dans un journal la mention d’une « machine de 7 tonnes », on ne peut pas savoir de quelle machine il s’agit, pas plus qu’on ne sait ce que désigne un « atomic bullet »
- L’essentiel n’est pas de savoir si l’explication semble facile, mais si une personne qui a les capacités de comprendre le sujet peut réellement le comprendre en la lisant
La confusion créée par le message d’erreur d’Outlook
- Dans une discussion sur Hacker News, le message d’erreur suivant a été tourné en ridicule
- “This message can't be saved because it no longer exists. It can only be discarded. Make sure you copy the contents of the message before you discard if you want to use them later.”
- L’utilisateur se voit donc dire qu’il peut copier le contenu d’un message qui n’existe plus, mais qu’il ne peut pas l’enregistrer
- Le problème n’est pas que les utilisateurs ordinaires ne connaissent pas les termes techniques, mais que même les utilisateurs capables de comprendre ne reçoivent aucune explication de l’état réel
Une approche qui ne cache pas server et cache
- Une autre formulation explique que le message a été supprimé du serveur de messagerie, mais qu’Outlook le conserve encore dans le cache temporaire de l’appareil
- L’utilisateur peut copier le contenu du message ou le retirer du cache
- S’il le retire du cache, il sera supprimé définitivement
- Certains ont réagi en disant que les utilisateurs ordinaires ne comprendraient pas des mots comme
cacheouserver - Pourtant, ces termes sont des indices exploitables pour apprendre par les utilisateurs curieux, et ils montrent plus clairement la situation réelle à ceux qui les comprennent déjà
- Les utilisateurs qui ne s’y intéressent pas ne tireront de toute façon pas beaucoup d’aide d’une quelconque explication, mais il faut laisser des indices à ceux que cela intéresse
Dire l’état du logiciel tel qu’il est réellement
- L’outil
substack-proxygénère, à partir d’une URL de billet Substack copiée-collée par l’utilisateur, une URL permettant de contourner la censure de Twitter - Comme trop de requêtes serveur étaient déclenchées pendant que l’utilisateur saisissait ou modifiait l’URL, un délai d’environ 1 seconde a été ajouté
- Le texte d’état initial était
loading…, mais en réalité il ne s’agissait pas d’un chargement : le système attendait que l’utilisateur finisse sa saisie - « En attente de la fin de la saisie » reflète plus fidèlement l’état réel de la machine
- Même en cas de blocage dû à une erreur, rester affiché sur « en attente de la fin de la saisie » révèle mieux un état problématique que
loading…
Il n’est pas nécessaire de tout enseigner, mais il faut rester fidèle
- Un logiciel n’a pas besoin de tout enseigner à tout le monde
- Souvent, les utilisateurs ne veulent pas connaître la cause ; ils veulent simplement que cela fonctionne correctement
- Malgré cela, si une explication est fournie, elle ne doit pas donner une représentation étrange ou inexacte du fonctionnement de l’ordinateur
- Il est aussi possible de ne fournir qu’un code d’erreur simple et les actions disponibles
Error code 1027: file cannot be saved.[Copy contents][Delete file]
- Les utilisateurs intéressés peuvent rechercher le code d’erreur, et ceux qui ne le sont pas voient immédiatement les choix possibles
Le critère de la simplification
- Une bonne simplification ne coupe pas les pistes qui mènent à la vérité que l’on cherche à expliquer
- Partir du principe que « l’utilisateur moyen ne comprendra pas » et rabaisser tous les utilisateurs au même niveau est une approche dangereuse
- “bits and bytes” est un exemple qui explique à des débutants comment allumer l’ordinateur et appuyer sur
enter, tout en allant jusqu’au code binaire dans le même épisode
1 commentaires
Avis sur Hacker News
L’exemple de message-doesn't-exist semble moins dû à une simplification excessive qu’à une erreur courante quand l’auteur oublie le contexte
Du point de vue d’un programmeur, on a essayé de récupérer quelque chose sur le serveur, et le serveur a répondu qu’il ne l’avait pas, donc « n’existe pas » peut être correct
Mais dans le contexte où l’utilisateur voit ce message sous ses yeux, « n’existe pas » est manifestement faux
Il faut recadrer le contexte, par exemple : « ce message n’est pas sur le serveur, il n’est pour l’instant que temporairement sur votre ordinateur, donc copiez-le »
Même si l’utilisateur ne sait pas ce qu’est un « serveur », le simple fait de savoir qu’« il n’est pas quelque part » rend la phrase beaucoup plus compréhensible
Si un mécanicien désigne toute la voiture en disant « ceci va être remplacé », c’est déroutant ; mais s’il dit « xxx va être remplacé », on peut comprendre même sans savoir ce qu’est xxx
La conception en ligne actuelle donne l’impression d’aller entièrement dans le sens de rendre les gens plus bêtes, en partant du principe que moins l’utilisateur réfléchit, plus il suit facilement
Par exemple, les résultats de recherche Google semblent chaque mois davantage calibrés sur le plus petit dénominateur commun, et même quand on cherche quelque chose de subtil, l’algorithme pousse une réponse qui n’aide pas
Peut-être que beaucoup de gens réagissent effectivement mieux à cette approche, ce qui la rend bonne dans les données, mais personnellement je la déteste
J’aimerais apprendre progressivement et rencontrer de la complexité en interagissant avec un système ; je ne veux pas que cette complexité soit cachée
On a donc rendu l’équipement réglable, et les performances se sont nettement améliorées tandis que les erreurs ont diminué
Je ne comprends pas pourquoi, dans la tech, on affirme exactement l’inverse : plus on s’adapte à un utilisateur moyen imaginaire, mieux ce serait, ou plus ce serait rentable
Je me demande pourquoi la diversité individuelle serait censée pouvoir être ignorée
Si Norton Disk Doctor me manque, ce n’est pas parce que je travaillais à la récupération de disques, mais parce qu’il avait une interface qui respectait l’intelligence de l’utilisateur
D’autres systèmes liés au stockage lançaient des formules indéchiffrables du type « Mode 5/7? [Y] », ou des questions rendues excessivement stupides comme « Are you sure? [N] »
Impossible de savoir de quoi il fallait être sûr, ce qu’était le mode 5, le 7, ou les deux
Norton, au contraire, expliquait en plusieurs paragraphes ce que signifiait chaque choix, replaçait les concepts dans leur contexte et indiquait les avantages et les risques
Au lieu de vous faire appuyer sans cesse sur Y en vous en remettant à la chance, il vous permettait de choisir en connaissance de cause
Ce respect envers le lecteur et l’utilisateur s’applique à toute écriture technique : manuels, interfaces utilisateur, billets de blog, documentation d’API, etc.
Plutôt que d’abêtir les textes pour le « grand public », je pense qu’il vaut mieux former tous les lecteurs qui lisent et comprennent, afin qu’ils progressent un peu techniquement
À titre de référence, « Mode 5/7? » était un vrai message apparu sur une baie SAN Hitachi contenant toutes les données d’un ministère, et le manuel expliquait obligeamment que cette option activait ou désactivait le mode 5/7
En se trompant de choix, la baie pouvait peut-être s’effacer toute seule et tuer un chat, ou bien il ne se passait rien. Qui sait
Les personnes qui créent les paramètres n’auraient presque aucun effort à fournir pour ajouter une courte infobulle explicative à chaque option, et pourtant, en pratique, elles ne le font presque jamais
Si l’objectif est de transmettre de l’information, c’est juste
Mais si l’objectif est d’augmenter les clics, de réduire les demandes au support et d’accroître l’engagement, il est difficile de dire qu’une explication techniquement précise et détaillée est meilleure qu’une explication simplifiée jusqu’à en devenir inexacte
Cela ne veut pas dire que j’approuve le fait de donner la priorité à l’engagement plutôt qu’à la transmission d’information
https://www.goodreads.com/quotes/65213-briefly-stated-the-ge...
Il faut faire en sorte que choisir de poursuivre de tels objectifs devienne réellement risqué pour les personnes qui prennent cette décision
Je me bats beaucoup avec ce problème au travail
On ne peut pas supposer que le lecteur maîtrise l’anglais, qu’il comprend le sujet, ni même qu’il ait envie de le comprendre
Nous avons donc adopté une écriture simple et sans ambiguïté, et nous expérimentons maintenant aussi des formats qui permettent de saisir l’essentiel d’un simple survol
Personnellement, je pense que nhs.uk est le meilleur exemple à suivre
Les gens ne sont pas stupides : ils sont occupés, fatigués, paresseux, ou simplement peu intéressés par les détails
Il y a un équilibre à trouver entre respecter l’intelligence du lecteur et respecter son temps
https://www.gov.uk/guidance/content-design/writing-for-gov-u...
Je pensais que le rasoir de Feynman allait à l’origine dans ce sens. Ça me rappelle sa réponse à une question du public lors de sa conférence QED en Nouvelle-Zélande en 1979.
À la question « Aimez-vous l’idée que notre image du monde doive être fondée sur des calculs incluant des probabilités ? », Feynman a répondu qu’il ne disait pas qu’il aimait ou n’aimait pas ça.
Il a expliqué qu’après une longue formation de scientifique, on développe une certaine façon de voir les choses ; dans une conférence, il peut simplifier un peu et tricher légèrement pour donner l’impression qu’il n’aime pas cela, mais que le vrai sens est plutôt : « c’est étrange ».
Il disait ne pas se demander si cela lui plaisait ou non, mais ce que c’est et ce que ce n’est pas ; le fait d’aimer ou non est totalement hors sujet, et il l’a évacué de son esprit.
Quand il s’agit de complexité et d’explications à des non-spécialistes, le terrier du lapin est toujours plus profond.
Il y a aussi une bonne citation dans la partie du cours de Caltech sur les rotations de l’espace : « Nous n’utiliserons pas ces équations dans toute leur généralité et n’en étudierons pas toutes les conséquences. Cela prendrait des années, et nous devons bientôt passer à un autre sujet. Dans un cours d’introduction, on ne peut que présenter les lois fondamentales et les appliquer à quelques situations qui présentent un intérêt particulier. »
Vu positivement, c’est l’attitude de quelqu’un qui, depuis une position d’expertise, ne veut pas dire quelque chose de faux ni laisser entendre quelque chose qui ne l’est pas ; mais en même temps, cela peut aussi donner l’impression qu’il esquive la question au lieu d’y répondre vraiment.
Dans la vidéo où l’intervieweur lui demande comment fonctionnent les aimants, il répond exactement de la même façon.
« Mon commentaire préféré était celui de lisper… », c’est chouette. Quelqu’un m’a reconnu.
Je m’applique à écrire une série de billets de blog sur la méthode scientifique, mais je reçois très peu de retours, et c’est étrange de voir qu’un commentaire léger comme celui-ci attire l’attention.
La vie est parfois amusante.
L’auteur lui-même n’a pas correctement reproduit la citation de Feynman.
Ce n’est pas « And there are not sixty two kinds of particles », mais « And there are now sixty two kinds of particles ».
Si l’on peut expliquer un sujet d’une manière qui satisfait à la fois les débutants et les experts sans termes techniques, à quoi sert le jargon ?
L’exemple de l’article n’est utile ni aux uns ni aux autres, et la présence ou l’absence de jargon ne l’améliore pas.
C’est simplement une mauvaise explication, ce qui affaiblit l’argument lui-même.
Il faut soit tout transmettre, soit le contourner au moyen de termes spécialisés.
Dans certains cas, une explication qui satisfait les deux camps est possible, mais elle est plus difficile et demande davantage de mots. Au moins dans un contexte médiatique, c’est important.
Cela dit, il existe un spectre, et je pense qu’on peut en général trouver un juste milieu.
Si cela crée une confusion du genre « le message n’existe pas, mais on peut en copier le contenu ? Si on peut le copier, pourquoi ne peut-on pas l’enregistrer ? S’il n’existe pas, pourquoi faut-il le jeter ? », il vaut peut-être mieux être moins explicatif.
Quelque chose comme : « Ce message ne sera bientôt plus disponible. Si vous voulez l’utiliser plus tard, copiez son contenu avant de le supprimer. » suffit.
Parler de cache n’aide pas l’utilisateur.
La vraie solution serait d’ajouter, à la fin du message, un bouton « Enregistrer le contenu du message sur l’appareil ».
Le libellé deviendrait alors clair et mènerait directement à une action.
L’explication plus détaillée pourrait être étiquetée, ou placée sur un second écran accessible via un bouton « explication avancée ».