Pourquoi le Mac est lent et comment le diagnostiquer

Un Mac lent est un problème de latence, et plusieurs goulots d'étranglement peuvent produire la même sensation : contention CPU, pression mémoire, capacité de stockage, E/S disque, limites thermiques ou service réseau lent. L'objectif est d'identifier quelle ressource est saturée pendant le ralentissement. Un instantané pris une fois le problème terminé prouve peu de chose.

Voici comment fonctionnent les pièces du puzzle, et les commandes pour les observer.

Le mythe de la RAM : la mémoire libre n'est pas l'objectif

Le réflexe le plus courant et le plus faux consiste à regarder la « mémoire libre » et à paniquer quand elle est basse. Sous macOS, une faible mémoire libre est normale et saine. Une RAM inutilisée est une RAM gaspillée, aussi le noyau la garde délibérément remplie : les fichiers récemment utilisés restent en cache mémoire pour que la prochaine lecture soit instantanée, et ce cache est libéré dès qu'un programme a besoin de l'espace.

macOS compresse aussi la mémoire. Depuis OS X Mavericks, quand la RAM se remplit, le système compresse sur place les pages inactives plutôt que de les écrire immédiatement sur le disque, ce qui permet à certaines données qui iraient sinon vers le swap plus lent de rester en RAM. Vous pouvez observer les compteurs directement :

vm_stat

Les chiffres sont en pages, avec la taille de page affichée en haut. Ce qui compte n'est pas Pages free, mais la pression mémoire et le rythme de variation. Swapins et Swapouts sont cumulés depuis le démarrage, donc un grand nombre isolé ne prouve pas un problème en cours. Exécutez la commande deux fois pendant le ralentissement, ou utilisez le Moniteur d'activité pour voir si le swap et la pression continuent d'augmenter.

La meilleure vue d'ensemble est la pression mémoire dans l'onglet Mémoire du Moniteur d'activité. Le guide mémoire d'Apple définit le vert comme une utilisation efficace, le jaune comme une pression possible et le rouge comme un besoin de plus de RAM. Lisez ce graphique avec la tendance du swap et la liste des applications, pas le seul chiffre de mémoire libre.

Trouver le vrai goulot d'étranglement

Ouvrez le Moniteur d'activité et parcourez ses onglets dans l'ordre, ou utilisez la ligne de commande :

• CPU : triez par usage avec top -o cpu dans Terminal, ou l'onglet CPU du Moniteur d'activité. Notez que le %CPU est par cœur, donc une valeur au-dessus de 100 % signifie qu'un processus utilise plusieurs cœurs, ce qui est normal pour une compilation ou un export, et suspect pour une app au repos.
• Mémoire : le graphique de pression, comme ci-dessus.
• Capacité disque : exécutez df -h /. APFS utilise l'espace libre pour le swap et les fichiers temporaires, et un disque presque plein peut bloquer des mises à jour ou laisser une charge de travail sans place temporaire. Il n'existe pas de pourcentage de sécurité universel : comparez la capacité disponible à la tâche qui échoue. Si c'est votre problème, trouvez ce qui remplit le disque et libérez de l'espace.
• E/S disque : dans l'onglet Disque du Moniteur d'activité, triez par Octets écrits ou Octets lus et observez le graphique pendant la pause. iostat -w 1 offre une vue live en ligne de commande. Une sync, une sauvegarde, une compilation ou un disque externe défaillant peut provoquer de la latence même quand il reste beaucoup de capacité.
• Chaleur : traité ci-dessous.
• Latence réseau ou de service : si seule une app cloud est lente alors que les apps locales restent réactives, vérifiez son activité réseau et l'état du service avant de modifier le Mac. Toute interaction lente n'est pas un goulot matériel.

Ces lectures distinguent un goulot système d'une seule app lente. Deviner avec un nettoyage générique peut changer plusieurs variables et masquer la vraie cause.

Un processus hors de contrôle

Si le CPU est saturé, top -o cpu place le coupable en tête. Une app bloquée, un client de sync qui rescane, ou un helper d'arrière-plan coincé dans une boucle sont les cas habituels. Si vous le reconnaissez comme sûr à terminer, quittez-le. S'il se relance en quelques secondes, un job launchd le maintient (voir la dernière section), et quitter le processus seul ne tiendra pas.

Méfiez-vous des processus système. Une montée de kernel_task est souvent le système qui utilise délibérément du temps CPU pour ralentir la puce quand elle chauffe, pas un bug à tuer. C'est un symptôme thermique, pas un problème de mémoire ou d'app.

Bridage thermique

Quand un Mac chauffe, la puce abaisse sa fréquence d'horloge pour refroidir, et le travail lourd devient pâteux. Vous pouvez le confirmer plutôt que de le deviner :

