find Linux : syntaxe, exemples et audit de sécurité

La commande find Linux sert à rechercher des fichiers ou des dossiers dans une arborescence selon leurs attributs — nom, type, taille, date, permissions — puis à agir directement sur les résultats. Contrairement à locate, elle parcourt le système de fichiers en temps réel : aucune base indexée à maintenir, aucun décalage entre le résultat et l’état réel du disque.

À quoi sert la commande find Linux

find répond à une question précise : quels fichiers, dans cette arborescence, correspondent à tel critère ?

Elle se distingue de grep, qui cherche un motif dans le contenu des fichiers, et de locate, qui interroge une base de noms de fichiers mise à jour périodiquement par le système plutôt que de parcourir le disque à chaque appel. locate est plus rapide, mais peut ignorer un fichier créé après la dernière mise à jour de sa base ; find est plus lent sur de grosses arborescences, mais toujours exact.

Syntaxe de find Linux

La syntaxe de find Linux tient en trois blocs, toujours dans le même ordre :

find [chemin] [filtres] [action]

Bloc	Rôle
Chemin	Point de départ. Si omis, GNU find utilise le dossier courant (.). BSD et macOS exigent un chemin explicite.
Filtres	Critères de sélection (-name, -type, -size…). Sans filtre, find renvoie tout.
Action	Ce qu’il faut faire des résultats (-print, -delete, -exec…). Sans action explicite, -print est implicite.

Ce n’est pas un détail cosmétique : find évalue les arguments de gauche à droite selon les règles de précédence, jusqu’à ce que le résultat de l’expression soit connu. Une commande comme find /tmp -delete -name '*.tmp' supprime donc tout le contenu de /tmp, parce que -delete s’exécute avant que -name n’ait eu l’occasion de filtrer quoi que ce soit.

Rechercher par nom avec find Linux

Avec find Linux, -name compare le motif au nom du fichier, sensible à la casse. -iname fait la même chose en l’ignorant.

# Fichiers .log, quelle que soit la casse de l'extension
find . -iname "*.log"

# Fichier exact, dans /etc
find /etc -name "hosts"

Le motif doit toujours être entre guillemets. Sans eux, c’est le shell qui interprète l’astérisque avant que find ne le reçoive, ce qui produit des résultats imprévisibles selon les fichiers déjà présents dans le dossier courant.

-name compare le motif à la seule dernière composante du chemin. find . -name "conf" trouve donc bien ./etc/conf, c’est le fonctionnement normal. En revanche, un motif qui contient une barre oblique ne correspond jamais à rien : -name "etc/conf" ne renvoie aucun résultat. Pour raisonner sur le chemin entier, il faut -path "*/etc/conf".

Autre point à connaître : -name n’est pas un moteur d’expressions régulières. Pour une vraie regex, find propose -regex, qui compare l’intégralité du chemin et non le seul nom du fichier. Attention au dialecte : GNU find utilise par défaut les expressions régulières d’Emacs, pas les ERE auxquelles on s’attend.

C’est une cause d’échec fréquente ; -regextype posix-extended rétablit la syntaxe habituelle.

Rechercher par type, taille et date avec find Linux

Type

find /etc -type d -name "*.d"   # uniquement des dossiers
find . -type f -name "*.sh"     # uniquement des fichiers réguliers

Dans find Linux, -type accepte f (fichier régulier), d (dossier), l (lien symbolique), ainsi que b, c, p et s pour les types de fichiers spéciaux. GNU find permet de combiner plusieurs types dans une liste séparée par des virgules, une extension propre à GNU : -type f,l.

Une subtilité coûte régulièrement des heures de débogage : -type l teste le lien symbolique lui-même, pas sa cible. Si vous ajoutez l’option -L en tête de commande, find résout les liens avant de tester, et find -L . -type l ne remonte alors plus que les liens cassés — ceux dont la cible n’existe pas. C’est la manière la plus courte de faire l’inventaire des liens morts d’une arborescence.

