Accélérer le démarrage de Linux : 6 étapes efficaces

Accélérer le démarrage de Linux commence par une mesure avec systemd-analyze, puis se poursuit en corrigeant uniquement les ralentissements identifiés et, si nécessaire, en réduisant le délai d’attente de GRUB. Le gain dépend de ce que révèle la mesure sur votre machine, mais il reste concret et mesurable, sans rien désinstaller et en conservant une procédure réversible ; la prudence reste toutefois indispensable avant de désactiver un service ou de modifier GRUB.

L’essentiel

Les six étapes en bref :

1. Mesurer le temps de démarrage actuel avec systemd-analyze time
2. Identifier les services lents avec blame et critical-chain
3. Désactiver les services non essentiels avec systemctl disable
4. Réduire le délai GRUB via GRUB_TIMEOUT
5. Remesurer pour comparer avant et après
6. Vérifier que tout fonctionne normalement

Prérequis

Avant de commencer à accélérer le démarrage de Linux, vérifiez les prérequis suivants :

• Un accès sudo sur le système.
• systemd comme système d’init — c’est le cas par défaut sur toutes les distributions listées plus haut. Vérifiez avec la commande ci-dessous.

# Doit afficher "systemd" si systemd gère le PID 1
ps -p 1 -o comm=

• Une sauvegarde directe de /etc/default/grub et, en complément facultatif, un instantané système avant de toucher à la configuration de GRUB : une erreur de syntaxe dans /etc/default/grub n’empêche pas GRUB de démarrer, mais une mauvaise manipulation reste plus confortable à annuler avec un filet de sécurité. Timeshift peut compléter cette sauvegarde, mais sa couverture de /boot et de la partition EFI dépend du mode d’instantané et du partitionnement de la machine.
• Environ 15 à 20 minutes.

 

Étape 1 — Mesurer le temps de démarrage actuel

systemd-analyze peut distinguer plusieurs phases du démarrage : le noyau, l’initrd, puis l’espace utilisateur (userspace). Ces phases ne sont pas toutes affichées sur toutes les machines : sur un système démarrant sans initrd, la ligne correspondante est simplement absente, et la documentation officielle montre elle-même une sortie réduite à la seule phase userspace. Son absence n’indique donc pas un problème.

systemd-analyze time

Sortie typique sur une machine physique :

Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace

Notez ce chiffre : c’est votre référence avant optimisation. systemd-analyze time mesure le noyau, l’initrd et l’espace utilisateur jusqu’au lancement des unités nécessaires au démarrage ; ce résultat ne signifie pas nécessairement que toutes les applications sont prêtes ni que le disque est au repos. Il peut aussi afficher les phases firmware et loader lorsque les horodatages UEFI sont disponibles. Si ces lignes n’apparaissent pas, le temps du chargeur d’amorçage n’est pas disponible dans cette mesure : chronométrez également le temps total entre l’allumage et l’écran de connexion pour mesurer le gain complet.

Étape 2 — Identifier les services qui ralentissent le démarrage

systemd-analyze blame classe les unités selon le temps nécessaire à leur activation, de la plus lente à la plus rapide. Ce classement ne prouve pas qu’une unité retarde à elle seule tout le démarrage, car de nombreuses tâches s’exécutent en parallèle :

systemd-analyze blame

         32.875s pmlogger.service
         20.905s systemd-networkd-wait-online.service
         13.299s dev-vda1.device
            ...
             23ms sysroot.mount

Ce classement peut être trompeur : il mesure surtout le temps passé dans l’état d’activation et ne reflète pas toujours les files d’attente, les unités de type simple, les délais matériels ou l’exécution parallèle. Pour examiner la chaîne critique visible et repérer les dépendances qui retardent la cible par défaut, utilisez critical-chain :

systemd-analyze critical-chain

multi-user.target @47.820s
└─pmie.service @35.968s +548ms
  └─pmcd.service @33.715s +2.247s
    └─network-online.target @33.712s
      └─systemd-networkd-wait-online.service @12.804s +20.905s

