Hazel Contents Contain ne fonctionne pas : pourquoi, et comment le corriger

Si la condition « Contents Contain » de Hazel ne trouve pas vos fichiers, regardez d'abord ce qu'elle lit réellement : pas le fichier, mais l'index Spotlight de ce fichier. Quand Spotlight n'a pas encore indexé un document — un fichier récent, synchronisé depuis le cloud, ou un dossier exclu de la recherche — la condition ne trouve rien, même si le texte est bien présent dans le document. Le forum d'assistance de Noodlesoft donne la solution directement : basculez la règle sur Contents Contain Match, qui lit le fichier lui-même et se passe entièrement de Spotlight. C'est plus lent. Noodlesoft le dit sans détour. Mieux vaut lent et juste que rapide et faux.

Ce correctif résout la majorité des cas en moins d'une minute. La suite de cet article explique pourquoi le problème survient, trois autres vérifications utiles si le changement de condition ne suffit pas à lui seul, et les cas où la correspondance de contenu de Hazel reste supérieure à toute alternative, File Arbor compris.

Pourquoi la condition « Contents Contain » de Hazel cesse-t-elle de fonctionner ?

Hazel a deux conditions distinctes pour vérifier ce qui se trouve à l'intérieur d'un fichier, et elles fonctionnent de façon complètement différente. Contents Contain demande à Spotlight si un mot apparaît dans un fichier — elle n'ouvre jamais le fichier lui-même. Contents Contain Match ouvre le fichier et cherche directement dans le texte.

C'est une conception raisonnable. L'index de Spotlight est rapide, et la plupart du temps il est exact. Le problème se situe dans l'écart entre « le fichier existe » et « Spotlight a fini de l'indexer ». Un fichier déposé dans un dossier surveillé il y a quelques secondes n'est peut-être pas encore cherchable. Un fichier synchronisé depuis iCloud Drive, Dropbox ou OneDrive peut rester non indexé pendant plusieurs minutes, surtout en plein téléchargement ou avec un client de synchronisation en version bêta. Un fichier sur un disque externe, un partage réseau, ou tout ce que couvrent les exclusions de confidentialité Spotlight de macOS n'apparaîtra pas du tout dans une recherche Spotlight — ce qui veut dire que Contents Contain ne le verra pas non plus, quel que soit le nombre de fois où la règle s'exécute.

Rien de tout cela n'est un bug dans votre règle. La règle interroge un index, et c'est l'index qui est en retard. Hazel exécute la règle correctement à chaque fois ; il reçoit simplement un « non » de Spotlight là où la réponse honnête serait « pas encore ».

Le vrai correctif : passer à « Contents Contain Match »

Ouvrez la règle, repérez la condition de contenu, et changez le menu déroulant de Contents Contain à Contents Contain Match. C'est tout le correctif pour la plupart des utilisateurs, et c'est celui vers lequel le forum de Noodlesoft renvoie systématiquement quand quelqu'un signale un échec de correspondance qui se révèle être un problème d'indexation.

Contents Contain Match ne pose aucune question à Spotlight. Il ouvre le fichier, en extrait le texte, et le cherche au moment même où la règle s'exécute. Aucun index à rattraper, aucune liste d'exclusions dans laquelle trébucher, aucune attente d'un processus en arrière-plan. Le coût, c'est la vitesse — lire un fichier directement prend plus de temps que consulter une table de correspondance — mais pour la plupart des volumes de dossiers Téléchargements ou Documents, cette différence ne se remarque pas.

Si vous gérez des dizaines de règles utilisant toutes Contents Contain, il n'est pas nécessaire de tout reconstruire depuis zéro. Ouvrez chacune, changez le seul menu déroulant concerné, et enregistrez. C'est fastidieux pour une grande bibliothèque de règles, mais c'est une modification mécanique, pas une refonte.

Trois autres vérifications avant de refaire toutes vos règles