Taille

find /var/log -type f -size +100M   # fichiers de plus de 100 Mio (M = 1024 Ko)
find . -type f -size -1000c         # fichiers de moins de 1000 octets

-size arrondit systématiquement à l’unité supérieure. C’est un piège documenté dans le manuel GNU lui-même : -size -1M ne matche que les fichiers vides, jamais les petits fichiers, parce qu’un fichier de 1 octet est déjà arrondi à 1 Mo. Pour raisonner en taille réelle, passez par le suffixe c (octets).

Les suffixes disponibles sont b (blocs de 512 octets, par défaut), c (octets), w (mots de 2 octets), k (kibioctets), M (mébioctets) et G (gibioctets) — des puissances de 1024, pas des méga/gigaoctets décimaux.

Date

find /tmp -type f -mtime +30   # modifies il y a au moins 31 tranches de 24 h
find . -type f -mmin -60       # modifiés il y a moins de 60 minutes

Trois horodatages distincts, souvent confondus : -mtime (date de modification du contenu), -atime (dernier accès) et -ctime (dernier changement de statut de l’inode — permissions, propriétaire, renommage — pas la date de création).

Un fichier copié peut apparaître comme ancien avec -mtime si cp a préservé la date d’origine. -ctime reflète alors mieux la réalité, puisqu’il se met à jour à chaque copie.

-mtime, -atime et -ctime raisonnent en tranches de 24 heures décomptées depuis le lancement de la commande, pas depuis minuit. La partie fractionnaire de chaque tranche est tronquée.

Ainsi, pour matcher -atime +1, un fichier doit avoir été accédé il y a au moins deux jours pleins, pas simplement « plus de 24 heures ».

Par extension, -mtime +7 cible les fichiers modifiés il y a au moins huit tranches de 24 heures, pas « avant la semaine calendaire ». Pour aligner le calcul sur le début de la journée courante plutôt que sur l’heure de lancement, ajoutez l’option GNU -daystart avant le test de date.

Pour des durées courtes, -mmin, -amin et -cmin fonctionnent en minutes.

Deux tests complémentaires évitent souvent un calcul de dates : -newer fichier sélectionne tout ce qui est plus récent qu’un fichier témoin — posez un fichier repère avant une opération, et vous retrouvez ensuite tout ce qui a changé depuis. -empty cible les fichiers ou dossiers vides, plus lisible et plus fiable que -size 0.

Rechercher par propriétaire et permissions avec find Linux

find /home -user alice              # fichiers appartenant à alice
find /tmp -perm 644                 # permissions exactement 644
find . -perm -644                   # au moins lecture/écriture propriétaire + lecture groupe/autres
find . -perm /222                   # au moins un bit d'écriture, peu importe pour qui

Avec find Linux, -perm mode (sans préfixe) exige une correspondance exacte. -perm -mode teste que tous les bits indiqués sont présents, sans exclure les autres — c’est la forme la plus utile en pratique, y compris avec des modes symboliques (-perm -g+w). -perm /mode teste qu’au moins un des bits est présent.

-user et -uid acceptent tous les deux un identifiant numérique : -user 1000 fonctionne aussi bien que -user alice.

rnrnrnrn

La vraie différence est que -uid accepte les comparaisons +n/-n (-uid +1000 pour « UID supérieur à 1000 »), là où -user ne teste qu’une correspondance exacte. C’est notamment utile pour retrouver les fichiers d’un propriétaire disparu du système, lorsque seul l’UID numérique subsiste.

Cette section est directement liée aux permissions Unix posées par chmod : find sert souvent à localiser ce que chmod doit ensuite corriger.

Combiner les critères avec find Linux

Avec find Linux, deux tests l’un à la suite de l’autre sont liés par un ET implicite, qui a une priorité plus forte que le OU :

# ET implicite : fichiers .log ET de plus de 10 Mo
find /var/log -type f -name "*.log" -size +10M

