Histoire des systèmes d’exploitation : des débuts au cloud

Des premiers moniteurs d’exécution aux systèmes mobiles et au cloud, l’histoire des systèmes d’exploitation raconte une même recherche : partager les ressources d’une machine sans perdre le contrôle des programmes, des données et des utilisateurs.

Un système d’exploitation attribue du temps de calcul aux programmes, distribue la mémoire, contrôle les périphériques, organise les fichiers et sépare les utilisateurs. Il fournit aussi aux applications des services communs. Sans lui, chaque programme devrait connaître intimement le processeur, le disque, l’écran, le clavier et les autres composants de la machine.

Cette définition paraît naturelle aujourd’hui, car le système d’exploitation est devenu presque invisible. Pourtant, les premiers ordinateurs n’en avaient pas. L’histoire des OS est celle d’une couche d’abstraction progressivement construite entre l’être humain, les programmes et le matériel.

Chaque génération tente de résoudre de nouveaux problèmes. Il faut d’abord éviter que la machine reste inactive, puis permettre à plusieurs utilisateurs de la partager. Viennent ensuite la protection des données, la portabilité des programmes et l’informatique personnelle. Aujourd’hui, les systèmes doivent aussi coordonner des milliards d’appareils et d’immenses centres de données.

Ce récit n’est donc pas une simple chronologie de produits. Il suit plusieurs tensions qui traversent toute l’histoire de l’informatique : efficacité contre simplicité, innovation contre compatibilité, ouverture contre contrôle, performance contre isolation. CTSS, Multics, Unix, DOS, Windows, Linux, macOS ou Android apportent des réponses différentes à ces mêmes problèmes.

Quand l’ordinateur n’avait pas encore de système d’exploitation

Le traitement par lots pour ne plus gaspiller la machine

Dans les années 1940 et au début des années 1950, utiliser un ordinateur signifie souvent réserver physiquement la machine. Le programmeur prépare des cartes perforées ou un ruban perforé, charge le programme, configure le calcul puis lance l’exécution.

Pendant les manipulations ou les corrections, un équipement extrêmement rare et coûteux peut rester inutilisé. Lorsque le nombre d’utilisateurs augmente, cette situation devient difficilement acceptable.

Le premier problème auquel répond le futur système d’exploitation n’est donc pas celui d’une interface agréable. Il faut d’abord empêcher le gaspillage du temps de calcul. Le traitement par lots, ou batch processing, apporte une première réponse en regroupant plusieurs travaux exécutés successivement.

Les premiers moniteurs, ancêtres des systèmes d’exploitation, automatisent progressivement cet enchaînement. Le mot ne désigne pas ici un écran, mais un petit programme de contrôle chargé de superviser les tâches.

Au lieu de charger manuellement chaque programme, l’opérateur prépare une série de travaux. Le moniteur lance le premier, détecte sa fin, récupère éventuellement son résultat, puis passe automatiquement au suivant.

Le système GM-NAA I/O, développé au milieu des années 1950 pour l’IBM 704 par General Motors et North American Aviation, figure parmi les réalisations pionnières. Les cartes de contrôle décrivant les travaux annoncent déjà les futurs langages de commande.

Le rendement de la machine s’améliore, mais celui du programmeur pas nécessairement. Une simple erreur peut n’être découverte qu’après une longue attente. L’ordinateur travaille davantage, mais l’utilisateur ne dialogue toujours pas avec lui.

CTSS : du calcul différé au dialogue avec la machine

Le principe du temps partagé

Le traitement par lots améliore l’utilisation de l’ordinateur, mais il ne résout pas un autre problème : le programmeur doit toujours attendre avant de voir le résultat de son travail. Au début des années 1960, plusieurs chercheurs explorent donc une nouvelle voie : permettre à plusieurs personnes d’utiliser directement le même ordinateur.

