Pourquoi un redémarrage répare-t-il les choses ? Guide visuel du système d’exploitation et de la gestion de mémoire

Si vous utilisez un PC, vous avez sans doute déjà croisé l’une de ces petites scènes du quotidien, plus d’une fois.

• Le PC vous demande parfois de redémarrer, par exemple après une mise à jour du système d’exploitation. Quelle différence avec un « arrêt puis démarrage » ?
• Le smartphone devient poussif après un long usage. Pourquoi l’éteindre puis le rallumer le relance-t-il ?

La plupart d’entre nous accomplissent ces gestes sans y penser, et très peu sauraient en expliquer la raison. Pourtant, dès qu’on remonte chaque cas à sa racine, ils partagent exactement la même explication.

Tant qu’un PC ou un smartphone tourne, l’OS (le logiciel système sous-jacent) ne cesse d’empiler par-dessus la mémoire « ce dont il se souvient en ce moment ». Un redémarrage est l’acte de tout remettre à zéro et reconstruire à partir de rien. Et sur Windows 10/11, « arrêter puis démarrer » et « redémarrer » ne sont en réalité pas la même chose (on y reviendra au §3-2).

Dans cet article, nous allons décortiquer :

• Ce qu’est réellement la mémoire et pourquoi elle s’évapore quand on coupe le courant (§1)
• Comment les applications s’exécutent en empruntant de la mémoire à l’OS (§2)
• Ce qu’un redémarrage fait concrètement, étape par étape (§3)
• Ce que sont les fuites mémoire et pourquoi elles apparaissent quand on garde une machine allumée longtemps (§4)
• L’autre piège, en plus de la mémoire ─ les handles de ressources (§5)
• Pourquoi les mises à jour réclament souvent un redémarrage (§6)
• L’univers « sans redémarrage » que le cloud et l’outillage de développement moderne ont fait émerger (§7)
• Une petite poignée de commandes que vous pouvez taper vous-même pour observer tout cela (§8)

Nous avancerons pas à pas, schémas à l’appui, sans présupposer aucune connaissance préalable.

1. Ce qu’est vraiment la mémoire ─ la différence entre un « bureau » et une « bibliothèque »

Pour parler des raisons pour lesquelles un redémarrage répare les choses, la première brique à acquérir est une intuition de la mémoire (le « bureau » sur lequel votre PC travaille en ce moment même). Beaucoup savent vaguement que « si la mémoire se remplit, l’ordinateur ralentit » ; allons un cran plus profond.

1-1. La RAM est volatile ─ on coupe le courant, tout disparaît

À l’intérieur d’un PC, il existe essentiellement deux sortes de contenants pour les données.

• RAM (mémoire principale) ─ rapide, mais tout ce qu’elle contient disparaît dès que l’alimentation est coupée (volatile)
• SSD / disque dur (stockage) ─ plus lent, mais le contenu survit à une mise hors tension (non volatile)

L’analogie du bureau et de la bibliothèque fonctionne bien. La RAM, c’est votre bureau ─ vous attrapez instantanément n’importe quel document étalé dessus, mais quand vous quittez l’office le soir, le bureau est rangé. Le SSD / disque dur, c’est la bibliothèque ─ un peu plus lent pour y ranger ou en sortir des documents, mais le contenu y reste pour la nuit.

Voilà la raison physique pour laquelle un redémarrage réinitialise le contenu de la mémoire. Au moment où le courant tombe réellement (ou qu’un mécanisme se comporte comme s’il tombait), tout ce que la RAM retenait disparaît, et l’OS doit relire depuis la bibliothèque ce dont il a besoin pour le réétaler sur le bureau.

1-2. La hiérarchie de mémoire ─ vitesse et capacité forment une pyramide inversée

En réalité, plusieurs couches plus fines s’intercalent entre la RAM et le SSD / disque dur. Du minuscule réservoir ultra-rapide à l’intérieur du CPU (les registres) jusqu’au SSD / disque dur qui contient le gros de la capacité de votre machine, vitesse et capacité dessinent une pyramide grossièrement inversée.

       [rapide / petit]
   ┌───────────────────────┐
   │  Registres CPU         │  quelques ns, des dizaines d'octets par cœur
   ├───────────────────────┤
   │  Cache L1              │  ~1 ns, des dizaines de Ko par cœur
   ├───────────────────────┤
   │  Cache L2              │  quelques ns, des centaines de Ko à quelques Mo
   ├───────────────────────┤
   │  Cache L3              │  ~10 ns, quelques Mo à des dizaines de Mo par CPU
   ├───────────────────────┤
   │  RAM (mémoire princ.)  │  ~100 ns, 8 à 64 Go
   ├───────────────────────┤
   │  SSD                   │  ~100 µs (= 100 000 ns), 500 Go à plusieurs To
   ├───────────────────────┤
   │  Disque dur            │  ~10 ms (= 10 000 000 ns), de l'ordre du To
   └───────────────────────┘
       [lent / grand]