Le temps après le @ indique quand l’unité a démarré ; le temps après le + indique combien de temps elle a mis à s’initialiser. Dans cet exemple, systemd-networkd-wait-online.service — qui attend que les interfaces gérées soient configurées et qu’au moins un lien atteigne l’état opérationnel attendu ; cela ne garantit pas nécessairement un accès à Internet — est le principal poste à examiner. Les exemples pmlogger/pmcd/pmie ci-dessus viennent de la documentation officielle systemd et correspondent à des services de supervision (Performance Co-Pilot) : sur votre machine, les postes les plus coûteux seront probablement différents — souvent liés au réseau, au montage de disques ou à la vérification de systèmes de fichiers.

Sur un poste de bureau Ubuntu, Linux Mint ou Fedora, le service réseau qui apparaît le plus souvent en tête de ce classement n’est pas systemd-networkd-wait-online.service mais NetworkManager-wait-online.service : ces distributions confient la gestion du réseau à NetworkManager. Le rôle est le même — retarder network-online.target jusqu’à ce que la connexion soit établie — et c’est donc ce nom que vous verrez dans la sortie de blame sur la majorité des installations grand public.

Pour visualiser le démarrage plutôt que de le lire ligne par ligne, systemd-analyze plot produit un chronogramme au format SVG, où les barres parallèles montrent d’un coup d’œil ce qui s’exécute en même temps et ce qui attend :

systemd-analyze plot > demarrage.svg

Ouvrez ensuite le fichier demarrage.svg dans un navigateur. Ce graphique complète blame et critical-chain : il rend visibles les périodes d’attente que les classements textuels ne montrent pas.

Étape 3 — Désactiver les services non essentiels au démarrage

systemctl disable retire les liens d’activation automatique d’une unité, sans la désinstaller. Elle reste disponible pour un lancement manuel et peut aussi être appelée par une autre unité, un socket ou un minuteur. La désactivation ne doit donc intervenir qu’après vérification de ses dépendances.

systemctl is-enabled nom-du-service.service
sudo systemctl disable nom-du-service.service

Deux pièges fréquents :

• disable n’arrête pas un service en cours d’exécution. Il retire seulement son activation automatique ; une dépendance, un socket ou un minuteur peut encore le lancer. Pour l’arrêter immédiatement aussi, ajoutez --now : sudo systemctl disable --now nom-du-service.service.
• Tous les services ne sont pas de bons candidats. Ne désactivez jamais une unité à partir de son nom seul. Vérifiez son rôle avec systemctl status nom-du-service.service, puis ce qui en dépend avec systemctl list-dependencies --reverse --all nom-du-service.service. Cette liste ne couvre que les unités actuellement chargées et ne remplace donc pas la lecture de la documentation du service. Les unités liées au réseau, aux montages distants, au chiffrement, à l’affichage ou à la connexion utilisateur peuvent être indispensables selon la machine.

N’hésitez pas à vous limiter aux services identifiés en étape 2 comme réellement coûteux plutôt que de désactiver par principe : un service à 200 ms peut être mesuré, mais son effet est rarement perceptible et peut ne pas raccourcir le chemin critique. À l’inverse, une unité qui bloque ce chemin pendant plusieurs secondes mérite un examen prioritaire.

Si une unité désactivée redémarre malgré tout au boot suivant, c’est qu’une autre unité la réclame comme dépendance, ou qu’un socket ou un minuteur l’active. systemctl mask va plus loin que disable : il remplace l’unité par un lien vers /dev/null, ce qui empêche tout démarrage, y compris par dépendance ou activation par socket.

sudo systemctl mask nom-du-service.service

Le masquage est à réserver aux cas où disable ne suffit pas, et uniquement après avoir vérifié ce qui dépend de l’unité : masquer un service réclamé par une cible essentielle peut empêcher cette cible d’aboutir. La commande inverse est sudo systemctl unmask nom-du-service.service.

Étape 4 — Réduire le délai d’attente de GRUB

Le comportement de GRUB dépend de GRUB_TIMEOUT et de GRUB_TIMEOUT_STYLE. Avec le style menu, le menu reste affiché pendant le délai indiqué ; avec hidden ou countdown, le compte à rebours s’effectue sans afficher le menu normal ; appuyer sur Échap ou F4, ou maintenir Maj, permet de l’afficher, tandis que l’expiration du délai lance l’entrée par défaut. Ce délai (GRUB_TIMEOUT) se règle dans /etc/default/grub.

sudo cp -a /etc/default/grub /etc/default/grub.bak
grep -E '^[[:space:]]*GRUB_TIMEOUT(_STYLE)?=' /etc/default/grub
sudoedit /etc/default/grub

