Gérer 400 redirections : extension ou fichier de configuration ?

Une refonte produit quelques centaines de redirections, un changement de structure d'adresses en produit autant, et un site vivant en accumule au fil des années sans que personne ne fasse le compte. Arrivé à quatre cents règles, la question du support cesse d'être théorique : chaque requête arrivant sur le site traverse ce jeu de règles, y compris les requêtes qui aboutissent normalement. Le choix entre une extension de gestion des redirections et un fichier de configuration serveur engage à la fois la performance, la facilité d'administration et la capacité à retrouver plus tard pourquoi telle adresse pointe vers telle autre. Les deux solutions sont défendables, sur des critères qui n'ont rien d'idéologique.

Ce que change le volume

À dix règles, tout fonctionne et le débat n'a pas lieu d'être. C'est la croissance du volume qui fait apparaître des différences de nature entre les deux approches, et il vaut mieux les connaître avant d'avoir mille règles. Le rôle du fichier de configuration local est détaillé dans notre article consacré au fichier htaccess et à ses possibilités.

Ce qui coûte dans une redirection

Le coût ne réside pas dans la redirection elle même, qui est instantanée, mais dans la recherche de la règle applicable. Pour chaque requête entrante, le système doit déterminer si une règle correspond, ce qui suppose de parcourir le jeu de règles ou d'interroger un index. Ce travail a lieu pour toutes les requêtes, y compris les millions de requêtes légitimes qui ne déclencheront aucune redirection. C'est cette asymétrie qui rend le sujet sensible : on paie le coût de la recherche en permanence pour un bénéfice qui ne concerne qu'une fraction infime du trafic. Une bonne implémentation limite donc ce coût aux seules requêtes qui n'ont trouvé aucune ressource, ce qui ramène la charge à presque rien et constitue le premier critère de qualité d'une solution.

L'ordre d'évaluation

Une redirection gérée par le serveur web est évaluée avant que le moteur du site ne soit chargé, donc avant le démarrage de l'interpréteur, la connexion à la base et l'initialisation des extensions. Une redirection gérée par une extension est évaluée après tout cela. La différence se compte en dizaines à centaines de millisecondes par requête redirigée, ce qui reste modeste sur un site ordinaire, et devient significatif lorsque des robots explorent massivement d'anciennes adresses, situation fréquente après une refonte. Dans les semaines qui suivent un changement de structure, les robots concentrent une part importante de leur exploration sur les anciennes adresses, et le coût unitaire se trouve multiplié par un volume inhabituel.

Le coût d'une extension

Une extension de redirection stocke ses règles en base et les interroge à chaque requête non résolue, parfois à chaque requête tout court selon son implémentation. Les extensions sérieuses mettent leurs règles en cache mémoire, ce qui ramène le coût à peu de chose. Les autres effectuent une requête de base par visite, ce qui devient perceptible à fort trafic. La différence entre ces deux comportements ne se lit dans aucune fiche descriptive et se constate uniquement en mesurant, ce qui explique les écarts d'expérience entre utilisateurs d'une même extension. Le test est simple : activer le suivi des requêtes de base sur une page ordinaire et compter combien d'entre elles proviennent du module de redirection.

Le coût d'un fichier de configuration

Sur Apache, un fichier de configuration local est relu à chaque requête, et quatre cents règles de réécriture y sont évaluées séquentiellement. Le coût unitaire est faible mais réel, et il s'applique à toutes les requêtes, images comprises. Placer les mêmes règles dans la configuration principale du serveur supprime la relecture et améliore nettement la situation, à condition d'avoir accès à cette configuration. Sur Nginx, la question ne se pose pas dans les mêmes termes, la configuration étant chargée en mémoire au démarrage, comme nous l'expliquons à propos de NGINX et de son fonctionnement.

À partir de quel volume la question se pose

En dessous de cinquante règles, n'importe quelle solution convient et le critère de choix est le confort d'administration. Entre cinquante et cinq cents, la question mérite d'être posée mais aucune solution n'est disqualifiée. Au delà de mille, les règles évaluées séquentiellement deviennent coûteuses et il faut passer à un mécanisme indexé, soit une extension correctement conçue, soit une table de correspondance chargée en mémoire par le serveur. Quatre cents règles se situent donc dans la zone où le choix se fait sur d'autres critères que la seule performance. C'est une bonne nouvelle, car ces autres critères sont plus faciles à évaluer et engagent moins l'avenir technique du site.

Les critères de décision

Ces critères pèsent souvent plus lourd que la performance, et ils sont rarement examinés explicitement, ce qui conduit à des choix par défaut que l'on regrette ensuite.

Qui doit pouvoir ajouter une règle