Les enseignements clés : chaque palier descendu multiplie grosso modo le temps d’accès par 10, et il y a une nette frontière entre L1 jusqu’à la RAM (volatile) et SSD / disque dur (non volatile). Tant que le courant est là, l’OS et les applications ne cessent de charger de l’état dans les couches « rapides et volatiles ». Quand le courant tombe, la moitié supérieure de la pyramide se vide d’elle-même.

2. Processus et mémoire ─ comment une application « emprunte le bureau »

Le §1 vous a donné l’image de « la mémoire comme un bureau ». Voyons maintenant comment chaque application utilise concrètement ce bureau. L’objectif est que vous puissiez vous représenter avec précision ce qu’un redémarrage remet à zéro.

2-1. Qu’est-ce qu’un processus ? ─ chaque programme en cours d’exécution, un à un

Ouvrez le Gestionnaire des tâches : Chrome, Slack, l’Explorateur et compagnie s’alignent à l’écran. Chaque ligne est un processus (une instance d’un programme en cours d’exécution). Quand vous lancez une application, l’OS lui remet un morceau de mémoire et l’enregistre comme processus. Quand vous la fermez, ce morceau retourne à l’OS qui le recycle pour quelqu’un d’autre.

Autrement dit, la relation est la suivante :

• Un programme est un fichier sur le disque (.exe, .app, etc.)
• Un processus est ce fichier déployé dans la RAM et en cours d’exécution

Ce qu’un redémarrage remet à zéro, c’est le second ─ tous les processus actuellement étalés dans la RAM.

2-2. La disposition mémoire d’un processus ─ quatre pièces

La zone mémoire attribuée à un seul processus se divise en gros en quatre « pièces » :

   ┌─────────────────────────┐
   │  Texte (code)            │ ← les instructions CPU à exécuter
   ├─────────────────────────┤
   │  Données / BSS           │ ← variables globales et constantes
   ├─────────────────────────┤
   │  Tas (heap)              │ ← mémoire allouée dynamiquement (croît ↓)
   │   ↓                      │
   │                          │
   │   ↑                      │
   │  Pile (stack)            │ ← traces des appels de fonction (croît ↑)
   └─────────────────────────┘

• Le texte, ce sont les instructions de l’application en cours d’exécution (le code déployé en RAM dont parlait le §1)
• Données / BSS est l’emplacement des variables fixées au démarrage
• Le tas (heap) est l’endroit où l’application dit « donne-moi un peu plus de mémoire » à l’OS pendant qu’elle tourne. C’est la partie qui a tendance à enfler dans les applications longue durée (le terrain de jeu principal des fuites mémoire du §4)
• La pile (stack) est le brouillon temporaire utilisé à chaque appel de fonction ; elle se nettoie d’elle-même quand la fonction retourne

Retenez juste que « le tas est la pièce qui enfle avec le temps ». C’est ce qui compte au §4.

2-3. Mémoire virtuelle ─ chaque application croit avoir son propre bureau privé

Encore une couche à connaître : même lorsque de nombreux processus s’exécutent en même temps, chaque application se comporte comme si le bureau lui appartenait en propre. Le mécanisme qui rend cela possible s’appelle la mémoire virtuelle (le « bureau privé fictif » que chaque application voit, fabriqué par l’OS).

   L'adresse que voit chaque application (adresse virtuelle)
          │
          │   Gestion mémoire de l'OS (MMU + table de pages)
          ▼
   L'emplacement réel dans la RAM physique (adresse physique)

L’OS tient à jour une table de correspondance (la table de pages) et traduit « écrire à l’adresse 0x1000 » en une véritable adresse de RAM physique. Le 0x1000 de l’application A et le 0x1000 de l’application B pointent en réalité vers des emplacements physiques totalement différents.

