Contrôler l'indexation d'un environnement de préproduction

Un environnement de recette contient une copie du site, avec les mêmes textes, les mêmes titres et les mêmes images. S'il devient accessible aux moteurs, il produit un site jumeau qui concurrence le site réel sur ses propres requêtes, capte une partie de son trafic et brouille les signaux de duplication. Le cas est fréquent et il survient rarement par négligence complète : la protection existe, elle est simplement insuffisante ou a été retirée pendant une intervention sans être remise. Cet article détaille les méthodes de blocage, celles qui donnent une fausse sécurité et la procédure à suivre lorsqu'une préproduction s'est déjà retrouvée dans l'index.

Pourquoi c'est un vrai problème

La gravité de la situation est souvent sous estimée, parce que l'environnement concerné n'est pas censé recevoir de visiteurs. Les conséquences sont pourtant réelles et elles touchent le site de production, ce qui change la nature du problème. Un environnement de recette indexé n'est pas un incident interne mais un incident public, avec des effets mesurables sur le trafic. Comprendre précisément ces effets aide à faire accepter les précautions auprès des équipes qui les trouvent superflues, ce qui est souvent le cas tant que rien ne s'est produit. Le mécanisme général de retrait de l'index est décrit dans notre article sur la désindexation et sa méthode de fonctionnement.

La duplication intégrale

Le contenu de la recette étant identique à celui de la production, chaque page existe en double. Le moteur doit alors choisir laquelle afficher, choix qui ne vous appartient pas et qui se fonde sur des critères variables. Il arrive que la version de recette soit retenue, notamment lorsqu'elle a été explorée à un moment où la production était momentanément indisponible. Le visiteur atterrit alors sur un environnement qui peut contenir des fonctionnalités inachevées, des textes de test ou des données factices. C'est la situation la plus embarrassante et elle se produit régulièrement.

La captation de requêtes de marque

Une recette portant un sous domaine reconnaissable peut apparaître sur les requêtes contenant le nom de l'entreprise, parfois en bonne position. Voir une adresse de test s'afficher au milieu des résultats officiels donne une impression déplorable, y compris auprès de clients existants. Ce cas est particulièrement visible lorsque le sous domaine emploie un terme explicite. Il suffit d'une exploration pour que la page entre dans l'index et il faut plusieurs semaines pour l'en sortir. Le déséquilibre entre la facilité d'entrée et la difficulté de sortie justifie à lui seul les précautions.

Le gaspillage d'exploration

Un robot qui explore la recette consacre à celle ci une part du budget qu'il aurait employé sur la production. Sur un site volumineux, cette déperdition ralentit la découverte des contenus réels. L'effet est proportionnel à la taille de l'environnement dupliqué, ce qui le rend significatif sur un catalogue. Il s'ajoute aux autres conséquences plutôt qu'il ne les remplace, et il est le plus difficile à mesurer précisément. Le constat se fait dans les journaux du serveur, où les passages sur la recette apparaissent clairement.

L'exposition de données

Une recette contient souvent une copie de la base de production, donc des données de clients réels. Son indexation rend potentiellement accessibles des pages qui ne devraient pas l'être, listes de commandes, exports, pages de test affichant des informations personnelles. Cette dimension dépasse le référencement et relève de la protection des données, sujet sur lequel nous ne sommes pas juristes et qui mérite un avis compétent. La règle pratique consiste à ne jamais copier de données personnelles réelles dans un environnement moins protégé que la production. C'est la précaution la plus importante de toutes.

Les liens accidentels

Un lien vers la recette publié par erreur dans un document, un courriel ou une publication rend l'environnement découvrable même sans aucune indexation préalable. Ces liens survivent longtemps et se propagent. C'est l'une des raisons pour lesquelles une protection reposant uniquement sur l'absence de liens ne tient pas. Un environnement doit être protégé par sa configuration, jamais par sa discrétion. La confidentialité par obscurité est un principe abandonné depuis longtemps dans tous les domaines techniques.

Le moment du basculement

Le risque culmine au moment de la mise en production, lorsque la recette devient la production ou lorsque les fichiers sont copiés d'un environnement à l'autre. Les directives de blocage voyagent alors avec les fichiers et se retrouvent sur le site réel, ce qui produit le problème inverse et bien plus grave. Ce cas est classique et il coûte des semaines de trafic. Il justifie que le blocage repose sur un mécanisme lié à l'environnement plutôt que sur un fichier copié. Cette distinction est le point le plus important de tout l'article.

Les méthodes qui fonctionnent

Trois approches offrent une protection réelle, avec des niveaux de contrainte différents. Le choix dépend de qui doit accéder à l'environnement et par quels moyens.

L'authentification au niveau du serveur

