Comment planifier des redirections pour pointer vers des cibles différentes au fil du temps ?

Une exigence courante dans la gestion des redirections consiste à servir une URL fixe qui doit pointer vers des cibles différentes au fil du temps, chaque cible devenant active automatiquement à un moment précis. Les cas typiques incluent les URL courtes imprimées (flyers, emballages, publicités) qui ne peuvent pas être réimprimées chaque semaine, mais dont la destination change selon un cycle promotionnel hebdomadaire.

redirection.io gère cela avec le déclencheur DATETIME. Cependant, la manière dont les règles sont publiées implique qu'une approche naïve - modifier une seule règle semaine après semaine - produit un vide pendant lequel aucune redirection n'est servie. Cet article explique pourquoi cela se produit et comment planifier correctement des redirections de remplacement, en utilisant plusieurs règles et la priorité des règles.

Un cas d'usage courant

Vous disposez d'une URL publique stable, par exemple /weekly-offers. Elle est imprimée à l'avance et ne peut pas être modifiée. Chaque semaine, elle doit rediriger vers une cible différente :

jusqu'à dimanche : /offers/week-A
à partir de dimanche : /offers/week-B

Le changement doit se produire automatiquement à une date et une heure définies, et la cible précédente doit continuer à fonctionner jusqu'à ce moment.

Le piège habituel : modifier une seule règle

L'approche intuitive consiste à conserver une seule règle pour l'URL et, une fois par semaine, à la modifier pour mettre à jour deux éléments :

le déclencheur DATETIME (la nouvelle date d'activation)
l'URL cible

Cela ne fonctionne pas, et la raison en est importante. Lorsque vous publiez une nouvelle version d'un ensemble de règles, la règle modifiée remplace sa version précédente. L'ancienne règle n'existe plus dans l'ensemble de règles publié. Si le nouveau déclencheur DATETIME est défini dans le futur (par exemple after 05/07/26), alors entre le moment où vous publiez et cette date future, il n'y a plus aucune règle correspondant à l'URL.

La conséquence :

l'ancienne cible cesse d'être servie immédiatement après la publication
la nouvelle cible n'est pas encore servie, car sa condition DATETIME n'est pas remplie

Pendant cet intervalle, l'URL ne renvoie aucune redirection, ce qui fait apparaître des erreurs pour les liens qui étaient censés correspondre encore à la cible précédente.

Une règle avec un trigger de date modifié

Vous pouvez confirmer ce vide dans le testeur de règles (Rules > Test a specific request). Tester l'URL pour une date qui tombe après la publication mais avant la nouvelle date d'activation ne renvoie aucune correspondance :

Le testeur de règles montre qu'aucune règle ne sera exécutée

La solution : une règle par période, plus la priorité

Créez une règle pour chaque période de temps, au lieu de modifier une seule règle :

règle A : URL /weekly-offers + DATETIME after <début de la semaine A> -> cible pour la semaine A
règle B : URL /weekly-offers + DATETIME after <début de la semaine B> -> cible pour la semaine B

Les deux règles peuvent être préparées et publiées bien à l'avance. Il n'y a pas de vide, car la règle A reste active en continu jusqu'à ce que la date d'activation de la règle B soit atteinte.

Une nouvelle règle avec le déclencheur DATE, à exécuter à une date future

Après cette date, cependant, les choses deviennent moins évidentes : la règle A sera-t-elle exécutée, ou la règle B ? Une fois que la date actuelle a dépassé les deux dates de début (par exemple le 8 juillet, où after 29/06 et after 06/07 correspondent tous les deux), les deux règles sont déclenchées. Vous devez donc définir la priorité de la règle afin que la règle couvrant la période la plus récente l'emporte.

Dans redirection.io, attribuez une priorité plus élevée à la règle ayant la date d'activation la plus tardive. Lorsque plusieurs règles correspondent, celle qui a la priorité la plus élevée est appliquée, de sorte que la destination correspond toujours à la dernière période qui a débuté.

Vous pouvez le vérifier lors de la création de nouvelles règles pour de nouvelles périodes. À condition d'avoir configuré des exemples corrects dans votre règle, l'étape "impact" permet d'organiser les priorités des règles :

Un exemple avec trois périodes

L'ensemble de règles suivant définit trois cibles pour trois semaines consécutives sur la même URL :

Trigger	Action (cible)	Priorité
`URL /example` + `DATETIME after 29/06/26 00:00`	`/week-29th-june`	0
`URL /example` + `DATETIME after 06/07/26 00:00`	`/week-6th-july`	1
`URL /example` + `DATETIME after 13/07/26 00:00`	`/week-13th-july`	2

Comportement au fil du temps :

entre le 29 juin et le 6 juillet : seule la première règle correspond -> /week-29th-june
entre le 6 juillet et le 13 juillet : les deux premières règles correspondent, la priorité 1 l'emporte -> /week-6th-july
à partir du 13 juillet : les trois correspondent, la priorité 2 l'emporte -> /week-13th-july

Plus la date d'activation est tardive, plus la priorité est élevée, de sorte que chaque nouvelle période remplace proprement la précédente au moment exact où elle commence.

Trois règles qui définissent le comportement d'une URL au cours des 3 prochaines semaines

Vérifier avant la mise en ligne

Le changement étant basé sur le temps, vous n'avez pas besoin d'attendre la date réelle pour le vérifier. Utilisez le testeur de règles et ajoutez une restriction DATETIME définie sur un moment futur pour simuler cette date.

Par exemple, tester /weekly-offers avec Datetime is 08/07/2026 00:00 montre quelle(s) règle(s) sera/seront appliquée(s) ce jour-là, l'URL cible résultante, et la liste complète des règles correspondantes dans l'ordre où elles sont évaluées. Cela vous permet de valider l'ensemble du calendrier à l'avance :

Le testeur de règles permet de prévisualiser un état futur

Résumé

Pour planifier des redirections qui remplacent une règle existante sans aucune interruption de service :

Ne modifiez pas une seule règle pour changer sa date et sa cible. La publication remplace la règle et crée un vide jusqu'à la nouvelle date d'activation.
Créez une règle par période, chacune correspondant à la même URL avec sa propre condition DATETIME after et sa propre cible.
Donnez une priorité plus élevée à la règle ayant la date d'activation la plus tardive, afin que la période la plus récente l'emporte lorsque plusieurs règles se chevauchent.
Validez le calendrier à l'avance avec le testeur de règles en simulant un DATETIME futur.

Cette approche vous permet de préparer chaque cible des semaines à l'avance, de ne pas toucher aux URL publiques fixes, et de faire en sorte que chaque redirection prenne le relais automatiquement au moment exact prévu.