Pourquoi les ingénieurs doivent étudier l’histoire des systèmes informatiques

Les ingénieurs rencontrent souvent le présent dans sa forme la plus comprimée : un framework, une API, un service cloud, une carte, un modèle, un protocole. Tout semble disponible immédiatement, comme si la technologie n’était qu’une succession de mises à jour. History of Computer Systems enseigne l’inverse. Le cours montre que l’informatique est cumulative, que les environnements techniques sont stratifiés et que chaque génération d’outils repose sur des décisions scientifiques, industrielles et politiques plus anciennes.

01 Pourquoi l’histoire a sa place dans une formation d’ingénieur

À DSTI, nous suivons une conviction ancienne de l’enseignement scientifique et de l’ingénierie : les humanités font partie de la formation technique. Un bon ingénieur ne se contente pas d’appliquer une méthode ; il sait la situer, reconnaître ses hypothèses et percevoir l’horizon historique dont elle provient. L’histoire ne dilue pas la formation technique — elle lui donne de la profondeur.

Cela vaut tout particulièrement en informatique, un domaine qui évolue vite mais se souvient plus qu’il ne l’admet. La surface à la mode change ; les structures profondes sont héritées — paradigmes de programmation, idées de systèmes d’exploitation, modèles de bases de données, architectures réseau et institutions qui les normalisent. Les sections qui suivent retracent concrètement quelques-uns de ces héritages, car l’enjeu n’est pas que l’histoire soit intéressante, mais qu’elle soit porteuse.

02 Une journée de travail est pleine des années 1970

Deux idées d’une seule décennie soutiennent encore l’essentiel de ce que touche un ingénieur logiciel. La première est UNIX. Commencé aux Bell Labs vers 1969 par Ken Thompson, puis réécrit dans le nouveau langage C de Dennis Ritchie au début des années 1970, il a posé quelques partis pris de conception d’une durabilité remarquable : un système de fichiers hiérarchique unique, le principe selon lequel presque tout — périphériques, processus, configuration — peut être traité comme un fichier, et de petits programmes composés au moyen de pipes plutôt qu’une seule grande application. Ces partis pris sont aujourd’hui partout. Linux en a hérité ; la lignée BSD fonctionne au cœur de macOS et d’iOS ; Android repose sur un noyau Linux ; et la plupart des serveurs cloud sont de type UNIX. Le standard POSIX existe précisément pour que cet héritage reste portable d’un fournisseur à l’autre.

La seconde est le modèle relationnel. En 1970, Edgar Codd, chez IBM, soutient que les données doivent s’exprimer sous forme de relations et s’interroger en décrivant ce que l’on veut plutôt qu’en parcourant la façon dont elles sont stockées. Les systèmes qu’il a supplantés — bases de données hiérarchiques comme l’IMS d’IBM, et bases de données en réseau — obligeaient l’application à suivre des chaînes de pointeurs à la main. Il a fallu des années et deux prototypes de recherche, System R d’IBM et Ingres de Berkeley, pour rendre l’idée de Codd opérationnelle ; SQL descend du premier. Elle a duré parce qu’elle a survécu à un changement de génération de matériel sans changer les questions qu’on lui pose.

03 Le mainframe n’a jamais disparu

Il est tentant de ranger les mainframes au rayon de l’histoire. Ils sont au contraire le lieu où plusieurs idées porteuses ont d’abord été élaborées. Le System/360 d’IBM, annoncé en 1964, a introduit quelque chose de plus important qu’aucune machine isolée : une famille d’ordinateurs partageant une même architecture — un même jeu d’instructions — indépendamment de la manière dont chaque modèle était construit en matériel. Cette séparation entre architecture et implémentation est le contrat que tout jeu d’instructions moderne honore encore, de x86 à Arm et RISC-V, et c’est pourquoi un logiciel peut survivre à la puce sur laquelle il a d’abord tourné.

La virtualisation, aujourd’hui substrat de l’informatique en nuage, n’a pas été inventée par le cloud ; IBM exécutait déjà des machines virtuelles complètes au début des années 1970. Les systèmes en temps partagé comme le CTSS du MIT et Multics, dans les années 1960, permettaient déjà à de nombreux utilisateurs de partager une même machine sous isolation et ordonnancement — l’ancêtre direct du cloud multilocataire. Et COBOL, normalisé en 1959, fait encore tourner une part importante des traitements bancaires, assurantiels et publics essentiels du monde. Qualifier ce code de « legacy » est exact ; le tenir pour inerte ne l’est pas. Une bonne part de ce qui est commercialisé comme « cloud-native » n’est que du temps partagé et de la virtualisation redécouverts, avec de meilleurs outils et un modèle de facturation.

04 Les réseaux sont des accords, pas seulement des câbles

Un protocole a l’apparence d’un artefact technique. Historiquement, il est aussi institutionnel, et les deux sont difficiles à séparer. La commutation de paquets — découper la communication en paquets routés indépendamment — a été proposée au début et au milieu des années 1960 par Paul Baran chez RAND, qui voulait un réseau capable de survivre à une destruction partielle, et indépendamment par Donald Davies au National Physical Laboratory britannique, qui a forgé le terme. ARPANET a transporté ses premiers paquets en 1969.

L’étape décisive intervient en 1974, lorsque Vinton Cerf et Robert Kahn spécifient le protocole qui deviendra TCP/IP, ainsi que dans le principe de bout en bout formulé par Saltzer, Reed et Clark en 1984 : garder le réseau simple et repousser l’intelligence vers les extrémités. Ce principe est un choix d’ingénierie aux conséquences politiques — il explique en partie pourquoi l’internet est resté ouvert à des applications que ses concepteurs n’avaient jamais imaginées. Il en va de même de la culture qui l’a normalisé : la devise de travail de l’IETF, « rough consensus and running code », et la série ouverte des RFC décrivent une manière particulière de décider qui peut définir un réseau interopérable. Déboguer une connexion, c’est travailler à l’intérieur de décisions de gouvernance autant que de paquets.

