Onze documents PDF, contenant des clauses types encore en cours de rédaction, sont apparus dans les résultats de recherche d’un moteur externe alors qu’ils n’avaient jamais été conçus pour être consultés en dehors du cabinet juridique qui les avait produits. La découverte est venue d’une recherche interne portant sur le nom d’un client, un collaborateur tombant par hasard sur l’un de ces modèles en cherchant tout autre chose.
Ces documents servaient de base de travail à l’équipe juridique, partagés entre collaborateurs via un espace WordPress interne pensé comme un intranet léger, avec des pages contenant des liens vers des fichiers déposés dans le dossier wp-content/uploads/ du site.
Un intranet construit sur une confusion de périmètre
L’espace de travail avait été conçu comme une simple extension du site vitrine public du cabinet, réutilisant la même installation WordPress pour des raisons de simplicité technique. Les pages listant les modèles de contrats n’étaient reliées à aucun menu public et ne figuraient dans aucun sitemap généré, ce qui avait conduit l’équipe à les considérer, à tort, comme suffisamment discrètes pour rester confidentielles.
Le dossier uploads, par nature accessible publiquement sans authentification, contenait pourtant les fichiers PDF eux-mêmes, chacun consultable par accès direct à son URL. Une page « discrète » sans lien entrant ne protège en rien les fichiers qu’elle référence : elle retarde seulement leur découverte accidentelle.
Comment l’indexation a eu lieu
L’examen des journaux du serveur a montré que les robots d’indexation avaient exploré ces URLs après les avoir rencontrées via un lien de partage envoyé par e-mail à un client, dont l’aperçu généré par son client de messagerie avait déclenché une requête préalable vers le fichier, requête ensuite tracée et suivie par un robot tiers.
- Aucune règle de
robots.txtn’excluait le sous-dossier contenant les modèles. - Aucune balise
noindexn’était présente sur les pages listant les documents. - Le dossier ne bénéficiait d’aucune protection par mot de passe au niveau du serveur.
Pourquoi noindex n’aurait pas suffi
Une réaction fréquente face à ce type d’incident consiste à ajouter une balise noindex aux pages concernées. Cette mesure empêche un moteur de recherche respectueux de la directive d’indexer le contenu, mais elle ne restreint en rien l’accès direct au fichier pour quiconque en connaît ou en devine l’URL. Le cabinet a choisi une approche différente, fondée sur un contrôle d’accès réel plutôt que sur une simple préférence d’indexation.
# Blocage au niveau du serveur, dans un fichier .htaccess dédié au sous-dossier
<FilesMatch "\.pdf$">
Require all denied
</FilesMatch>
Les documents ont ensuite été déplacés vers un espace protégé par une authentification HTTP, distinct du dossier uploads public, chaque collaborateur disposant d’un accès nominatif.
Demander le retrait auprès du moteur de recherche
Le blocage au niveau du serveur n’efface pas les pages déjà indexées : une demande explicite de suppression d’URL doit être adressée via la console de gestion pour webmasters du moteur concerné, en complément du blocage d’accès. Sans cette étape, les documents restent visibles dans les résultats de recherche pendant plusieurs semaines, même une fois l’accès effectivement fermé.
| Étape | Effet obtenu |
|---|---|
| Blocage serveur du dossier concerné | Empêche tout nouvel accès direct au fichier |
| Demande de retrait via la console webmaster | Accélère la disparition des résultats déjà indexés |
| Migration vers un espace authentifié dédié | Sépare durablement le contenu interne du contenu public |
Repère retenu par le cabinet après cet incident : un fichier déposé dans un dossier public reste public, quelle que soit la discrétion de la page qui y mène. Seule une authentification réelle change cette réalité.
En résumé
Ce cas ne relève pas d’un problème de référencement du site, qui reste un sujet distinct et volontairement écarté ici, mais d’une confusion entre discrétion et confidentialité. Un document sans lien visible reste techniquement public tant qu’aucun contrôle d’accès réel ne l’en empêche, et un moteur de recherche finit statistiquement par le découvrir, tôt ou tard.
