Une file d'attente, pas un bug
L'indexeur suit le journal de modifications USN de NTFS, donc chaque événement massif sur les fichiers devient du travail d'indexation. Une mise à jour de Windows qui relit le volume système, une synchronisation OneDrive ou Teams qui rapatrie des milliers de fichiers, une sauvegarde restaurée ou un node_modules tout frais d'un développeur — chacun de ces événements met en file des centaines de milliers d'éléments. Indexer un élément coûte peu ; en indexer quelques centaines de milliers prend des heures, et c'est exactement ce que vous regardez dans le Gestionnaire des tâches.
L'autre classique, c'est Outlook : une grosse archive .pst ou .ost s'indexe élément par élément dans le même pipeline, et une archive de messagerie de 20 Go peut occuper l'indexeur la majeure partie d'une journée de travail. Ouvrez Options d'indexation et lisez la ligne d'état : un compteur énorme d'éléments restants avec un total indexé qui grimpe signifie un indexeur sain qui traite une file. Un compteur immobile, ou une base qui enfle jusqu'à l'absurde pendant que le processeur reste haut, désigne un index corrompu qui se reconstruit en boucle — le seul scénario qui réclame le bouton Régénérer.
- Outlook classique avec de gros fichiers .pst ou .ost — indexation élément par élément par le même service
- OneDrive, Teams ou une restauration de sauvegarde qui rapatrie des milliers de fichiers sur la machine
- Une mise à jour de Windows qui relit le volume système et revérifie l'index
- Arborescences de développeur : node_modules, sorties de build et .git avec des dizaines de milliers de petits fichiers
- Des outils qui parcourent les fichiers et touchent aux métadonnées, remettant tout le disque en file
- Une base Windows.edb ou Windows.db corrompue qui se reconstruit, enfle et se reconstruit encore
Dompter l'indexeur sans casser la recherche
Le geste le plus rentable, c'est la maîtrise du périmètre, pas du service. Dans Options d'indexation, cliquez Modifier et décochez chaque arborescence où vous ne cherchez jamais : dossiers de build, archives multimédias, le marécage de Téléchargements — puis laissez le changement se stabiliser. Pour les archives Outlook classiques, n'indexez que les magasins dans lesquels vous cherchez réellement, pas chaque .pst jamais branché. Après tout rétrécissement, offrez une nuit à l'indexeur : une file qui paraît infinie à 18 heures est souvent terminée au matin.
Désactiver le service de recherche pour tuer un pic de processeur est la mauvaise route. La recherche de l'Explorateur dans les dossiers indexés, les résultats du menu Démarrer et la recherche Outlook retombent en mode ralenti à parcours complet, et la file revient de toute façon dès que le service est réactivé. Si l'index est réellement corrompu — le symptôme de la boucle de reconstruction —, passez par Options avancées puis Régénérer dans Options d'indexation pour supprimer et refaire pousser la base une seule fois : cela coûte quelques heures de processeur une fois et coupe la boucle. Sur les serveurs à nombreux utilisateurs simultanés, l'indexeur tourne par personne, et plusieurs processus SearchIndexer.exe sont plusieurs files distinctes.
Questions et réponses
Pourquoi SearchIndexer.exe utilise-t-il autant de processeur ?
Il absorbe une file d'indexation — une archive de courrier neuve, une synchronisation OneDrive, la relecture du volume après une mise à jour — et Options d'indexation affiche la taille de la file directement.
Faut-il désactiver la recherche Windows pour arrêter la charge processeur ?
Non : la recherche dans l'Explorateur, le menu Démarrer et Outlook replonge en mode lent, et la file revient à la réactivation ; réduisez le périmètre indexé ou régénérez l'index corrompu.
Vérifiez le contenu avant l'achat.
L'essai unique de 30 minutes couvre les fonctions de base. Les fonctions marquées PRO restent verrouillées jusqu'à l'activation d'une licence payante.
À lire ensuite
Écrivez-nous: [email protected]