Basculer vers Contents Contain Match corrige le symptôme. Si vous voulez comprendre pourquoi Spotlight a raté le fichier en premier lieu — ou si vous préférez conserver la condition la plus rapide là où c'est sans risque — ces trois vérifications couvrent le reste des causes réelles.

1. Réindexer le dossier concerné. Cherchez un mot du fichier avec Spotlight ou une fenêtre du Finder. Si le fichier n'apparaît pas, Spotlight ne l'a réellement pas encore indexé. Apple documente un correctif ciblé : ajoutez le dossier à la liste de confidentialité Spotlight, attendez quelques secondes, puis retirez-le. Spotlight interprète ce retrait comme un signal pour réindexer ce dossier depuis le début, ce qui est plus rapide que de réindexer tout un volume.
2. Vérifier la liste d'exclusions elle-même. Ouvrez Réglages Système, puis Spotlight, et repérez la liste des emplacements exclus de la recherche (Search Privacy ; sur les versions antérieures de macOS, elle se trouve dans les préférences de Spotlight) et confirmez que le dossier surveillé — ainsi que tout dossier parent, disque externe ou volume réseau sur lequel il se trouve — n'y figure pas déjà. Un dossier peut s'y retrouver par accident, notamment après une restauration de sauvegarde ou une migration vers un nouveau Mac.
3. Confirmer que le fichier possède réellement une couche de texte. Ouvrez le PDF dans Aperçu et essayez de sélectionner une ligne de texte au curseur. Si rien ne se surligne, le fichier n'a pas de couche de texte — c'est une image scannée ou une photo — et aucune condition de Hazel ne le trouvera sans OCR. Notre guide sur la couche de texte d'un PDF détaille ce test pas à pas, sur Mac comme sous Windows.

Ce que Hazel 6 sait faire et que File Arbor ne fait pas

Autant le dire clairement, car c'est la réponse honnête : si vos fichiers sont surtout des PDF chiffrés, Hazel convient mieux à ce travail, et rien ci-dessous ne change ce constat.

Hazel 6 a ajouté une reconnaissance de texte à la volée — la documentation de Noodlesoft la décrit comme une OCR qui s'exécute sur les images et sur les PDF qui ne contiennent pas déjà de couche de texte, avant qu'une règle ne tente de les faire correspondre. Cela veut dire qu'une facture scannée ou la photo d'un reçu prise au téléphone, un fichier sans aucun texte extractible, peut malgré tout correspondre à une règle Hazel. Hazel 6 a aussi ajouté la possibilité de fournir un mot de passe pour un PDF chiffré, si bien qu'un document verrouillé n'échoue plus silencieusement.

Avant la version 1.3.0, File Arbor ne faisait ni l'un ni l'autre. Depuis, une règle Pro réglée pour lire aussi les documents scannés exécute l'OCR sur les PDF scannés et sur les images JPEG, PNG et TIFF, en lisant la première et la dernière page de chacun. Les PDF protégés par mot de passe restent hors de portée — il n'y a pas d'option de mot de passe — et c'est une vraie lacune, pas une note de bas de page mineure. C'est la raison la plus claire pour laquelle un utilisateur Mac qui a des documents chiffrés devrait rester sur Hazel plutôt que d'en changer.

« Contents Contain » et « Contents Contain Match » en un coup d'œil

Où File Arbor a sa place — et où il ne l'a pas

Si ce qui vous a réellement amené ici, c'est l'envie d'avoir le même type de règle de contenu sans dépendance à Spotlight à surveiller, c'est le seul endroit où File Arbor se rapproche de Contents Contain Match plutôt que de Contents Contain. Sa condition « le contenu contient » — réservée à la version Pro — lit directement le texte d'un fichier : aucun index de recherche n'entre en jeu, sur aucun des deux systèmes d'exploitation où l'application tourne. Une règle qui correspond à societe correspond aussi à société, puisque la comparaison ignore la casse et les accents, et elle fonctionne de la même façon sous Windows et sur macOS. Elle lit les PDF avec une couche de texte, les fichiers DOCX et le texte brut, et depuis la version 1.3.0 les PDF scannés et les photos quand la règle est réglée pour les lire, mais les mêmes lacunes que partout ailleurs s'appliquent : pas de feuilles de calcul, pas d'en-têtes, pieds de page ou notes de bas de page de DOCX, et pas de PDF chiffrés.

