Logiciel

Le mot « ingénierie » a été appliqué au logiciel délibérément, non de façon descriptive. En 1968, lors d’une conférence de l’OTAN à Garmisch en Allemagne, des informaticiens ont choisi la phrase « ingénierie logicielle » comme une provocation—une exigence aspirationnelle que la discipline s’impose elle-même la rigueur que la physique impose à l’ingénierie civile et mécanique. Le mot n’était pas une reconnaissance; c’était un défi. Cinquante ans plus tard, le défi reste non résolu. Et le malaise que ressentent les ingénieurs formés lorsqu’ils entrent dans le logiciel—cette sensation que le terrain est d’une certaine manière moins solide, que les règles sont plus négociables, que les enjeux sont plus difficiles à calibrer—n’est pas un manque d’imagination. C’est la perception correcte de quelque chose de véritablement différent. …

En 1990, à l’Universidad de Antioquia à Medellín, il y avait une revue IEEE dans la bibliothèque dont les pages n’avaient jamais été coupées. Ce n’était pas une métaphore. Avant l’ère du livre de poche et du tout-numérique, certaines publications arrivaient pliées, les cahiers intacts, et il fallait passer un couteau ou un doigt le long du bord pour ouvrir chaque section. Si les pages étaient encore scellées, cela voulait dire que personne ne l’avait lue. Quelqu’un l’avait reçue, rangée, et oubliée. L’information qu’elle contenait était techniquement disponible et pratiquement inaccessible — un savoir en suspension, attendant que quelqu’un s’y intéresse. …

Le tour ne dit pas au mécanicien où placer l’arbre. L’oscilloscope ne dit pas à l’ingénieur électricien par où acheminer le signal. La grue ne dit pas à l’ingénieur civil où mettre les murs. Toute discipline d’ingénierie mature l’a compris tôt et n’y est jamais revenue : le problème physique pilote la conception. Les outils sont des moyens, pas des fins. Le logiciel a été l’exception — et pendant un temps remarquablement long. …

I. Le triomphe de l’objet Descartes avait posé la règle dans le Discours de la méthode : pour résoudre un problème difficile, décompose-le en ses parties les plus simples, analyse chaque partie séparément, puis remonte vers le complexe. C’est l’instinct analytique de l’Occident — et c’est, à sa manière, la préhistoire de la programmation orientée objet. Le nom de Grady Booch sert à fixer quelque chose qui s’est produit dans les années 1980 et 1990 : le triomphe de l’objet. Avant cela, le logiciel était processus — verbes COBOL, sous-routines Fortran, fonctions C. Tu décrivais ce que le système fait, non ce qu’il est. Les programmes avaient des flux, des instructions, des verbes. …