Une demande d'identifiant et de mot de passe posée par le serveur web, avant tout traitement applicatif, constitue la protection la plus robuste. Un robot recevant une demande d'authentification ne peut ni explorer ni indexer, et la protection ne dépend d'aucun réglage applicatif susceptible d'être modifié. Elle s'applique à l'ensemble des ressources, y compris les fichiers statiques et les exports. Sa mise en place tient en quelques lignes de configuration et elle survit aux mises à jour du site. C'est la méthode à retenir par défaut sur tout environnement qui n'a pas besoin d'être accessible publiquement.

Le filtrage par adresse réseau

Restreindre l'accès aux adresses de l'entreprise et des prestataires offre une protection équivalente sans demander de saisie. Elle convient bien lorsque les intervenants travaillent depuis des connexions fixes identifiées. Sa limite apparaît avec le travail à distance et les connexions mobiles, dont les adresses changent, ce qui produit des demandes d'ajout régulières. La combinaison des deux méthodes, filtrage pour les adresses connues et authentification pour les autres, constitue le compromis le plus pratique. Elle se configure en une seule directive sur la plupart des serveurs.

La directive d'en tête appliquée par l'environnement

Lorsque l'environnement doit rester accessible sans authentification, par exemple pour une démonstration client, l'en tête de réponse interdisant l'indexation constitue la protection applicative la plus fiable. Envoyé par le serveur sur toutes les réponses, il couvre aussi les fichiers non HTML, contrairement à la balise équivalente. Il doit être posé par la configuration du serveur de recette, jamais par le code applicatif, afin de ne pas voyager lors d'un déploiement. Cette nuance est exactement ce qui distingue une protection sûre d'une protection dangereuse. Le principe de cette directive est détaillé dans notre article sur la balise noindex et son utilité en SEO.

Le réglage natif de visibilité

Les systèmes de gestion de contenu proposent en général une case demandant aux moteurs de ne pas indexer le site. Elle pose la balise appropriée et modifie le fichier des robots. Sa faiblesse tient à ce qu'elle est stockée en base : une copie de base de production vers la recette l'écrase, et une copie de recette vers la production l'y transporte. Elle constitue donc un complément utile et jamais une protection principale. Beaucoup d'incidents viennent d'une confiance excessive accordée à cette seule case.

Le sous domaine dédié et isolé

Héberger la recette sur un sous domaine distinct, voire sur un domaine séparé, permet d'appliquer des règles indépendantes sans risque de contamination. Cette séparation facilite aussi le nettoyage en cas d'incident, puisque la demande de retrait porte sur un domaine entier. Elle évite enfin toute confusion dans les outils de mesure, où les deux environnements resteraient autrement mélangés. Son coût est nul et elle devrait être systématique. Un environnement de recette servi depuis un répertoire du site de production est une configuration à proscrire.

La vérification automatisée

Une vérification hebdomadaire, interrogeant l'adresse de recette et contrôlant qu'elle demande bien une authentification ou renvoie la directive attendue, détecte immédiatement une régression. Ce contrôle tient en quelques lignes de script et peut alerter par courriel. Il vaut mieux qu'une confiance dans une configuration posée il y a deux ans par quelqu'un qui n'est plus là. C'est le filet qui rattrape les interventions ayant retiré une protection sans la remettre. Son absence explique la majorité des incidents constatés.

Les fausses protections

Plusieurs méthodes couramment employées donnent un sentiment de sécurité sans offrir de protection réelle. Les connaître évite de s'y fier.

Le blocage par le fichier des robots

Interdire l'exploration de tout le site dans ce fichier est la première idée qui vient et c'est une erreur. Cette directive empêche le robot de lire la page, pas de l'indexer : une adresse connue par un lien externe peut être indexée sans son contenu, avec un titre reconstitué. Pire, elle empêche le robot de voir une éventuelle balise interdisant l'indexation, ce qui rend la situation impossible à corriger. Le fichier des robots ne doit donc jamais être employé pour empêcher une indexation. Son rôle et ses limites sont développés dans notre article sur la manière de configurer le fichier robots.txt sur un serveur.

L'absence de lien

Compter sur le fait que personne ne connaît l'adresse ne constitue pas une protection. Les adresses circulent par les courriels, les tickets, les captures d'écran, les certificats de sécurité publiquement journalisés, les extensions de navigateur et les listes de sous domaines aisément énumérables. Un environnement de recette est découvert en quelques jours dans la plupart des cas. Cette découverte ne demande aucune compétence particulière et elle est en grande partie automatisée. La discrétion doit être considérée comme nulle.

Le nom de sous domaine imprévisible

