L'écart entre logiciel et logique

Michel Volle
 

   J'ai longtemps cru que le logiciel était logique, car il appartient au monde de la pensée alors que la matière dont sont faits les processeurs, mémoires et réseaux est soumise aux aléas du monde de la nature (transformation de la structure cristalline, effets du rayonnement cosmique, etc.).

   Mais les logiciels qu'une DSI achète à des fournisseurs (systèmes d'exploitation, « progiciels », ERP, CRM, etc.) sont-ils vraiment des êtres logiques ?

   La plupart sont un assemblage de composants « boîte noire » dont on ne connaît que les interfaces d'entrée et de sortie (les « API ») et que l'on aura collés ensemble avec une « glu » de code.

Nota Bene : Cette description est encore trop optimiste. Si les diverses parties du logiciel étaient des boîtes noires elles seraient isolées les unes des autres et on pourrait, en procédant à des tests, explorer leur comportement. En fait le code est au moins en partie accessible et il peut donc se trouver modifié par quelqu'un qui le comprend mal. Le logiciel est alors une sauce aux ingrédients mal identifiés et qui présente des interactions surprenantes.

   Un exemple fameux est celui de la faille SSL de Linux : un intervenant a supprimé un passage dont il ne comprenait pas l'utilité et cela a réduit de façon catastrophique l'entropie cryptographique. Il a fallu dix-huit mois pour que cette bogue soit découverte.

   Si le logiciel est un produit de la pensée, il s'agit d'une pensée en cascade dont la compréhension ne se transmet pas d'un étage à l'autre : cela le rend aussi complexe qu'un être naturel ou matériel.

   Le fournisseur teste le produit ainsi fabriqué pour s'assurer qu'il répond convenablement à quelques situations type, fait rédiger une documentation à l'intention des utilisateurs, organise des formations, puis commercialise l'ensemble que forment le logiciel, la documentation et la formation.

   Les exigences de la vraie vie étant plus complexes qu'une liste de situations type, les DSI qui ont acheté le logiciel découvrent qu'il ne fonctionne pas bien alors même que l'on suit la documentation à la lettre.

   Pour limiter la casse le fournisseur ouvre un forum qui accueille les questions des utilisateurs. Il y publie des réponses qui sont autant de rustines qu'il faudra ajouter au logiciel et dont certaines plongent dans les couches profondes du compilateur, du système d'exploitation, voire du matériel. Progressivement ce forum contiendra la réponse à la plupart des bogues qui se rencontrent en pratique (mais non à toutes celles que l'on peut rencontrer).

   Les rustines efficaces pour une version du logiciel ne le seront cependant pas pour les suivantes et il faudra recommencer : des questions seront de nouveau posées sur le forum, les réponses seront autant de nouvelles rustines.

   Une DSI renouvelle son matériel tous les cinq ans environ : une machine qui a huit ans d'âge n'est plus suivie par le constructeur, il a fermé les services de maintenance et de support. Lors d'un changement de machine, nombre des rustines ajoutées aux logiciels sont alors inopérantes, il faut les remplacer par d'autres.

   Les informaticiens s'épuisent ainsi, sous la pression des utilisateurs, à faire fonctionner des machines qui deviennent instables, des logiciels bogués, en utilisant des rustines dont la nature échappe à leur entendement. Leur métier qui, vu de loin, semble relever de la logique pure, est ainsi soumis à une démarche empirique.

   Une DSI peut limiter les dégâts en se dotant d'une infrastructure aussi stable que possible et en sélectionnant les logiciels selon la qualité et le sérieux des fournisseurs. Mais cela demande un investissement dont une direction générale ne voit pas toujours l'utilité.

*
*    *

   Si l'informatique du chercheur est une science, celle de l'ingénieur est un art comme la médecine du médecin généraliste.

   Pour exercer cet art il faut un solide apprentissage des bases scientifiques, mais l'expérience est irremplaçable. C'est pourquoi un DSI doit savoir trouver les bons ingénieurs, savoir les faire travailler ensemble, savoir leur donner envie de rester. S'il n'y parvient pas tout le reste est voué à l'échec.

   Voici le témoignage de l'ancien DSI d'une université :

   « Le logiciel de gestion de la scolarité (inscriptions des étudiants, nomenclature des unités d'enseignement, délivrance des diplômes) était une usine à gaz qui tenait à coup de rustines. Il ne pouvait pas en être autrement : le problème est intrinsèquement complexe, à quoi s'ajoutent les fantaisies réglementaires changeantes du ministère sans parler de celles du législateur. Inutile d'espérer un logiciel stable, c'est impossible.

   J'ai réussi à recruter une des trois ou quatre personnes en France qui connaissaient ce logiciel sur le bout des doigts, ça a marché.

   Après mon départ l'université a voulu augmenter la productivité et réduire les coûts : certains éléments clé, dont cette personne, sont partis sous des cieux plus agréables et depuis ça cafouille. Toute institution aura le système d'information qu'elle mérite. »

Michel Volle

Paru le 19 juillet sur le site de Michel Volle :
http://michelvolle.blogspot.fr/2016/07/lecart-entre-logiciel-et-logique.html

Cet article est sous licence Creative Commons (selon la juridiction française = Paternité - Pas de Modification). http://creativecommons.org/licenses/by-nd/2.0/fr/