Le time-sharing, ou temps partagé, repose sur un constat simple. Le processeur exécute ses instructions bien plus vite que l’être humain ne peut lui répondre. Pendant qu’un utilisateur lit un résultat, réfléchit ou tape une commande, la machine peut travailler pour quelqu’un d’autre.

Au MIT, cette idée conduit notamment au développement de CTSS, le Compatible Time-Sharing System. Un IBM 7090 peut ainsi être relié à plusieurs terminaux installés dans différents laboratoires.

Pendant qu’une personne prépare sa prochaine commande, l’ordinateur traite le problème d’une autre. Le processeur attribue de très courtes tranches de temps à chaque utilisateur.

Sur une machine à processeur unique, les programmes ne fonctionnent donc pas réellement tous au même instant. Mais l’alternance est suffisamment rapide pour donner l’impression à chaque utilisateur de disposer directement de l’ordinateur.

Une nouvelle manière de programmer

Le changement dépasse largement la performance. Avec un terminal interactif, le programmeur peut saisir une commande, observer la réponse, modifier son programme et recommencer.

La programmation devient exploratoire. La boucle écrire → exécuter → observer → corriger, aujourd’hui banale, remplace progressivement les longues attentes du traitement par lots.

Mais le partage de la machine crée aussi de nouvelles responsabilités. Le système doit identifier les utilisateurs, conserver leurs fichiers et répartir équitablement les ressources. Il doit également empêcher un programme d’endommager le travail des autres.

Dès qu’une communauté entière utilise le même ordinateur, l’OS ne doit plus seulement lancer les travaux : il doit aussi organiser et protéger un espace commun.

CTSS démontre que cette organisation est possible. Il montre également qu’un environnement informatique peut devenir difficile à abandonner lorsque des applications, des données et des habitudes se construisent autour de lui. Cette dépendance aux logiciels deviendra une question centrale de toute l’histoire des systèmes d’exploitation.

Les années 1960 : le système d’exploitation change d’échelle

CTSS montre qu’un ordinateur peut être partagé de manière interactive. Mais au même moment, l’industrie rencontre un autre problème : changer de machine impose souvent de modifier, voire de réécrire, une partie importante des logiciels.

Deux transformations vont alors progresser en parallèle. IBM cherche à construire une famille de machines compatibles. De leur côté, le MIT, General Electric et les Bell Labs veulent pousser beaucoup plus loin l’idée d’un ordinateur partagé entre de nombreux utilisateurs.

Ces deux directions donneront notamment System/360 et OS/360 d’un côté, et Multics de l’autre.

System/360 et OS/360 : l’informatique devient une plateforme industrielle

Au début des années 1960, chaque modèle d’ordinateur possède encore souvent son propre environnement logiciel. Changer de machine peut imposer d’adapter les programmes, voire d’en abandonner certains.

Or les entreprises commencent à prendre conscience d’un phénomène nouveau : le logiciel représente désormais un investissement considérable. Développer et fiabiliser une application demande du temps, des équipes et de nombreux essais.

Remplacer une machine ne signifie donc plus seulement acheter du nouveau matériel. Cela peut aussi remettre en cause plusieurs années de développement logiciel.

Présentée en 1964, la famille IBM System/360 cherche à rompre avec cette fragmentation. Plusieurs machines de puissances différentes partagent une architecture compatible.

Une organisation peut ainsi évoluer vers un modèle supérieur tout en conservant une grande partie de ses programmes et de ses données. La compatibilité protège désormais autant l’investissement logiciel que l’investissement matériel.

OS/360 : lorsque le logiciel devient un projet industriel

Une architecture commune ne suffit cependant pas. Il faut aussi fournir aux programmes un environnement cohérent capable de gérer les ressources, les périphériques, les fichiers et l’exécution des travaux.

IBM développe plusieurs systèmes pour la gamme System/360, dont OS/360 pour les configurations les plus importantes.

