i

Description

La navette spatiale Challenger transportée sur son chenillard vers la rampe de lancement, au milieu des marais de Floride.

Source

NASA · page d’origine

Licence

PD Domaine public

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

Le Dunning-Kruger du manager

Plus on s'éloigne de la pratique, plus on croit comprendre ce qu'on ne voit plus que de loin, et plus personne n'ose le dire.

En bref

• Quoi : un responsable qui a été bon technicien juge aujourd'hui des choix techniques avec une confiance que sa pratique actuelle ne justifie plus.
• Pourquoi : la compétence technique se périme, la confiance, elle, reste ; la hiérarchie coupe les retours qui permettraient de s'en apercevoir.
• Détecter : arbitrages tranchés sans les experts, estimations « à vue », vocabulaire d'il y a dix ans, objections des équipes qui s'éteignent.
• Éviter : séparer « décider » et « juger la technique », demander les raisons plutôt que l'avis, borner son propre périmètre de compétence, se faire contredire.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on le rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. La veille du lancement de Challenger : « enlevez votre casquette d'ingénieur » 27-28 janvier 1986
   2. Pourquoi les moins compétents ne le voient pas, et ce qui aide 1999-2008
5. Signaux de détection
6. Réflexes d'évitement
7. 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
8. Limites
9. Sources et vérification
10. Voir aussi
    1. Se combine avec, ou renforce
    2. Biais voisins
    3. Contrepoids et réflexes associés

Définition#

Illustration inspirée de la personne

Illustration fictive

Le Dunning-Kruger du manager n'est pas un biais distinct au sens strict : c'est la rencontre d'un phénomène établi, la surestimation de sa compétence là où l'on en a peu (voir la fiche Dunning-Kruger), avec une situation très répandue dans les organisations : le responsable qui juge un domaine qu'il ne pratique plus.

Le cas typique est celui de l'excellent développeur devenu chef d'équipe, puis directeur. Il a de la légitimité technique, de bonnes intuitions, un vrai vécu. Mais ce vécu date : la plateforme, les outils, les pratiques et les contraintes ont changé. Il continue de trancher avec l'assurance de l'époque où il était le spécialiste.

À distinguer de deux situations voisines : le manager généraliste qui sait qu'il ne sait pas (situation saine) et le manager qui n'a jamais pratiqué le domaine (le biais est alors le Dunning-Kruger classique). Ici, c'est la péremption qui est en cause.

Le mécanisme#

Kruger et Dunning (1999) ont proposé que, dans un domaine, les compétences nécessaires pour réussir sont les mêmes que celles qui permettent d'évaluer sa réussite : qui en manque juge mal, y compris son propre jugement. Chez le manager, trois facteurs s'ajoutent.

• La compétence se périme, pas la confiance. Une connaissance technique a une durée de vie : les versions, les outils, les pratiques de déploiement et de sécurité évoluent. Le souvenir de « comment ça marche » reste, avec la certitude qui l'accompagne ; ce qui a disparu, c'est la mise à jour. On ne perçoit pas ce qu'on a cessé d'apprendre.
• Les retours disparaissent avec la pratique. Un développeur voit son code échouer aux tests ; un manager voit des synthèses. Les erreurs de jugement technique d'un manager se manifestent des mois plus tard, sous d'autres noms (retard, dette, incident) et sans lien visible avec sa décision. Kahneman et Klein (2009) rappellent que l'intuition d'expert n'est fiable que dans un environnement régulier avec des retours rapides ; le poste de manager en est dépourvu.
• La hiérarchie fait taire la correction. Contredire son responsable est coûteux ; on lui apporte donc des réponses qui le confortent. Il en déduit qu'il avait raison. L'autorité et l'effet de halo (« il était excellent, il l'est encore ») ferment la boucle.

Où on le rencontre#

En conduite de projet#