05 L’IA est un long débat, pas une arrivée soudaine

Aucun domaine n’est décrit de façon plus anhistorique que l’intelligence artificielle, et aucun n’en souffre davantage. Le nom remonte à l’atelier de Dartmouth de 1956, mais la conversation est plus ancienne — la Cybernétique de Norbert Wiener paraît en 1948, et les statistiques comme l’optimisation sont plus anciennes encore. Le schéma, depuis, est cyclique et non linéaire.

Le perceptron de Frank Rosenblatt (1958) a suscité un grand optimisme ; Perceptrons de Minsky et Papert (1969) en a explicité les limites et reste associé à l’effondrement des financements qu’on appelle aujourd’hui le premier « hiver de l’IA ». Les méthodes neuronales sont revenues lorsque la rétropropagation a été popularisée en 1986, ont de nouveau reflué avec l’effondrement des systèmes experts à la fin des années 1980, et ne se sont imposées que lorsqu’il a existé assez de puissance de calcul et de données étiquetées pour faire fonctionner les réseaux profonds — moment que l’on date généralement du résultat d’AlexNet sur ImageNet en 2012. Les systèmes d’aujourd’hui sont la dernière couche de cette suite d’espoirs, de déceptions et d’accumulation.

06 La technologie est aussi une histoire politique : le cas français

Parce que l’ingénierie n’est jamais séparée des institutions qui la financent et la normalisent, un même système peut prendre des formes très différentes selon les États. La France est un cas d’étude d’une clarté inhabituelle — l’une des raisons de sa place dans ce cours. Après les restrictions américaines à l’exportation et l’absorption de la firme française Bull par General Electric, la France lance le Plan Calcul en 1966 : un programme d’État destiné à bâtir une industrie informatique souveraine, qui donne naissance au constructeur CII et à l’institut de recherche devenu l’INRIA.

Deux décennies plus tard, le réseau Minitel installe, dès le début des années 1980, un terminal en ligne opérationnel dans des millions de foyers français — un annuaire, des services et un modèle de paiement, des années avant le web grand public. C’est un exemple d’école de stratégie nationale réellement réussie qui a créé sa propre forme ultérieure de verrouillage. Lus ensemble, ces épisodes enseignent ce qu’aucun schéma d’architecture ne peut transmettre : qui finance une technologie, qui la normalise et quelles structures industrielles et administratives l’entourent façonnent le résultat autant que l’ingénierie elle-même. Ce discernement compte directement lorsque les diplômés travaillent ensuite sur la gouvernance des données, la conception de plateformes, la cybersécurité ou le déploiement de l’IA.

07 Pourquoi ce cours figure dans le BSc

Le cours donne aux étudiants la carte ci-dessus et l’habitude de s’en servir : relier une architecture actuelle à la génération de systèmes qui la précède, comprendre pourquoi certains héritages survivent et certains standards perdurent, et lire une technologie nouvelle en se demandant quel problème elle a d’abord résolu et de quelle couche plus ancienne elle dépend encore. Il complète la programmation, les systèmes, les mathématiques et la pratique de l’ingénierie plutôt qu’il ne les concurrence — l’objectif est un ingénieur doté de mémoire technique autant que de savoir-faire technique, capable de reconnaître le battage sans devenir cynique à l’égard des évolutions réelles.

À DSTI, le cours est assuré par Pr Pierre Mounier-Kuhn, historien de l’informatique et chercheur (CNRS ; Centre Roland Mousnier, Sorbonne Université), dont les travaux sur l’émergence de l’informatique comme science, et sur le cas français en particulier, figurent dans les références ci-dessous.

08 Pour aller plus loin

Pour qui souhaite consulter les sources plutôt que se fier au résumé :

• Pierre-Éric Mounier-Kuhn, L’Informatique en France, de la seconde guerre mondiale au Plan Calcul. L’émergence d’une science (Presses de l’Université Paris-Sorbonne, 2010) — l’histoire institutionnelle de la constitution de l’informatique en discipline en France.
• Pierre-Éric Mounier-Kuhn, Mémoires vives. 50 ans d’informatique chez BNP Paribas (BNP Paribas, 2010) — cinquante ans d’informatique d’entreprise vus de l’intérieur d’une organisation.
• Martin Campbell-Kelly & William Aspray, Computer: A History of the Information Machine — l’ouvrage de référence en un seul volume.
• E. F. Codd, “A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM (1970) — l’article qui sous-tend toute base de données SQL.
• D. M. Ritchie & K. Thompson, “The UNIX Time-Sharing System”, Communications of the ACM (1974) — UNIX décrit par ses auteurs.
• V. G. Cerf & R. E. Kahn, “A Protocol for Packet Network Intercommunication”, IEEE Transactions on Communications (1974) — l’origine de TCP/IP.
• J. H. Saltzer, D. P. Reed & D. D. Clark, « End-to-End Arguments in System Design » (1984) — pourquoi l’internet garde l’intelligence à ses extrémités.

Note éditoriale. Ceci est une présentation éditoriale du cours du BSc « History of Computer Systems » et des raisons de sa place dans le cursus. Les résumés historiques sont écrits pour un public d’ingénierie généraliste et simplifiés en conséquence ; la rédaction éditoriale n’est pas attribuée au Pr Pierre Mounier-Kuhn. Les lectures suggérées sont indiquées pour qui souhaite consulter directement les sources.