i

Description

Les mains d'un pianiste posées sur les touches d'un piano, en noir et blanc.

Source

Jamille Queiroz · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

La malédiction du savoir

Ce qui nous paraît évident ne l'est que parce que nous le savons déjà, et nous oublions ce que c'était de l'ignorer.

En bref

• Quoi : celui qui sait surestime ce que les autres savent et sous-estime l'effort nécessaire pour comprendre.
• Pourquoi : une fois la connaissance acquise, on ne peut plus la « désapprendre » pour simuler l'ignorance.
• Détecter : « c'est évident », des sigles jamais définis, une documentation que seuls ses auteurs comprennent.
• Éviter : faire relire par un novice, observer quelqu'un qui essaie, expliquer pas à pas, mesurer plutôt que supposer.

Sur cette page

1. Définition
2. Le mécanisme
3. L'expérience des « tapeurs » et des « auditeurs »
4. Où on la rencontre
   1. En conduite de projet
   2. En management
5. Cas célèbres
   1. Les tapeurs de Stanford 1990
   2. Quand l'expert prédit le temps du novice 1999
   3. Des marchés où l'on ne peut plus « oublier » 1989
6. Signaux de détection
7. Réflexes d'évitement
8. Avec l'IA : détecter, remédier, atténuer
   1. Détecter
   2. Remédier
   3. Atténuer
   4. Prompts à intégrer à vos usages
   5. Comment les intégrer
   6. Précautions
9. Limites
10. Sources et vérification
11. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration fictive

Illustration fictive

La malédiction du savoir (curse of knowledge) est la difficulté, pour une personne informée, à raisonner du point de vue d'une personne qui ne l'est pas. Dès qu'on sait quelque chose, on le trouve simple, on suppose que les autres le savent aussi, et on oublie les étapes qui ont été nécessaires pour y arriver.

L'expression est popularisée en économie par Colin Camerer, George Loewenstein et Martin Weber (1989) : dans une expérience de marché, des agents informés sur les résultats futurs d'une entreprise n'arrivaient pas à ignorer cette information pour deviner ce que des agents non informés estimeraient. En psychologie du développement et de la cognition, on retrouve le même phénomène chez l'adulte (Birch et Bloom, 2007). Il est proche de l'illusion de transparence, mais il concerne les connaissances plutôt que les émotions.

Ce n'est ni de la mauvaise volonté, ni de l'arrogance : c'est un effet mécanique, qui frappe d'autant plus qu'on est compétent.

Le mécanisme#

• Le savoir ne se met pas en pause. Pour imaginer l'état d'esprit d'un novice, on part de son propre état d'esprit et on essaie de le corriger. Comme pour l'ancrage, la correction est insuffisante.
• La connaissance devient invisible. Plus un savoir est ancien et automatisé, moins on se souvient qu'il a été appris : les experts « compressent » les étapes (chunking) et ne voient plus ce qui était difficile.
• On juge la difficulté de l'extérieur à partir du résultat. Le lecteur d'un document déjà compris le trouve clair ; il aurait pu le trouver obscur avant.
• Les signaux de retour manquent. L'interlocuteur qui ne comprend pas n'ose pas toujours le dire, surtout face à un expert ou un supérieur ; l'expert prend le silence pour de la compréhension.

L'expérience des « tapeurs » et des « auditeurs »#

Où on la rencontre#

En conduite de projet#

• Documentation et README : « lancer le script de build » sans dire où, avec quelle version, avec quels droits. L'auteur a fait ces étapes cent fois et ne les voit plus.
• Onboarding : l'ancien explique l'architecture en vingt minutes, avec des sigles internes, et conclut « vous avez des questions ? ». Le nouveau arrive à dire « non » par pudeur.
• Spécifications et tickets : « gérer le cas habituel », « comme d'habitude ». Le développeur qui découvre le sujet doit deviner l'habitude.
• Messages d'erreur et interfaces : « Erreur 4021 » parle à l'équipe qui a écrit le code, pas à l'utilisateur.
• Estimation : l'expert estime le temps qu'un novice mettra à apprendre un outil en se basant sur son propre temps. Hinds (1999) a observé que des experts sous-estimaient le temps nécessaire à des novices pour utiliser un appareil, et que leur confiance dans leurs prévisions était élevée.
• Revue de code : le relecteur qui connaît le module trouve le code « lisible » ; le suivant, qui ne le connaît pas, y passe une journée.

En management#

• Consignes et délégation : « tu t'en occupes ? », sans le contexte, le critère de réussite ni l'échéance, parce que tout cela est évident pour le manager.
• Retour d'information : « sois plus stratégique », « plus de leadership » : le manager sait ce qu'il veut dire, le collaborateur ne sait pas quoi changer.
• Formation et accompagnement : un expert devenu formateur saute des étapes ; les stagiaires hochent la tête et décrochent.
• Annonces de changement : la direction a réfléchi des mois à la réorganisation ; elle l'annonce en dix minutes comme si le raisonnement allait de soi.
• Passation : celui qui part laisse une note de trois lignes sur un poste qu'il connaît par cœur.

Cas célèbres#

Signaux de détection#