# OU explicite : parenthèses obligatoires
find /var/log -type f ( -name "*.log" -o -name "*.txt" )

Sans parenthèses, une commande comme find . -name "*.log" -o -name "*.txt" -mtime +7 ne fait pas ce qu’on croit : le ET implicite associe -mtime +7 uniquement au second -name, jamais au premier. Les parenthèses doivent être échappées (( )) ou mises entre guillemets, car le shell les interprète sinon lui-même.

Pour exclure un motif, ! (opérateur POSIX) ou son équivalent -not (extension GNU, non conforme POSIX mais largement supportée) fonctionnent, mais avec deux limites que l’on découvre souvent trop tard.

D’abord, la négation filtre entrée par entrée : ! -name "node_modules" masque bien le dossier lui-même, mais son contenu continue de s’afficher, puisque chaque fichier qu’il contient porte un autre nom. Il faudrait ! -path "*/node_modules/*" pour masquer le contenu.

Ensuite, dans les deux cas, find descend quand même dans le dossier et en paie le coût de parcours. Pour réellement ignorer un dossier entier — et gagner le temps de parcours associé — c’est -prune qu’il faut utiliser :

# Exclure node_modules sans y descendre
find . -name "node_modules" -prune -o -type f -name "*.js" -print

Le -print final n’est pas optionnel dans cette construction : sans lui, l’action -print implicite s’appliquerait aussi à la branche -prune, et les dossiers exclus s’afficheraient malgré tout. Autre point de vigilance documenté dans le manuel GNU : -prune n’a aucun effet si l’option -depth est active, et -delete active -depth automatiquement — les deux ne se combinent donc pas utilement.

Agir sur les résultats

Dans find Linux, -print (par défaut) et -print0 sont sans risque. -delete et -exec modifient le système de fichiers.

# SÛR : visualiser d'abord
find /tmp -name "*.tmp" -print

# Une fois la liste vérifiée
find /tmp -name "*.tmp" -delete

Attention — -delete supprime directement, sans confirmation. Ne l’ajoutez jamais en tête de commande : find évalue la ligne de gauche à droite, donc find /chemin -delete -name motif supprime tout ce qui se trouve sous /chemin avant même d’appliquer le filtre. Testez toujours avec -print en premier.

Pour exécuter une commande sur chaque résultat, -exec propose deux syntaxes aux performances très différentes :

# Un appel à chmod par fichier : lent sur un grand nombre de fichiers
find . -type f -name "*.sh" -exec chmod +x {} ;

# Un seul appel à chmod avec tous les fichiers en argument : nettement plus rapide
find . -type f -name "*.sh" -exec chmod +x {} +

Avec {} +, find regroupe les fichiers trouvés dans un nombre réduit d’invocations de la commande, à la manière de xargs.

La contrepartie ne concerne que cette forme groupée : {} doit alors être le dernier argument, immédiatement suivi de + — une construction comme -exec cp {} /destination + échoue pour cette raison, cp ayant besoin de sa destination après la liste de fichiers.

Avec ;, en revanche, {} peut apparaître n’importe où dans la commande : -exec cp {} /destination ; est parfaitement valide, simplement plus lent qu’un appel groupé sur un grand nombre de fichiers.

Il existe une façon de garder la vitesse du mode groupé quand la commande a besoin d’un argument après la liste de fichiers, et la norme POSIX la donne elle-même en exemple : déléguer à un shell intermédiaire qui replace les arguments dans le bon ordre.

# Deplacer en lot vers un dossier de destination, malgre la contrainte du mode +
find . -name "*.old" -exec sh -c 'mv "$@" /destination/' sh {} +

Le sh qui suit sh -c '...' n’est pas une faute de frappe : il occupe la place de $0, ce qui permet à "$@" de démarrer réellement au premier fichier.