C’est élégant, mais comme effet de bord, l’OS finit par garder en mémoire une quantité énorme de données de tables de pages et de tenue de livres associée. Cela fait partie aussi de « l’état » qui s’empile dans la RAM pendant que la machine tourne, et tout cela retourne à zéro lors du redémarrage.

3. [Cœur du sujet] Ce que fait réellement un redémarrage

Jusqu’ici nous avons posé que « l’OS et les applications empilent beaucoup d’état dans la RAM » et que « couper le courant balaie tout cela ». Que fait alors réellement, sous le capot, le bouton « Redémarrer » que vous pressez avec autant de désinvolture ? Décomposons-le en 8 phases.

3-1. Les 8 phases d’un redémarrage

Chaque phase prend de quelques centaines de millisecondes à plusieurs dizaines de secondes ; leur somme correspond au « temps d’attente de redémarrage » que vous percevez.

1. 1Signal d’arrêt aux appsL’OS envoie aux applications en cours un signal « veuillez conclure ». Elles sauvegardent leur état, vident leurs caches et quittent proprement.
2. 2Arrêt des services / pilotesLes démons d’arrière-plan et les pilotes (petits programmes qui font la traduction entre l’OS et le matériel) s’arrêtent dans l’ordre, libérant leurs ressources.
3. 3Synchro FS → extinctionLes écritures en attente encore tamponnées dans la RAM sont vidées vers le SSD (sync), puis la machine est physiquement éteinte. C’est là que la RAM se vide physiquement.
4. 4POST UEFI/BIOSJuste après le retour du courant, l’auto-test matériel (POST) s’exécute. CPU / mémoire / SSD / périphériques signalent chacun « je suis là ».
5. 5Lancement du bootloaderLe programme d’amorçage situé au début du SSD (Windows Boot Manager / GRUB / systemd-boot) se charge et décide quel OS démarrer.
6. 6Initialisation du noyauLe cœur de l’OS (le noyau) est chargé en RAM puis met en place, dans l’ordre, la gestion mémoire, la gestion des processus et le système de fichiers.
7. 7Démarrage des servicesL’OS lance les démons dont il a besoin (réseau, audio, impression, etc.). Win = Services, Linux = systemd, macOS = launchd jouent ici le rôle de chef d’orchestre.
8. 8Connexion → ouverture de sessionL’écran de connexion apparaît ; une fois identifié, le bureau et vos applications réapparaissent. Redémarrage terminé.

Pour mémoriser : « signal → arrêt → sync → auto-test → choix d’amorçage → noyau → services → connexion ». Depuis l’instant où vous appuyez sur le bouton de redémarrage jusqu’au retour du bureau, vous passez systématiquement par ces 8 étapes.

3-2. « Arrêter puis démarrer » et « redémarrer », est-ce pareil ?

C’est la réponse directe à la première question du §0. Sur Windows 10/11, ce n’est pas la même chose.

Depuis Windows 10, une fonctionnalité appelée Démarrage rapide (Fast Startup) est activée par défaut. Quand vous choisissez « Arrêter », au lieu de tout démonter pour de bon, l’OS procède ainsi :

1. Ferme vos applications utilisateur (jusque-là, cela ressemble à un « vrai » arrêt)
2. Sauvegarde l’état du noyau et des pilotes dans un fichier sur le SSD (semblable à une mise en veille prolongée)
3. Coupe l’alimentation

La fois suivante, quand vous allumez la machine, les parties lourdes (POST → bootloader → initialisation du noyau, phases 4-6) sont restaurées depuis le SSD au lieu d’être réexécutées depuis zéro, ce qui donne l’impression d’un démarrage plus rapide.

Voilà le piège : « l’état » empilé dans la zone du noyau est lui aussi restauré tel quel la fois suivante. Si vous choisissez « Redémarrer », à l’inverse, le Démarrage rapide est contourné et vous passez par les 8 phases complètes, ce qui est le seul moyen de réellement reconstruire à partir de zéro.

La règle pratique est donc :

• Si vous ne visez qu’un démarrage plus rapide → arrêter puis allumer convient
• Si « ça déraille depuis quelque temps » ou que vous voulez qu’une mise à jour Windows s’applique proprement → choisissez toujours « Redémarrer »

C’est une distinction discrète mais silencieusement importante. macOS et Linux n’ont pas vraiment ce décalage ─ arrêt → allumage et redémarrage y sont à peu près équivalents.