Le projet prend une ampleur considérable pour l’époque. Il mobilise de nombreux programmeurs, accumule les difficultés et montre à quel point le logiciel est devenu complexe, long et coûteux à mettre au point.

OS/360 n’est pas le premier système d’exploitation. En revanche, son développement montre un changement d’échelle. L’OS devient un projet industriel majeur et un élément stratégique de la plateforme informatique.

IBM cherche surtout à résoudre un problème de compatibilité et de continuité. Pendant ce temps, un autre projet pousse beaucoup plus loin les idées expérimentées avec CTSS : Multics veut transformer l’ordinateur partagé en véritable service informatique.

Multics : penser l’informatique comme un service

Une architecture pensée pour le partage

Après l’expérience de CTSS, le MIT, General Electric et les Bell Labs entreprennent un projet beaucoup plus ambitieux.

Multics signifie Multiplexed Information and Computing Service. Le nom résume son objectif : fournir la puissance informatique comme un service général, continuellement disponible et accessible à de nombreux utilisateurs.

Le système développe ou généralise plusieurs idées importantes : authentification, mémoire virtuelle, segmentation, partage contrôlé de l’information, liaison dynamique, flux d’entrée-sortie et protection des sous-systèmes.

Beaucoup de ces notions appartiennent toujours au vocabulaire des systèmes contemporains.

La mémoire virtuelle dissocie l’espace logique utilisé par un programme de la mémoire physique réellement installée. La segmentation organise cet espace en unités ayant une signification : code, données ou objets partagés.

Le système peut alors décider quelles parties doivent être présentes en mémoire et contrôler leurs droits d’accès.

Un système de fichiers hiérarchique

Multics développe également un système de fichiers organisé en répertoires et en chemins. Les informations ne sont plus pensées comme de simples blocs placés sur un périphérique.

Elles appartiennent à un espace structuré dans lequel les utilisateurs peuvent partager certaines ressources tout en protégeant les autres.

Protection, privilèges et complexité

Les anneaux de protection répartissent le logiciel entre plusieurs niveaux de privilèges. Plus un composant se trouve près du cœur du système, plus ses droits sont importants.

L’objectif consiste à limiter les conséquences d’une erreur ou d’une attaque en évitant que tous les programmes disposent du même pouvoir sur la machine.

Multics ne doit cependant pas être transformé rétrospectivement en ancêtre parfait. Sa sophistication demande beaucoup de ressources et son développement reste complexe. Ses partenaires ne partagent pas toujours les mêmes objectifs.

En 1969, les Bell Labs quittent finalement le projet. Pour plusieurs chercheurs, dont Ken Thompson et Dennis Ritchie, ce retrait ouvre une autre voie.

Plutôt que de reproduire toute la richesse de Multics, ils vont chercher une architecture plus compacte et plus cohérente.

Unix : chercher la puissance dans la simplicité

Des outils simples que l’on peut combiner

Unix naît à partir de 1969 dans un contexte presque opposé à celui de Multics. Une petite équipe, des moyens plus modestes et la volonté de construire un système cohérent remplacent le vaste projet institutionnel précédent.

Unix reprend pourtant plusieurs idées du monde du temps partagé : environnement multi-utilisateur, fichiers organisés hiérarchiquement, interpréteur de commandes et séparation entre applications et ressources du système.

Son approche privilégie cependant des mécanismes plus petits et plus faciles à assembler.

De nombreux programmes Unix accomplissent une tâche limitée. Leur puissance vient de leur composition. Une commande peut sélectionner des données, une autre les trier et une troisième les compter.

L’utilisateur combine ainsi des outils génériques au lieu d’utiliser une application monolithique différente pour chaque problème.

Unix étend aussi l’abstraction du fichier. Documents, terminaux et plusieurs périphériques peuvent être manipulés au travers d’interfaces similaires. Cette uniformité réduit le nombre de concepts que le programmeur doit apprendre.

Le langage C rend Unix portable