• Arbitrage d'architecture : le directeur technique impose une solution qu'il maîtrisait il y a dix ans (« on a toujours fait comme ça »), sans lire les retours récents de l'équipe sur ses limites actuelles.
• Estimation « à vue » : « ce n'est qu'un champ à ajouter, deux jours ». L'estimateur a oublié les tests, les migrations de données, la revue de sécurité, le déploiement : tout ce qui, dans sa pratique d'alors, était fait par d'autres ou n'existait pas.
• Revue de dette technique : le sujet est classé « du confort de développeur » parce que le manager ne perçoit pas le coût de ce qu'il ne subit plus au quotidien.
• Choix d'outil ou de prestataire : jugé sur une démonstration, par quelqu'un qui n'a plus l'œil pour distinguer ce qui est solide de ce qui est présentable.
• Revue de code ou de conception en passant : un commentaire péremptoire, formulé en une ligne, qui oriente un chantier de plusieurs semaines.

En management#

• Évaluation de la performance d'un expert : on juge sa vitesse et sa fiabilité sur ce qu'on comprend de son travail, c'est-à-dire sur ses livrables visibles, pas sur la difficulté réelle de ce qu'il traite.
• Recrutement technique : questions d'entretien obsolètes, ou choix de candidats rassurants parce qu'ils parlent le langage connu.
• Promotion de l'expert en manager : il garde l'habitude de trancher seul le technique, par réflexe de ses anciennes fonctions.
• Cadrage d'un objectif : un délai ou un périmètre fixé « parce que c'est faisable » par quelqu'un qui n'a plus les ordres de grandeur actuels.

Cas célèbres#

Signaux de détection#

• Les choix techniques sont tranchés en comité, sans que ceux qui pratiquent aient été entendus, ou après qu'ils ont parlé.
• « Ça ne doit pas être bien compliqué » ou « de mon temps, on faisait ça en une journée ».
• Les réponses aux objections des experts sont des arguments d'autorité (« je connais ça ») et non des raisons.
• Les experts cessent de proposer, et les discussions techniques se font avant et après la réunion, pas pendant.
• Le vocabulaire et les exemples du manager sont ceux d'une technologie ou d'une époque dépassées.
• Les estimations du manager sont systématiquement plus courtes que celles de l'équipe, et l'écart n'est jamais testé.
• Il n'y a plus d'erreur reconnue sur un sujet technique depuis longtemps : ce n'est pas un signe de justesse, mais d'absence de retour.

Réflexes d'évitement#

1. Séparer décider et juger. Le manager décide des priorités, des coûts, des risques acceptables ; les experts jugent la faisabilité et la solidité technique. Dire à voix haute qui tranche sur quoi évite que l'autorité d'un rôle déborde sur le domaine d'un autre.
2. Demander les raisons, pas l'avis. « Qu'est-ce qui te fait penser que ça ne tiendra pas ? Quelles données ? Que faudrait-il voir pour que tu changes d'avis ? » On juge une argumentation sans avoir à juger la technique elle-même.
3. Cartographier son propre périmètre. Pour chaque domaine, noter honnêtement : « pratiqué cette année », « suivi de près », « connu autrefois », « jamais pratiqué ». Le qualificatif « connu autrefois » interdit de trancher seul.
4. Désigner un contradicteur. Confier à quelqu'un le rôle d'avocat du diable sur les décisions techniques, avec la garantie explicite qu'il ne subit aucune conséquence (voir l'effet d'entraînement, qui joue en sens inverse).
5. Parler en dernier. Quand le sujet est technique, le manager donne son avis après les experts, pas avant : parler le premier ancre les réponses.
6. Entretenir une pratique réelle. Une demi-journée par semaine de lecture de code, de support ou de recette ; la participation à un incident ; un petit sujet technique mené jusqu'au bout. L'objectif n'est pas de redevenir expert, mais de garder des critères à jour et des retours directs.
7. Mesurer ses propres jugements. Noter la prévision (« je pense que ce sera livré en trois semaines ») et comparer avec le résultat, dans un carnet de décisions. Les erreurs de calibrage deviennent enfin visibles.
8. Faire un pré-mortem. Avant une décision technique engageante, demander à l'équipe d'imaginer qu'elle a échoué et d'en donner les raisons : cela légitime la critique sans la rendre personnelle.

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