Lisez d’abord le résultat de la commande grep ci-dessus : la valeur de départ n’est pas la même partout. Debian livre GRUB_TIMEOUT=5, mais Ubuntu et ses dérivées, dont Linux Mint, livrent GRUB_TIMEOUT=0 associé à GRUB_TIMEOUT_STYLE=hidden sur une installation à système unique. Sur ces machines, il n’y a aucun délai à réduire : passer la valeur à 2 ajouterait deux secondes au démarrage au lieu d’en retirer. Cette étape ne concerne donc que les configurations affichant déjà un délai non nul.

Lorsqu’un délai existe, 2 secondes restent un compromis raisonnable sur une machine à démarrage unique. En double démarrage, ou si vous utilisez régulièrement un ancien noyau, conservez plutôt 3 à 5 secondes. Évitez de descendre à GRUB_TIMEOUT=0 sans conserver GRUB_TIMEOUT_STYLE=hidden, sous peine de rendre l’accès aux entrées de secours beaucoup plus difficile :

GRUB_TIMEOUT=2

Une fois le fichier modifié, régénérez la configuration. La commande diffère selon la distribution :

Distribution	Commande
Debian, Ubuntu, Linux Mint	sudo update-grub
Fedora 34 et versions ultérieures, RHEL/Rocky Linux 9	sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Arch Linux, Manjaro	sudo grub-mkconfig -o /boot/grub/grub.cfg
openSUSE Leap, Tumbleweed	sudo grub2-mkconfig -o /boot/grub2/grub.cfg

update-grub sur Debian/Ubuntu est un simple raccourci qui appelle en interne grub-mkconfig -o /boot/grub/grub.cfg : les deux commandes font la même chose.

Sur Fedora 34 et versions ultérieures ainsi que RHEL 9, en BIOS comme en UEFI, grub2-mkconfig -o /boot/grub2/grub.cfg régénère le fichier réellement lu au démarrage sur ces versions et leurs dérivées correspondantes ; le fichier sous /boot/efi/EFI/…/grub.cfg sert alors de relais et ne doit pas être régénéré directement. Cette configuration varie selon la méthode d’installation d’origine : en cas de doute, la documentation Red Hat sur GRUB2 et UEFI permet de vérifier la vôtre avant de continuer.

Étape 5 — Mesurer à nouveau et comparer

Redémarrez la machine, puis relancez la mesure de départ :

systemd-analyze time

Comparez le nouveau résultat à celui de l’étape 1. systemd-analyze time mesure de nouveau le noyau, l’initrd et l’espace utilisateur. Pour mesurer aussi le gain lié à GRUB lorsque la phase loader n’est pas affichée, utilisez le chronométrage total effectué avant l’optimisation. Répétez idéalement le test trois fois et retenez la valeur médiane, car un démarrage isolé peut varier. Le gain sur GRUB_TIMEOUT dépend du délai effectivement appliqué par GRUB ; le gain sur les services désactivés dépend de ce qui a réellement été coupé.

Étape 6 — Vérifier que le démarrage de Linux est bien accéléré

Avant de considérer l’opération terminée :

• Redémarrez une seconde fois pour confirmer que le système démarre normalement, puis exécutez systemctl --failed afin de vérifier qu’aucune unité n’est en échec.
• Vérifiez que les fonctions dont vous avez besoin au quotidien fonctionnent toujours : réseau, son, affichage, périphériques externes.
• Si un service désactivé manque, il est toujours disponible en réactivation — rien n’a été supprimé.

Variantes par distribution

La méthode pour accélérer le démarrage de Linux décrite ici s’applique à l’identique sur les quatre familles de distributions, à l’exception des commandes de régénération de GRUB (tableau ci-dessus) : systemd-analyze et systemctl restent des commandes systemd, pas des commandes propres à une distribution. La sortie, certaines options et le comportement précis peuvent toutefois varier selon la version de systemd et la configuration retenue.

Annuler les modifications

Pour réactiver un service désactivé :

sudo systemctl enable nom-du-service.service
sudo systemctl start nom-du-service.service