Autre variante utile, -execdir fonctionne comme -exec mais lance la commande depuis le dossier contenant le fichier, ce qui la rend nettement moins vulnérable aux noms de fichiers hostiles — à une condition que le manuel pose explicitement : votre variable PATH ne doit pas contenir ., sans quoi la protection tombe.

Et si vous voulez confirmer chaque exécution une par une, -ok remplace -exec en demandant une validation avant chaque appel.

Pour chaîner avec un outil externe quand le nom de fichier peut contenir des espaces ou des caractères spéciaux, le pipeline à base de séparateur nul reste la référence :

find . -name "*.pdf" -print0 | xargs -0r mv -t ~/backup/

Un nom de fichier Unix peut contenir n’importe quel octet à deux exceptions près : la barre oblique / et le caractère nul . Comme / sert déjà de séparateur de chemin, l’octet nul est le seul séparateur d’enregistrements réellement fiable — contrairement à l’espace ou au saut de ligne, qu’un nom de fichier peut légalement inclure.

Limiter le parcours et accélérer la recherche

Sur une arborescence volumineuse, le temps d’exécution ne se joue pas sur les filtres mais sur ce que find accepte de ne pas visiter. Quatre options décident de l’étendue du parcours.

Option	Effet	Quand l’utiliser
-maxdepth N	Ne descend pas au-delà de N niveaux	Chercher dans /etc sans fouiller ses sous-dossiers
-prune	N’entre pas du tout dans le dossier ciblé	Écarter node_modules, .git, vendor
-xdev	Ne franchit pas les points de montage	Un find / qui ne doit pas partir dans un montage réseau
-quit	S’arrête au premier résultat	Vérifier l’existence d’un fichier, sans lister tout le reste

-xdev est celle qu’on oublie le plus souvent, et c’est celle qui change le plus le temps d’exécution : sans elle, un find / traverse les montages réseau, les disques de sauvegarde et les systèmes virtuels comme /proc.

# Chercher un fichier et s'arreter des qu'il est trouve
find / -xdev -name "postgresql.conf" -print -quit

Un dernier point mérite d’être corrigé, car beaucoup de mémos se trompent dessus : contrairement à ce qu’on lit souvent, écrire -name avant -size ne change rien. GNU find réordonne lui-même les tests portant uniquement sur le nom pour les évaluer en premier, et ce dès le niveau d’optimisation par défaut (-O1). Vous pouvez le constater avec find -D opt . -size +0c -name "conf", qui affiche l’expression réellement optimisée.

L’ordre garde en revanche un effet réel face à -type, qui n’est promu qu’à partir de -O2. Écrire -name "*.log" -type f évite alors un appel stat() sur chaque fichier — c’est exactement l’optimisation que le manuel GNU signale dans ses propres exemples.

Ce que les tutoriels obsolètes enseignent encore

Beaucoup de pages sur find reprennent des informations qui étaient exactes il y a dix ans et ne le sont plus. Quatre points méritent une correction, tous vérifiables sur des sources officielles.

-perm +MODE n’existe plus. Cette syntaxe, qui testait « au moins un de ces bits », a été dépréciée dès findutils 4.2.21 (2005) puis supprimée en 4.5.12 (2013) au profit de -perm /MODE. Une commande comme find . -perm +222 renvoie donc find: invalid mode '+222' sur toute distribution Linux actuelle.

Deux nuances utiles : la suppression ne vise que les modes octaux, un mode symbolique comme +u+w restant accepté ; et sur BSD comme sur macOS, -perm +MODE demeure documenté et fonctionnel. C’est donc un piège de portabilité autant qu’une question d’ancienneté.

-iname et -print0 ne sont plus des extensions GNU. Longtemps présentées comme propres à GNU, ces deux options ont été intégrées à la norme POSIX dans l’Issue 8 (IEEE Std 1003.1-2024), tout comme -mount. Un script qui les utilise est aujourd’hui conforme au standard, alors que la plupart des articles en ligne les présentent encore comme des extensions GNU.

