# Pourquoi le Mac est lent et comment le diagnostiquer

> Mesurez CPU, pression mémoire, capacité de stockage, I/O disque, état thermique et latence réseau pendant le ralentissement.

Published: 2026-07-04 | Updated: 2026-08-08

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](https://support.apple.com/guide/activity-monitor/actmntr34865/mac)
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

<figure class="blog-diagram">
  <img src="https://mole.fit/img/en/status.webp" width="2584" height="1741" loading="lazy" alt="Un tableau de bord système avec des tuiles pour le CPU à 6 pour cent et 44 degrés, le GPU à 1 pour cent, la mémoire à 55 pour cent avec une pression de 18 pour cent, le disque, le réseau et le ventilateur, au-dessus d'une liste des processus principaux triés par CPU et mémoire">
  <figcaption>Les chiffres qui expliquent un Mac lent sur un seul écran : charge et température du CPU, pression mémoire, et les processus qui consomment le plus de ressources. C'est la vue Statut de Mole.</figcaption>
</figure>

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](https://mole.fit/fr/blog/how-to-find-large-files-on-mac) et
  [libérez de l'espace](https://mole.fit/fr/blog/how-to-free-up-space-on-mac).
- **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.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/performance-bottlenecks.webp" width="1360" height="454" loading="lazy" alt="Une charge se ramifiant en saturation CPU, pression mémoire, entrées et sorties disque, et freinage thermique avant de converger en latence">
  <figcaption>Contention CPU, pression mémoire, E/S disque et limites thermiques se traduisent toutes par de la latence, mais chacune demande un correctif différent.</figcaption>
</figure>

## 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](https://mole.fit/fr/blog/macbook-fan-loud-overheating)
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](https://github.com/tw93/Mole) 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 :

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/tiered-metrics-sampling.webp" width="1360" height="454" loading="lazy" alt="Des métriques système rapides, lentes et ponctuelles passent par des collecteurs ou caches concurrents, fusionnent en un instantané, entrent dans un tampon circulaire, et s'affichent dans la vue d'état et le HUD de la barre des menus">
  <figcaption>Les implémentations sont séparées, mais le schéma de planification est le même : les métriques rapides se rafraîchissent en direct, les sondes lentes réutilisent des résultats en cache, et un instantané fusionné alimente les lectures courantes plus un historique borné.</figcaption>
</figure>

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](https://mole.fit/) 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.

---

Canonical HTML page: https://mole.fit/fr/blog/why-is-my-mac-so-slow
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
