Vous ouvrez Activity Monitor parce que votre Mac semble lent — ventilateurs bruyants, voyant du disque qui clignote sans arrêt — et le processus en tête de la colonne CPU s’appelle mds_stores, souvent à 100 %, 200 %, ou plus. L’arrêter paraît mal indiqué ; attendre semble être une perte de temps. Contrairement à une application qui se comporte mal, il peut s’agir ici de travail légitime — ou d’un processus bloqué. Ce guide vous donne une méthode claire pour distinguer les deux, puis détaille les correctifs qui fonctionnent vraiment.
Réponse rapide
mds_stores est le processus « worker par volume » de Spotlight, l’index de recherche de macOS. Une utilisation CPU élevée signifie en général du vrai travail : indexation initiale après une installation ou une mise à jour, un disque externe fraîchement monté, du churn dû à la synchronisation cloud, ou un workflow de développement qui crée des milliers de petits fichiers. Trois signaux suggèrent qu’il est bloqué plutôt qu’en train de travailler :
- Il tourne depuis plus de 24 heures sur le même volume, sans progression visible.
- Aucun déclencheur récent n’est actif — pas de synchro cloud en cours, pas de grosse copie de fichiers, pas de disque fraîchement monté — et pourtant la CPU et le disque restent élevés pendant des heures.
- Il boucle sur les mêmes fichiers, encore et encore.
Le panneau Open Files (Fichiers ouverts) de ProcXray affiche exactement les chemins que mds_stores est en train de lire — le moyen le plus rapide d’identifier le déclencheur. L’inspecteur de processus d’Activity Monitor liste lui aussi les fichiers ouverts, mais sous forme de boîte de dialogue statique sans recherche ni historique — pas l’idéal pour trier en temps réel des milliers de chemins d’indexation. Le panneau de ProcXray résout souvent le diagnostic en quelques secondes.
Qu’est-ce que mds_stores ?
mds_stores est l’un des trois processus qui composent Spotlight sur macOS :
mds— le coordinateur du serveur de métadonnées. Il se trouve à/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds. Il y en a un seul par système.mds_stores— un processus par volume indexé, qui détient le store d’index sur disque. Votre SSD interne en a un ; chaque disque externe indexé en a un ; certains points de montage réseau en ont également un.mdworker_shared(parfoismdworker) — les processus worker qui ouvrent chaque fichier, extraient les métadonnées (texte, EXIF, ID3, propriétés de documents, etc.) et renvoient le résultat àmds_stores.
Si vous voyez plusieurs processus mds_stores dans Activity Monitor, c’est normal — cela signifie simplement que plusieurs volumes sont en cours d’indexation. Un Mac inactif avec un index complet tourne mds_stores à environ 0–5 % de CPU. Le modèle par volume implique aussi qu’un mds_stores lié à un disque externe peut s’emballer indépendamment de celui du volume de démarrage.
À propos des pourcentages : dans Activity Monitor, 100 % équivaut à un cœur CPU complet. Sur un Mac multi-cœurs, un seul processus peut afficher bien au-delà de 100 %. Donc mds_stores à 250 % occupe environ deux cœurs et demi.
Recadrage : travailler vs être bloqué
C’est le recadrage le plus important de ce guide. Contrairement à WindowServer, qui est toujours en aval d’une application qui le sollicite, mds_stores consommant du CPU signifie en général que l’indexeur est légitimement occupé — et un travail légitime a une fin. La question diagnostique n’est donc pas « qu’est-ce qui ne va pas avec mds_stores ? » mais :
Est-ce une indexation transitoire qui va se terminer, ou l’indexeur est-il bloqué ?
Une grille rapide :
- Probablement en travail (attendre) — démarrage après un événement connu (mise à jour de l’OS, grosse copie de fichiers, montage d’un disque externe, gros
git pull) ; CPU élevé mais en baisse sur quelques minutes à quelques heures ;mdutil -sindique une indexation en cours. - En travail mais lent — une application de synchronisation cloud est active en arrière-plan, ou vous avez un dossier rempli de petits fichiers qui changent en permanence (artefacts de build, répertoires de logs, boîtes mail).
- Probablement bloqué (intervenir) — tourne depuis plus de 24 heures ;
mdutilindique l’indexation terminée ; le processus boucle sur les mêmes fichiers ; ou il repart immédiatement en CPU élevé après avoir été tué. - Probablement un index corrompu (intervenir) — démarre juste après un arrêt forcé, un kernel panic, ou une réparation de volume APFS.
Cette grille structure le reste de l’article : identifier le déclencheur, vérifier si ça va se terminer, appliquer le bon correctif.
Ce qui déclenche les pics de mds_stores
Six déclencheurs courants, classés grosso modo par fréquence :
1. Nouvelle installation ou mise à jour de macOS
La première fois que Spotlight indexe un volume, il doit extraire les métadonnées de chaque fichier. Sur un Mac récemment configuré, cela prend 30 minutes à plusieurs heures, selon la taille du répertoire personnel et le nombre de photos ou de documents. Les grosses mises à jour de macOS déclenchent parfois une réindexation partielle.
2. Un nouveau disque externe, ou une grosse copie de fichiers
Chaque nouveau fichier nécessite une extraction de métadonnées. Monter un disque externe de 1 To rempli de contenu mixte peut occuper mds_stores pendant une à plusieurs heures. Une grosse copie sur le volume de démarrage — par exemple restaurer un dossier depuis une sauvegarde — a le même effet.
3. Churn de synchronisation cloud
C’est la cause unique la plus fréquente de « mds_stores ne s’arrête jamais ». iCloud Drive, Dropbox, OneDrive, Google Drive et Box créent, modifient et suppriment des fichiers en arrière-plan. Chacun de ces changements est un événement du système de fichiers que Spotlight doit suivre. Deux comportements sont notoires : Optimiser le stockage du Mac d’iCloud (qui évince et re-télécharge les fichiers) et Fichiers à la demande de OneDrive (même idée). Chaque cycle d’éviction/re-téléchargement réindexe le fichier concerné.
4. Workflows de développement qui génèrent des milliers de petits fichiers
npm install / yarn install (le fameux node_modules), les builds Xcode qui écrivent dans ~/Library/Developer/Xcode/DerivedData, un git checkout sur une grosse branche, l’extraction d’images Docker, les mises à jour Homebrew — tous génèrent de grosses rafales d’événements du système de fichiers. Spotlight tente de tout indexer.
5. Premier backup Time Machine ou gros snapshot
Time Machine partage le même flux d’événements du système de fichiers que Spotlight surveille. Un premier backup ou une opération de snapshot importante peuvent interagir avec mds_stores et faire monter les deux processus simultanément.
6. Index corrompu nécessitant une reconstruction
Après un arrêt forcé, un kernel panic, un problème de volume APFS, ou une réparation de disque ratée, l’index Spotlight peut devenir incohérent. mds_stores se met alors à le reconstruire intégralement — opération qui ressemble à une indexation initiale, mais qui démarre sans raison apparente.
Quelques applications à pointer du doigt comme sources fréquentes de churn : la synchronisation Adobe Creative Cloud, Backblaze, Carbon Copy Cloner, et tout antivirus qui scanne à l’accès. Si l’un d’eux tourne, soupçonnez-le en premier.
Comment savoir si ça va se terminer tout seul
Activity Monitor est le point de départ naturel, mais sa vue des fichiers ouverts est une fenêtre modale statique — sans recherche ni historique — et c’est précisément le détail qui résout le plus souvent ce cas : quels chemins de fichiers mds_stores est en train de lire, et comment ils évoluent dans le temps.
Étape 1 : Vérifier si l’indexation est activée
Ouvrez Terminal et exécutez :
mdutil -s /
La sortie est l’une de :
Indexing enabled— l’indexation Spotlight est activée pour ce volumeIndexing and searching disabled— l’indexation est désactivée ; un CPU élevé ici serait inhabituelError: unknown indexing state— l’index est dans un mauvais état ; signal fort qu’il faut le reconstruire
Répétez la commande pour chaque volume (mdutil -s /Volumes/External).
Important : mdutil -s indique uniquement si l’indexation Spotlight est activée sur le volume — il ne rapporte pas la progression, ni si l’indexation est en train d’avancer. Pour savoir si elle progresse encore, combinez-le avec : la tendance des lectures disque dans l’Étape 2, l’évolution des chemins de fichiers dans le panneau Open Files dans le temps (Étape 3), et le fait que la fenêtre de recherche Spotlight affiche encore ou non une barre d’état « Indexation en cours… ».
Étape 2 : Premières observations dans Activity Monitor
Onglet CPU → trier par CPU et confirmer que mds_stores est en tête. Passez à l’onglet Disque et triez par Octets lus. Si mds_stores domine la lecture disque, c’est qu’il est en train de scanner activement des fichiers (ce à quoi ressemble l’indexation). Surveillez cinq minutes — la CPU baisse, stagne ou monte ?
Étape 3 : Identifier ce qu’il indexe, avec ProcXray
ProcXray est conçu spécifiquement pour ce genre de diagnostic transversal aux ressources :
- Le panneau Open Files révèle les chemins de fichiers exacts que
mds_storesa actuellement ouverts. C’est la fonctionnalité décisive pour ce problème. Si les chemins se regroupent sous~/Library/Mobile Documents/, vous avez un déclencheur iCloud ; sous~/Dropbox/ou~/OneDrive/, la synchro cloud correspondante ; sousnode_modules/ouDerivedData/, un workflow de développement. - Resource History vous laisse remonter sur des heures de données CPU et I/O. Une tendance à la baisse signifie que ça va se terminer ; une ligne plate et soutenue pendant des heures après la fin de l’événement déclencheur signifie que c’est bloqué.
- La colonne I/O par processus trie tous les processus par lectures et écritures disque, confirmant que
mds_storesest bien le moteur des I/O et non un coup de chance. - La vue Process Tree affiche la hiérarchie
mds→mds_stores→mdworker_sharedet vous permet de voir si les workers travaillent réellement ou tournent à vide.
Pour plus de détails sur les lacunes d’Activity Monitor dans ce genre de débogage, voir ProcXray vs Activity Monitor.
Étape 4 : Test A/B en retirant les déclencheurs suspects
Une fois une hypothèse formulée, éjectez les disques externes un par un. Mettez en pause les apps de synchro cloud une à une. Quittez les outils de build. Après chaque changement, surveillez mds_stores pendant une minute. Une baisse nette confirme la cause — sans redémarrage, sans interrompre votre session.
Correctifs étape par étape
À appliquer dans l’ordre — du moins coûteux et perturbant au plus.
1. À la première observation, attendre 30 minutes à 2 heures
Le correctif le plus souvent oublié. La plupart des indexations se terminent dans cette fenêtre. Branchez le Mac sur secteur et laissez-le tourner. Revenir devant un Mac dont l’index est terminé est presque toujours le bon résultat.
2. Ajouter le dossier coupable à la Confidentialité de Spotlight
Réglages Système → Spotlight → Confidentialité → glisser le dossier. Spotlight cesse de l’indexer. Les dossiers qui valent le plus la peine d’être exclus :
- les répertoires
node_modules - les sorties de build (
build/,dist/,target/,DerivedDatade Xcode) - les répertoires temporaires, les répertoires de logs, les gros dossiers d’archives que vous ne cherchez jamais
Le compromis : ces fichiers ne remonteront pas dans la recherche Spotlight. Pour les artefacts de build et node_modules, c’est presque toujours le bon choix.
3. Mettre en pause la synchro cloud temporairement
Si le panneau Open Files a montré que mds_stores lit dans un dossier iCloud, Dropbox, OneDrive ou Google Drive, mettez cette app en pause. Si mds_stores se calme en quelques minutes, vous avez confirmé la cause. À long terme, soit acceptez le coût d’indexation, soit excluez le dossier cloud de Spotlight via Confidentialité. Si « Optimiser le stockage du Mac » d’iCloud est activé et que vous avez l’espace disque, envisagez de le désactiver — le cycle d’éviction/re-téléchargement permanent est une cause fréquente de boucles.
4. Désactiver l’indexation sur un volume spécifique
Pour les disques externes que vous ne cherchez pas via Spotlight (par exemple un scratch disk, une archive média). Ne désactivez pas l’indexation sur un disque de sauvegarde Time Machine — Time Machine s’appuie sur l’indexation Spotlight de ce volume pour fonctionner.
sudo mdutil -i off /Volumes/External
À réactiver plus tard avec sudo mdutil -i on /Volumes/External.
5. Forcer une reconstruction propre quand l’index est corrompu
Si mdutil -s a rapporté « unknown indexing state », ou si vous avez écarté tous les déclencheurs mais que mds_stores continue à tourner, effacez et reconstruisez l’index :
sudo mdutil -E /
Comptez 30 minutes à plusieurs heures de CPU et de disque élevés pendant la reconstruction — c’est la reconstruction elle-même, pas un problème. À utiliser quand vous avez confirmé une corruption, pas comme premier réflexe.
6. En dernier recours : tuer mds_stores directement
macOS le relance proprement en quelques secondes. Cela ne corrige pas le déclencheur, mais peut interrompre une boucle qui s’emballe le temps d’enquêter. Via « Forcer à quitter » d’Activity Monitor, ou :
sudo killall mds_stores
Non recommandé : désactiver Spotlight de façon permanente avec sudo mdutil -a -i off. Vous perdez la recherche Spotlight, la recherche dans Mail, et toute application qui dépend des API de métadonnées sous-jacentes. Presque jamais la bonne solution — préférez exclure les dossiers bruyants via Confidentialité.
Pour un triage performance plus large quand mds_stores n’est pas le seul suspect, voir comment réparer un Mac lent en tuant les bons processus.
FAQ
Est-ce que je peux tuer mds_stores sans risque ?
Oui. macOS le relance automatiquement en quelques secondes. Le tuer interrompt ce qu’il était en train de faire, mais n’endommage ni l’index ni vos données. Le piège : si vous le tuez et que la même charge le ramène immédiatement à un CPU élevé, vous n’avez rien corrigé — vous avez seulement confirmé que la cause est persistante et qu’il faut appliquer un vrai correctif de la liste ci-dessus.
Combien de temps devrait durer une indexation normale ?
Indexation initiale sur un Mac récemment configuré : typiquement 30 minutes à 2 heures, jusqu’à 4–6 heures pour des répertoires personnels très volumineux. Indexation d’un disque externe 1 To fraîchement monté : grosso modo proportionnelle au nombre de fichiers, souvent 1 à 4 heures. Indexation après une rafale de synchro cloud : quelques minutes. Une activité soutenue au-delà de 24 heures sur un ensemble de fichiers stable est inhabituelle et indique soit un processus bloqué, soit une source de churn incontrôlée.
Pourquoi mds_stores réindexe-t-il sans cesse les mêmes fichiers ?
Presque toujours à cause d’une application de synchro cloud ou d’un outil de sauvegarde qui touche les mêmes fichiers à répétition. Optimiser le stockage du Mac d’iCloud Drive est un coupable fréquent — il évince et re-télécharge les fichiers, et chaque cycle réindexe le fichier concerné. Vérifiez Réglages Système → [Votre nom] → iCloud → iCloud Drive → Optimiser le stockage du Mac. Le désactiver (si vous avez l’espace disque) résout souvent la boucle.
Est-ce que je devrais désactiver Spotlight de façon permanente ?
Non, sauf si vous avez une raison très spécifique et que vous n’utilisez ni Spotlight, ni Mail, ni aucune fonction de recherche système. Beaucoup d’applications dépendent des API de métadonnées sous-jacentes — désactiver Spotlight casse bien plus que l’icône loupe. Exclure les dossiers bruyants via Confidentialité vous donne l’essentiel du bénéfice pour quasiment aucun coût.
Pourquoi mds_stores utilise le disque mais à peine la CPU ?
L’indexation est largement bound par les I/O. mds_stores passe l’essentiel de son temps à lire le contenu des fichiers depuis le disque, avec de brèves rafales CPU pour parser les métadonnées. Disque élevé + CPU faible est la signature normale de l’indexation. Si la CPU est aussi élevée, c’est que l’indexeur traite beaucoup de petits fichiers — typique de node_modules, des boîtes mail ou des objets git.
Sources et références
- Assistance Apple — Modifier les réglages de Spotlight sur le Mac
man mdutil(page de manuel macOS intégrée) — référence officielle de la commandemdutil- WindowServer et utilisation CPU élevée sur Mac
- kernel_task et utilisation CPU élevée sur Mac
- ProcXray vs Activity Monitor
- Comment surveiller les processus sur macOS : un guide complet pour développeurs
Télécharger ProcXray gratuitement → — voyez exactement quels fichiers mds_stores est en train d’indexer. macOS Sonoma+, Apple Silicon & Intel.