Le tournant majeur vient du langage C. Unix n’est pas le premier système écrit dans un langage de haut niveau, mais son association avec C rend beaucoup plus réaliste son adaptation à différentes machines.

Le BCPL influence le langage B de Ken Thompson, qui sert ensuite de point de départ au C de Dennis Ritchie.

Lorsque le noyau Unix est réécrit en C au début des années 1970, le logiciel et le langage se renforcent mutuellement. Unix donne au C une application particulièrement exigeante, tandis que C libère progressivement Unix d’une architecture matérielle unique.

Unix devient une famille

La diffusion d’Unix dans les universités entraîne rapidement sa diversification. Berkeley développe BSD et une pile réseau promise à une grande influence. AT&T poursuit de son côté la lignée System V.

SunOS puis Solaris, AIX, HP-UX et plusieurs systèmes BSD prolongent ensuite différentes branches de cet héritage.

Le mot « Unix » finit ainsi par désigner plusieurs réalités. Il peut s’agir du système historique des Bell Labs, des familles qui en descendent, d’une manière de concevoir les logiciels ou d’un ensemble d’interfaces normalisées.

CP/M et DOS : l’OS entre dans le micro-ordinateur

CP/M crée une plateforme commune

Pendant que les systèmes Unix se développent sur des mini-ordinateurs et des machines professionnelles, le microprocesseur rend possible une autre révolution.

Avec des puces comme l’Intel 8080 puis le Zilog Z80, un ordinateur peut désormais tenir sur quelques cartes électroniques et coûter beaucoup moins cher qu’un système central.

Les premiers micro-ordinateurs disposent de très peu de mémoire et de stockage. Ils ont néanmoins besoin d’un environnement logiciel commun.

Gary Kildall développe alors CP/M, notamment pour rendre l’utilisation des disquettes beaucoup plus pratique que celle des bandes de papier.

La réussite de CP/M tient notamment à la séparation entre les fonctions générales du système et une couche adaptée au matériel. Cette organisation facilite son installation sur différentes machines.

Les constructeurs disposent ainsi d’un environnement commun tandis que les éditeurs peuvent viser un marché plus vaste.

MS-DOS et la force de la compatibilité

Lorsque IBM prépare son Personal Computer, Microsoft obtient les droits d’un système appelé 86-DOS, conçu par Tim Paterson, puis l’adapte à la nouvelle machine.

IBM le distribue sous le nom PC DOS tandis que Microsoft peut le proposer à d’autres fabricants sous le nom MS-DOS.

Cette stratégie, replacée dans le parcours de Bill Gates et de Microsoft, devient décisive lorsque les compatibles IBM PC se multiplient.

DOS reste techniquement modeste. Il protège peu les programmes entre eux, n’est pas réellement multi-utilisateur et conserve les contraintes des premiers processeurs x86.

Pourtant, la diffusion du PC transforme cette modestie en avantage économique. Les développeurs veulent toucher la plateforme la plus utilisée et les utilisateurs veulent conserver leurs logiciels.

La compatibilité devient dès lors l’une des forces les plus importantes de l’histoire des systèmes d’exploitation.

Macintosh, Amiga et Windows : l’interface devient centrale

Le Macintosh popularise l’interface graphique

Une autre transformation concerne la relation entre l’utilisateur et le système. En 1984, le Macintosh contribue à populariser auprès du grand public un environnement graphique cohérent.

Fenêtres, icônes, menus et souris deviennent les éléments visibles de l’interaction avec l’ordinateur.

L’ordinateur personnel ne doit plus seulement être programmable : il doit devenir directement manipulable.

Il faut cependant distinguer cette histoire de celle du macOS actuel. Le Mac OS classique, jusqu’à Mac OS 9, n’est pas un Unix. Ses premières versions sont conçues pour des machines disposant de ressources très limitées et ne possèdent pas les fondations Mach/BSD qui apparaîtront plus tard avec Mac OS X.

L’Amiga et le multitâche

