Le propre d'un bon polar ou d'une bonne histoire à rebondissements est de faire démarrer l'histoire dans une voie sans issue ou de présenter la situation d'une façon biaisée : ainsi, les postulats de base sont faux, on échafaude un raisonnement et/ou une compréhension dessus, et quand arrive l'éclairage qui nous manque, subitement, tout devient plus clair.
Pour prendre un exemple simple, on pense que Rogue est le méchant dans le premier tome d'Harry Potter (à l'école des Sorciers), car on le voit prononcer des formules magiques alors que Harry est en difficulté sur son balai. Il parait logique d'en déduire qu'il est la cause des soucis qui arrivent au jeune sorcier. Alors qu'à la fin du premier tome, on se rend compte qu'il essayait en fait de l'aider et que les soucis étaient causés par un autre.
Même si c'est un peu différent, on retrouve cette idée dans l'Allégorie de la caverne de Platon : l'homme ne voit que l'ombre projetée de la réalité et échafaude un raisonnement basé sur sur cette ombre et non sur la réalité.
En informatique et sur les sites Web, quand on parle de bugs, c'est souvent la même chose. Je m'explique.
Quand on me signale un bug non trivial, je prends ma casquette de Sherlock Holmes, et je ré-échafaude un raisonnement logique qui m'amène à comprendre comment ce problème est arrivé. Mon raisonnement est basé sur des postulats : si tel champ est rempli, alors il est à l'étape 4, si tel truc est renseigné dans la base, alors il s'est passé telle chose, etc.
Et souvent, le problème vient totalement d'ailleurs : en fait, on s'aperçoit qu'une entrée dans la base de données a été affichée dans l'administration du site alors qu'elle n'aurait pas dû l'être, du coup, on s'est retrouvé dans un cas considéré impossible, et évidemment, le système n'est pas prévu pour ! En résulte un e-mail vide, une entrée qui a fait déconner une autre partie, etc.
Et bien sûr, les informations que j'ai à ma disposition sont les ombres projetées de la réalité : cet e-mail vide, le problème généré ailleurs, etc. Donc, je vais essayer de comprendre comment c'est arrivé, et la plupart du temps, il est difficile de partir de la fin. Des fois, on va même patcher à tort une partie alors qu'une autre est en cause.
Et bien évidemment, personne ne va m'indiquer qu'en fait, une entrée a été validée à tort, ce qui a généré un souci ailleurs. Sinon, ce serait trop facile.
Donc, quand un informaticien vous dit : « je n'arrive pas à reproduire le bug », ou « cela ne devrait pas arriver », ce n'est pas par fainéantise ou je-m'en-foutisme, c'est qu'à partir des ombres que vous lui envoyez, il manque d'informations pour comprendre ce qu'il s'est passé. C'est pour cela qu'il est important de préciser l'environnement, comment on est arrivé là, le navigateur, etc.
Pensez-y la prochaine fois que vous soumettrez un bug !
Quand ça vient de non-informaticiens ça passe : on se dit qu'ils n'ont pas la compréhension suffisante de ce qu'est la correction de bugs et ne conçoivent donc pas forcément que dire juste "Quand je vais dans le module XYZ, ça marche pas !" n'est pas suffisant.
C'est plus difficile à prendre de manière détendue quand ce sont des gens qui travaillent dans le web depuis longtemps voire des développeurs qui font des remontées à peine plus détaillées...
Mais c'est vrai que j'avais pas pensé à prendre l’Allégorie de la caverne pour illustrer le problème ^^