On a tous prononcé son nom au moins une fois en renversant notre café sur un clavier neuf ou en voyant une démo planter exactement au moment où le client entrait dans la salle. Mais qui était vraiment Murphy ? Un philosophe du pessimisme ? Un poissard légendaire ?
J'ai eu l'opportunité (imaginaire) de m'asseoir avec le Capitaine Edward A. Murphy Jr., au bord d'une piste d'essai poussiéreuse de la base Edwards, pour rétablir la vérité sur sa célèbre loi. Et spoiler : il n'a jamais parlé de tartines beurrées.
Julien Canon : Capitaine Murphy, c'est un honneur. Vous savez que vous êtes probablement l'ingénieur le plus cité de l'histoire de l'informatique ?
Edward Murphy : (Il soupire en ajustant sa casquette de l'US Air Force) Laissez-moi deviner... Vous pensez que je suis le saint patron de la malchance ? Le gars qu'on invoque quand il pleut le jour du barbecue ?
JC : Eh bien... C'est un peu l'idée reçue, oui. "Tout ce qui peut mal tourner, tournera mal." C'est bien de vous, non ?
EM : C'est ce que l'histoire a retenu, mais c'est un raccourci terrible ! Je ne suis pas un fataliste, Julien. Je suis un ingénieur en aérospatiale. Ma "loi" n'était pas une prédiction de malheur, c'était un principe de conception. C'est très différent. Si vous concevez un système où l'erreur est physiquement possible, alors, tôt ou tard, quelqu'un commettra cette erreur. Ce n'est pas du pessimisme, c'est de la statistique.
JC : Remontons un peu en arrière. D'où vient cette phrase, si elle ne vient pas d'une tartine ?
EM : Nous sommes en 1949. Base aérienne d'Edwards, Californie. Je travaillais sur le projet MX981.
JC : Le projet avec le Colonel Stapp ? L'homme le plus rapide du monde ?
EM : Lui-même. John Paul Stapp. Un fou furieux et un héros. Notre mission était de tester la tolérance humaine à la décélération (les fameux "G"). On attachait Stapp sur un traîneau-fusée, le "Gee Whiz", on le propulsait à plus de 300 km/h, et on freinait brutalement pour voir si ses yeux sortaient de leurs orbites. Littéralement.
Mon rôle était de concevoir les capteurs (des jauges de contrainte) pour mesurer la force exacte encaissée par son corps. C'était de la haute précision.
JC : Et c'est là que l'incident s'est produit ?
EM : Exactement. Un jour de test critique, on lance le traîneau. Stapp encaisse une décélération monstrueuse. Il est secoué comme un prunier, le visage déformé, à la limite de l'évanouissement. On se précipite sur les relevés pour voir les données... et là : Zéro. Rien. Le graphique est plat.
JC : Les capteurs étaient cassés ?
EM : Pire. Ils étaient mal branchés. J'avais conçu le harnais avec 16 capteurs. Il n'y avait que deux façons de les brancher : la bonne et la mauvaise. L'assistant technique qui s'en est chargé a réussi l'exploit de brancher les 16 à l'envers. Statistiquement, c'était presque impossible de se tromper à ce point sans le faire exprès !
C'est là, sous le coup de la frustration, que j'ai lâché la phrase originale à propos de ce technicien : "S'il y a une façon de commettre une erreur, il le fera."
JC : Donc à l'origine, c'était une critique de votre collègue ?
EM : Disons une observation empirique sur la fiabilité humaine. Mais c'est Stapp, le Colonel, qui a transformé ça en légende. Lors d'une conférence de presse quelques jours plus tard, un journaliste lui a demandé comment il avait survécu à de tels tests sans blessure grave. Il a répondu : "C'est parce que nous prenons en compte la Loi de Murphy."
Il voulait dire que nous avions anticipé toutes les possibilités d'échec pour les contrer. Il a transformé ma colère en un principe de sécurité aérienne.
JC : C'est fascinant. Donc pour vous, la "Loi de Murphy" est en fait un outil de qualité ?
EM : Absolument ! C'est ce que vous, les gens du logiciel, appelez le "Defensive Design" ou le "Poka-Yoke" (détrompeur).
Si vous laissez à un utilisateur la possibilité de cliquer sur le mauvais bouton, il cliquera dessus. Si une API peut recevoir une date dans un format incorrect, elle la recevra. Ma loi ne dit pas "vous allez échouer". Elle dit : "Si une erreur est possible, elle est inévitable. Alors concevez votre système pour qu'elle soit impossible."
JC : C'est très proche de la philosophie DevOps ou du Chaos Engineering aujourd'hui. On part du principe que le système va faillir, donc on construit de la résilience.
EM : Exactement ! Si j'avais conçu ces capteurs avec une prise asymétrique qui ne pouvait s'insérer que dans un seul sens, le technicien n'aurait pas pu se tromper. C'était ma faute, pas la sienne. C'est ça, la vraie leçon de Murphy : ne blâmez pas l'utilisateur, blâmez le design.
JC : Une dernière question, Capitaine. Que pensez-vous de la réputation de votre loi aujourd'hui ?
EM : (Il sourit) Tant que cela pousse les ingénieurs à vérifier leurs backups, à écrire des tests unitaires et à ne jamais supposer que "ça va passer", alors je suis fier de mon héritage. Mais s'il vous plaît, arrêtez avec cette histoire de tartine. C'est juste de la physique et un centre de gravité mal placé, ça n'a rien à voir avec moi !
Ce qu'il faut retenir pour nos projets
La discussion avec "Murphy" nous rappelle trois piliers essentiels pour le développement logiciel moderne :
- L'erreur est humaine, la fiabilité est système : Ne comptez pas sur la vigilance humaine pour éviter les erreurs de prod. Automatisez les garde-fous.
- Loi de Murphy ≠ Fatalisme : Ce n'est pas parce que les choses vont mal tourner qu'il faut être pessimiste. Au contraire, c'est une invitation à être proactif.
- Design Défensif : Si une mauvaise configuration est possible, elle arrivera. Utilisez des types forts, des validateurs, et des infrastructures immutables pour réduire la surface d'erreur possible.
La prochaine fois que vous entendrez "C'est la loi de Murphy", ne levez pas les yeux au ciel. Vérifiez vos logs.
