Votre MacBook lent, c'est en fait un problème de stockage ?

« Mon Mac est devenu lent » est généralement suivi de gens qui regardent l’utilisation de la RAM, le graphique CPU du Moniteur d’activité, ou qui concluent que la machine est simplement vieille. La cause réelle, plus souvent que toutes celles-là, est banale et se vérifie en dix secondes :

df -h /

Si Avail représente moins d’environ 10 à 15 % de votre capacité totale, c’est très probablement votre réponse — et contrairement à un problème matériel, c’est réparable cet après-midi même, gratuitement.

Pourquoi l’espace libre affecte la vitesse

Ça surprend les gens parce que ça ne semble pas devoir être lié. Deux mécanismes rendent ça bien réel :

La mémoire virtuelle a besoin d’un endroit où faire du swap. macOS utilise l’espace disque libre comme extension de la RAM — quand la mémoire physique se remplit, il transfère les données inactives vers le disque. Sur un volume presque plein, le système n’arrive plus à allouer de l’espace de swap efficacement, ou doit travailler plus dur pour trouver de l’espace contigu, et vous ressentez ça exactement comme les symptômes que les gens décrivent : les applications mettent plus de temps à se lancer, la roue arc-en-ciel apparaît plus souvent, une lenteur générale sous charge.

APFS lui-même devient moins efficace près de sa capacité maximale. Les Mac récents utilisent APFS, un système de fichiers en copie sur écriture qui a besoin de marge de manœuvre pour bien fonctionner — allouer de nouvelles extensions de fichiers, gérer les instantanés, exécuter la maintenance en arrière-plan. Un volume rempli à 97-98 % laisse à APFS nettement moins de marge qu’un volume à 80 %, et la différence se manifeste par une réactivité générale du système, pas seulement par des opérations liées au stockage.

Le test rapide

Si vous voulez confirmer la théorie avant de passer du temps sur le nettoyage, voici le moyen le plus rapide : libérez ne serait-ce que 15 à 20 Go avec les étapes d’urgence du guide « pas assez d’espace disque » — Corbeille, Téléchargements, instantanés locaux de Time Machine, ~/Library/Caches — et voyez si les choses paraissent différentes dans l’heure qui suit une utilisation normale. Si c’est le cas, le stockage était bien votre véritable goulot d’étranglement, pas le processeur ou la RAM qu’on soupçonne en premier.

Ce qui n’est vraiment pas un problème de stockage

Pour être honnête envers les autres explications : si le Moniteur d’activité montre un processus précis qui bloque un cœur de processeur à 100 % en continu, ou si le nombre de cycles de votre batterie est très élevé et que la machine ne devient lente que sur batterie, ou si une application précise est la seule chose lente pendant que tout le reste semble normal — ça pointe ailleurs, et aucune quantité d’espace disque libéré ne réglera ça. Le stockage est la première chose à écarter, la moins coûteuse à vérifier, pas la seule cause possible.

# 30-second sanity check for a runaway process instead
top -o cpu -n 5

Si un processus reste constamment au-dessus de 90 % de CPU alors que vous ne faites rien de particulier, c’est le problème d’un autre article — quitter ou réinstaller cette application précise, pas libérer de l’espace disque.

Les développeurs le ressentent plus tôt

Si vous êtes développeur, votre disque se remplit plus vite que celui d’un utilisateur classique, pour des raisons couvertes dans tout ce blog — le DerivedData d’Xcode, l’image de disque de VM de Docker, des node_modules éparpillés dans chaque projet que vous avez jamais cloné, les index et caches d’IDE — ce qui veut dire que vous franchissez le seuil « le stockage me ralentit maintenant » plus tôt que quelqu’un qui utilise un Mac pour les e-mails et la navigation. C’est aussi pourquoi le correctif est généralement plus important une fois que vous vous en occupez enfin : le Mac d’un développeur a couramment plus de 100 Go de cache de compilation purement régénérable, quelque part entre « agaçant » et « me ralentit activement ».

# The three largest developer-specific hoards, checked in one pass
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
du -sh ~/Library/Caches/org.swift.swiftpm 2>/dev/null

La vraie solution, pas le pansement quotidien

Libérer de l’espace une fois vous achète quelques semaines avant de vous retrouver ici — chaque cache dans cette équation se remplit à nouveau en continu, dès que vous utilisez normalement votre Mac. Mettez en favori le guide de nettoyage d’urgence et exécutez-le à la main à chaque fois — c’est gratuit et ça fonctionne, simplement pas automatiquement.

DevCruft, une application Mac gratuite pour développeurs, est en cours de création : elle doit afficher l’espace libre aux côtés de ce qui le consomme exactement, pour vous éviter de relancer cinq commandes de nettoyage séparées, de mémoire, chaque fois que les performances chutent. Inscrivez-vous sur la liste d’attente pour savoir quand elle sera disponible.