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.

I. La provocation de 1968

La « crise du logiciel » de la fin des années soixante était réelle : les grands projets logiciels accusaient systématiquement des retards, dépassaient les budgets, étaient peu fiables et impossibles à maintenir. La conférence de l’OTAN a été convoquée précisément pour affronter cette panique. Le choix du mot « ingénierie » était stratégique—il importait la connotation de rigueur, de discipline, et de méthode systématique dans un domaine qui fonctionnait largement comme un artisanat, où les problèmes se résolvaient par intuition et effort héroïque individuel plutôt que par méthode reproductible.

Edsger Dijkstra, qui était à Garmisch, était sceptique face à la métaphore. Il pensait que le logiciel était plus proche des mathématiques que de l’ingénierie—que son fondement correct était le raisonnement formel, non l’analogie physique. Il avait probablement raison sur le fondement et probablement tort de penser que cela rendait inutile le cadre ingénierial. Les deux ne sont pas contradictoires: les mathématiques fournissent le fondement; l’ingénierie fournit la discipline d’application sous des contraintes du monde réel.

II. Le spectre des contraintes

Ce que l’ingénierie classique impose n’est pas simplement la rigueur—c’est la rigueur externe. L’ingénieur n’a pas le choix de savoir si le pont obéit à l’équation de charge. La contrainte vient de l’extérieur du système, imposée par la matière elle-même. Un poids tombera. Une poutre fléchira. Un matériau se corrodera. Le monde physique est un professeur impitoyable.

Ce que l’ingénierie logicielle doit imposer est la rigueur interne. Il n’existe pas de thermodynamique du code. Un programme peut allouer de la mémoire indéfiniment; un pont ne peut pas croître sans matériau. Un système logiciel peut atteindre un espace d’états astronomique sans violer une seule loi physique. La contrainte en logiciel n’est pas l’entropie physique mais la complexité logique—et la complexité logique ne s’annonce pas avant de s’être accumulée dans un système que personne ne peut modifier sans crainte.

C’est le « permissivisme » que remarquent les ingénieurs formés lorsqu’ils entrent dans le logiciel. Ce n’est pas que le logiciel n’ait pas de contraintes. C’est que les contraintes ne s’appliquent pas automatiquement. Vous devez les construire vous-même, dans les tests, les systèmes de types, les contrats, les processus de révision, la documentation, la structure de l’équipe. En électronique, la contrainte est intégrée dans le matériau. En logiciel, elle doit être gravée dans la culture. Le travail est le même; le médium ne vous aide pas comme il aide un ingénieur structurel en refusant simplement de coopérer avec les mauvais designs.

Fred Brooks a appelé cela la différence entre l’essence et l’accident dans The Mythical Man-Month. L’essence du logiciel est la complexité conceptuelle—l’espace du problème lui-même. Les accidents sont les outils, langages, et plateformes que nous utilisons pour exprimer cette complexité. Vous pouvez rendre les accidents plus faciles, mais vous ne pouvez pas éliminer la difficulté essentielle. Et dans un médium où la matière est complètement permissive, où tout ce que vous tapez est syntaxiquement valide jusqu’à ce que vous essayiez de l’exécuter, vous devez imposer la discipline que d’autres médiums imposent gratuitement.

III. Où l’ingénierie systémique s’insère

Ludwig von Bertalanffy, dans General System Theory, a avancé une affirmation qui semblait alors presque triviale : que les mêmes principes organisationnels apparaissent dans les systèmes physiques, biologiques et informationnels. Une cellule et une corporation et une carte de circuit sont tous, à un certain niveau de description, des systèmes de composants en interaction dont le comportement émergent ne peut pas se déduire des composants seuls. Un système est plus que la somme de ses parties parce que les parties interagissent.

L’ingénierie systémique, comme discipline, prend cela au sérieux. Son objet d’étude n’est pas les composants mais les interfaces—les contrats entre sous-systèmes, les propriétés émergentes qui surgissent de l’interaction, les modes de défaillance qui vivent dans les écarts entre les parties. Les ingénieurs systémiques se posent la question : que se passe-t-il lorsque le composant A fait ce qu’il est censé faire et le composant B fait ce qu’il est censé faire et les deux le font en même temps?