Prompts à intégrer à vos usages#

1. Ce qui a changé depuis ma pratique. À utiliser avant un arbitrage dans un domaine que vous ne pratiquez plus.

J'ai pratiqué [technologie / domaine] jusqu'en [année], et je dois arbitrer sur [sujet] aujourd'hui.
1. Liste ce qui a changé depuis cette date et qui pourrait rendre mes réflexes obsolètes (outils, pratiques, risques, contraintes).
2. Dis ce qui, de ce que je dois probablement croire encore, risque d'être faux ou incomplet.
3. Donne les dix questions les plus utiles à poser à mon équipe, formulées pour que je comprenne sans les mettre en difficulté.
Précise ce dont tu es sûr et ce qui demande vérification ; n'invente aucune référence.

2. Avocat du diable sur une décision technique. À poser avant de trancher, avec votre décision et vos raisons.

Je m'apprête à décider : [décision]. Mes raisons : [raisons].
Joue un expert technique actuel qui n'est pas d'accord avec moi.
Donne les trois objections les plus sérieuses, les signaux qui prouveraient que j'ai tort et ce que mon équipe pourrait hésiter à me dire.
Ne cherche pas à me rassurer et signale si mes raisons reposent sur une expérience ancienne.

Comment les intégrer#

• Avant la réunion : le prompt 1 prépare des questions ; vous les posez, vous ne tranchez pas à sa place.
• Avant de décider : le prompt 2, puis un échange réel avec les personnes concernées ; l'IA prépare le dialogue.
• En revue : consignez vos prévisions dans le carnet de décisions et relisez-les trimestriellement.

Précautions#

• L'IA peut confirmer ce que vous croyez si votre question le suppose : décrivez les faits, pas votre conclusion.
• Ses explications techniques sont plausibles mais parfois fausses ; vérifiez auprès de ceux qui pratiquent avant d'agir.
• Ne collez pas de code, de données clients ou d'informations confidentielles dans un outil non autorisé.
• Elle ne doit jamais servir à court-circuiter les experts, ou à justifier a posteriori une décision déjà prise.

Limites#

• L'effet Dunning-Kruger lui-même est débattu : une partie de la courbe observée peut s'expliquer par des artefacts statistiques (Gignac et Zajenkowski, 2020), et l'étude d'origine porte sur des tâches de laboratoire.
• La transposition au manager est une hypothèse raisonnable, pas un résultat établi par des mesures sur des managers. Le tableau ci-dessus décrit un risque, pas une loi.
• Un manager peut conserver un excellent jugement technique longtemps (formation continue, pratique résiduelle, grande expérience). L'ancienneté n'est pas un défaut ; l'absence de mise à jour et de retours l'est.
• L'inverse existe : le manager qui doute trop de lui-même, abdique et laisse les experts sans arbitrage. Le but est un jugement calibré, pas la défiance.

Sources et vérification#

• Kruger & Dunning (1999), « Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments », Journal of Personality and Social Psychology
• Ehrlinger, Johnson, Banner, Dunning & Kruger (2008), « Why the unskilled are unaware: Further explorations of (absent) self-insight among the incompetent », Organizational Behavior and Human Decision Processes
• Gignac & Zajenkowski (2020), « The Dunning-Kruger effect is (mostly) a statistical artefact: Valid approaches to testing the hypothesis with individual differences data », Intelligence
• Kahneman & Klein (2009), « Conditions for intuitive expertise: A failure to disagree », American Psychologist
• Rogers Commission (1986), Report of the Presidential Commission on the Space Shuttle Challenger Accident, NASA — chapitre V, « The Contributing Cause of the Accident ».
• Vaughan (1996), The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, University of Chicago Press.
• Peter & Hull (1969), The Peter Principle, William Morrow — pour la notion voisine de promotion au-delà de sa compétence.

Voir aussi#