Pièges courants à éviter

La feuille de route que nous avons abordée pour vous aider à prendre en main le processus de révision post-incident est utile, mais il peut également être utile de connaître certains des obstacles que vous pourriez rencontrer dans ce parcours.

Dans cette unité, vous découvrirez certains pièges courants dans lesquels d’autres sont tombés pendant le processus de révision après incident et comment les éviter.

Piège 1 : Attribution à « erreur humaine »

Vous vous rappellerez peut-être que « erreur de pilotage », une forme spécifique de l’étiquette plus générale « erreur humaine », était la conclusion que les enquêteurs initiaux ont tirée dans l’histoire du B-17 que nous avons commencée dans l’introduction du module. Revenons à cette histoire.

Dans cette introduction, nous avons suggéré que les conclusions tirées pourraient être insatisfaisantes pour vous. Ils ont certainement été insatisfaisants pour Alphonse Chapanis, psychologue militaire à qui les US Army Air Forces (USAAF) ont demandé d’enquêter sur ces incidents. Il a remarqué, entre autres, que ces accidents étaient uniques aux B-17 et à un petit nombre d’autres avions. Il y avait des milliers d’avions de transport C-47 utilisés en Europe occidentale en même temps, mais aucun C-47 n’avait jamais connu un incident similaire.

Il a donc interviewé les pilotes, et en fonction de ce qu’il a entendu de eux, il est allé et a regardé les cockpits B-17. Ce qu’il a vu il y avait deux commutateurs : le commutateur d’engrenages et le commutateur de volets. Les commutateurs étaient d’environ 3 pouces à part l’un de l’autre dans le cockpit. Leur mode d’opération était identique. Ils étaient trop faciles à confondre entre eux, et c’est ce qui s’était passé dans ces incidents. À l’atterrissage d’un avion, les volets sont déployés, puis rétractés avant son immobilisation. Et donc Chapanis a essayé quelque chose de différent.

Il colla une petite roue en caoutchouc sur le levier du train d’atterrissage et une « languette » à angles marqués sur le levier des volets, ce qui fut suffisant pour mettre fin aux accidents.

Il est maintenant connu comme l’un des fondateurs du domaine de l’ergonomie (l’étude des facteurs de conception dans les performances humaines), et il a eu une observation simple : la conception du cockpit pourrait affecter la probabilité d’erreur humaine. Cette approche a continué d’influencer la conception d’avions modernes. Par exemple, aux États-Unis, les règlements relatifs aux avions de catégorie transport exigent que le contrôle du train d'atterrissage ait la forme d'une roue et soit distinct du contrôle de volet.

Alors, pourquoi avons-nous dit cette histoire ?

Les humains font des erreurs. Toutefois, l’erreur humaine n’est pas une cause ; C’est un symptôme. Lorsque l’erreur humaine est considérée comme la raison d’un échec, les gens s’arrêtent là au lieu d’analyser davantage l’incident.

La conception du système, le contexte organisationnel et le contexte personnel influencent tous quand, comment et avec quel impact les personnes font des erreurs. L'« erreur humaine » est une étiquette qui vous amène à cesser d’examiner précisément le moment où vous êtes sur le point de découvrir quelque chose d’intéressant sur votre système.

Le problème avec la conclusion de l'« erreur humaine » dans les enquêtes est qu’il vous fait perdre de vue le fait que ce que les humains ont fait sens pour eux à l’époque. Les erreurs, par définition, ne sont pas délibérées, donc elles n’ont pas l’intention de faire une erreur.

Lorsque nous voyons ou entendons « erreur humaine », c’est un signal que nous devons examiner plus en profondeur. Si nous voulons apprendre, nous ne devons pas arrêter d’examiner quand nous trouvons une erreur humaine, comme nous le faisons souvent. Comme le montre l’histoire des B-17, juste au-delà de l’erreur humaine, nous apprenons des choses intéressantes sur notre système.

Piège 2 : Raisonnement contrefactuel

Contrefactuel signifie « contraire aux faits », et le raisonnement contrefactuel fait référence à raconter une histoire sur les événements qui n’ont pas eu lieu afin d’expliquer les événements qui ont eu lieu. Cela n’a pas beaucoup de sens, même si les gens ont tendance à le faire tout le temps.

Vous pouvez identifier les déclarations contrefactuelles à partir de phrases clés.

• Pourrait avoir
• Devrait avoir
• Aurait
• N’a pas pu
• Ne
• Si seulement

Voici quelques exemples d'énoncés contrefactuels liés aux révisions post-incident :