Un mot sur la référence exacte à citer, car elle prête à confusion. Cette même spécification porte trois désignations pour un contenu identique : Open Group Base Specifications Issue 8, IEEE Std 1003.1-2024 et, depuis mars 2026, ISO/IEC/IEEE 9945:2026.

Le rapport de statut officiel du groupe Austin explique ce parcours : le projet a d’abord progressé comme une révision d’ISO/IEC 9945, puis a été retiré en raison des contraintes éditoriales de l’ISO, avant d’être resoumis par l’IEEE via le processus PSDO — afin, écrit le groupe, que le texte publié reste techniquement identique entre ISO/IEC, l’IEEE et l’Open Group.

Il ne s’agit donc pas d’une révision plus récente que l’Issue 8, mais de la même norme sous un autre label — un point utile à connaître si vous devez citer POSIX dans une documentation d’entreprise.

-mount et -xdev ne sont plus tout à fait synonymes. Historiquement interchangeables, ils ont été distingués par cette même Issue 8 : les deux empêchent de descendre sous un point de montage, mais -xdev agit sur le point de montage lui-même, là où -mount ne le fait pas.

La différence est mince, mais elle existe désormais dans la norme.

Une réserve pratique s’impose toutefois : GNU find a longtemps traité -mount comme un simple alias de -xdev, et c’est encore le cas sur les versions installées par la plupart des distributions, comme sur BSD et macOS dont le manuel indique explicitement que -mount est l’équivalent de -xdev.

Vérifiez le comportement de votre version avant de vous appuyer sur cette distinction dans un script.

Dernier point d’actualisation, côté outil voisin : la base interrogée par locate n’est plus mlocate sur les distributions récentes. Le projet plocate l’a remplacée comme implémentation par défaut sur Debian, Ubuntu et Fedora, avec une base stockée dans /var/lib/plocate/ et des temps de réponse sans commune mesure. Les articles qui citent encore /var/lib/mlocate/mlocate.db décrivent un système qui n’est plus celui installé.

Audit de sécurité avec find Linux

find sert aussi à auditer une machine, pas seulement à retrouver un fichier perdu. Quatre recherches reviennent régulièrement en administration système :

# Fichiers avec le bit SUID actif (exécutés avec les droits du propriétaire)
find / -perm -4000 -type f 2>/dev/null

# Fichiers avec le bit SGID actif
find / -perm -2000 -type f 2>/dev/null

# Fichiers accessibles en écriture par tout le monde
find / -perm -0002 -type f 2>/dev/null

# Fichiers sans propriétaire ni groupe valide (souvent laissés par un paquet désinstallé)
find / -nouser -o -nogroup 2>/dev/null

Un binaire SUID appartenant à root s’exécute avec les droits root, quel que soit l’utilisateur qui le lance : c’est une cible classique d’escalade de privilèges si le binaire n’est pas censé avoir ce bit actif.

Comparer périodiquement la sortie de find / -perm -4000 à une liste de référence connue fait partie des vérifications de base d’un durcissement système. Le manuel GNU findutils documente cet usage directement dans ses exemples officiels, en combinant -perm -4000 avec -fprintf pour journaliser les résultats dans un fichier plutôt que de les afficher.

Cette vérification manuelle reste complémentaire des outils automatisés comme rkhunter et chkrootkit, qui exécutent ce type de contrôle en tâche planifiée plutôt qu’à la demande.

La redirection 2>/dev/null masque les erreurs Permission denied inévitables sur un parcours de / en tant qu’utilisateur non root.

Elle est acceptable pour une vérification manuelle ; dans un script automatisé, il vaut mieux laisser les erreurs visibles et surveiller le code de retour de find — la documentation officielle garantit seulement une valeur 0 si tout s’est bien déroulé et une valeur supérieure à 0 en cas d’erreur, sans figer de code précis.

Un script robuste teste donc $? -ne 0, pas une valeur fixe.

GNU find, BSD et macOS : les différences