C'est ce dernier point qui constitue la vraie différence à retenir. Les conditions de contenu de Hazel sont réservées à macOS. Celles de File Arbor sont multiplateformes — la même règle, surveillant un dossier, sous Windows ou sur Mac, depuis une seule application. Pour un usage exclusivement Mac, ce n'est pas une raison de changer : Hazel fait déjà ce dont vous avez besoin, et en fait davantage une fois les PDF chiffrés pris en compte. Cela ne compte que si vous gérez aussi des règles sur une machine Windows et que vous voulez qu'elles correspondent.

Il vaut aussi la peine d'être précis sur ce que font les conditions de contenu de File Arbor : elles choisissent un dossier de destination, rien d'autre. Extraire du texte d'un document pour l'intégrer à un nouveau nom de fichier est une fonctionnalité Pro distincte, ajoutée dans la version 1.3.0 : vous cliquez une fois, sur un document d'exemple, sur une valeur telle qu'une date de facture, et la règle construit à partir d'elle le nom de fichier et les dossiers. Hazel peut le faire aussi, grâce à un jeton de capture. Pour un panorama plus large de ce que le classement par contenu peut et ne peut pas faire selon les outils, voir notre guide sur le tri des fichiers par contenu.

Quel correctif essayer en premier ?

« Ma règle fonctionnait hier et ne trouve plus rien aujourd'hui, même dossier, mêmes fichiers. » Basculez d'abord cette règle sur Contents Contain Match. C'est presque toujours un problème d'indexation, et la variante directe le contourne entièrement.

« Le fichier est sur OneDrive, Dropbox, ou un disque externe. » Vérifiez d'abord la confidentialité Spotlight pour ce volume. Les clients de synchronisation cloud et les disques externes sont les endroits les plus courants où un dossier se retrouve exclu sans que personne ne l'ait fait exprès.

« J'ai copié-collé moi-même le texte du PDF, il est bien dedans. » Éliminez ensuite l'hypothèse de la couche de texte — le test de sélection dans Aperçu prend dix secondes et indique immédiatement si l'OCR est réellement l'élément manquant.

« J'ai des documents scannés ou des PDF protégés par mot de passe, rien de tout cela ne s'applique. » Restez sur Hazel et utilisez ses options d'OCR et de mot de passe. Un correctif Spotlight ne vous y mènera pas, et si File Arbor Pro lit les scans depuis la version 1.3.0, il ne peut pas ouvrir les PDF protégés par mot de passe — c'est un véritable avantage de Hazel, et cet article ne prétend pas vous en dissuader.

« Je veux la même règle de contenu sur une machine Windows aussi. » C'est le seul cas où File Arbor mérite un coup d'œil — non pas comme remplaçant de Hazel, mais comme moyen d'exécuter une règle équivalente sur une seconde plateforme que Hazel n'atteint pas.

Garder des règles de contenu fiables sur la durée

Par défaut, utilisez Contents Contain Match pour toute règle qui surveille un dossier synchronisé avec un service cloud ou situé sur un support amovible — le léger coût en vitesse vaut la peine de ne plus jamais se demander si Spotlight a rattrapé son retard. Réservez Contents Contain aux dossiers sur votre disque interne principal, là où vous avez confirmé que l'indexation suit le rythme, puisque c'est l'option la plus rapide quand l'index est réellement à jour.

Testez une nouvelle règle de contenu sur un fichier dont vous savez déjà qu'il correspond, avant de lui faire confiance sur les prochaines arrivées. Une règle qui ne fait silencieusement rien est bien plus difficile à remarquer qu'une règle qui se déclenche à tort, et les conditions de contenu sont précisément le genre de règle qui échoue silencieusement quand l'extraction de texte sous-jacente — celle de Spotlight ou une lecture directe — revient bredouille.