L’Amiga explore parallèlement d’autres priorités. AmigaOS associe un environnement multitâche à un matériel spécialisé dans l’image et le son.

Sa trajectoire rappelle cependant une constante de l’histoire informatique : la qualité technique d’un système ne garantit pas à elle seule son succès. Prix, distribution, applications et stratégie industrielle comptent tout autant.

Windows impose l’interface graphique sur le PC

Sur le PC, Windows transforme progressivement l’environnement DOS en plateforme graphique dominante. Windows 3.x puis Windows 95 rendent l’interface graphique familière à des millions d’utilisateurs.

Microsoft doit cependant continuer à faire fonctionner une grande quantité de logiciels plus anciens. Cette contrainte de compatibilité va profondément influencer l’évolution de Windows.

OS/2 et Windows NT : comment moderniser sans tout casser ?

OS/2 tente de sortir du monde DOS

À mesure que les processeurs x86 progressent, les limitations héritées de DOS deviennent plus difficiles à accepter. Les nouveaux modes protégés permettent notamment de mieux isoler la mémoire et d’exploiter davantage de ressources.

Le problème est que des millions d’utilisateurs disposent déjà de logiciels conçus pour l’ancien environnement.

OS/2, développé initialement par IBM et Microsoft, tente d’organiser cette transition. Il introduit notamment multitâche, processus, fils d’exécution et communications entre programmes.

Le système exploite aussi le mode protégé tout en conservant la possibilité d’exécuter certaines applications DOS.

Cette tentative illustre un dilemme durable : la compatibilité facilite l’adoption, mais elle transporte dans le nouveau système une partie des contraintes de l’ancien.

Windows NT repart sur de nouvelles bases

Microsoft développe parallèlement une architecture destinée à ne plus dépendre de DOS : Windows NT.

Sous la direction de Dave Cutler, ancien architecte de VMS chez Digital Equipment Corporation, NT est conçu comme un système portable et protégé. Il doit pouvoir servir aussi bien de station de travail que de serveur.

Le système sépare notamment le mode utilisateur du mode noyau. Une application ordinaire dispose d’un espace d’adressage virtuel protégé. Elle ne peut donc pas modifier librement la mémoire du système ou celle d’un autre programme.

Les premières versions de NT prennent aussi en charge plusieurs architectures matérielles. Le système n’est donc pas pensé comme dépendant d’un seul processeur.

La branche Windows destinée au grand public et celle construite autour de NT finissent par converger. Windows XP généralise les fondations NT sur les PC domestiques.

GNU, MINIX et Linux : refaire Unix sans reprendre son code

GNU et MINIX préparent le terrain

Une autre histoire se développe autour du logiciel libre. En 1983, Richard Stallman annonce le projet GNU afin de construire un système compatible avec Unix dont les utilisateurs puissent étudier, modifier et redistribuer le code.

GNU produit progressivement compilateurs, bibliothèques, interpréteurs de commandes et nombreux utilitaires. Son noyau ne devient cependant pas assez tôt la base d’un système largement utilisable.

MINIX joue parallèlement un rôle pédagogique. Andrew Tanenbaum le conçoit afin que les étudiants puissent étudier un véritable petit système d’exploitation.

Son organisation en micronoyau place plusieurs services hors de la partie la plus privilégiée du système. Cette architecture favorise la modularité et l’isolation des composants.

1991 : Linus Torvalds développe son noyau

En 1991, Linus Torvalds, étudiant à l’université d’Helsinki, commence à développer un noyau destiné à son ordinateur équipé d’un processeur Intel 80386.

MINIX lui fournit notamment un environnement d’apprentissage, tandis que les outils GNU apportent une grande partie de l’espace utilisateur nécessaire autour du nouveau noyau.

La distinction est importante : Linux n’est pas une continuation directe du code de l’Unix des Bell Labs. Le noyau est développé indépendamment, tout en reprenant plusieurs principes et interfaces du monde Unix.