Un ingénieur en électronique comprend les composants. Un ingénieur logiciel comprend la logique. Un ingénieur systémique comprend ce qui se passe quand ils se rencontrent. Ce n’est pas une hiérarchie de sophistication; c’est une question de position d’où vous observez le problème. L’expérience en électronique n’est pas une honte pour une carrière en logiciel. C’est une voie inhabituelle et directe vers la compréhension de pourquoi l’interface logiciel-matériel est l’endroit où vivent les problèmes intéressants—l’avionique, les dispositifs médicaux, la commande industrielle, les systèmes embarqués, tout le monde où une erreur de logique en code produit une conséquence physique.

Nancy Leveson dans Engineering a Safer World démontre comment la pensée systémique s’applique au logiciel critique pour la sécurité. Sa méthodologie STAMP force les ingénieurs à considérer non seulement les composants individuels mais les interactions entre eux, l’information qui circule, les boucles de rétroaction, les moments où l’intention diverge de l’exécution. C’est ce que l’ingénierie ressemble quand les enjeux sont physiques.

IV. Ce que l’ingénierie « réelle » exige

L’anxiété quant à savoir si le logiciel « compte » comme ingénierie porte partiellement sur la rigueur et partiellement sur les enjeux. L’ingénierie civile dispose d’un corpus légal, d’exigences de certification, de responsabilité professionnelle. Quand un pont s’effondre, il y a une enquête physique, une analyse médico-légale, une débâcle qui met fin à des carrières. Quand le logiciel échoue, le correctif se déploie le mardi.

Le monde critique pour la sécurité impose la rigueur que le logiciel général n’impose pas : DO-178C pour les logiciels d’avionique, IEC 62443 pour la commande industrielle, ISO 26262 pour l’automobile. Ces normes sont aussi exigeantes que n’importe quoi en ingénierie classique, précisément parce que le logiciel embarqué contrôle des systèmes physiques et les conséquences d’une défaillance sont physiques. Vous ne pouvez pas déployer un correctif sur un avion en vol. Vous ne pouvez pas faire un push de correctif d’urgence sur une centrale électrique. La discipline existe; elle n’est simplement pas universelle.

V. La résolution d’identité

Le passage de l’électronique au logiciel n’est pas un changement de discipline. C’est un mouvement le long d’un axe d’abstraction tout en conservant la même préoccupation sous-jacente : concevoir des systèmes qui ne s’effondrent pas sous leur propre complexité. L’ingénieur qui abandonne la loi d’Ohm n’abandonne pas l’ingénierie. Il apprend à imposer la discipline dans un domaine où la matière refuse de le faire.

Ce qui change est ce que « s’effondrer » signifie. En électronique, cela signifie que le circuit échoue à transporter le courant comme prévu. En logiciel, cela signifie que l’espace d’états devient innavigable, que la base de code devient intraitable. En ingénierie systémique, cela signifie que le comportement émergent du tout diverge du comportement voulu parce que personne n’a correctement modélisé les interactions.

L’ingénieur qui a travaillé dans les trois registres—physique, logique, systémique—n’a pas abandonné la rigueur en passant des lois de la nature aux lois de sa propre création. Il a appris à vivre dans un domaine où il n’existe pas de matière pour objecter, où chaque contrainte est auto-imposée, où le coût de se tromper se compose lentement jusqu’à ce que soudainement la structure entière soit trop emmêlée pour être démêlée. C’est plus difficile, non plus facile. Le malaise est approprié.

Dans Airplane! (1980), Johnny se tient dans la tour de contrôle lors d’un atterrissage de nuit désespéré—la météo se ferme, le pilote lutte, la piste est sombre. Il se penche et débranch le câble qui contrôle les lumières de la piste. Le blackout est complet. Tout le monde panique. Et puis il le branche à nouveau, sourit à la caméra, et dit : « Je plaisantais ! » La blague fonctionne parce que la contrainte est si fragile, si dépendante de la décision d’une personne de ne pas débrancher le câble. Dans Watchmen (2009), le Comédien réalise la vérité plus profonde : « C’est une blague. C’est un gag. » Son personnage décide que dans un monde où les règles sont créées et peuvent être cassées à tout moment, la seule réponse sensée est de devenir une parodie de la société elle-même. Les deux moments révèlent le même vertige : des systèmes construits sur le permissivisme, maintenus ensemble par rien d’autre que l’accord collectif de ne pas débrancher le câble. Le malaise de l’ingénieur est la réponse correcte à cette connaissance. Le monde matériel impose ses propres règles. Nous ne le faisons pas.

Lectures complémentaires