« Le système de surveillance n’a pas pu détecter le problème. »

« L’ingénieur n’a pas vérifié la validité de la configuration avant de l’adopter. »

« Cela aurait pu être détecté dans l’environnement canari. »

Le problème avec ce type de raisonnement dans une révision post-incident est que vous parlez de choses qui n’ont pas eu lieu au lieu de prendre le temps de comprendre comment ce qui s’est passé, s’est passé. Tu n’apprends rien de cette spéculation.

Piège 3 : Langue normative

La langue normative implique souvent qu’il y avait un cours d’action « évidemment correct » que les opérateurs auraient dû entreprendre, et juge les actions de ces opérateurs avec l’avantage du recul.

La langue normative peut généralement être identifiée par des adverbs tels que « inadapté », « insouciant », « hastily », etc.

La pensée normative vous conduit à juger les décisions en fonction de leurs résultats. Cette façon de parler n’est pas logique, car le résultat est la seule information qui n’était pas disponible pour ceux qui ont pris les décisions et les jugements.

La langue normative peut également être utilisée dans le sens opposé. Les gens peuvent féliciter les opérateurs d’avoir agi « de manière appropriée », par exemple. Mais encore une fois, ce jugement est souvent fait avec l’avantage de l’information que les gens en question n’ont pas eu.

Le problème de la langue normative est similaire au problème du raisonnement contrefactuel : si nous faisons des jugements après le fait utilisant des informations qui n’étaient pas disponibles pour les humains impliqués au cours de l’incident, nous négligeons de comprendre comment les actions des opérateurs leur ont été logiques à l’époque.

Piège 4 : raisonnement mécaniste

Le raisonnement mécaniste fait référence au concept selon lequel un résultat particulier peut être déduit de l’intervention. C’est parfois appelé le syndrome des enfants meddling (inventé par Jessica DeVita) basé sur le principe que « Notre système aurait fonctionné bien... s’il n’avait pas été pour ces enfants médants.

Lorsque vous utilisez le raisonnement mécaniste dans votre révision post-incident, vous fondez vos conclusions sur le sophisme selon lequel les systèmes avec lesquels vous travaillez et au sein desquels vous opérez fonctionnent correctement, et si seulement ces "gosses fouineurs" n'avaient pas fait ce qu'ils ont fait, l'échec n'aurait pas eu lieu.

Toutefois, ce n’est pas la façon dont les systèmes fonctionnent.

Pour illustrer ce point, imaginez le scénario suivant : vous travaillez sur un service de production. Maintenant, vous êtes dit que vous n’êtes pas autorisé à toucher ou à faire quoi que ce soit à ce service. Tout ce qui se passe en dehors de votre équipe se poursuit comme avant : les clients continuent d’utiliser le service, les dépendances externes continuent de changer, l'Internet fonctionne normalement.

Mais vous ne pouvez apporter aucune modification au code ou à la configuration. Aucun déploiement, aucune opération de plan de contrôle, rien.

Pensez-vous que votre service serait toujours opérationnel comme prévu après une journée ? Après une semaine ? Après un mois ? Après un an ? Combien de temps pouvez-vous vous attendre à ce que votre service continue de fonctionner sans intervention humaine ? Dans la plupart des cas, ce n’est pas le cas.

Cet exercice de pensée nous conduit à une conclusion importante :

La capacité adaptative humaine est nécessaire pour maintenir nos systèmes opérationnels.

La seule raison pour laquelle vos systèmes restent opérationnels en premier lieu est en raison des actions des humains dans la boucle de contrôle. C’est seulement par l’action humaine et la capacité à s’adapter aux circonstances changeantes que le système continue de fonctionner.

Par conséquent, il est erroné de conclure que le système était « essentiellement opérationnel... s’il n’avait pas été pour ces enfants médants. En fait, la fiabilité de votre service n’est pas indépendante des humains qui travaillent dessus. Au lieu de cela, il s’agit d’un résultat direct du travail que les humains font tous les jours.

Le problème avec le raisonnement mécaniste est qu’il vous conduit à un chemin où vous croyez que trouver l’homme défectueux équivaut à trouver le problème. Cependant, ce même humain imparfait a improvisé et s'adapte pour maintenir le système en fonctionnement pendant des semaines et des mois. Peut-être que ce rôle est suffisamment important pour être pris en compte lors de votre examen post-incident.

Maintenant que vous connaissez certaines choses à éviter lors d’une révision post-incident, nous pouvons passer à l’unité suivante où nous explorons certaines des pratiques utiles pour ces révisions.