Google dorking : la technique des experts pour trouver l'introuvable

Vous cherchez votre propre nom sur Google par curiosité, et là, vous tombez sur un fichier PDF interne de votre ancien employeur qui traîne en accès libre. Avec votre adresse, votre numéro de sécu, le montant de votre prime de fin d'année. Personne ne l'a piraté. Le fichier est simplement là, indexé, attendant qu'une requête un peu précise le débusque.

C'est exactement le genre de découverte que permet le google dorking — aussi appelé Google Hacking. Pas de logiciel, pas d'exploit, pas de terminal. Juste le moteur de recherche que vous utilisez tous les jours, et une poignée d'opérateurs que 99 % des gens ignorent.

Je vais être franc avant d'aller plus loin : j'ai moi-même passé des heures à jouer avec ça, et j'ai trouvé des choses que j'aurais préféré ne pas voir. Cet article n'est pas un tutoriel pour faire du mal. C'est une explication de ce que la technique permet, de pourquoi elle fonctionne encore en 2026, et de ce que vous devez vérifier sur vos propres sites.

Qu'est-ce que le google dorking, vraiment ?

La définition qu'on lit partout est correcte mais incomplète. On vous dit : « c'est utiliser des opérateurs avancés pour trouver des informations cachées ». Sauf que ce n'est pas tout à fait ça.

La vraie mécanique, c'est celle-ci : Google ne cache rien, il indexe ce qu'on lui donne. Si un fichier se retrouve dans ses résultats, c'est que quelqu'un, à un moment, a laissé les robots du moteur y accéder. Le dorking ne force aucune porte. Il se contente de demander précisément.

La différence avec une recherche normale

Quand vous tapez « rapport annuel » dans Google, le moteur essaie de deviner ce que vous voulez. Il vous sort des résultats populaires, récents, pertinents. Il interprète.

Quand vous tapez filetype:pdf intitle:"rapport annuel" site:exemple.com, il n'interprète plus. Il obéit. Vous lui avez donné trois contraintes exactes, il vous renvoie tout ce qui les respecte. Aucune, parfois. Des milliers, parfois aussi.

Cette absence d'interprétation, c'est toute la puissance de la chose. Et toute sa dangerosité.

Les opérateurs qui comptent vraiment

Il existe des dizaines d'opérateurs. Franchement, vous en utiliserez cinq ou six dans 95 % des cas. Les autres servent pour des recherches très pointues, ou pour frimer.

Les quatre indispensables

Voici ceux que je tape le plus souvent, avec un exemple concret à chaque fois :

• site: limite la recherche à un domaine. site:exemple.com ne renverra que ce domaine et ses sous-domaines.
• filetype: filtre par extension de fichier. filetype:xlsx pour les tableurs, filetype:pdf pour les documents, filetype:env pour les fichiers de configuration (et là, ça devient intéressant).
• intitle: cherche dans le titre de la page. intitle:"index of" est le classique des classiques.
• inurl: cherche dans l'URL. inurl:admin ou inurl:login font ressortir les pages d'administration — pas toutes, mais assez.

Deux opérateurs sous-estimés

intext: cherche dans le corps de la page. Utile quand le mot-clé n'est ni dans le titre ni dans l'URL. cache: affiche la version en cache de Google — pratique quand un site a été modifié depuis l'indexation.

Et il y a les exclusions. Le signe moins, -, retire un terme. J'ai récupéré des heures de tri avec une simple requête bien construite : au lieu de parcourir 200 résultats pour en garder 4, je récupérais directement les 4. Le gain paraît minuscule. Il ne l'est pas.

Exemple concret de combinaison

Imaginez que vous administrez un site et que vous voulez savoir ce qui a fuité. Une requête comme site:monsite.com (filetype:xls OR filetype:csv OR filetype:sql) vous dira en quelques secondes si des fichiers de données sont accessibles publiquement. Si la réponse est « oui », vous avez un problème à régler aujourd'hui, pas la semaine prochaine.