4. Fuites mémoire ─ « la place de bureau qui ne revient jamais »

Au §2-2 nous avons dit que « le tas est la partie qui enfle avec le temps ». Le contrat est simple : une application devrait rendre la zone à l’OS dès qu’elle n’en a plus besoin. En pratique pourtant, certaines applications empruntent et ne rendent jamais. C’est une fuite mémoire (un incident dans lequel les retours oubliés rétrécissent peu à peu votre espace de travail utilisable).

4-1. Ce qui se passe vraiment

Emprunter et rendre de la mémoire, schématiquement, ressemble à ceci :

   [emprunt]                                [retour]
   App → « donne-moi 100 Mo »                App → « je n'en ai plus besoin, tiens »
   OS  → « voilà pour toi »                  OS  → « reçu, je recycle pour quelqu'un »

Une fuite survient quand l’application oublie de rendre la mémoire au moment où elle le devrait. La cause est presque toujours un bug de programmation ─ une référence oubliée, un gestionnaire d’arrêt non appelé. Même des fuites de quelques centaines d’octets peuvent gonfler à plusieurs gigaoctets sur des heures ou des jours si elles se produisent dans une boucle exécutée plusieurs fois par seconde.

4-2. La RAM progressivement grignotée avec le temps

Voici une image stylisée de la consommation totale de RAM quand une application avec fuite tourne pendant 24 heures.

   Utilisation RAM
   100% ┤                                                                ████
        │                                                          ██████████
    80% ┤                                                    ██████████████
        │                                              ██████████████████
    60% ┤                                        ██████████████████████
        │                                  ██████████████████████████
    40% ┤                            ██████████████████████████████
        │                      ██████████████████████████████████
    20% ┤                ██████████████████████████████████████
        │  ██████████████████████████████████████████████████
     0% └─────────────────────────────────────────────────────────────────────→
        0h        4h        8h        12h       16h       20h       24h

Une application qui démarrait parfaitement bien remplit silencieusement la RAM en quelques heures. Une fois la RAM épuisée, l’OS bascule sur le swap (§2-3) et déplace des pages vers le SSD, mais les E/S du swap sont environ 1000 fois plus lentes que la RAM, et c’est toute la machine qui semble alors poussive.

Pourquoi un redémarrage répare cela : un redémarrage essuie la RAM (fuites comprises), et chaque application repart d’un état frais ; le total fuité est instantanément remis à zéro.

4-3. Les smartphones ont le même problème

Contrairement aux PC, les smartphones n’ont pas vraiment l’habitude d’être « éteints » ou « redémarrés ». La plupart des gens tournent en simple veille pendant des semaines voire des mois d’affilée.

Mais les applications mobiles fuient aussi :

• Une application sociale en arrière-plan accumule discrètement de la mémoire
• Les onglets de navigateur laissés ouverts continuent de faire enfler le tas
• Un jeu conserve indéfiniment la mémoire image qu’il a allouée une fois

Tout cela s’accumule. Quand « mon téléphone se traîne ces derniers temps » ou que « la batterie se vide plus vite que d’habitude », la raison pour laquelle l’éteindre puis le rallumer le ramène à la vie est la même que sur PC ─ cette accumulation est remise à zéro. Les plateformes mobiles ont une gestion mémoire automatique plus stricte que les PC, mais elles ne peuvent pas rattraper tous les bugs propres à chaque application.

5. Épuisement des handles de ressources ─ la mémoire n’est pas la seule chose finie

« Un redémarrage répare les trucs bizarres » ne tient pas seulement aux fuites mémoire. L’OS gère bon nombre de ressources finies, en plus de la mémoire, qui souffrent du même problème d’« emprunt sans retour ». On les regroupe sous le nom de handles de ressources (des tickets numérotés que l’OS distribue, tous en quantité finie).

5-1. Les principaux types de handles

Les handles distribués par l’OS aux applications se rangent grossièrement dans les catégories ci-dessous. Tous ont un plafond, et une fois ce plafond atteint, plus aucune nouvelle opération de ce type n’est possible.

5-2. Ce que « je ne peux rien ouvrir » veut vraiment dire

Quand les handles fuient, vous croisez généralement ce genre de symptômes :