find existe sur tous les systèmes Unix, mais sous des implémentations différentes. La norme POSIX ne garantit qu’un socle commun ; GNU find (celui de toutes les distributions Linux) ajoute de nombreuses extensions, dont certaines n’existent pas ailleurs.

Comportement	GNU find (Linux)	BSD find (FreeBSD, macOS)
Chemin de départ	Optionnel, . par défaut	Obligatoire dans la syntaxe
-delete	Disponible (extension)	Documenté et disponible
-print0 / -iname	Disponibles, et normalisés POSIX depuis l’Issue 8 (2024)	Documentés dans les manuels FreeBSD et macOS
-regex	Disponible (extension, hors POSIX)	Disponible, mais syntaxe d’expression différente
Types de fichiers combinés (-type f,l)	Supporté (extension GNU)	Non supporté
-maxdepth / -mindepth	Supporté	Documentés, mais signalés comme extensions hors POSIX

Un script find écrit et testé sur Linux n’est donc pas automatiquement portable sur macOS sans adaptation, en particulier sur l’omission du chemin de départ. Pour un script destiné à circuler entre systèmes, mieux vaut toujours écrire le chemin explicitement et vérifier la disponibilité des options GNU visées.

Erreurs courantes avec find Linux

Message ou symptôme	Cause	Solution
find: 'X': Permission denied	Pas de droit de lecture sur le dossier	sudo, ou 2>/dev/null pour masquer sans corriger
find: missing argument to '-exec'	; ou + oublié en fin de -exec	Terminer la commande : -exec cmd {} ;
Aucun résultat alors que le fichier existe	Le shell a interprété le motif avant find	Toujours mettre le motif entre guillemets : -name "*.log"
-o ne filtre pas comme prévu	Le ET implicite est plus prioritaire que le OU	Ajouter des parenthèses échappées : ( ... -o ... )
find: paths must precede expression	Le shell a développé un motif non protégé en plusieurs noms de fichiers	Protéger le motif : -name '*.c' ou -name *.c
Un dossier exclu apparaît quand même	!/-not masque l’entrée, pas son contenu, et n’empêche pas la descente	Utiliser -prune à la place

Commandes complémentaires

find s’utilise rarement seul. Pour chercher un motif dans le contenu des fichiers plutôt que par leurs attributs, voyez la commande grep. Pour archiver une sélection de fichiers trouvés par find, tar prend le relais. Et pour corriger les permissions qu’un audit find -perm vient de révéler, chmod (vu plus haut) est l’outil naturel.

FAQ — Questions fréquentes sur la commande find Linux

Quelle est la différence entre find et locate ?

find parcourt le système de fichiers en temps réel à chaque exécution : le résultat reflète l’état actuel du disque. locate interroge une base de noms de fichiers mise à jour périodiquement (généralement par une tâche planifiée) : plus rapide, mais capable de manquer un fichier créé depuis la dernière mise à jour.

Comment chercher des fichiers par taille avec find ?

Avec -size, suivi d’un signe (+ pour plus grand, - pour plus petit) et d’une unité (c pour les octets, k, M, G). Attention : sans suffixe, l’unité par défaut est b, soit des blocs de 512 octets — -size 100 ne signifie donc pas 100 octets. -size arrondit toujours à l’unité supérieure : pour cibler de petits fichiers avec précision, utilisez le suffixe c.

Comment supprimer des fichiers en sécurité avec find ?

Lancez d’abord la même commande avec -print pour visualiser la liste, vérifiez-la, puis remplacez -print par -delete. Ne placez jamais -delete avant les filtres : find évalue la ligne de gauche à droite.

Quelle est la différence entre -exec {} ; et -exec {} + ?

; lance la commande une fois par fichier trouvé. + regroupe les fichiers et lance la commande en un nombre réduit d’appels, à la manière de xargs — nettement plus rapide sur un grand nombre de résultats.

Comment exclure un dossier de la recherche avec find ?