FAQ

Pourquoi la condition « Contents Contain » de Hazel ne trouve-t-elle pas mes fichiers ?

Contents Contain interroge l'index Spotlight, pas le fichier lui-même. Si Spotlight n'a pas indexé le fichier — parce qu'il est récent, synchronisé depuis le cloud, sur un disque externe, ou que le dossier est exclu dans la confidentialité Spotlight — la condition ne trouve rien, même si le texte est clairement présent dans le document. Le forum de Noodlesoft confirme qu'il s'agit de la cause la plus fréquente.

Quelle est la différence entre Contents Contain et Contents Contain Match dans Hazel ?

Contents Contain interroge l'index Spotlight et va vite ; Contents Contain Match lit le fichier directement, plus lentement, mais sans aucune dépendance à Spotlight. Noodlesoft recommande la seconde option chaque fois que la première rate un fichier qu'elle aurait dû trouver, car une lecture directe ne peut pas être trompée par un index périmé ou incomplet.

Comment corriger « Contents Contain » quand il ne fonctionne pas ?

Ouvrez la règle et changez la condition de Contents Contain à Contents Contain Match — c'est le correctif que recommande Noodlesoft lui-même, et il fonctionne parce que la variante Match lit directement le texte du fichier au lieu de s'appuyer sur Spotlight. Si cela ne suffit pas, vérifiez que Spotlight a bien indexé le dossier et que le fichier possède une vraie couche de texte, et non une simple image scannée.

Hazel peut-il lire des PDF scannés ou des photos de documents ?

Oui, depuis Hazel 6. Noodlesoft a ajouté une reconnaissance de texte à la volée, qui applique une OCR aux images et aux PDF sans couche de texte avant la vérification de la règle, ainsi qu'une option pour fournir un mot de passe sur les PDF chiffrés. Les versions antérieures de Hazel et la plupart des concurrents basés sur des règles ne lisent pas un fichier dépourvu de couche de texte ; File Arbor Pro le peut depuis la version 1.3.0, mais il n'a pas d'option de mot de passe.

File Arbor dépend-il de Spotlight comme Hazel ?

Non. Les conditions de contenu de File Arbor lisent directement le texte d'un fichier, comme Contents Contain Match chez Hazel, donc aucun index ne peut devenir périmé ni exclure un dossier. Le compromis est le même : lire le fichier est plus lent que consulter un index, mais cela ne dépend jamais de ce que Spotlight a ou non déjà traité.

File Arbor peut-il remplacer Hazel pour l'OCR ou les PDF chiffrés ?

Pour les scans, oui depuis la version 1.3.0, même si File Arbor Pro ne lit que la première et la dernière page ; pour les PDF chiffrés, non. File Arbor ne peut pas ouvrir un PDF protégé par mot de passe, donc un document chiffré ne correspondra jamais à une règle de contenu. Hazel 6 fait les deux. Si vos fichiers sont surtout des PDF chiffrés, Hazel reste le plus adapté ; l'avantage de File Arbor est d'exécuter les mêmes règles sous Windows et sur Mac, sans Spotlight.

Ce qu'il faut retenir

La condition Contents Contain de Hazel n'est pas cassée — elle répond honnêtement en fonction de ce que Spotlight a indexé, ce qui ne correspond pas toujours à ce qui se trouve réellement dans le fichier. Basculez la règle sur Contents Contain Match et l'écart lié à Spotlight disparaît entièrement. Si les PDF chiffrés font partie de votre quotidien, la gestion des mots de passe de Hazel 6 fait quelque chose qu'aucun correctif Spotlight et aucune règle File Arbor ne permettent aujourd'hui.

Si vous conservez aussi des fichiers sous Windows et souhaitez le même type de règle de contenu là-bas, le niveau gratuit de File Arbor suffit pour tester une règle sur vos propres fichiers avant de décider si elle mérite de s'ajouter à Hazel, pas de le remplacer. Voir la page tarifs pour ce que couvre la version Pro.