Du noyau Linux à un système complet

Linux désigne d’abord le noyau. Il gère le processeur, la mémoire, les périphériques, le réseau et les systèmes de fichiers.

Une machine réellement utilisable demande cependant bien d’autres éléments : bibliothèques, commandes, services, compilateurs et outils d’administration. Une grande partie de cet espace utilisateur provient historiquement du projet GNU.

Linux devient une infrastructure mondiale

Linux adopte principalement une architecture de noyau monolithique et modulaire plutôt que le modèle en micronoyau défendu par Tanenbaum.

Grâce à sa licence libre, à la disponibilité de son code source et à la participation de développeurs individuels comme d’entreprises, Linux dépasse rapidement le PC.

On le retrouve dans les serveurs, les supercalculateurs, les routeurs, les téléviseurs, les systèmes embarqués et les infrastructures cloud.

NeXTSTEP puis Mac OS X : Unix revient chez Apple

NeXTSTEP apporte une nouvelle fondation

La trajectoire d’Apple suit une généalogie différente. Après son départ d’Apple en 1985, Steve Jobs fonde NeXT.

L’entreprise développe NeXTSTEP, qui associe une base reposant sur Mach et BSD à une interface graphique et à des outils de développement orientés objet.

Le système ne devient pas un produit de masse, mais son environnement de développement exerce une influence importante. C’est notamment sur une machine NeXT que Tim Berners-Lee développe le premier serveur et le premier navigateur Web.

Au milieu des années 1990, Apple cherche un successeur au Mac OS classique. Le système historique devient difficile à faire évoluer vers une mémoire protégée, un multitâche moderne et une architecture plus robuste.

Le rachat de NeXT en 1996 apporte une nouvelle fondation technologique et ramène Steve Jobs dans l’entreprise.

Mac OS X ne constitue donc pas une simple évolution de Mac OS 9. Apple remplace profondément ses fondations tout en essayant de préserver l’expérience et les applications familières aux utilisateurs.

Darwin, Mach, BSD et XNU

Le socle libre de Mac OS X est nommé Darwin. Son noyau XNU associe des éléments issus de Mach et de BSD ainsi que le système de pilotes I/O Kit.

Mach contribue notamment à la mémoire virtuelle, à l’ordonnancement et aux communications internes. L’héritage BSD fournit une grande partie du modèle Unix des processus, utilisateurs, permissions, réseaux et interfaces POSIX.

La différence avec Linux doit donc rester claire. Linux est un noyau de type Unix écrit indépendamment. macOS possède pour sa part une filiation passant notamment par NeXTSTEP, Mach et BSD.

Une autre branche : systèmes embarqués et temps réel

Pendant que Windows, Unix, Linux et macOS structurent l’informatique générale, d’autres systèmes évoluent dans des domaines aux contraintes différentes.

Dans l’industrie, les télécommunications ou les appareils mobiles, les priorités peuvent devenir le temps de réponse, la consommation énergétique, la fiabilité ou la taille du système.

QNX et la contrainte du temps réel

Dans un équipement industriel, un véhicule, un dispositif médical ou un système de communication, produire le bon résultat ne suffit parfois pas. Il faut également le produire avant une échéance déterminée.

Dans un système temps réel, la justesse d’un résultat dépend donc aussi du moment où il arrive. Une commande de sécurité correcte mais exécutée trop tard ne remplit plus sa fonction.

QNX adopte une architecture en micronoyau. Le noyau conserve un nombre limité de mécanismes essentiels tandis que plusieurs services et pilotes s’exécutent séparément.

Cette organisation favorise l’isolation des composants et permet de construire des configurations adaptées à des machines très différentes.

Palm : réduire le système au besoin réel

Les premiers assistants personnels imposent d’autres choix. Avec le PalmPilot, l’objectif n’est pas de reproduire un ordinateur de bureau miniature.

