Activer le bozo bit coupe l’apprentissage

• Le bozo bit désigne l’attitude qui consiste à considérer qu’il ne vaut plus la peine d’écouter les paroles ni le jugement d’une certaine personne
• Si l’on met à distance la personne impliquée dans un incident en la jugeant incompétente, l’organisation a moins d’occasions d’apprendre de cet incident
• La réponse de PocketOS à un incident lié à l’IA relève du distancing through differencing décrit par Cook et Woods
• En considérant l’incendie d’une usine à l’étranger comme l’affaire des autres, une usine américaine est passée à côté des points communs systémiques qu’elles partageaient
• Si l’on conclut un incident lié à l’IA par « ils auraient dû le savoir », il devient difficile d’en tirer des améliorations de sécurité

---

Considérer un incident comme le problème des autres fait cesser l’apprentissage

• Le bozo bit est une expression du secteur logiciel qui désigne le fait de ne plus respecter le jugement d’une personne donnée et de considérer qu’il ne vaut plus la peine d’écouter ce qu’elle dit
• Quand on réagit à la nouvelle d’un incident par une phrase du type « Comment peut-on ne pas faire X ? », on en vient à voir les personnes concernées comme incompétentes et à les séparer de sa propre organisation
• Le post de Jer Crane, fondateur de PocketOS, sur X, An AI Agent Just Destroyed Our Production Data. It Confessed in Writing, a beaucoup attiré l’attention comme incident lié à l’IA, et de nombreux messages en ligne présentaient PocketOS comme incompétent
• Cette attitude réduit les occasions d’apprendre de l’incident et correspond à ce que Cook et Woods appellent distancing through differencing

• Mettre à distance par la différenciation (distancing through differencing)

  • Richard Cook et David Woods ont employé ce terme dans leur texte de 2006, Distancing Through Differencing: An Obstacle to Organizational Learning Following Accidents
  • Ce texte a été publié comme un chapitre de Resilience Engineering: Concepts and Precepts
  • Lorsqu’on se concentre sur les différences entre la partie ayant subi l’incident et soi-même, on finit par penser qu’il n’y a aucune leçon à appliquer à ses propres opérations et pratiques
  • La conclusion « cet incident ne peut pas se produire ici » est une forme typique de ce phénomène

Des incidents qui se répètent et des points communs manqués

• Cook et Woods prennent comme exemple un incendie chimique dans une usine de fabrication américaine
• Un incendie similaire s’était déjà produit auparavant dans une usine du même groupe à l’étranger, et les employés américains le savaient
• Pourtant, les employés américains considéraient leurs collègues étrangers comme moins qualifiés, moins motivés et moins prudents, et ont jugé qu’ils n’avaient rien à apprendre d’eux
• Même après l’incendie dans l’usine américaine, les travailleurs d’une autre équipe de la même usine ont attribué la cause à la faible qualification de l’équipe touchée
• Ce type de séparation empêche de voir les points communs du système partagés entre les personnes impliquées et soi-même
• Cook et Woods estiment qu’il ne faut pas écarter des événements qui semblent différents en surface, et que si chaque événement est unique à un certain niveau d’analyse, il révèle à un autre niveau des schémas communs
• Si l’on réduit l’incident de PocketOS à la conclusion simpliste selon laquelle « ils ont utilisé l’IA de manière irresponsable », il n’y a plus rien à apprendre
• Le fournisseur Railway, utilisé par PocketOS, exposait une delete API et a ensuite indiqué dans Your AI wants to nuke your database. Guardrails fix that avoir mis en place des changements pour améliorer la sécurité de l’ensemble du système
• D’autres incidents liés à l’IA continueront d’apparaître dans le secteur, et adopter l’attitude « ils auraient dû savoir qu’il ne fallait pas faire X » revient à tomber dans le piège du distancing through differencing
• Il y a une différence entre quelqu’un qui prend délibérément un risque excessif et quelqu’un qui le prend sans s’en rendre compte, et il est difficile de blâmer une personne simplement parce qu’elle ignorait ce qu’elle ignorait
• C’est en dépassant le distancing through differencing que la réponse des organisations peut changer

[GN⁺]

Avis sur Lobste.rs

