Linux lent ou instable : comment diagnostiquer et vérifier l'état de son système

Un Linux lent, qui gèle par moments, redémarre tout seul ou se montre capricieux n’est pas forcément condamné. Dans la plupart des cas, le problème vient d’une cause identifiable : disque saturé, service planté, mémoire épuisée, mise à jour manquée ou log qui déborde. Avec les bonnes commandes, on fait le tour complet d’un système en moins de 20 minutes et on sait exactement ce qui ne va pas — sans avoir à réinstaller à l’aveugle.

1. Commencez par vérifier l’espace disque avec df -h avant toute autre manipulation.
2. Contrôlez la RAM et le swap avec free -h pour écarter une saturation mémoire.
3. Regardez la charge CPU avec uptime ou top et identifiez les processus gourmands.
4. Vérifiez les services en échec avec systemctl list-units --failed.
5. Consultez les logs d’erreurs récents avec journalctl -p err --since "24 hours ago".
6. Contrôlez l’état SMART du disque dur avec smartctl si vous suspectez une panne matérielle.
7. Vérifiez les mises à jour disponibles avec apt list --upgradable.

Pourquoi un système Linux devient lent ou instable

Linux a la réputation d’être stable et léger, et c’est souvent vrai. Mais aucun système n’est à l’abri d’une dérive progressive. Les causes les plus courantes ne sont généralement pas dramatiques.

Disque plein ou presque plein

C’est la première chose à éliminer. Quand la partition système est saturée, Linux ralentit brutalement : il ne peut plus écrire les fichiers temporaires, les journaux système explosent en taille, les applications se mettent à crasher. Un système à plus de 90 % de remplissage se comporte souvent comme s’il était en panne alors qu’il suffit de libérer de l’espace.

Trop de processus ou un processus fou

Un processus qui consomme 100 % du CPU sans s’arrêter passe souvent inaperçu. Il peut s’agir d’une mise à jour en cours, d’un antivirus qui scanne, d’une tâche cron partie en boucle ou d’un logiciel planté qui tourne dans le vide. Le résultat est le même : tout le reste ralentit.

RAM insuffisante ou swap utilisé

Quand la RAM est pleine, Linux commence à utiliser le swap — un espace sur le disque qui simule de la mémoire vive. Le problème est que le disque est 50 à 100 fois plus lent que la RAM. Un système qui swape massivement devient très lent, parfois à la limite de l’inutilisable.

Services plantés ou en boucle

Un service système qui redémarre en boucle après un échec consomme des ressources et peut provoquer des comportements erratiques. C’est typiquement le genre de problème qui passe inaperçu mais dégrade progressivement les performances.

Logs qui débordent

Sur certaines configurations, les journaux système peuvent occuper plusieurs gigaoctets si logrotate n’est pas configuré correctement. Le résultat : disque lentement saturé et système qui ralentit sans raison apparente.

Disque dur en mauvaise santé

Un disque mécanique qui commence à faillir peut provoquer des lenteurs inexplicables, des gels ou des erreurs de lecture aléatoires. L’interface SMART permet de lire l’état interne du disque et d’anticiper une panne avant qu’elle ne devienne une perte de données.

Les symptômes qui méritent une vérification complète

Étape 1 — Vérifier l’espace disque

C’est le premier réflexe sur n’importe quel système lent. L’équivalent Linux du chkdsk Windows ou du scandisk, c’est justement ce diagnostic par étapes qui commence ici.

df -h

La commande affiche l’espace utilisé sur chaque partition. L’essentiel est de regarder la colonne Use% sur la ligne / (partition racine). Au-delà de 85 %, le système commence à se dégrader. Au-delà de 95 %, c’est urgent.