L’appareil doit être immédiatement disponible, simple et économe. Le système reste donc au service de l’usage et de la synchronisation plutôt que de chercher à accumuler les fonctions.

Ces systèmes rappellent une idée essentielle : il n’existe pas d’architecture d’OS idéale indépendamment du problème à résoudre.

iOS et Android : l’OS devient une plateforme mobile

iOS prolonge une partie de l’architecture du Mac

Lors du développement de l’iPhone, Apple peut réutiliser une partie des fondations de Mac OS X. Conserver une base commune évite de maintenir deux systèmes totalement indépendants.

iOS et macOS partagent ainsi une partie de leur architecture sans être pour autant le même système. Le mobile impose d’autres contraintes en matière d’énergie, d’interface, de sécurité et de gestion des applications.

Android utilise Linux comme noyau

Android suit une trajectoire différente. Il utilise le noyau Linux pour gérer les processus, la mémoire, les pilotes et le réseau.

Google et l’Android Open Source Project construisent au-dessus un environnement spécifique avec son runtime, ses services système et son framework applicatif.

Android n’est donc ni l’Unix historique, ni simplement une distribution GNU/Linux adaptée à un écran tactile. C’est une plateforme mobile utilisant Linux comme noyau.

L’application devient isolée dans une sandbox

Les deux familles renforcent fortement l’isolation des applications. Chaque programme travaille dans un environnement limité et doit obtenir l’autorisation d’accéder à certaines ressources.

Signature du code, permissions, magasins d’applications et mécanismes de mise à jour deviennent des éléments centraux du système.

L’OS ne contrôle plus seulement la mémoire et les périphériques. Il peut également déterminer quelles applications sont distribuées et quelles interfaces leur sont accessibles.

Du navigateur au cloud : la plateforme quitte progressivement la machine

Le navigateur devient lui aussi une plateforme

Au milieu des années 1990, certains responsables de Microsoft craignent déjà que le navigateur devienne une nouvelle plateforme d’applications.

Si un programme fonctionne dans un environnement Web identique sur plusieurs systèmes, Windows risque de perdre une partie de son rôle direct auprès du développeur.

Cette intuition s’est en partie réalisée. Une application Web peut aujourd’hui fonctionner sur Windows, macOS, Linux, Android ou iOS avec une base de code largement commune.

Le système local reste indispensable, mais il n’est plus toujours la plateforme directement visée.

La virtualisation partage le matériel

Le cloud pousse cette abstraction beaucoup plus loin. Une application peut s’exécuter dans une machine virtuelle située dans un centre de données. Son utilisateur ignore souvent sur quel ordinateur physique elle fonctionne réellement.

La virtualisation permet à plusieurs systèmes complets de partager un même serveur. Un hyperviseur attribue processeurs, mémoire et périphériques virtuels comme si chaque machine virtuelle possédait son propre matériel.

Le principe rappelle certains objectifs très anciens des systèmes multi-utilisateurs : transformer une ressource physique commune en plusieurs environnements apparemment indépendants.

Les conteneurs partagent le noyau

Les conteneurs utilisent une autre approche. Plusieurs applications isolées partagent généralement le noyau du même système hôte.

Sous Linux, cette séparation repose notamment sur des espaces de noms, des groupes de contrôle et différents mécanismes de sécurité.

L’isolation est moins lourde qu’une machine virtuelle complète car il n’est pas nécessaire d’exécuter un noyau différent pour chaque conteneur.

Kubernetes déplace le problème à l’échelle du centre de données

Kubernetes organise ensuite l’exécution de ces conteneurs sur un ensemble de machines. Il les place, surveille leur état, redémarre ceux qui échouent et adapte leur nombre.

Il ne remplace pourtant pas le système d’exploitation. Chaque nœud possède toujours un noyau, des pilotes, une mémoire, un réseau et des processus à gérer.

