Fermer le capot de son laptop, c’est le geste le plus banal du monde. Tu termines ta session, tu rabats l’écran, tu glisses l’ordi dans ton sac. Sauf que sous Linux, ce geste anodin peut littéralement tuer ton système de fichiers si ta configuration n’est pas correcte. Pas de façon spectaculaire, pas immédiatement, mais à coups de corruptions silencieuses, de fichiers tronqués, de partitions qui finissent par ne plus monter au démarrage.
Le problème ne vient pas du matériel. Il vient de ce qui se passe (ou ne se passe pas) quand Linux reçoit le signal de fermeture du capot.
À retenir
- 90% des utilisateurs Linux ferment leur laptop sans savoir qu’ils risquent une corruption silencieuse du système de fichiers
- Deux scénarios précis transforment votre mise en veille en cauchemar pour vos données
- Une simple ligne à modifier dans systemd peut changer tout — mais l’environnement de bureau peut vous saboter
Ce que Linux fait vraiment quand tu fermes l’écran
Par défaut, sur la plupart des distributions grand public, fermer le capot déclenche une mise en veille (suspend to RAM, aussi appelé S3). Le système gèle son état en mémoire vive, coupe l’écran, réduit la consommation. Quand tu rouvres, tout reprend. En théorie.
Le vrai danger apparaît dans deux scénarios précis. Premier cas : tu fermes le capot pendant qu’une opération d’écriture est en cours. Une mise à jour qui tourne en fond, un éditeur de texte qui auto-sauvegarde, un paquet qui s’installe via ton gestionnaire de logiciels. Si la mise en veille se déclenche au mauvais moment, les tampons d’écriture du noyau n’ont pas le temps d’être vidés sur le disque. Le fichier est à moitié écrit. Parfois ça se règle seul au redémarrage. Parfois non.
Deuxième cas, plus vicieux : la mise en veille échoue silencieusement. Le système croit être en veille, mais certains processus continuent à tourner en arrière-plan. Le SSD reçoit des commandes d’écriture pendant que d’autres parties du système sont gelées. C’est le genre de situation qui crée des incohérences dans le journal du système de fichiers ext4 ou btrfs, des erreurs que tu ne verras peut-être jamais jusqu’au jour où fsck te sort un mur de rouge au démarrage.
Le vrai coupable : systemd-logind et sa configuration par défaut
Tout se gère dans un seul fichier : /etc/systemd/logind.conf. C’est là que systemd-logind définit ce qu’il faut faire quand le capot se ferme, quand la batterie est critique, quand on appuie sur le bouton power. Et par défaut, la valeur HandleLidSwitch=suspend est souvent active, ce qui est raisonnable pour un usage nomade classique, mais qui devient problématique si ton matériel a des drivers de veille approximatifs (ce qui concerne encore pas mal de laptops sous Linux en 2026, surtout sur certaines puces graphiques hybrides).
Pour voir ta configuration actuelle, ouvre un terminal et tape :
cat /etc/systemd/logind.conf | grep -i lidSi la ligne est commentée (précédée d’un #), c’est la valeur par défaut qui s’applique. Pour la modifier, ouvre le fichier avec les droits root :
sudo nano /etc/systemd/logind.confDécommente la ligne HandleLidSwitch et choisis ton comportement parmi les options disponibles : suspend, hibernate, lock, poweroff ou ignore. L’hibernation (suspend to disk) est généralement plus sûre qu’une mise en veille RAM si ton matériel la supporte correctement, parce que l’état complet du système est écrit sur le swap avant d’éteindre. Mais elle est aussi plus lente.
Après modification, recharge la configuration sans redémarrer :
sudo systemctl restart systemd-logindLe cas particulier des environnements de bureau
GNOME, KDE Plasma, XFCE, chacun de ces environnements ajoute sa propre couche de gestion de l’énergie par-dessus systemd. Ce qui veut dire que même si tu modifies logind.conf, ton bureau peut passer outre. C’est une source de confusion classique sur les forums : « J’ai changé la config systemd mais mon laptop se met quand même en veille ! »
Sous GNOME, le comportement est géré par le démon gnome-settings-daemon et les paramètres d’alimentation dans les Réglages système. Sous KDE, c’est PowerDevil qui prend le dessus. La bonne pratique : configure les deux niveaux de façon cohérente, ou désactive complètement la gestion d’énergie au niveau du bureau et laisse systemd gérer seul.
Pour vérifier quel processus a la main sur la gestion du capot, la commande systemd-analyze blame et l’inspection des logs via journalctl -b | grep -i lid donnent souvent des indices précieux sur ce qui s’est passé lors de la dernière fermeture.
Protéger ses données avant tout
Au-delà de la configuration de veille, un réflexe simple protège la majorité des données : s’assurer que les écritures en attente sont bien vidées sur le disque avant de fermer le capot. La commande sync fait exactement ça, elle force le noyau à vider ses tampons d’écriture. Certains utilisateurs avancés l’ajoutent comme alias à leur commande de fermeture de session.
Si tu utilises un système de fichiers btrfs, la commande btrfs filesystem sync / fait un travail similaire sur le système de fichiers racine. Et si tu as régulièrement des problèmes de corruption, activer les snapshots automatiques avec snapper ou timeshift te sauvera la mise bien plus sûrement que n’importe quelle configuration de veille.
Le fond du problème, c’est que Linux sur laptop reste un terrain où le matériel et le logiciel ne se parlent pas toujours parfaitement. La veille fonctionne à merveille sur certaines machines depuis des années, et reste un casino sur d’autres. La différence entre les deux, c’est rarement la chance, c’est la configuration. Et maintenant tu sais où regarder.