Mettre un site en maintenance paraît simple : on remplace la page par un message « de retour bientôt ». En pratique, c’est souvent le moment où le développeur a le plus besoin d’accéder au vrai site pour vérifier sa mise à jour. Sur Azim404, l’écran de travaux est pensé pour les deux publics à la fois : les visiteurs voient un message soigné, le développeur continue de naviguer normalement.

Un interrupteur dans la console

Chaque site de l’écosystème a sa fiche dans la console : son domaine, son titre de maintenance, son message et un interrupteur. On peut mettre tout le site en travaux ou seulement certaines adresses, par exemple une page de paiement en cours de refonte. Le changement est immédiat, sans redéploiement ni redémarrage, parce que la décision n’est pas écrite dans le code du site mais demandée à chaque visite.

nginx pose la question à chaque requête

Chaque site du serveur passe par le module auth_request de nginx. Avant de servir une page, nginx envoie une petite requête interne à l’API de la console : ce site, à cette adresse, est-il en travaux pour ce visiteur ? Si la réponse est non, la page est servie comme d’habitude. Si elle est oui, nginx affiche l’écran de travaux à la place, aux couleurs du site concerné.

Un point compte plus que les autres : si l’API de la console ne répond pas, le site reste ouvert. Une panne de l’outil d’administration ne doit jamais couper les sites qu’il administre. Le même principe vaut pour les nouveaux projets, qui reçoivent automatiquement l’inclusion nginx de l’écran de travaux lors de leur création.

  • tout le site ou seulement une liste d’adresses ;
  • un titre et un message propres à chaque site ;
  • les couleurs relevées sur le site, retouchables dans la console ;
  • aucun redéploiement : le changement s’applique à la requête suivante.

La dérogation : un cookie signé

Pour que le développeur continue de voir le vrai site, la console lui délivre une dérogation. C’est un cookie HttpOnly signé par le serveur, valable trente jours et partagé par tous les sous-domaines. Il est accordé à une session administrateur ou contre une clé secrète, et nginx le transmet à l’API avec la question habituelle. Le cookie n’est pas lisible par le JavaScript des pages, ce qui le protège des scripts tiers.

Les anciennes versions stockaient une clé en clair dans le navigateur. Ce n’était pas satisfaisant : n’importe quel script de la page pouvait la lire, et la clé ne pouvait pas être retirée à distance. Avec un cookie signé, le serveur garde la main : il vérifie la signature à chaque requête et peut révoquer la dérogation à tout moment. Un bouton « Quitter » permet aussi de revenir à la vue d’un visiteur pour contrôler l’écran.

Les robots et les audits

Un site en travaux reste mesurable. Les outils d’audit de la console présentent eux aussi le cookie de dérogation sur les domaines azim404.com : ils notent le site tel qu’il est vraiment, et non son écran de maintenance. Sans cela, un site mis en pause quelques minutes perdrait toute sa note de sécurité ou de performance au prochain passage.

Ce mécanisme tient en quelques dizaines de lignes de configuration et un point d’API. Il évite de modifier chaque projet, fonctionne avec n’importe quelle technologie servie derrière nginx et laisse le développeur travailler sereinement pendant que les visiteurs patientent devant un écran à l’image du site.

Bien rédiger le message

Le texte de l’écran compte autant que la technique. Un bon message dit ce qui se passe, combien de temps cela devrait durer et comment joindre quelqu’un en cas d’urgence. L’écran de travaux d’Azim404 affiche une adresse de contact copiable en un clic : un visiteur qui avait besoin du site peut prévenir directement, au lieu de repartir sans laisser de trace.