J'ai fait ce test sur trois sites que je gère. Sur l'un d'eux, un vieux fichier de sauvegarde d'une base clients était encore en ligne, à une URL que personne ne connaissait. Sauf Google. Je l'ai supprimé dans l'heure.

Pourquoi ça fonctionne encore en 2026

On pourrait croire que les grandes plateformes ont verrouillé tout ça depuis longtemps. La réalité est plus nuancée.

Ce qui a changé, c'est la surface d'exposition. Il y a dix ans, une entreprise gérait un site statique et c'était tout. Aujourd'hui, la même entreprise gère un site, un blog, un espace client, des sous-domaines de test, une documentation technique, un dépôt Git, une API, et j'en passe. Chaque brique a ses propres oublis.

Le vrai problème est humain

Les robots d'indexation ne font pas d'erreur. Ce sont les humains qui publient un dossier « backup » pour dépanner, oublient de le retirer, et passent à autre chose. Six mois plus tard, le dossier est toujours là, indexé, référencé.

J'ai vu ça sur un projet perso : j'avais laissé un répertoire /test/ avec des identifiants en clair pour une base de démonstration. Le temps de finir le développement, j'ai oublié. Trois semaines plus tard, en cherchant autre chose, je suis tombé dessus via Google. Les identifiants étaient toujours valides. Je les ai changés par réflexe, mais la leçon est restée.

Ce n'est pas un problème de technologie. C'est un problème de processus.

Entre usage légitime et abus : où est la ligne ?

C'est la partie que les articles techniques traitent souvent en deux paragraphes expédiés. Sauf que c'est la plus importante à comprendre si vous ne voulez pas vous retrouver dans une situation désagréable.

Ce qui est autorisé

Utiliser des opérateurs de recherche avancés sur des sites publics est parfaitement légal dans la majorité des contextes. Vous consultez de l'information rendue publique par le moteur. Point. Un journaliste qui enquête, un chercheur en sécurité dans le cadre d'un bug bounty, un consultant SEO qui analyse la concurrence — tous font du dorking sans le nommer.

Ce qui ne l'est pas

Le glissement se produit quand vous utilisez ce que vous avez trouvé. Découvrir un fichier accessible ne vous autorise pas à l'utiliser. Télécharger une base de données clients, exploiter des identifiants, accéder à un espace d'administration qui n'est pas le vôtre — tout cela relève de l'intrusion, et la loi ne fait pas de distinction selon la facilité avec laquelle vous êtes entré.

En France, l'accès frauduleux à un système de traitement automatisé de données est puni par le code pénal, même sans intention de nuire. Le fait que la porte était ouverte ne change rien.

Et si je trouve une fuite par hasard ?

La bonne pratique est simple : signaler. À l'entreprise concernée si elle est identifiable, ou à l'autorité compétente. Ne pas télécharger, ne pas diffuser, ne pas tester plus loin. Vous n'êtes pas dans un film.

Côté défense : ce qu'il faut vérifier sur votre propre site

Vous ne pouvez pas empêcher des inconnus de taper des requêtes. Vous pouvez, en revanche, faire en sorte qu'elles ne renvoient rien de fâcheux. Voici ce qui marche réellement.

Le fichier robots.txt n'est pas une protection

C'est l'erreur classique. Mettre Disallow: /admin/ dans un robots.txt ne cache rien. Au contraire : vous indiquez à qui veut l'entendre où se trouve le dossier sensible. Le robots.txt dit aux robots polis de ne pas indexer. Il ne dit rien aux humains curieux. Et il ne protège rien.

Les vraies contre-mesures

Ce qui fonctionne :