Choisir un nom aléatoire plutôt que le mot recette n'apporte rien, les certificats de sécurité émis étant inscrits dans des registres publics consultables par tous. Cette pratique donne une fausse assurance et complique la vie des intervenants. Elle peut au mieux ralentir une découverte manuelle, en aucun cas une découverte automatisée. Mieux vaut un nom clair et une vraie protection qu'un nom obscur et aucune. La clarté du nom facilite par ailleurs les procédures de retrait en cas d'incident.

La balise posée par le thème

Ajouter la balise interdisant l'indexation dans le gabarit du thème fonctionne tant que les fichiers restent sur la recette. Elle part avec eux au premier déploiement, ce qui désindexe le site de production. Cet incident est parmi les plus coûteux qui puissent survenir et il se produit plusieurs fois par an dans le secteur. La conditionner au nom d'hôte réduit le risque sans le supprimer, un environnement mal nommé rétablissant le problème. La protection doit vivre dans la configuration du serveur.

La mise hors ligne temporaire

Éteindre l'environnement entre deux phases de travail ne protège pas les périodes d'activité, qui sont précisément celles où le contenu est publié. Un robot peut passer pendant une session de recette et indexer ce qu'il trouve. Cette approche ne constitue donc pas une protection mais une réduction d'exposition. Elle reste utile pour d'autres raisons, coût d'hébergement et surface d'attaque. Elle ne dispense d'aucune des mesures précédentes.

La page de maintenance applicative

Une extension affichant une page de maintenance à tous les visiteurs non connectés semble régler la question. Elle renvoie souvent un code de succès plutôt qu'un code de service indisponible, ce qui n'empêche pas l'indexation de cette page. Elle laisse par ailleurs accessibles les fichiers statiques, les exports et les points d'interface. Sa protection est partielle et elle dépend d'un réglage applicatif modifiable. Elle ne remplace pas une authentification au niveau du serveur.

Sortir de l'index quand c'est arrivé

Lorsque l'environnement est déjà indexé, la procédure demande de la rigueur dans l'ordre des opérations, un mauvais enchaînement pouvant bloquer le retrait pour des mois.

Ne pas commencer par bloquer l'exploration

Le premier réflexe consiste à interdire l'exploration dans le fichier des robots, ce qui est exactement l'inverse de ce qu'il faut faire. Le robot ne peut alors plus lire la directive de désindexation et les pages restent dans l'index pendant très longtemps. L'ordre correct consiste à laisser l'exploration ouverte le temps que la directive soit vue, puis à fermer. Cette erreur est commise dans la majorité des situations d'urgence. La comprendre à l'avance fait gagner plusieurs mois.

Poser la directive de retrait

L'en tête ou la balise interdisant l'indexation doit être posé sur l'ensemble des pages, et le robot doit pouvoir les explorer pour le constater. Ce constat prend de quelques jours à quelques semaines selon la taille de l'environnement et l'attention que lui porte le moteur. Le suivi se fait en interrogeant l'index sur le domaine concerné et en observant la décroissance du nombre de résultats. La patience est la principale qualité requise à cette étape.

Employer l'outil de retrait temporaire

Les outils pour webmasters proposent un retrait rapide, effectif en quelques heures et valable quelques mois. Il masque les pages le temps que la désindexation définitive s'opère, ce qui règle l'urgence de visibilité. Il demande de revendiquer la propriété du domaine concerné, formalité rapide. Ce retrait étant temporaire, il ne dispense pas de la directive permanente, faute de quoi les pages réapparaissent à l'expiration.

Mettre en place la vraie protection

Une fois la désindexation constatée, l'authentification au niveau du serveur doit être posée pour que la situation ne se reproduise pas. La poser trop tôt empêcherait le robot de voir la directive de retrait, ce qui ramène au problème de l'ordre des opérations. Cette séquence en trois temps, ouvrir, désindexer, fermer, est contre intuitive et elle est la seule qui fonctionne. La documenter permet de la rejouer sans réfléchir en cas de récidive.

Vérifier l'absence de liens résiduels

Des liens vers l'environnement peuvent subsister dans des documents publics, des publications ou des sites tiers. Une recherche sur le nom d'hôte les fait apparaître. Demander leur correction lorsque c'est possible évite que la découverte ne se reproduise. Ce nettoyage est fastidieux et il constitue la dernière étape logique de la remise en ordre.

Écrire la procédure

La création d'un nouvel environnement doit suivre une liste de contrôle écrite : sous domaine dédié, authentification posée, données personnelles remplacées, vérification automatique activée. Cette liste tient sur une demi page et elle évite de refaire les mêmes erreurs à chaque projet. Elle doit être relue lors de chaque mise en production, moment où les protections sont le plus souvent perdues. C'est l'investissement le plus rentable de tout le sujet, car il traite la cause plutôt que les conséquences. Elle se limite à trois points, l'adresse concernée, la protection en place et la personne qui la rétablit, format assez court pour être réellement relu le jour de la mise en production.