• La valeur du bozo bit tient au fait que certaines personnes constituent une source stable d’information inverse
  Ces gens arrivent de façon habituelle et répétée à des conclusions erronées, comprennent de travers même des documents rédigés très directement, et proposent des conceptions qui ne résolvent pas le problème visé tout en en créant de nouveaux
  Activer le bozo bit pour quelqu’un signifie qu’on a jugé que chercher à tirer de la connaissance de sa communication était une perte de temps
  Cet article mélange le bozo bit avec un autre phénomène : être fermement convaincu qu’un problème donné ne peut pas arriver, puis fabriquer a posteriori des raisons à partir de là
  Le terme que j’ai déjà entendu pour ça est rationalisation a posteriori, et on débat depuis des siècles, voire des millénaires, de la nécessité d’éviter cela
  Pour revenir à l’exemple de l’article, l’entreprise qui a donné à un LLM des privilèges d’administrateur sur la base de données de production : la réaction « ça ne m’arriverait pas à cause de X » est légitime si X ressemble à « donner des privilèges d’administrateur de base de données de production à un LLM est tellement aberrant et follement dangereux qu’on ne le ferait jamais au départ »
  C’est comparable aux personnes qui mangent quelque chose de dangereux et finissent en catastrophe. Si je lis qu’une personne est morte d’un parasite cérébral après avoir mangé une limace, je peux être certain que je ne mourrai pas de cette cause précise
  L’auteur imagine que c’est parce que je me crois meilleur ou plus intelligent que la personne morte, mais le raisonnement réel ressemble plutôt à : « même si j’étais affamé sur une île déserte remplie de limaces bien dodues, je suis sûr à 100 % que je n’en mangerais pas volontairement, donc les parasites transmis par les limaces ne font pas partie de mon modèle de risque »
  J’ai aussi du mal à être d’accord avec l’idée que dire « ils auraient dû le savoir » serait incohérent. On reproche constamment aux gens ce qu’ils ne savent pas, et ça fait partie de la vie adulte
  Si un enfant de 3 ans mangeait une limace, je ne lui en voudrais pas ; mais si un collègue de 30 ans mangeait une limace, je lui en voudrais évidemment. On peut blâmer quelqu’un pour un comportement absurdement stupide et évident

  • À l’idée qu’on ne pourrait pas blâmer quelqu’un pour « ne pas savoir quelque chose », il existe déjà le terme ignorance volontaire
    Je pense que cet article apporte un bon point auquel je n’avais pas pensé auparavant, mais pour moi il avait aussi quelques défauts nets, et c’est le premier
    Le second, c’est qu’en lisant des histoires sur des Américains, je me suis demandé : « mais est-ce vraiment la même chose que ce que je fais quand j’écarte d’un revers de main des incidents de suppression en production liés à l’IA, via ce distancing through differencing ? »
    Autrement dit, s’ils avaient simplement écarté l’idée qu’un risque puisse les atteindre sans rien savoir de la façon dont le danger est apparu dans une autre usine, ce ne serait pas justifié
    Mais si j’apprenais que la direction avait introduit sur le site de production un robot humanoïde nouveau, expérimental et non déterministe, autorisé à aider librement les ouvriers qualifiés à travailler plus vite, alors leur désinvolture ne se verrait pas sous le même jour
    J’accepte quand même la conclusion. Parce que l’imprudence n’est pas binaire
    La prochaine fois que j’entendrai une histoire absurde, je pense que je m’arrêterai un instant pour me demander : « même si je ne suis pas aussi négligent qu’eux, qu’est-ce que je fais, moi, qui mériterait davantage de prudence et quelques garde-fous ? »
  • Je ne demanderais pas pourquoi un enfant de 3 ans a mangé une limace
    Mais si un collègue de 30 ans avait mangé une limace, j’enquêterais à fond sur la chaîne d’événements qui l’y a conduit
    Si j’avais envie de lui en « vouloir », je commencerais d’abord par demander pourquoi nous avons embauché quelqu’un qui mange des limaces, et si c’est toujours le cas aujourd’hui
  • La principale conclusion que je tire de cet article, c’est que l’auteur ne sait pas ce qu’est un bozo bit

