Comment fonctionne réellement un système d’exploitation ?
Tu appuies sur le bouton d'alimentation et quelques secondes plus tard, ton curseur bouge.
Tu appuies sur le bouton d’alimentation et quelques secondes plus tard, ton curseur bouge. Ce qui se passe entre les deux est le logiciel le plus sous-estimé au monde – et c’est exactement ce sur quoi repose chaque pod, chaque conteneur et chaque VM cloud.
Les points clés en bref
- Du bouton d’alimentation au noyau, il y a quatre étapes : Le firmware (UEFI) démarre le chargeur de démarrage, qui charge le noyau dans la RAM, le noyau bascule la CPU en mode protégé et construit son propre monde. Jusqu’ici, il n’y a ni fichiers ni processus.
- La mémoire virtuelle est le plus grand mensonge en informatique : Chaque programme voit son propre espace d’adressage, la MMU traduit en arrière-plan vers la RAM réelle. C’est précisément ce mensonge qui rend possible l’isolation des conteneurs et les limites de mémoire dans les cgroups.
- Le planificateur, les appels système et l’IPC sont les fondements du cloud que personne n’explique : Le planificateur Linux distribue les processus sur les cœurs de CPU, le planificateur Kubernetes distribue les pods sur les nœuds – le même mécanisme à un niveau supérieur.
En rapport :Kubernetes 1.31 Conteneurs Sidecar / Comparaison des environnements d’exécution de conteneurs
Alimentation : chargeur de démarrage et anneaux de privilèges
Un système d’exploitation n’est pas un programme unique, mais une séquence chorégraphiée de dix étapes. Quiconque débogue des conteneurs ou planifie des clusters Kubernetes travaille chaque jour avec le résultat – la plupart du temps sans savoir ce qui se passe dans la salle des machines.
Tu appuies sur le bouton d’alimentation. Le courant électrique arrive sur la carte mère, la CPU se réveille et exécute la toute première instruction à une adresse câblée. À ce stade, il n’y a ni gestion de la mémoire ni fichiers – juste un seul cœur qui exécute un firmware. Sur les ordinateurs modernes, il s’appelle UEFI, auparavant c’était le BIOS.
Le firmware réveille juste assez de matériel pour trouver un disque dur et passe ensuite la main au chargeur de démarrage : Grub sous Linux, iBoot sur Mac, Boot Manager sous Windows. Le chargeur de démarrage a exactement une tâche – charger le noyau dans la RAM. Dès que cela est fait, la CPU fonctionne en anneau 0, le mode avec contrôle total du matériel.
L’anneau 0 contre l’anneau 3 est la ligne de démarcation la plus importante de ton ordinateur. Les CPU x86 ont quatre anneaux, mais seuls deux comptent vraiment : l’anneau 0 pour le noyau, l’anneau 3 pour tout le reste. Un bogue dans le code de l’anneau 0 paralyse toute la machine – la célèbre panne de Crowdstrike à l’été 2024 était précisément cela : un pilote défectueux dans l’anneau 0 qui a provoqué l’écran bleu de la mort sur des machines Windows dans le monde entier.
Le plus grand mensonge en informatique : la mémoire virtuelle
Lorsqu’un programme demande une adresse mémoire, cette adresse est presque toujours un mensonge. Il s’agit d’une adresse virtuelle qu’un composant matériel appelé MMU (Unité de gestion de la mémoire) traduit en une véritable adresse physique. La traduction se fait via une structure de données appelée Table des pages, que le noyau gère par processus. La mémoire est fournie en pages de 4 kilo-octets, chaque processus obtient son propre espace d’adressage virtuel.
C’est précisément cette séparation qui explique pourquoi ton navigateur ne peut pas lire dans la mémoire de ton gestionnaire de mots de passe. Tous deux vivent dans des univers parallèles que seul le noyau peut surveiller.
La MMU met en cache les traductions fréquentes dans un tampon minuscule, le TLB. Lorsqu’un processus accède à une page qui n’est pas en RAM, la MMU déclenche une erreur de page, le noyau charge la page depuis le disque et le processus continue comme si de rien n’était. C’est précisément ce mécanisme qui est à la base des limites de mémoire des conteneurs : lorsqu’un pod dépasse sa limite de cgroup, l’OOM Killer intervient et tue le processus – pas de swap, pas d’avertissement.
Pilotes, interruptions et premier processus
Dès que le noyau connaît la mémoire et le système de fichiers, il charge les pilotes. Les pilotes traduisent les requêtes génériques du noyau en commandes spécifiques aux puces pour le GPU, la carte Wi-Fi, le clavier. Ils s’exécutent dans l’anneau 0, ce qui est pratique pour les performances, mais dangereux pour la stabilité. L’incident Crowdstrike mentionné précédemment est un rappel à l’industrie de l’importance de prendre au sérieux les révisions des pilotes.
Avec les pilotes, le noyau active les interruptions. Comment un système d’exploitation sait-il que tu viens d’appuyer sur une touche ? Il ne le demande pas dans une boucle infinie. Au lieu de cela, le clavier envoie un signal électrique qui interrompt la tâche actuelle du processeur et fait sauter le noyau dans un gestionnaire d’interruptions. Chaque mouvement de souris, chaque paquet Wi-Fi, chaque réponse du disque est une interruption.
Ce n’est qu’à ce moment-là que le noyau crée le premier processus en espace utilisateur : PID 1, généralement systemd sous Linux moderne. PID 1 est l’ancêtre de tous les autres processus – si PID 1 meurt, le noyau panique et l’ordinateur s’arrête. À partir de ce moment, tout s’exécute dans l’anneau 3 et doit demander l’autorisation au noyau via des appels système chaque fois qu’il souhaite accéder au système de fichiers, au réseau ou au matériel.
Multitâche sur huit cœurs pour des centaines de processus
Une VM cloud moderne dispose peut-être de huit ou seize vCPU, mais de centaines de processus. Pour que cela fonctionne, il existe l’ordonnanceur (Scheduler). Il décide à l’échelle de la milliseconde quel processus s’exécute sur quel cœur. L’ordonnanceur Linux actuel s’appelle EEVDF (Earliest Eligible Virtual Deadline First) et garantit à chaque processus sa juste part de CPU.
Lorsque tu tapes kubectl get pods dans Kubernetes, le même mécanisme s’exécute en arrière-plan, un niveau plus haut : l’ordonnanceur Kubernetes répartit les pods sur les nœuds, de la même manière que l’ordonnanceur Linux répartit les processus sur les cœurs. Les requêtes et limites de ressources dans K8s sont les équivalents des valeurs nice et des quotas cgroup au niveau du système d’exploitation.
Au sein d’un processus, il arrive souvent que plus d’un chemin s’exécute – via des threads. Les threads partagent la mémoire, mais disposent de leurs propres piles. C’est puissant, mais dangereux : si deux threads écrivent simultanément sur la même variable, des conditions de course apparaissent. Les langages modernes tentent de prévenir cela, Go via les goroutines avec canaux, Rust via le vérificateur d’emprunt qui refuse le code non sûr pour les threads dès la compilation.
Lorsque deux processus complètement distincts doivent communiquer entre eux, l’IPC – la communication inter-processus – est utile. La forme la plus simple est la pipe, inventée en 1973 par Doug McIlroy chez Bell Labs et toujours incontournable aujourd’hui : cat log.txt | grep ERROR en est un exemple. Il existe également des sockets et des files de messages – toute l’architecture des microservices est conceptuellement de l’IPC, mais étendue au réseau.
Ce que les ingénieurs cloud en retirent
Un conteneur n’est pas un système d’exploitation à part entière. Il s’agit d’un processus d’espace utilisateur sur un noyau hôte, isolé via des namespaces et limité en ressources via des cgroups. C’est précisément pour cela que les conteneurs démarrent en millisecondes au lieu de secondes comme une VM – le véritable système d’exploitation est déjà en cours d’exécution. Une fois compris, cela permet de déboguer les pods OOMKilled, les workloads critiques en latence et les architectures Sidecar avec un regard complètement différent.
La vidéo Fireship « Every operating system concept in one video » présente les dix étapes en onze minutes – un excellent complément visuel sous forme de crash course. Pour aller plus loin, la documentation du noyau Linux et la lecture classique « Operating Systems: Three Easy Pieces » de Remzi Arpaci-Dusseau, disponible gratuitement en ligne, sont très utiles. Pour approfondir les implications de sécurité des pilotes Ring-0, vous trouverez sur le portail sœur SecurityToday l’analyse de la façon dont les agents KI découvrent les zero-days du noyau Linux.
Foire aux questions
Ai-je besoin de connaissances sur l’OS si je n’utilise que Kubernetes ?
Au plus tard lors du premier pod OOMKilled, lors de la première limitation de CPU ou lors du premier bug de journalisation Sidecar. Kubernetes n’abstrait pas le système d’exploitation, il s’y superpose. Tu ne peux définir de manière judicieuse les limites de ressources, les sondes de liveness et les politiques de réseau que si tu comprends comment fonctionnent les cgroups, les namespaces et le planificateur Linux en dessous.
Les conteneurs sont-ils plus légers que les VM parce qu’ils n’ont pas de système d’exploitation ?
Les conteneurs ont bien un système d’exploitation – ils partagent simplement le noyau de l’hôte. Ce qui se trouve dans l’image du conteneur, c’est l’espace utilisateur : bibliothèques, binaires, configuration. Une VM embarque un noyau complet qui lui est propre, ainsi que la surcharge de l’hyperviseur. C’est la principale raison pour laquelle les conteneurs démarrent en millisecondes et les VM en secondes.
Pourquoi Linux tue-t-il mon conteneur au lieu d’utiliser le swap ?
Parce que les cgroups appliquent des limites de mémoire strictes. Dès qu’un conteneur dépasse sa limite, l’OOM Killer envoie un SIGKILL – sans avertissement, sans tentative de swap. C’est intentionnel : les performances prévisibles sont plus importantes dans le cluster que la survie au mieux des pods individuels. Celui qui veut contourner cela doit soit augmenter les limites, soit effectuer un profilage de la mémoire.
Quelle est la différence entre l’espace noyau et l’espace utilisateur ?
L’espace noyau s’exécute dans l’anneau 0 avec un contrôle total du matériel. Les pilotes, le planificateur et le module de système de fichiers s’y trouvent. L’espace utilisateur s’exécute dans l’anneau 3, sans accès direct au matériel. Chaque serveur Web, chaque base de données, chaque conteneur s’exécute dans l’espace utilisateur. S’il veut accéder au matériel ou aux fichiers, cela ne peut se faire que par des appels système – le seul pont entre les deux mondes.
Que se passe-t-il réellement lors de l’arrêt ?
À l’inverse du démarrage : PID 1 envoie à chaque processus un SIGTERM (demande polie de se terminer). Celui qui ne répond pas reçoit après timeout un SIGKILL. Ensuite, les systèmes de fichiers vident leurs journaux, les pilotes libèrent le matériel, le noyau synchronise la mémoire sur le disque, désactive les interruptions et le firmware coupe l’alimentation. Tout cela en moins de deux secondes sur une machine normale.
Source de la une : Pexels / Manuel Geissinger (px:2881229)
Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image
