i

Description

Une quincaillerie « Hammer and Nails » (carte postale ancienne)

Source

Tichnor Brothers, Publisher · 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.

L'effet marteau

Quand on a un marteau, tout ressemble à un clou : on applique la solution qu'on maîtrise, qu'elle convienne ou non.

En bref

• Quoi : l'outil, la technologie ou la méthode que l'on maîtrise devient la réponse par défaut, même à des problèmes pour lesquels elle n'est pas faite.
• Pourquoi : l'effort d'apprentissage est déjà payé, la solution connue est rassurante, et le problème est reformulé pour qu'elle s'y applique.
• Détecter : la solution est nommée avant que le problème soit décrit ; personne n'a comparé d'alternative.
• Éviter : décrire le besoin sans nommer d'outil, comparer au moins deux options sur des critères écrits, demander ce qui ferait renoncer à l'outil.

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. Les 15 841 cas perdus par un tableur 25 septembre - 2 octobre 2020
   2. Les noms de gènes transformés en dates 2016
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 fictive

Illustration fictive

L'effet marteau, ou « loi de l'instrument », est la tendance à traiter tous les problèmes avec l'outil que l'on connaît le mieux. Le philosophe Abraham Kaplan en donne la formule en 1964 dans The Conduct of Inquiry : « Donnez un marteau à un petit garçon, et vous verrez que tout ce qu'il rencontre a besoin d'être martelé » (Give a small boy a hammer, and he will find that everything he encounters needs pounding). Le psychologue Abraham Maslow en popularise la version aujourd'hui la plus connue en 1966, dans The Psychology of Science : « Je suppose qu'il est tentant, si le seul outil dont on dispose est un marteau, de tout traiter comme si c'était un clou » (I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail).

Ce n'est pas une règle générale selon laquelle « les outils sont mauvais ». Un outil maîtrisé est souvent un bon choix. Le biais commence quand l'outil est choisi avant d'avoir regardé le problème, ou quand le problème est déformé pour entrer dans l'outil. Il ne s'agit pas non plus d'un biais mesuré en laboratoire comme l'ancrage : c'est une observation ancienne et très répandue, plus qu'un effet chiffré de façon précise. La fiche le dit pour ne pas lui faire dire davantage.

Le mécanisme#

Plusieurs ressorts se combinent, qui tiennent tous à la même idée : ce que je sais faire m'est plus accessible que ce que j'ignore.