• Il y a quelques points valables
  Sur le passage « je veux expliquer pourquoi cette réaction est contre-productive. Et aussi nommer le terme technique de ce phénomène apparenté à l’activation du bozo bit. Cela s’appelle le distancing through differencing », cette réaction est productive tout en étant contre-productive
  Elle est productive parce que, dans un monde où il tombe déjà bien trop d’incidents pour qu’on puisse tous les absorber, ne pas avoir à évaluer chaque entrée est une optimisation énorme
  En même temps, elle est aussi contre-productive pour les raisons données dans l’article
  Le vrai savoir-faire, c’est de savoir quoi prendre au sérieux et à quoi prêter attention. Quand j’aurai acquis ce savoir-faire, je vous le ferai savoir

• Qu’y a-t-il à apprendre du fait que quelqu’un a donné à une IA un accès direct à la production ?

  • Si on interprète l’incident LLM avec une certaine générosité, on peut en tirer la leçon que l’accès à la production doit relever du contrôle d’accès, et que les opérations destructrices doivent nécessiter une approbation à deux personnes
    J’ai travaillé autrefois dans une entreprise alors en forte croissance, dont beaucoup de pratiques d’ingénierie ressemblaient davantage à celles d’une startup dans un garage qu’à celles d’un groupe multinational de 1 000 personnes
    À l’époque, trois choses étaient vraies. Premièrement, le déploiement d’un service se faisait en se plaçant avec cd dans le répertoire de checkout Git du portable, puis en exécutant <tool> deploy <service-name>, ce qui déployait exactement le commit Git actuellement checkouté
    Deuxièmement, la culture de confiance envers les collègues faisait que le contrôle d’accès du système de déploiement était minimal. Il y avait une liste de personnes autorisées à déployer, et si vous en faisiez partie, vous pouviez déployer n’importe quel service
    Troisièmement, le dépôt Git principal était volumineux et le Wi‑Fi du bureau saturé, donc un clone prenait du temps. Pour permettre aux nouvelles recrues de démarrer plus vite, l’image de provisionnement des portables incluait déjà un checkout Git du dépôt principal
    Puis un jour, un nouveau stagiaire est arrivé dans l’équipe base de données et, en suivant le tutoriel wiki Database Team 101, il a exécuté la commande recommandée pour vérifier que ses droits de déploiement fonctionnaient : <tool> deploy --prod <database>
    Il s’est avéré que l’image de provisionnement des portables n’était pas à jour, et que ce stagiaire n’avait pas encore suivi l’étape d’onboarding où l’on faisait git pull origin master
    L’histoire du « LLM qui a cassé la production » et celle du « stagiaire qui a cassé la production » se ressemblent, mais la seconde est plus facile à comprendre, parce que les erreurs individuelles y sont plus petites

• Vu sous l’angle de l’analyse d’incident, activer le bozo bit puis cesser d’apprendre revient à s’arrêter sur un seul facteur contributif, à savoir « erreur humaine ! », alors qu’il faudrait regarder tout l’arbre de défaillance
  Dans l’exemple donné, le nœud « on a donné l’accès à la production à la boucle LLM » dans l’arbre de défaillance déclenche chez le lecteur l’heuristique « les idiots, j’ignore »
  Mais le nœud frère « le système autorisait des suppressions non confirmées via l’API » est une leçon précieuse, que l’on peut manquer si l’on s’arrête au premier nœud qui saute aux yeux
  L’arbre de défaillance devrait aussi inclure des nœuds enfants examinant pourquoi cette opération dangereuse avait été retirée de l’interface graphique mais restait possible via l’API, et pourquoi le LLM avait obtenu l’accès à la production

  • D’un côté, on peut se demander s’il faut considérer comme moins probable la reconstitution d’un arbre de défaillance raisonnable à partir d’un rapport émanant d’un bozo
    D’un autre côté, la vraie question est peut-être de savoir si, dans des conditions bozo, il contient des nœuds qui brillent plus fortement
    Que ces nœuds soient mal identifiés ou mal reliés n’a peut-être pas tant d’importance. Après tout, ce dont j’ai besoin, ce n’est pas d’un arbre de défaillance pour leurs échecs passés, mais de vérifier ce que j’ai moi-même oublié dans l’arbre de défaillance afin d’éviter mes échecs futurs

• Cet article saute de façon assez flagrante l’explication de pourquoi activer le bozo bit pour le bozo de son exemple principal est une erreur
  Il passe à un cas d’étude académique et ne traite pas l’exemple central de son propre texte
  Cela donne l’impression que l’auteur essaie discrètement de laisser passer un autre bozo

• J’ai quand même appris quelque chose : ne pas utiliser d’outils d’IA