# Pour voir les plus gros dossiers et identifier ce qui prend de la place
du -sh /* 2>/dev/null | sort -rh | head -15

Les coupables habituels : /var/log (journaux), /var/cache (paquets), /tmp (fichiers temporaires), ou un dossier utilisateur qui a grossi sans qu’on s’en rende compte.

# Nettoyer le cache des paquets apt
sudo apt clean

# Vérifier la taille des journaux systemd
journalctl --disk-usage

# Vider les anciens journaux (garder les 7 derniers jours)
sudo journalctl --vacuum-time=7d

À noter : si df -h montre une partition à plus de 90 %, commencez par libérer de l’espace avant de faire le reste du diagnostic. Beaucoup de symptômes disparaissent une fois le disque respire.

Étape 2 — Contrôler la mémoire RAM et le swap

free -h

La sortie donne la RAM totale, utilisée, libre et le swap. Ce qui compte :

• Mem: — regardez la colonne available : c’est la mémoire réellement disponible. En dessous de 200-300 Mo sur un système actif, c’est tendu.
• Swap: — si used est supérieur à zéro de manière persistante, le système swape. Si c’est supérieur à 50 %, il y a un vrai problème de mémoire.

# Identifier les processus qui consomment le plus de RAM
ps aux --sort=-%mem | head -11

Si un processus particulier monopolise la RAM (navigateur web, serveur de base de données, application), le problème est identifié. Il faut alors décider si on le redémarre, si on l’arrête ou si la machine a simplement besoin de plus de mémoire.

Étape 3 — Analyser la charge CPU

uptime

La sortie ressemble à ceci : load average: 0.52, 0.38, 0.31

Ces trois chiffres représentent la charge moyenne sur 1 minute, 5 minutes et 15 minutes. Pour l’interpréter, il faut connaître le nombre de cœurs CPU de la machine (nproc pour l’afficher). Une charge de 1.0 sur un CPU 4 cœurs est très faible. Une charge de 4.0 sur un CPU 2 cœurs est critique.

# Voir le nombre de cœurs
nproc

# Top des processus par consommation CPU
ps aux --sort=-%cpu | head -11

# Vue en temps réel
top

Dans top, tapez q pour quitter. La colonne %CPU indique la consommation de chaque processus. Un processus à 99 % en permanence mérite investigation.

Si la charge est élevée mais que vous ne trouvez pas le coupable, regardez aussi les processus système : kworker, systemd-journal, packagekitd, ou des tâches cron qui tournent en boucle.

Étape 4 — Vérifier les services système

sudo systemctl list-units --failed

Si la liste est vide, tout va bien. Si des services apparaissent avec le statut failed, c’est une piste directe.

# Voir les logs d'un service en échec (remplacer <nom> par le vrai nom)
sudo journalctl -u <nom-du-service> --since "1 hour ago"

# Redémarrer un service planté
sudo systemctl restart <nom-du-service>

# Vérifier l'état détaillé d'un service
sudo systemctl status <nom-du-service>

Les services critiques à vérifier même s’ils ne sont pas en échec :

sudo systemctl status ssh
sudo systemctl status cron
sudo systemctl status networking

Un service qui se relance toutes les 30 secondes n’apparaît pas forcément comme “failed” mais consomme des ressources et peut produire des erreurs en cascade.

Étape 5 — Lire les journaux d’erreurs

Les logs sont l’une des forces de Linux : tout y est écrit. Le problème est que c’est parfois une quantité de données considérable. Voici comment aller directement à l’essentiel.

# Erreurs des dernières 24 heures
sudo journalctl -p err --since "24 hours ago"

# Erreurs critiques des 7 derniers jours
sudo journalctl -p crit --since "7 days ago"

# Kernel panic ou OOM killer (manque de mémoire)
sudo dmesg | grep -i "oom\|killed\|panic\|error" | tail -20

Ce qu’il faut chercher en priorité :

• OOM killer (Out of Memory) : le noyau a tué un processus faute de RAM — signe de saturation mémoire.
• I/O error : erreur de lecture/écriture sur le disque — signe de disque défaillant.
• Segmentation fault : une application a planté — pas toujours grave, mais à surveiller si c’est répétitif.
• ACPI error : problème matériel lié à l’alimentation ou à la gestion d’énergie.

Si vous voyez des erreurs en boucle sur le même service ou le même composant, c’est là que se trouve le problème.

Étape 6 — Contrôler l’état du disque dur (SMART)

Le protocole SMART (Self-Monitoring, Analysis and Reporting Technology) permet aux disques durs et SSD de rapporter leur propre état interne. C’est l’outil le plus fiable pour détecter un disque en fin de vie avant la panne.

# Installer smartmontools si nécessaire
sudo apt install smartmontools

# Vérification rapide (remplacer sda par votre disque — vérifier avec lsblk)
sudo smartctl -H /dev/sda

Le résultat SMART overall-health self-assessment test result: PASSED signifie que le disque est en bonne santé. FAILED signifie que la panne est imminente — sauvegardez immédiatement.

# Rapport complet avec tous les attributs
sudo smartctl -a /dev/sda

Les attributs critiques à surveiller dans le rapport complet :

Note : sur un SSD NVMe, le disque apparaît généralement comme /dev/nvme0n1 et non /dev/sda. Utilisez lsblk pour identifier vos disques.

Étape 7 — Vérifier la sécurité

Un système lent peut aussi être un système compromis. Quelques vérifications rapides.

# État du pare-feu
sudo ufw status verbose

# Connexions réseau actives (chercher des connexions suspectes)
sudo ss -tlnp

# Dernières connexions réussies sur le système
last | head -15

# État de fail2ban (si installé)
sudo fail2ban-client status

Si le pare-feu est inactif sur un serveur exposé sur internet, c’est un problème de sécurité à corriger immédiatement. Sur un poste de travail, c’est moins critique mais recommandé.

Étape 8 — Vérifier les mises à jour disponibles

Un système non mis à jour peut avoir des failles de sécurité, des bugs connus et des problèmes de compatibilité. Sur Debian/Ubuntu :

# Mettre à jour la liste des paquets
sudo apt update

# Voir les mises à jour disponibles
apt list --upgradable 2>/dev/null

# Vérifier si un redémarrage est nécessaire après mise à jour
ls /var/run/reboot-required 2>/dev/null && echo "Redémarrage requis" || echo "Pas de redémarrage nécessaire"

Appliquer les mises à jour corrige souvent des lenteurs liées à des bugs connus dans des versions anciennes de paquets. C’est particulièrement vrai pour le noyau, les pilotes et les bibliothèques système.

Récapitulatif du diagnostic complet

Ce que faire après le diagnostic

Si le disque est plein

Libérez de l’espace : sudo apt clean, sudo journalctl --vacuum-time=7d, puis identifiez les gros fichiers avec du -sh /* 2>/dev/null | sort -rh | head -15.

Si la RAM est saturée

Identifiez le processus responsable. Redémarrez-le s’il a fuitée en mémoire. Si la machine tourne régulièrement à plus de 90 % de RAM, une mise à niveau matérielle est la solution durable.

Si SMART signale une anomalie

Sauvegardez immédiatement tous vos fichiers importants. Un disque avec des secteurs défaillants peut lâcher sans prévenir. Planifiez son remplacement dans les plus brefs délais.

Si un service est en échec

Lisez ses logs avec journalctl -u <service>, corrigez la configuration ou réinstallez le paquet concerné. Un service qui redémarre en boucle indique souvent un problème de configuration ou une dépendance manquante.

Si tout semble normal mais que le système reste lent

Dans ce cas, le problème est peut-être plus subtil : pilote graphique inadapté, distribution trop lourde pour le matériel, swap sur un disque très lent, ou configuration de bureau (GNOME, KDE) inadaptée aux ressources disponibles. Une distribution plus légère (Xfce, LXQt) peut transformer un vieux PC.

FAQ — Linux lent : les questions fréquentes

Comment savoir si mon Linux est lent à cause du disque ou de la RAM ?

Si free -h montre du swap utilisé, c’est la mémoire. Si les temps de réponse sont lents même avec peu de RAM utilisée, vérifiez le disque avec smartctl et surveillez les temps d’accès avec iostat -x 1 5 (paquet sysstat).

chkdsk n’existe pas sous Linux — quel est l’équivalent ?

Sous Linux, on n’utilise pas de scandisk ou chkdsk à la volée. Pour vérifier un disque, on utilise fsck (à lancer sur une partition non montée, donc hors système pour la partition racine). Pour surveiller la santé générale du disque, smartctl est l’outil de référence. Pour l’espace disque, df -h et du.

Mon Linux redémarre tout seul — c’est grave ?

Oui, c’est un signe à prendre au sérieux. Les causes les plus fréquentes sont une surchauffe (vérifier avec sensors si disponible), un OOM killer qui a tué un processus critique (chercher dans dmesg), ou un kernel panic (chercher dans /var/log/kern.log). Si le problème se répète, faites vérifier le matériel.

Est-ce que réinstaller Linux règle les problèmes de lenteur ?

Rarement. La réinstallation efface les problèmes logiciels mais ne change pas le matériel. Si le disque est en mauvaise santé ou si la RAM est insuffisante, le système redevient lent rapidement. Mieux vaut diagnostiquer avant de réinstaller.

journalctl affiche des milliers de lignes — comment s’y retrouver ?

Filtrez par niveau de sévérité : journalctl -p err pour les erreurs, -p crit pour le critique. Ajoutez --since "1 hour ago" pour limiter la période. Si vous cherchez un service précis : journalctl -u nom-du-service. Pour les 50 dernières lignes : journalctl -n 50.

Mon Linux est lent seulement au démarrage — que faire ?

Analysez les services qui ralentissent le boot avec systemd-analyze blame. La commande liste les services par ordre de temps de démarrage. Les suspects habituels sont les services réseau, les mises à jour automatiques et certains services inutiles activés par défaut.

En résumé

Un Linux lent ou instable se diagnostique méthodiquement. Le disque d’abord, la RAM ensuite, puis le CPU, les services, les logs et enfin la sécurité. Dans la grande majorité des cas, la cause est identifiable en moins de 20 minutes avec les commandes présentées ici. L’essentiel est de ne pas réinstaller à l’aveugle avant d’avoir compris d’où vient le problème — une réinstallation sur un disque défaillant ou une machine sous-dotée en RAM ne règle rien durablement.

Besoin d’aide pour interpréter les résultats ? Si le diagnostic vous dépasse ou si vous préférez confier cette vérification à un technicien, contactez-nous pour un audit à distance ou une intervention à domicile (Montpellier / Île-de-France).