Avec -prune, jamais avec !/-not seul : ce dernier masque l’affichage mais n’empêche pas find de descendre dans le dossier, ce qui reste lent sur une grosse arborescence.

find fonctionne-t-il de la même façon sur Linux, BSD et macOS ?

La syntaxe de base est commune, mais GNU find (Linux) ajoute des extensions absentes ou limitées sur BSD et macOS : chemin de départ optionnel, types combinés par virgule, certaines options récentes. Un script destiné à circuler entre systèmes doit toujours préciser le chemin de départ.

Comment auditer les fichiers SUID et SGID avec find ?

find / -perm -4000 -type f liste les fichiers SUID, find / -perm -2000 -type f les fichiers SGID. Comparer régulièrement cette sortie à une liste de référence connue fait partie des vérifications de base d’un audit de sécurité système.

Pourquoi find . -perm +644 ne fonctionne-t-il pas ?

Parce que la syntaxe -perm +MODE a été supprimée de findutils en version 4.5.12 (2013), après avoir été dépréciée en 2005. Elle est remplacée par -perm /MODE, qui teste la présence d’au moins un des bits indiqués. Les tutoriels qui proposent encore +MODE n’ont pas été relus depuis plus de dix ans.

Comment accélérer une recherche find sur une grosse arborescence ?

Limitez le parcours avant de filtrer : -maxdepth N pour borner la profondeur, -xdev pour ne pas franchir les points de montage, -prune pour écarter des dossiers entiers et -quit pour s’arrêter au premier résultat. GNU find réordonne automatiquement les tests portant sur le nom : le principal gain vient donc de la réduction de l’arborescence parcourue, pas du placement de -name avant -size ou -mtime.

Quelle est la différence entre grep et find ?

find cherche des fichiers d’après leurs attributs — nom, type, taille, date, permissions — tandis que grep cherche un motif à l’intérieur du contenu des fichiers. Autrement dit, find répond à « quels fichiers correspondent à ce critère ? » et grep à « quels fichiers contiennent ce texte ? ». Les deux se combinent : find . -name "*.conf" -exec grep -l "motif" {} + localise d’abord les fichiers, puis filtre sur leur contenu.

Comment localiser un dossier sous Linux ?

Utilisez find avec le filtre -type d, qui restreint les résultats aux répertoires : find / -type d -name "nom-du-dossier" 2>/dev/null. Partir de ~ plutôt que de / rend la recherche nettement plus rapide, et -iname à la place de -name ignore la casse.

Quelle est la commande Linux pour rechercher du texte dans un fichier ?

C’est grep, pas find : grep -rin "motif" dossier/ parcourt récursivement un dossier et affiche les lignes correspondantes. find ne lit jamais le contenu des fichiers, il ne travaille que sur leurs attributs. Pour combiner les deux, passez les fichiers trouvés par find à grep via -exec.

Conclusion

La commande find Linux répond à une logique en trois temps — où chercher, quoi garder, quoi faire — et la quasi-totalité des erreurs viennent d’un non-respect de cet ordre. Une fois cette mécanique acquise, la commande couvre aussi bien la recherche ponctuelle d’un fichier que l’audit de sécurité d’un système entier via -perm.

Pour corriger les permissions qu’un audit -perm vient de révéler, chmod prend le relais, et pour automatiser cette veille au-delà d’une recherche manuelle ponctuelle, les scanners présentés dans l’article sur la détection de rootkits couvrent le même terrain en tâche planifiée.

Dernière vérification des commandes et des versions : 2 août 2026, d’après le manuel officiel GNU findutils (version 4.11.0, publiée le 11 juillet 2026), la page de manuel find(1) sur man7.org et la norme POSIX Issue 8 (IEEE Std 1003.1-2024). Sources complémentaires : le groupe Austin pour le calendrier de publication ISO/IEC/IEEE 9945:2026, le manuel find(1) de FreeBSD pour les différences BSD, et le projet plocate.