• Des erreurs « Impossible d’ouvrir le fichier » / « Too many open files »
• Le navigateur refuse d’ouvrir un nouvel onglet
• Toutes les connexions réseau échouent (parce qu’en coulisses vous avez brûlé tous les sockets)
• Un message « impossible d’ouvrir la fenêtre » sous Windows

Contrairement aux fuites mémoire, la consommation de RAM paraît souvent parfaitement normale pendant ce temps, ce qui sème la confusion : « la mémoire va bien, pourquoi tout est-il cassé ? ». Surface différente, mais même problème fondamental d’« oubli de retour » du §4.

Pourquoi un redémarrage répare cela : quand un processus se termine, l’OS récupère de force tous les handles que ce processus détenait. Un redémarrage tue tous les processus, donc tous les compteurs de handles retournent à zéro et les ressources finies de l’OS sont totalement libérées.

6. Mises à jour et « fichiers en cours d’utilisation » ─ ce que veut vraiment dire « redémarrer pour appliquer »

Tout le monde a vu « Windows Update installé. Veuillez redémarrer pour terminer les modifications. » Pourquoi la mise à jour ne peut-elle pas simplement se finir d’elle-même ? Cela tient à une contrainte autour des fichiers que l’OS lui-même est en train d’utiliser.

6-1. Verrouillage de fichier ─ impossible de remplacer quelque chose pendant qu’il tourne

L’OS dispose d’un mécanisme appelé verrouillage (l’OS pose une étiquette « en cours d’utilisation, ne pas toucher » sur un fichier). La raison est évidente : si quelqu’un écrase un document pendant qu’une autre partie est en train d’y écrire, vous obtenez de la corruption.