pmset -g therm

Cela rapporte l'état d'avertissement thermique et de performance enregistré lorsque macOS l'expose. Pour un échantillon détaillé de puissance et de pression thermique :

sudo powermetrics --samplers thermal,cpu_power -n 1

Interprétez les tendances sous la même charge de travail plutôt que de traiter une température comme une limite universelle. Si le bridage est le goulot, le correctif est la charge, le flux d'air ou le service, pas le nettoyage de cache. Un ventilateur bruyant peut être un indice, mais les Mac sans ventilateur peuvent aussi brider, et pourquoi le ventilateur de votre MacBook est bruyant couvre ce qu'il faut faire.

Spotlight et éléments d'ouverture

Deux causes d'arrière-plan méritent d'être écartées. Après une mise à jour macOS, une migration ou un gros déplacement de fichiers, Spotlight peut reconstruire une partie de son index. mdutil -s / indique si l'indexation est activée, pas si une reconstruction est en cours. Un CPU soutenu de mds ou mdworker plus les E/S disque et l'interface de progression de Spotlight fournissent le contexte. La durée dépend du volume de données, de la vitesse de stockage, des permissions et des modifications répétées de fichiers : il n'y a pas de promesse fiable d'« une heure ».

L'autre est la charge au démarrage. Réglages Système > Général > Ouverture et extensions sépare les apps ouvertes à la connexion des logiciels autorisés à s'exécuter en arrière-plan. Ceux-ci peuvent utiliser Service Management, launchd, des extensions ou des helpers d'app. Désactivez un élément connu à la fois et confirmez que l'app propriétaire fonctionne encore.

Sous le capot : comment un moniteur lit cela sans l'aggraver

Vous pouvez sauter cette partie, mais elle explique pourquoi le conseil mémoire ci-dessus est juste, et pourquoi un moniteur live ne devient pas lui-même l'un de vos processus lents. Le CLI open source de Mole (cmd/status) et l'app Mac native utilisent des collecteurs séparés, mais les deux séparent les lectures rapides de l'enrichissement lent.

Le CLI complète la valeur de mémoire en cache que sa bibliothèque de métriques multiplateforme ne peut pas fournir sous macOS en analysant les pages file-backed de vm_stat et en multipliant par la taille de page rapportée. Il lit l'état de pression système via memory_pressure plutôt que de le dériver des octets libres. L'app native atteint la même réponse sans passer par le shell : elle lit les compteurs VM avec host_statistics64 et le niveau de pression via kern.memorystatus_vm_pressure_level.

Rester léger est l'autre moitié. Un moniteur qui remesurerait tout à chaque tick serait son propre problème de performance, aussi le collecteur échantillonne par niveaux :

Les chiffres bon marché (CPU, mémoire et réseau) se rafraîchissent environ une fois par seconde. L'enrichissement processus, GPU et disque tourne sur des ticks plus lourds, tandis que les sondes matériel et périphériques réutilisent des caches plus longs. Des historiques de taille fixe ne retiennent que les échantillons récents qui dessinent les sparklines. C'est ainsi qu'un HUD de barre de menus peut se mettre à jour en direct sans transformer le moniteur en charge de travail que vous essayez de diagnostiquer.

Où un outil aide

Tout ce qui précède se lit avec des commandes intégrées, et c'est le point : vous n'avez pas besoin d'une app pour diagnostiquer un Mac lent. Ce qu'une app vous épargne, c'est l'assemblage. La vue Statut de Mole affiche CPU, pression mémoire, disque, température et les processus principaux sur un seul écran, avec une lecture live dans la barre de menus, et un clic sur un processus explique ce qui l'a lancé, s'il maintient le Mac éveillé, et ce qu'il lit et écrit, le même détail launchd et E/S que vous rassembleriez autrement à la main. C'est un confort par rapport aux commandes, pas un substitut à leur compréhension.

Quoi que vous utilisiez, évitez les balayages « accélérer en un clic » qui modifient un état sans rapport. Vous ne créez pas de gain de performance durable en forçant un cache de fichiers utile hors de la RAM. Redémarrer peut être un diagnostic utile pour un processus bloqué et est requis par certaines mises à jour, mais macOS gère déjà mémoire et swap en continu.

Un diagnostic reproductible

Reproduisez le ralentissement, observez le CPU, la pression mémoire, la capacité disque, les E/S disque, l'état thermique et l'activité réseau, puis changez une variable. Remesurez sous la même charge de travail. Cela transforme « le Mac a l'air lent » en une cause falsifiable et empêche de prendre un redémarrage ou un nettoyage temporaire pour un correctif permanent.