Le parallèle historique est frappant. Dans les années 1960, CTSS et Multics cherchaient à donner à plusieurs utilisateurs l’impression de disposer d’un ordinateur disponible pour eux.

Dans le cloud, l’infrastructure tente de donner à des milliers d’applications les ressources dont elles ont besoin. L’échelle a changé, mais le problème reste celui du partage contrôlé des ressources.

Les systèmes d’exploitation aujourd’hui

Des familles différentes qui partagent de nombreuses idées

Aucun système n’a définitivement remplacé tous les autres. Les grandes familles se sont spécialisées tout en empruntant progressivement des idées communes : mémoire virtuelle, isolation, processus, permissions, réseau, virtualisation, mise à jour automatique et protection cryptographique.

Windows repose toujours sur la lignée NT et conserve un important héritage applicatif. macOS prolonge les technologies issues de NeXTSTEP, Mach et BSD.

Linux domine une grande partie des serveurs, du calcul scientifique, des infrastructures cloud et de l’embarqué.

Android emploie le noyau Linux au sein d’une plateforme mobile distincte. iOS adapte de son côté la famille technologique d’Apple aux contraintes du smartphone. Les BSD, QNX et de nombreux autres systèmes continuent parallèlement d’occuper des domaines spécialisés.

L’OS doit gérer bien plus qu’un processeur et un disque

Le travail du système d’exploitation s’est considérablement étendu. Un OS moderne ne gère plus seulement un processeur, une mémoire et un disque.

Il doit coordonner plusieurs cœurs, des processeurs graphiques, des accélérateurs d’intelligence artificielle, des composants cryptographiques, des caméras, des capteurs et plusieurs interfaces radio.

Le système doit en même temps surveiller la consommation énergétique, mettre certains composants en veille et les réactiver rapidement.

La sécurité devient une activité permanente

Les premiers systèmes multi-utilisateurs cherchaient surtout à protéger les utilisateurs les uns des autres.

Les OS contemporains doivent également résister aux logiciels hostiles, vérifier le démarrage de la machine, chiffrer les données, contrôler les permissions et distribuer des mises à jour pendant parfois plus d’une décennie.

La sécurité n’est plus une fonction supplémentaire : elle accompagne désormais tout le cycle de vie du système.

La compatibilité reste une contrainte historique

La compatibilité reste pourtant aussi déterminante qu’à l’époque du System/360, de CP/M ou de Windows 95.

Les architectures peuvent passer de x86 à ARM, les interfaces être modernisées et certains composants internes entièrement remplacés. Les utilisateurs continuent cependant d’attendre que leurs programmes et leurs documents fonctionnent.

Une grande partie de l’histoire des systèmes d’exploitation est ainsi faite de révolutions techniques contraintes par des promesses de continuité.

Conclusion : une même question, à des échelles différentes

Le système d’exploitation est né de la nécessité de ne pas gaspiller une machine coûteuse. Il a ensuite appris à enchaîner les travaux, partager le temps du processeur, dialoguer avec plusieurs utilisateurs et protéger leurs données.

Il a aussi permis de transporter les programmes vers de nouvelles machines avant d’accompagner l’essor de l’ordinateur personnel, du smartphone et du cloud.

Derrière toutes ces transformations reste une même question :

comment permettre à plusieurs programmes, utilisateurs ou organisations de partager des ressources informatiques sans perdre le contrôle de leurs données et de leur exécution ?

Dans les années 1950, le problème concernait quelques travaux réunis en lots. Avec CTSS et Multics, il concernait une communauté connectée à un ordinateur central. Avec le PC, il s’est déplacé vers les applications d’un utilisateur.

Avec le smartphone, il touche les données personnelles de milliards de personnes. Dans le cloud, il concerne des services répartis sur des milliers de machines.

L’histoire des systèmes d’exploitation n’est donc pas terminée. Elle change continuellement d’échelle. Plus le système devient invisible pour son utilisateur, plus les responsabilités qu’on lui confie deviennent importantes.