C'est le critère décisif dans la plupart des cas. Si la personne qui repère une adresse cassée est un rédacteur ou un responsable marketing, une interface d'administration est indispensable, et le débat s'arrête là. Si les redirections sont ajoutées par un technicien lors d'interventions planifiées, un fichier versionné est préférable. Choisir une solution que l'équipe ne sait pas utiliser garantit que les redirections ne seront pas créées, ce qui coûte bien plus cher en trafic perdu que quelques millisecondes de traitement. Un compromis courant consiste à confier l'interface aux équipes éditoriales pour les cas courants et à réserver la configuration serveur aux règles générales, arbitrage qui satisfait à peu près tout le monde.

L'accès au serveur

Sur un hébergement mutualisé, l'accès se limite au fichier de configuration local, avec la relecture systématique que cela implique. Sur un serveur dédié ou virtuel, la configuration principale devient accessible et change complètement l'équation. Cet élément est purement factuel et se vérifie en cinq minutes, mais il élimine parfois d'emblée la moitié des options, ce qui simplifie beaucoup la discussion et évite de concevoir une solution qui ne pourra pas être déployée.

La nature des redirections

Un jeu de règles composé d'adresses exactes, une par une, se prête bien à une table de correspondance et à une extension. Un jeu composé de motifs généraux, par exemple la réécriture de toute une branche d'arborescence vers une autre, s'exprime en quelques lignes de configuration serveur et devient laborieux dans une interface. La plupart des situations réelles mélangent les deux, ce qui plaide pour une approche mixte plutôt que pour un choix exclusif entre les deux méthodes. Les motifs généraux vont au serveur, les cas particuliers à l'interface, et chacun est traité là où il se maintient le mieux.

Le besoin de suivi

Savoir combien de fois une redirection a été empruntée, et depuis quelle source, permet de purger les règles devenues inutiles et de repérer les liens externes à faire corriger. Les extensions fournissent ce suivi nativement. Une configuration serveur ne le fournit pas, sauf à analyser les journaux, ce qui est parfaitement faisable mais suppose un outillage et une habitude. Ce besoin est réel sur un site à forte histoire, et anecdotique sur un site jeune dont les règles viennent toutes d'une refonte unique. Il devient en revanche déterminant dès que l'on souhaite convaincre un partenaire de corriger un lien plutôt que de maintenir une règle indéfiniment.

La sensibilité à la performance

Sur un site à trafic modéré, la différence entre les deux approches est indétectable pour un visiteur. Sur une boutique à fort volume ou sur un site subissant une exploration intensive, elle devient mesurable. Le critère doit être évalué avec des chiffres réels plutôt qu'en principe : une mesure du temps de réponse avec et sans les règles, effectuée sur une copie du site, tranche la question en une heure et évite des mois de débat théorique entre les deux camps.

Le risque d'erreur

Une erreur dans un fichier de configuration serveur peut rendre le site entièrement inaccessible, y compris l'administration, ce qui impose un accès de secours par transfert de fichiers. Une erreur dans une extension reste circonscrite et se corrige depuis l'interface. Ce risque est asymétrique et mérite d'être pris en compte selon les compétences disponibles et selon la façon dont les modifications sont déployées, un déploiement versionné avec possibilité de retour arrière annulant largement cette objection.

Organiser un jeu de règles important

Quel que soit le support retenu, l'organisation compte davantage que le choix technique. Quatre cents règles mal rangées deviennent ingérables, quatre cents règles structurées se maintiennent sans difficulté particulière.

Séparer les règles exactes des règles à motif

Les deux familles ne se maintiennent pas de la même façon et ne présentent pas les mêmes risques. Les règles exactes sont sûres et nombreuses, les règles à motif sont peu nombreuses et dangereuses, une expression trop large pouvant capturer des adresses légitimes. Les séparer physiquement, dans deux fichiers ou deux catégories, permet de relire les secondes avec l'attention qu'elles méritent sans se perdre dans le volume des premières, qui ne demandent aucune vigilance particulière. Cette séparation facilite aussi les tests, les règles à motif méritant une batterie de cas de contrôle que les règles exactes ne justifient pas.

Générer plutôt qu'écrire

Les redirections issues d'une refonte proviennent d'un rapprochement entre l'ancienne et la nouvelle arborescence, rapprochement qui existe généralement sous forme de tableau. Générer les règles depuis ce tableau, plutôt que de les saisir, supprime les fautes de frappe et permet de tout régénérer si la correspondance évolue. Le tableau devient alors la source de vérité et le fichier de règles un produit dérivé, ce qui est exactement la bonne répartition et facilite considérablement les corrections en série. Le tableau se conserve avec le projet, ce qui permet de répondre des années plus tard à la question de savoir quelle ancienne adresse correspondait à quelle nouvelle.

Regrouper par famille

