« Lorsque nous utilisions des systèmes électromécaniques, nous pouvions les tester de manière exhaustive », regrette Nancy Leveson, spécialiste d’astronautique, d’aéronautique et de sécurité logicielle au MIT. Les systèmes logiciels sont différents parce qu’ils peuvent être changés à moindre coût, qu’ils sont sans cesse mis à jour et bien plus complexes. Pour Leveson, « le problème est que nous essayons de construire des systèmes qui dépassent notre capacité à les gérer intellectuellement ».
La recherche d’exhaustivité dans un système complexe est une bataille perdue d’avance contre des moulins à vent. Ce qu’il faut tenter d’améliorer ce n’est pas la réduction du nombre de bugs en amont mais la réactivité pour corriger ceux détectés lorsque le système est en place. Un logiciel (non-critique !) devrait être fait pour répondre à 80% des problématiques rencontrées. Si nous sommes si loin du compte aujourd’hui — en tout cas dans le Web (cache) — cela est dû au manque d’empathie des développeurs vis-à-vis de bénéficiaires qui ne peuvent exprimer leurs voix de façon pertinente à la fois par manque de compétences et de moyens de communication. Il est quasi-impossible de savoir quel est le ressenti d’une personne utilisant un outil informatique au sens large. Autant les frustrations que les joies seraient pourtant requises pour améliorer le système, mais comment réussir à faire une synthèse de ces ressentis ?
Ma solution actuelle est de tenter de réduire les boucles de rétro-actions permettant d’améliorer le système de manière progressive et éclairée ; une fois que la problématique a été elle-même simplifiée afin d’en réduire le périmètre. La complexité qui ne peut-être débuguée est un péché d’orgueil, pas forcément celui du développeur. Je ne pense pas qu’il faille réinventer la programmation en elle-même mais plutôt les conditions de son application et surtout de son évolution. Interviewer des utilisateurs en amont d’une conception ET une fois le système mis en production est malheureusement loin d’être une pratique courante.
Les languages et les modélisations afférentes ne sont que des grammaires sans vies, l’équipe et sa connaissance d’une problématique donnée sont les composantes qu’il faut soigner. En laissant le temps à la confiance de s’installer, condition indispensable à l’ouverture qu’est cet autre : l’utilisateur. Ce partenaire d’une symbiose dont on essaye de créer l’outil sans en mesurer les appétences ni les conséquences (cache).
Aujourd’hui encore, trop de développeurs regardent sur Stack Overflow, l’une des grandes plateformes de partage pour développeurs, les méthodes des autres, copient des bouts de code et de fonctions, les collent ensembles et les ajustent par itération. Ça fonctionne jusqu’à ce qu’on tombe sur un vrai problème !, souligne Newcombe.
Ibid.
Stack Overflow est l’équivalent de l’encyclopédie Wikipedia dont les entrées se font en langage naturel (par des questions) et il ne s’agit pas de copier bêtement des résultats mais d’analyser les différentes réponses pour se faire son propre avis sur une question complexe. Il ne s’agit pas uniquement d’assembler du code d’autrui mais de liens vers des documentations officielles mal indexées ou des parties de RFC (Request For Comment) pertinentes pour une problématique donnée. Je ne connais pas d’équivalent dans d’autres profession, aussi je conçois que cela soit difficile à appréhender. Le seul malheur de la plateforme est d’être détenue par des intérêts privés ce qui met notamment en question la pérennité d’un tel service. Je suis un développeur moyen qui utilise cet outil de manière quotidienne et je n’en éprouve aucune honte. Un grand merci à mes pairs qui viennent alimenter cette base de discussion continuellement mise à jour.
