i

Description

Le contrôle de mission d'Apollo 13 et le « mailbox »

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.

La fixation fonctionnelle

Une chose connue pour servir à X est difficilement vue comme pouvant servir à Y, même quand Y est exactement ce qu'il faudrait.

En bref

• Quoi : on ne voit un objet, un composant ou une méthode que dans la fonction pour laquelle on les connaît.
• Pourquoi : l'usage habituel est le premier à venir à l'esprit et masque les autres propriétés de l'objet.
• Détecter : on est bloqué alors que les « ingrédients » de la solution sont sous les yeux ; « ça ne sert qu'à ça ».
• Éviter : décrire les choses par leurs propriétés, changer de vocabulaire, lister les usages possibles, demander à un non-spécialiste.

Sur cette page

1. Définition
2. Le mécanisme
3. Où on la rencontre
   1. En conduite de projet
   2. En management
4. Cas célèbres
   1. Apollo 13 et le « mailbox » 13-17 avril 1970
   2. Le problème de la bougie 1945
   3. Les Shuar d'Amazonie équatorienne 2005
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

La fixation fonctionnelle (functional fixedness) est la difficulté à utiliser un objet autrement que dans la fonction pour laquelle on le connaît. Le psychologue allemand Karl Duncker l'a décrite dans On problem-solving (1945), à partir d'expériences menées dans les années 1930 : un objet dont on vient d'utiliser la fonction habituelle devient plus difficile à percevoir comme un élément d'une autre solution.

Le problème est resté célèbre sous le nom de problème de la bougie : on donne à un participant une bougie, une boîte de punaises et des allumettes, et on lui demande de fixer la bougie au mur, de manière à ce que la cire ne coule pas sur la table. La solution consiste à vider la boîte, à la punaiser au mur et à poser la bougie dessus : la boîte sert de support, pas de récipient. Beaucoup de participants ne la voient pas, parce que la boîte leur est présentée pleine de punaises : elle « est » un contenant.

Le mécanisme#