• Les mots « évident », « trivial », « bien sûr », « comme tout le monde sait ».
• Une documentation que seuls ses auteurs comprennent, ou que personne n'ose critiquer.
• Des sigles, noms de code et abréviations internes jamais définis.
• Les nouveaux arrivants posent toujours les mêmes questions, ou n'en posent aucune.
• « On l'a expliqué pourtant ! » après un malentendu.
• Un onboarding annoncé pour une semaine qui en dure deux mois.

Réflexes d'évitement#

1. Faire relire par un novice. Un document n'est terminé que quand quelqu'un qui ne connaît pas le sujet a pu l'utiliser seul. Observez-le sans l'aider.
2. Tester plutôt que demander « c'est clair ? ». Demandez de reformuler, de refaire l'étape, ou de dire ce qu'il ferait en premier. La réponse « oui » ne prouve rien.
3. Définir avant d'employer. Chaque sigle est défini à sa première apparition ; un glossaire et un schéma d'ensemble en tête de document.
4. Dire le pourquoi, pas seulement le quoi. Le contexte, l'objectif et le critère de réussite font ce que l'expert croit évident.
5. Donner un exemple complet. Un cas concret de bout en bout, avec les valeurs, vaut dix paragraphes abstraits.
6. Noter les questions des nouveaux. Chaque question d'un débutant est un trou dans la documentation ; corrigez-le le jour même.
7. Multiplier ses estimations de formation. Pour un temps de prise en main, partez du temps constaté sur les derniers arrivants.

Avec l'IA : détecter, remédier, atténuer#

Prompts à intégrer à vos usages#

1. Relecteur novice. À lancer sur un document avant de le diffuser (sans données confidentielles).

Tu es [un développeur junior / un nouveau chef de projet / un client non technique] qui découvre ce sujet. Tu n'as aucun contexte en dehors du texte ci-dessous.
1. Liste tous les termes, sigles et références que tu ne comprends pas.
2. Indique chaque endroit où tu manques d'une étape, d'un prérequis ou d'un exemple pour réussir seul.
3. Écris les dix premières questions que tu poserais à l'auteur.
4. Ne comble pas les blancs : si une information manque, dis-le plutôt que de la deviner.

Texte : [document]

2. Test de compréhension sans contexte. Pour vérifier qu'un texte se suffit à lui-même.

Voici une procédure. En n'utilisant que ce qui est écrit dans le texte, réponds aux questions ci-dessous. Pour chaque question, indique si la réponse figure dans le texte (cite le passage) ou si elle n'y figure pas.
Questions : [par exemple : que fait-on en premier ? avec quels droits ? que faire si l'étape 3 échoue ? comment sait-on que c'est terminé ?]

Texte : [procédure]

Comment les intégrer#

• Au moment d'écrire : le prompt 1 sert de première relecture, avant même de solliciter un collègue.
• Avant diffusion : le prompt 2 vérifie que le document est autonome.
• Au final : un vrai novice relit quand même ; l'IA ne remplace pas un lecteur humain, elle le précède.

Précautions#

• Ne collez pas de documents contenant des données personnelles, des secrets ou des informations client dans un outil non autorisé.
• Précisez le niveau du public : sans cela, l'IA suppose un lecteur moyen et manque les trous.
• L'IA complète volontiers les blancs avec des suppositions plausibles : demandez-lui explicitement de signaler ce qui manque plutôt que de le deviner.
• Elle a elle-même une forme de « malédiction » : ses explications utilisent un vocabulaire d'expert si on ne la contraint pas.

Limites#

• L'effet est bien établi, mais son ampleur varie selon la tâche ; les stratégies de correction (« imagine que tu ne sais pas ») ont une efficacité modeste, ce qui plaide pour des dispositifs extérieurs (relecture, test) plutôt que pour la bonne volonté.
• Le récit des tapeurs est un résultat de thèse, diffusé surtout par des ouvrages de vulgarisation : l'ordre de grandeur est solide, mais le détail des conditions est moins bien documenté que dans un article publié.
• Simplifier n'est pas infantiliser : un public expert apprécie un document dense. Le but est d'adapter au public réel, pas de tout expliquer à tous.

Sources et vérification#

• Camerer, Loewenstein & Weber (1989), « The Curse of Knowledge in Economic Settings: An Experimental Analysis », Journal of Political Economy, 97(5)
• Birch & Bloom (2007), « The Curse of Knowledge in Reasoning About False Beliefs », Psychological Science, 18(5)
• Hinds (1999), « The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance », Journal of Experimental Psychology: Applied, 5(2)
• Newton, E. L. (1990), thèse de doctorat, université Stanford (titre cité sous plusieurs formes selon les sources, dont The Rocky Road from Actions to Intentions, ainsi que dans l'ouvrage des frères Heath) — l'expérience des tapeurs.
• Heath, C. & Heath, D. (2007), Made to Stick: Why Some Ideas Survive and Others Die, Random House — récit de l'expérience de Newton (3 airs reconnus sur 120).
• Pinker, S. (2014), The Sense of Style, Viking — la malédiction du savoir comme cause principale des textes opaques.

Voir aussi#