• Le coût déjà payé. Apprendre un outil, une plateforme, un langage ou un cadre de travail demande des mois. Le renoncer, c'est perdre cet investissement ; l'utiliser de nouveau semble gratuit, alors qu'il ne l'est pas toujours (voir les coûts irrécupérables).
• La disponibilité. On pense d'abord à ce qu'on connaît. Les solutions que l'on n'a jamais pratiquées ne viennent simplement pas à l'esprit au moment de formuler les options.
• La reformulation silencieuse. Le problème est redéfini pour correspondre à l'outil : « on a besoin d'un entrepôt de données » devient « on a besoin d'une table de plus » ; « on a besoin d'un suivi » devient « on a besoin d'un classeur partagé ». Le besoin glisse sans que personne ne l'ait décidé.
• Le confort social. Dans une équipe, proposer l'outil que tout le monde connaît est facile à défendre. Proposer autre chose oblige à justifier, à former et à assumer le risque.
• L'identité professionnelle. Celui qui est « l'expert de » tel outil a intérêt, sans malice, à ce que cet outil soit pertinent (voir le biais de l'expert).

Où on le rencontre#

En conduite de projet#

• Le tableur devenu base de données. Un classeur partagé sert de référentiel, d'outil de suivi et de source de rapports. Il fonctionne tant que le volume reste faible, puis les formules, les versions et les droits deviennent ingérables.
• La technologie unique. Une équipe qui connaît bien une base relationnelle y range des documents, des files de messages ou des séries temporelles. À l'inverse, une équipe enthousiaste d'une technologie récente l'applique à des besoins simples qui n'en demandent pas tant.
• La méthode universelle. Le même rituel (cycle en V, sprints de deux semaines, Kanban) est appliqué à une maintenance, à un projet d'infrastructure, à une recherche de solution, parce que « c'est ainsi que nous travaillons ».
• Le script pour tout. L'ingénieur qui aime l'automatisation écrit un script là où une configuration standard de l'outil en place suffirait, et laisse à l'équipe un code à maintenir.
• Le prestataire. Un fournisseur de services propose, quel que soit le besoin, ce qu'il sait faire et vendre : sa plateforme, sa méthode, ses profils.

En management#

• Le manager à une seule clé. Issu de la technique, il règle un conflit d'équipe par un processus ; issu des ressources humaines, il règle un défaut de conception par une conversation. Chacun traite avec ce qu'il sait faire.
• Le tableau de bord pour tout. Face à une difficulté, la réponse est un indicateur de plus, quel que soit le problème (voir l'effet Goodhart).
• La réorganisation comme réflexe. Un dirigeant qui a réussi par une réorganisation en propose une à chaque difficulté.
• La formation comme réponse. Un défaut qui tient à l'outillage, au calendrier ou à la charge est traité par un stage, parce que la formation est l'outil que l'on a sous la main.

Cas célèbres#

Signaux de détection#

• La solution est nommée avant que le problème soit décrit : « on va faire ça en [outil] ».
• Les options présentées ne diffèrent que par la manière d'utiliser la même technologie.
• Le besoin est exprimé avec le vocabulaire de l'outil (« une table », « un workflow », « un dashboard ») plutôt qu'avec celui de l'usage.
• Les contournements s'accumulent : macros, scripts, exports manuels pour compenser ce que l'outil ne fait pas.
• « On a toujours fait comme ça », « on a déjà la licence », « c'est ce que l'équipe connaît » sont les seules justifications.
• Personne ne sait dire dans quel cas l'outil ne serait pas le bon.

Réflexes d'évitement#

1. Décrire le besoin sans nommer d'outil. Écrivez le problème en termes d'usage, de volume, de fiabilité, de durée de vie, d'utilisateurs. Si l'outil figure dans la phrase, la phrase décrit déjà la solution.
2. Comparer au moins deux options, dont une inhabituelle. Pas pour la choisir à tout prix, mais pour s'obliger à justifier le choix par des critères écrits.
3. Fixer les critères avant d'examiner les outils. Volume, délai, compétences disponibles, coût de maintenance, risque, réversibilité. Ils pèsent plus que la familiarité.
4. Écrire ce qui ferait renoncer. « Nous abandonnerons cette approche si le volume dépasse X, ou si nous ajoutons plus de Y contournements. » La limite écrite à l'avance est plus facile à appliquer que celle qu'on découvre en crise.
5. Chiffrer le coût réel du connu. La licence déjà payée n'est pas le coût ; comptez la maintenance, les contournements, le risque d'erreur silencieuse.
6. Faire entrer un regard extérieur. Une personne qui n'a pas investi dans l'outil pose naturellement la question de l'alternative.
7. Tenir un test de limite. Pour tout outil placé au centre d'une chaîne, ajoutez un contrôle de complétude (nombre d'éléments entrés contre nombre d'éléments traités).

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

Prompts à intégrer à vos usages#

1. Options pour un besoin décrit sans outil. À utiliser avant de choisir un outil ou une technologie.

Voici un besoin décrit sans aucune mention d'outil ni de technologie.
Propose quatre familles de solutions de natures différentes (pas quatre variantes de la même).
Pour chacune : ce qu'elle fait bien, ce qu'elle fait mal, le volume ou le contexte à partir duquel elle ne convient plus, et le coût de maintenance à prévoir.
Ne recommande rien : je veux comparer. Ne cite pas de produit dont tu n'es pas certain qu'il existe.

Besoin : [description : usage, volume, fiabilité attendue, durée de vie, utilisateurs, contraintes]

2. Défendre l'alternative et chercher les conditions de sortie. Quand l'équipe est sur le point de retenir l'outil qu'elle connaît.

Notre équipe s'apprête à résoudre ce besoin avec [outil habituel] : [besoin].
1. Donne les meilleurs arguments pour qu'une approche très différente soit préférable, sans caricaturer notre choix.
2. Liste les symptômes qui indiqueraient dans six mois que [outil habituel] n'était pas adapté (volumes, contournements, erreurs silencieuses).
3. Propose un contrôle simple de complétude ou de cohérence à mettre en place dès le début.
4. Dis, en une phrase, dans quels cas [outil habituel] reste malgré tout le bon choix.

Comment les intégrer#

• Au cadrage : lancez le prompt 1 avant toute discussion d'outil, puis comparez avec ce que l'équipe a en tête.
• Avant la décision : le prompt 2 alimente la rubrique « conditions de sortie » du dossier de choix.
• En revue d'architecture : demandez à voir l'alternative écartée et la raison du refus, pas seulement la solution retenue.

Précautions#

• Ne nommez pas l'outil dans votre question : vous orienteriez la réponse.
• Les produits, versions et limites cités par l'IA peuvent être faux ou périmés : vérifiez-les dans la documentation officielle.
• Une liste d'options n'est pas une décision : c'est à l'équipe, qui connaît ses compétences et son contexte, de trancher.
• Ne collez pas de données ou de plans d'architecture confidentiels dans un outil non autorisé.

Limites#

• Il s'agit d'une observation de bon sens plus que d'un résultat expérimental précis : il n'existe pas d'effet chiffré de référence comme pour l'ancrage.
• S'appuyer sur ce que l'on maîtrise est souvent rationnel : le coût d'apprentissage, le support, le recrutement et la maintenance penchent légitimement vers le connu. Le biais n'est pas de choisir l'outil connu, c'est de ne pas avoir comparé.
• L'effet inverse existe : l'attrait de la nouveauté, qui pousse à ignorer l'outil adapté parce qu'il est ancien (voir le biais pro-innovation).
• Les deux « cas » de cette fiche illustrent le risque de l'outil unique ; ils ne prouvent pas que les équipes concernées ont suivi ce raisonnement. L'attribution à un biais reste une interprétation.

Sources et vérification#

• Kaplan, A. (1964), The Conduct of Inquiry: Methodology for Behavioral Science, Chandler Publishing — origine de la « loi de l'instrument » (la formule du petit garçon et du marteau).
• Maslow, A. H. (1966), The Psychology of Science: A Reconnaissance, Harper & Row — formule du marteau et du clou.
• The Register (5 octobre 2020), article sur l'erreur de comptage des cas par Public Health England — 15 841 cas, limite du format .xls.
• The Conversation (2020), « Why you should never use Microsoft Excel to count coronavirus cases »
• Ziemann, Eren & El-Osta (2016), « Gene name errors are widespread in the scientific literature », Genome Biology — 704 articles sur 3 597.

Voir aussi#