1. L'authentification sur tout ce qui n'est pas destiné au public — pas de dossier « test » accessible sans mot de passe.
2. L'en-tête HTTP noindex sur les pages sensibles, pour empêcher l'indexation côté moteur.
3. La suppression pure et simple des fichiers qui n'ont plus à être en ligne. Le meilleur dossier caché est celui qui n'existe plus.
4. La surveillance régulière via Google Search Console : vous y voyez ce que Google a indexé de votre domaine. Si un fichier bizarre apparaît, vous le savez.
5. La vérification des métadonnées de vos documents PDF et images. Un PDF peut contenir l'historique de modifications, les noms des auteurs, parfois le chemin du serveur d'origine. Ces informations-là ne se voient pas à l'œil nu.

Sur les métadonnées, je dois avouer que j'ai longtemps négligé ce point. J'ai découvert en inspectant un vieux rapport que le PDF contenait le chemin complet de mon disque et le nom de mon client interne. Rien de dramatique, mais rien d'utile non plus pour lui.

Un test simple à faire ce mois-ci

Le tableau ci-dessous résume les requêtes à faire sur votre propre domaine. Cinq minutes, et vous saurez à peu près où vous en êtes.

Objectif	Requête type	Ce que ça révèle
Fichiers de données exposés	site:mondomaine.com (filetype:xlsx OR filetype:csv OR filetype:sql)	Des exports, des bases, des sauvegardes accessibles
Listings de répertoires	site:mondomaine.com intitle:"index of"	Des dossiers sans page d'accueil, listés en vrac
Pages d'administration	site:mondomaine.com inurl:admin	Des interfaces de gestion qui pourraient être accessibles
Fichiers de configuration	site:mondomaine.com (filetype:env OR filetype:config OR filetype:ini)	Des variables sensibles, des accès à des services tiers
Documents internes	site:mondomaine.com (filetype:pdf OR filetype:docx) "confidentiel"	Des documents jamais destinés au public

Si l'une de ces requêtes renvoie un résultat légitime, tant mieux. Si elle renvoie un résultat que vous ne connaissiez pas, vous savez ce qu'il vous reste à faire.

Le côté SEO que personne ne mentionne

La plupart des articles sur le sujet traitent le google dorking comme une technique de sécurité. C'est vrai. Mais il y a un angle beaucoup moins discuté et pourtant très pratique : la veille concurrentielle.

Vouloir savoir quels contenus attirent du trafic chez un concurrent, quelles pages il a désindexées, quels dossiers il a oublié de nettoyer — tout cela passe par les mêmes opérateurs. Une recherche du type site:concurrent.com -inurl:blog -inurl:produit peut révéler des pages qu'il préférerait garder discrètes. Des annonces, des pages de test, parfois une ancienne version de sa grille tarifaire.

Je l'ai utilisé sur un projet éditorial il y a deux ans pour identifier des thématiques que trois concurrents directs avaient abandonnées. Pas de magie : leurs anciens articles étaient toujours indexés, mais plus mis à jour. J'ai produit du contenu frais sur ces sujets. Représentation modeste mais réelle dans mes résultats de recherche sur les mois suivants.

C'est de la veille, pas de l'espionnage. La nuance compte, et elle tient à ce que vous faites des informations après les avoir trouvées.

Ce qu'il faut retenir

Le google dorking n'est pas une technique de hacker. C'est une manière de parler à un moteur de recherche sans passer par ses interprétations. Une fois qu'on a compris ça, on ne revient pas en arrière : chaque recherche normale paraît soudain imprécise.

Ce qui m'a le plus marqué en pratiquant, ce n'est pas la quantité de choses qu'on peut trouver. C'est la banalité des fuites. Jamais un système savamment percé. Toujours un dossier oublié, un test jamais nettoyé, un fichier exporté un vendredi soir et jamais supprimé.

Alors voici la question qui me trotte depuis un moment, et je vous la transmets : combien de fichiers de votre organisation sont indexés en ce moment même, que personne n'a jamais pensé à vérifier ?

La réponse prend cinq minutes à obtenir. La surprise, elle, peut durer plus longtemps.