Le hic, c’est que l’OS lui-même (le noyau) et les exécutables des services résidents sont eux aussi verrouillés en « en cours d’utilisation » tout le temps que le système tourne.

   [en cours d'exécution]
   Fichier du noyau sur le SSD ─── verrouillé (pas d'écrasement autorisé)
            │
            ▼
   Chargé en mémoire ───── le CPU exécute ces instructions en ce moment

   ↓ Même quand une mise à jour apporte un nouveau fichier de noyau…

   Fichier du noyau sur le SSD ─── toujours verrouillé
   Nouveau fichier de noyau    ─── déposé à côté, en attente

On peut donc déposer une nouvelle version, mais on ne peut pas remplacer celle en cours d’exécution. « Redémarrez pour terminer la modification » signifie :

1. Arrêter un instant l’ancien noyau (mise hors tension)
2. Au prochain démarrage, faire charger le nouveau par le bootloader

Dans le langage Windows, il s’agit de « créer un instant pendant lequel le remplacement est autorisé » via un redémarrage.

6-2. Comment Windows / macOS / Linux diffèrent

La raison est la même sur chaque OS : un programme en cours d’exécution ne peut pas écraser ses propres fichiers sur place.

6-3. L’exception ─ correctifs à chaud / live patching (mises à jour sans redémarrage)

Ces dernières années, il existe aussi le live patching (un mécanisme limité qui réécrit silencieusement un noyau en cours d’exécution). Les principaux exemples sont :

• Noyau Linux : kpatch (Red Hat) / livepatch (Canonical) / Ksplice (Oracle)
• Windows Server : certaines corrections de sécurité peuvent être appliquées en correctifs à chaud

Cela dit, cela ne s’applique pas à n’importe quelle mise à jour. Les changements à haut risque (gros remaniements du noyau, modifications de structures de données, etc.) exigent toujours un vrai redémarrage. Aucune formule magique ne couvre encore toutes les mises à jour sans en passer par là.

7. L’univers du « sans redémarrage » qui existe aujourd’hui

Jusqu’ici, on s’est concentré sur la raison pour laquelle un redémarrage est nécessaire. Dans le cloud et dans l’outillage de développement moderne, de plus en plus de situations cachent astucieusement le redémarrage à l’utilisateur. La question naturelle ─ « les services web tournent 24/7, alors quand redémarrent-ils ? » ─ trouve ici sa réponse.

7-1. Cinq approches qui évitent ou masquent un redémarrage

7-2. Comment chacun fonctionne (avec des éclairages en langage simple)

• Redémarrage progressif ─ exécuter le même service sur plusieurs serveurs et les redémarrer un à un. Le trafic utilisateur est routé vers les machines pas encore redémarrées, si bien que le service dans son ensemble reste accessible sans interruption. La réputation « toujours en ligne » du cloud repose en grande partie là-dessus.
• Recréation de conteneur ─ reconstruire à partir de zéro un conteneur (en gros, une « petite pièce portable » qui scelle l’application et ses dépendances) tout entier pour mettre à jour l’application. Bien plus rapide que redémarrer tout l’OS (quelques secondes), et généralement combinée avec un redémarrage progressif.
• Hot reload ─ la technique consistant à injecter du nouveau code ou de la nouvelle configuration sans stopper le processus. L’expérience « j’enregistre le fichier et la page se met à jour instantanément » pendant le développement, c’est exactement cela. Le support en production varie beaucoup selon le langage et le framework.
• Live patching ─ la technique du §6-3 consistant à réécrire un noyau pendant qu’il tourne. Ne s’applique pas à toutes les mises à jour, mais sert pour des correctifs limités.

7-3. Conclusion ─ « sans redémarrage » veut toujours dire que quelqu’un redémarre quelque part

Le motif devrait être clair maintenant : même les mondes qui prétendent « sans redémarrage » s’appuient toujours sur le fait que quelqu’un, quelque part, redémarre à un moment donné. Les services cloud font tourner leurs flottes à tour de rôle via des redémarrages progressifs ; les conteneurs sont recréés en permanence.

Et dans l’autre sens : sur un PC personnel où vous gardez la même installation d’OS pendant des années, les redémarrages périodiques restent inévitables, encore aujourd’hui. Mieux vaut ne pas traiter le redémarrage comme un méchant ─ voyez-le plutôt comme « une occasion de remettre proprement à zéro l’état de l’OS ».

8. L’observer en pratique ─ jetez un œil à la mémoire et au redémarrage sur votre propre machine

Maintenant que la théorie est posée, ouvrez votre propre machine. Une ou deux commandes par OS vous diront combien de RAM est en usage en ce moment et quand vous avez redémarré pour la dernière fois.

8-1. Vérifier l’utilisation de la mémoire

# Windows (PowerShell) ─ top 5 des processus par mémoire
Get-Process | Sort-Object WS -Descending | Select-Object -First 5 Name, @{n=\u0022RSS_MB\u0022;e={[math]::Round($_.WS/1MB,1)}}

# macOS ─ statistiques mémoire du système
vm_stat

# Linux ─ mémoire en format lisible
free -h

8-2. Vérifier l’heure de démarrage (quand vous avez redémarré pour la dernière fois)

La question « quand ai-je vraiment redémarré pour la dernière fois ? » :

# Windows (PowerShell) ─ heure de démarrage
(Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime

# macOS / Linux ─ depuis combien de temps la machine tourne
uptime

uptime affiche en une seule ligne « heure actuelle, temps écoulé depuis le démarrage, utilisateurs connectés et charges moyennes ». Sur un serveur Linux, un uptime de plusieurs centaines de jours est parfois un signal d’alerte pour « appliquez-vous bien les mises à jour de sécurité ? » (une exploitation saine privilégie souvent des redémarrages périodiques).

8-3. Vérifier le nombre de handles (avancé)

Curieux à propos des handles du §5 ? Vous pouvez les compter en direct ainsi :

# Linux ─ descripteurs de fichier en usage à l'échelle du système
cat /proc/sys/fs/file-nr

# Windows (PowerShell) ─ top 5 des processus par nombre de handles
Get-Process | Sort-Object Handles -Descending | Select-Object -First 5 Name, Handles

Si les compteurs ne cessent de grimper sans jamais redescendre, c’est un signal fort de fuite.

Conclusion ─ l’essence en quatre lignes

Article long, mais l’essence tient en quatre lignes :

• Un redémarrage = reconstruire à zéro la mémoire volatile et l’état de l’OS ─ la RAM se vide physiquement, donc tout l’état disparaît
• Vous avez besoin d’un redémarrage pour trois choses ─ les fuites, l’épuisement des handles et les fichiers en cours d’utilisation ─ aucune ne se résout pendant qu’un processus est en vie
• « Arrêter puis démarrer » n’est pas la même chose que « redémarrer » sur Windows 10/11 ─ choisissez « Redémarrer » quand vous avez réellement besoin d’un état propre
• Le cloud cache astucieusement les redémarrages derrière des redémarrages progressifs et des conteneurs ─ sur un PC personnel, les redémarrages périodiques restent une bonne pratique

Une fois ce cadre intériorisé, « pourquoi cette chose se comporte-t-elle mal et pourquoi un redémarrage la répare-t-il ? » devient la même grille de lecture pour les PC, les smartphones et les serveurs.

Pour les fondations côté réseau, voyez Qu’est-ce qu’une adresse IP ?, et pour la poignée de main côté logiciel avec l’OS, voyez Pourquoi un logiciel ne fonctionne-t-il pas sans installation ?. Combinés à l’angle « état que l’OS accumule » de cet article, vous obtenez une vision à peu près complète de ce qui se trame réellement à l’intérieur de votre ordinateur.

FAQ

Q1. Quelle est la différence entre veille, veille prolongée et redémarrage ?

R. Elles diffèrent sur l’endroit où l’état est sauvegardé et sur le fait qu’on obtient ou non « l’effet redémarrage ». La veille garde la RAM sous tension et met simplement le CPU et l’écran en pause ─ le contenu est intact, donc on reprend en quelques secondes, mais aucun élément de l’état de l’OS n’est remis à zéro (le bug est toujours là). La veille prolongée écrit le contenu de la RAM dans un fichier sur le SSD puis éteint la machine ; au redémarrage, le fichier est restauré en RAM, donc l’état revient lui aussi (toujours bugué). Arrêter puis démarrer sur Windows 10/11 sauvegarde l’état d’hibernation du noyau via le Démarrage rapide, ce qui veut dire que ce n’est pas vraiment un démarrage à froid propre (voir §3-2). Seul Redémarrer contourne le Démarrage rapide et parcourt l’ensemble complet des phases, en vidant physiquement la RAM et en réinitialisant tout l’état. Si votre but est de réparer un truc bizarre, choisissez juste « Redémarrer ».

Q2. Si j’ajoute de la RAM, puis-je arrêter de redémarrer ?

R. Non, ce n’est pas une vraie solution. Plus de RAM ne fait qu’acheter du temps avant que vous ne remarquiez une fuite ─ la fuite, elle, ne s’arrête pas. Pire, elle peut passer inaperçue assez longtemps pour que les E/S de swap grignotent discrètement vos performances et qu’un beau jour la machine s’effondre. La marge de RAM est une « assurance », pas une « solution ».

Q3. Existe-t-il vraiment des serveurs qui ne redémarrent pas pendant des centaines de jours ?

R. À moitié vrai, à moitié un peu trompeur. Oui, il existe des serveurs individuels avec un uptime de plus de 1 000 jours. Mais dans l’exploitation cloud moderne, les redémarrages périodiques et intentionnels sont en fait recommandés (pour appliquer les mises à jour de sécurité de manière fiable, remettre à zéro les fuites latentes et l’épuisement des handles, détecter les dérives de configuration, etc.). La sensation « toujours en ligne » d’un service est obtenue par l’approche du redémarrage progressif du §7-1, où des serveurs individuels redémarrent régulièrement tandis que le service dans son ensemble continue de servir le trafic. Autrement dit, « l’application ne tombe jamais » et « l’instance OS ne redémarre jamais » sont deux choses distinctes.

Q4. Des redémarrages fréquents vont-ils user ma machine ?

R. Pour un usage normal, en gros non. À l’époque des disques durs, on s’inquiétait un peu de l’usure mécanique, mais les SSD modernes éliminent quasiment ce souci. Ce qu’il faut éviter, c’est maintenir le bouton d’alimentation pour forcer l’arrêt ─ cela saute la synchro FS (phase 3 du §3-1) et risque de corrompre des fichiers. Choisir « Redémarrer » correctement est sans danger, même au quotidien.

Q5. On entend dire que les Mac n’ont presque pas besoin de redémarrer ─ est-ce vrai ?

R. À moitié vrai. macOS a un verrouillage de fichiers plus souple, si bien que les mises à jour d’applications ne réclament souvent pas de redémarrage ; les mises à jour du noyau, elles, en réclament toujours un ; et sa gestion mémoire agressive (mémoire compressée, etc.) masque mieux la pression sur la RAM, donc vous « remarquez moins le besoin de redémarrer » que sur Windows. Cela dit, les fuites mémoire et l’épuisement des handles surviennent sur tous les OS, donc « les Mac n’ont jamais besoin de redémarrer » est un excès de confiance. Si quelque chose semble cloche, allez-y, redémarrez.