Un commentaire d'en-tête par groupe de règles, indiquant l'origine et la date, transforme un fichier illisible en document exploitable. Trois ans plus tard, la question qui se pose est toujours la même : peut on supprimer cette règle. Sans indication d'origine, la réponse est non par précaution, et le fichier ne diminue jamais. Avec une date et un motif, la décision devient possible et le jeu de règles reste dans une taille raisonnable au fil des années.

Éviter les chaînes

Une adresse redirigée vers une adresse elle même redirigée double le temps de résolution et dilue les signaux de référencement. Les chaînes apparaissent naturellement au fil des refontes successives, personne ne pensant à mettre à jour les anciennes règles. Un contrôle périodique détecte ces enchaînements et les remplace par une redirection directe vers la cible finale, opération purement mécanique qui peut être scriptée et qui améliore mesurablement le comportement du site après plusieurs refontes. Le même contrôle détecte au passage les boucles, plus rares mais autrement plus gênantes puisqu'elles rendent une adresse définitivement inaccessible.

Purger régulièrement

Une règle qui n'a été empruntée par personne depuis douze mois n'a plus d'utilité, sauf si elle correspond à un lien externe important. Les statistiques d'utilisation permettent cette purge, ce qui constitue d'ailleurs un argument sérieux en faveur des solutions qui les fournissent. Sans purge, le jeu de règles ne fait que croître, et le coût de recherche avec lui, jusqu'au jour où l'on découvre plusieurs milliers de règles dont l'immense majorité ne sert plus à rien. Une purge annuelle, décidée sur des chiffres plutôt qu'au jugé, suffit à maintenir le dispositif dans un état sain.

Mettre en place et vérifier

La mise en place de quatre cents règles ne s'improvise pas, et la vérification demande plus de temps que l'écriture elle même.

Tester avant de publier

Un script parcourant la liste des anciennes adresses et vérifiant que chacune renvoie le bon code et la bonne destination valide l'ensemble en quelques minutes. Ce test doit tourner sur une copie du site avant toute mise en production, et son résultat doit être conservé. C'est la seule façon de garantir qu'aucune règle n'a été perdue ni mal transcrite, contrôle qu'aucune relecture humaine ne peut assurer sur un volume pareil. Le fichier de test se conserve avec le projet et se rejoue à chaque intervention ultérieure sur les règles.

Le contrôle après mise en ligne

Le même script rejoué sur le site en production détecte les écarts entre l'environnement de test et l'environnement réel, notamment ceux introduits par un service intermédiaire ou par un cache. Ce second contrôle est indispensable : un jeu de règles parfaitement valide en local peut se comporter différemment derrière un réseau de diffusion, qui met parfois en cache les réponses de redirection avec leur propre durée de vie. Une redirection erronée mise en cache pendant plusieurs heures se corrige alors bien plus difficilement qu'une simple erreur de configuration.

Surveiller les erreurs restantes

Les adresses non couvertes se révèlent dans les rapports d'erreurs et dans les journaux du serveur. Une revue mensuelle des adresses les plus demandées parmi celles qui échouent permet d'ajouter les règles manquantes là où elles servent réellement. Cette approche par le trafic constaté est bien plus efficace que la tentative de tout prévoir à l'avance, exercice dans lequel on ajoute des centaines de règles inutiles tout en manquant celles qui comptent. Quelques dizaines de règles ajoutées ainsi, au vu du trafic réel, couvrent généralement mieux le besoin que plusieurs centaines écrites par anticipation.

Choisir le bon code

Une redirection définitive transmet les signaux à la nouvelle adresse et informe les moteurs que l'ancienne peut être oubliée. Une redirection temporaire conserve l'ancienne adresse dans l'index et convient aux situations réellement provisoires. Le mélange des deux, fréquent quand les règles sont ajoutées au fil de l'eau par des personnes différentes, produit des résultats incohérents, sujet que nous détaillons dans notre article sur le code HTTP 302 et ses enjeux.

Documenter l'origine des règles

Chaque groupe de règles doit porter la mention du projet ou de l'incident qui l'a créé. Cette information ne coûte rien à l'écriture et vaut de l'or trois ans plus tard, quand il s'agit de décider si une famille entière peut disparaître. Sur une interface d'administration ne prévoyant pas de champ de commentaire, un préfixe dans le libellé de la règle remplit le même office, solution rustique mais parfaitement efficace. L'essentiel est que l'information existe quelque part et qu'elle reste attachée à la règle plutôt qu'à un document séparé qui finira par se perdre.

Prévoir la reprise

Les règles doivent pouvoir être exportées dans un format lisible et réimportées ailleurs, ce qui protège d'un changement d'extension, d'un changement d'hébergement ou d'une refonte du site. Un export périodique conservé avec les sauvegardes suffit, et il constitue souvent le seul endroit où l'historique des adresses d'un site existe encore après quelques années. Cette précaution prend deux minutes et évite de reconstituer un travail de plusieurs jours à partir de rien.