• L'étiquette fonctionnelle. Un objet est mémorisé avec sa fonction (« une boîte de punaises »). C'est cette étiquette, plus que sa forme, sa matière ou ses dimensions, qui vient à l'esprit.
• L'usage récent occupe la place. Dès qu'un élément vient d'être utilisé dans une fonction, il est « pris » : le réaffecter demande un effort que l'on ne fait pas tant qu'une autre piste est disponible.
• Le cadre du problème. La façon dont le problème est posé désigne déjà les outils à employer, et on cherche dans cet espace-là, plutôt que de revenir aux propriétés de ce dont on dispose.
• L'expertise comme filtre. Plus on connaît un outil, plus ses usages standard sont ancrés ; l'expert est parfois plus touché que le novice (voir l'effet marteau).

Où on la rencontre#

En conduite de projet#

• Résolution de problème technique : une fonctionnalité du système est vue comme « ne servant qu'à X » ; on ne pense pas à l'utiliser pour Y (une file de messages comme journal, un champ libre comme extension, un export comme interface).
• Réutilisation de composants : un module construit pour un usage n'est jamais envisagé pour un autre besoin similaire, et on en réécrit un.
• Données : une donnée collectée pour la facturation n'est pas imaginée comme matière d'analyse de la qualité ou de l'usage.
• Outils : un outil de suivi de tickets n'est vu que comme un outil de tickets, pas comme support d'un registre de décisions, d'une base de connaissances ou d'un tableau de bord.
• Gestion de crise : à court de ressources, l'équipe cherche l'outil prévu, pas ce qui, dans l'environnement, pourrait faire l'affaire.
• Conception : on reprend la solution que l'on a déjà employée pour un problème qui lui ressemble, sans se demander si une autre fonction du même outil serait plus simple.

En management#

• Affectation des personnes : un collaborateur est « un testeur » ou « une chargée de support » ; on ne voit pas qu'il pourrait animer un atelier, former ou piloter un sujet, parce que sa fonction l'enferme.
• Rôles et réunions : le comité de pilotage sert à piloter, la rétrospective à regarder le passé ; on n'imagine pas de les utiliser autrement, même quand ils ne répondent plus au besoin.
• Budgets et espaces : un budget de formation « ne sert qu'à des stages » ; une salle de réunion « n'est pas un lieu de travail silencieux ».
• Organisation du travail : un processus conçu pour une situation est appliqué tel quel à une autre, plutôt que de ne retenir de lui que son intention.

Cas célèbres#

Signaux de détection#

• « Ça ne sert qu'à ça », « ce n'est pas fait pour ça ».
• Le problème est bloqué alors qu'on dispose, de l'avis de tous, des ressources nécessaires.
• La discussion tourne autour de ce que l'outil est (son nom, sa catégorie) plutôt que de ce qu'il fait.
• On achète ou on développe un outil neuf alors qu'un outil existant a les propriétés requises.
• Un nouvel arrivant ou un non-spécialiste propose en deux minutes une idée que personne n'avait envisagée.
• La solution est « évidente » une fois qu'on l'a trouvée.

Réflexes d'évitement#

1. Décrire par les propriétés. Remplacer « une boîte de punaises » par « un petit récipient rigide, plat, que l'on peut fixer au mur ». Faites de même pour un module, une table ou une réunion : ce qu'ils font, pas comment on les nomme.
2. Lister avant de chercher. Inventoriez ce dont on dispose (outils, données, personnes, temps), puis demandez « qu'est-ce que chaque élément pourrait faire d'autre ? » avant de chercher la solution.
3. Reformuler le problème. Passer du « comment faire X avec Y ? » à « quelle est la fonction à obtenir ? ». Plus le besoin est abstrait, plus les solutions possibles sont nombreuses.
4. Changer de vocabulaire. Un mot de métier enferme : employer le vocabulaire d'un autre domaine ou un mot neutre desserre le cadre.
5. Demander à un non-spécialiste. Quelqu'un qui n'a jamais utilisé l'outil n'est pas gêné par sa fonction officielle.
6. Chercher les usages détournés. Cherchez comment d'autres ont détourné le même outil ; la communauté d'utilisateurs en a souvent trouvé.
7. Prendre un temps de pause. Après un blocage, changer d'activité puis revenir permet souvent de repartir sur une autre représentation du problème.

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

Prompts à intégrer à vos usages#

1. Redécrire les ressources par leurs propriétés. Quand on est bloqué alors qu'on dispose, en principe, de tout ce qu'il faut.

Voici un problème : [description]. Voici ce dont nous disposons : [liste des outils, composants, données, personnes, contraintes].
1. Redécris chaque élément par ses propriétés et capacités, sans utiliser son nom ni sa fonction habituelle.
2. Pour chacun, donne trois usages inhabituels qui pourraient contribuer à résoudre le problème.
3. Combine deux ou trois éléments pour proposer cinq solutions, de la plus classique à la plus audacieuse.
4. Indique, pour chaque solution, la contrainte ou le risque qui pourrait la rendre irréalisable.

2. Du problème à la fonction. Pour sortir de la solution qu'on avait en tête.

Mon problème est formulé ainsi : [formulation]. Elle contient probablement une solution implicite.
Reformule-le en trois niveaux d'abstraction croissants, de plus en plus centrés sur la fonction à obtenir (« permettre à... de... »).
Pour chaque niveau, cite des familles de solutions très différentes qui y répondraient, y compris des solutions sans technologie ou sans outil nouveau.
Ne présume pas que mes outils actuels doivent être conservés.

Comment les intégrer#

• Lors d'un blocage : lancer le prompt 1 avant de convoquer une réunion, puis discuter des pistes en équipe.
• Au démarrage d'un chantier : le prompt 2 évite de partir de la solution habituelle.
• En atelier : projeter les résultats de l'IA et faire voter sur la faisabilité.

Précautions#

• L'IA suggère parfois des usages qui n'existent pas ou qui ne marchent pas ; testez avant de vous engager.
• Ne collez pas d'architecture interne, de données ou d'informations de clients dans un outil non autorisé.
• Elle peut elle-même être « fixée » : si vous lui donnez la solution en tête, elle la développe. Décrivez le besoin avant la solution.

Limites#

• L'expérience de la bougie est devenue un symbole de la créativité, mais ses résultats portent sur une tâche artificielle et de petits échantillons ; les liens avec la créativité professionnelle sont plausibles, pas démontrés.
• Les répétitions sont nombreuses mais leur ampleur varie, et la littérature discute encore de ce qui est la cause de l'effet (présentation, expérience, instructions).
• Un usage conventionnel a de bonnes raisons d'exister : détourner un outil peut introduire des risques (maintenance, sécurité, support). La fixation fonctionnelle est un problème quand elle empêche d'envisager, pas quand elle conduit à choisir l'usage standard après examen.
• Le récit d'Apollo 13 est connu en grande partie par des témoignages et des reconstitutions ; la procédure en 19 étapes figure aux archives de la NASA.

Sources et vérification#

• Duncker, K. (1945), « On problem-solving » (traduction de L. S. Lees), Psychological Monographs, 58(5), n° 270.
• Adamson, R. E. (1952), « Functional fixedness as related to problem solving: A repetition of three experiments », Journal of Experimental Psychology, 44(4).
• German & Barrett (2005), « Functional fixedness in a technologically sparse culture », Psychological Science, 16(1)
• NASA, Apollo 13 Flight Journal — la « boîte aux lettres » (adaptateur de CO₂)
• Lovell, J. & Kluger, J. (1994), Lost Moon: The Perilous Voyage of Apollo 13, Houghton Mifflin.

Voir aussi#