Pour restaurer directement la copie créée avant modification, exécutez sudo cp -a /etc/default/grub.bak /etc/default/grub, puis régénérez la configuration. Sinon, pour remettre le délai GRUB à sa valeur d’origine, rouvrez /etc/default/grub, remettez GRUB_TIMEOUT à sa valeur précédente (valeur notée avant la modification), puis régénérez la configuration avec la commande de votre distribution (tableau de l’étape 4).

Erreurs courantes

bash: update-grub: commande introuvable

Cette commande est fournie principalement par Debian, Ubuntu et leurs dérivés ; elle n’est pas portable entre toutes les distributions. Sur Fedora, Arch ou openSUSE, utilisez la commande correspondante du tableau de l’étape 4.

Le service désactivé apparaît toujours comme actif

systemctl disable retire les liens d’activation automatique, mais n’arrête pas une unité déjà active et n’empêche pas un déclenchement par dépendance, socket ou minuteur. Vérifiez l’état avec systemctl is-active nom-du-service.service et utilisez sudo systemctl disable --now nom-du-service.service seulement après avoir confirmé que l’unité peut être arrêtée.

grub-mkconfig échoue après modification de /etc/default/grub

Le fichier est interprété comme un script shell : une valeur contenant des espaces doit être entourée de guillemets correctement fermés. Relisez la ligne modifiée avant de relancer la régénération.

FAQ — Questions fréquentes pour accélérer le démarrage de Linux

Combien de temps peut-on gagner en désactivant des services au démarrage ?

Cela dépend entièrement des services identifiés par systemd-analyze blame sur votre machine. Une unité qui attend le réseau, un disque ou un service optionnel propre à la configuration peut représenter plusieurs secondes ; un service déjà rapide (moins de 200 ms) apporte rarement un gain perceptible et peut ne pas raccourcir le chemin critique une fois désactivé.

systemd-analyze fonctionne-t-il sur toutes les distributions Linux ?

Sur toute distribution utilisant systemd comme système d’init, ce qui couvre Debian, Ubuntu, Linux Mint, Fedora, RHEL, Arch, Manjaro et openSUSE par défaut. Les distributions qui n’utilisent pas systemd (Alpine, Void, Devuan) n’ont pas cette commande.

Est-ce dangereux de désactiver un service au démarrage ?

Le risque est limité, mais jamais nul, même si vous vous limitez aux services identifiés comme réellement coûteux et vérifiez leur rôle avant de les couper. systemctl disable est généralement réversible avec systemctl enable : le service n’est pas supprimé, mais son état initial doit avoir été noté avant la modification.

Pourquoi mon Linux met-il plus de temps à démarrer après une mise à jour ?

Une mise à jour peut activer un nouveau service, modifier le noyau ou l’initramfs, changer un pilote, ou faire apparaître une attente réseau ou disque. Relancez systemd-analyze blame et systemd-analyze critical-chain pour identifier la phase réellement ralentie plutôt que de supposer la cause.

Faut-il remplacer GRUB par systemd-boot pour accélérer le démarrage ?

C’est possible et documenté par le projet Arch Linux, mais le gain varie fortement selon le matériel et la configuration. C’est une opération plus engageante qui sort du cadre de cet article : elle modifie le chargeur de démarrage lui-même, pas seulement sa configuration, et n’est pas nécessaire pour la majorité des gains accessibles via les étapes précédentes.

Conclusion

Accélérer le démarrage de Linux tient en trois leviers mesurables : identifier ce qui ralentit réellement le boot avec systemd-analyze, désactiver ce qui n’est pas nécessaire sans toucher au reste, et réduire le délai d’attente de GRUB. Les modifications proposées sont conçues pour être réversibles à condition de noter l’état initial des services et de conserver la sauvegarde de /etc/default/grub. Pour aller plus loin sur les performances globales du système une fois le démarrage optimisé, consultez le guide complet d’optimisation des performances Linux, qui couvre la mémoire, le stockage et le CPU. Avant de modifier la configuration de démarrage, un point de restauration avec Timeshift constitue une protection complémentaire, mais ne remplace pas la copie directe de /etc/default/grub ni la vérification du résultat de la régénération.

Sources officielles

• systemd-analyze — documentation officielle systemd
• systemctl — documentation officielle systemd
• openSUSE Leap 15.6 — The boot loader GRUB 2
• Red Hat Enterprise Linux 9 — configuration de GRUB
• GNU GRUB Manual — Simple configuration