La maintenance, c’est savoir que le formulaire livre aujourd’hui, pas que le serveur répond 200.

Le parcours d’une demande jusqu’à un humain, pas la disponibilité du serveur. `GET /api/health/contact` vérifie en une seule requête deux choses : que le jeton du canal de notification est encore valide — via un appel réel au fournisseur, avec un timeout de 8 secondes — et que le journal des demandes peut être écrit. Il répond 200 quand les deux sont vraies et 503 quand ce n’est pas le cas. Vous pouvez l’appeler dès maintenant sur ce site : il est public, justement parce qu’il ne renvoie que des valeurs logiques.

Parce que la partie visible continue de fonctionner. La page se charge, le bouton répond, le serveur renvoie 200 sur toutes les pages — seule la dernière étape se casse, celle qui n’a pas d’interface. Sur ce site, le jeton du bot de notification a été révoqué : le fournisseur répondait `401 Unauthorized`, la route renvoyait 500, et la demande n’était écrite nulle part. Trois échecs réels en environ sept heures, visibles uniquement dans le journal d’erreurs du processus. C’est pour cela que le journal s’écrit désormais avant la livraison : même si la notification échoue, la demande existe.

La demande est déjà écrite dans le journal avec son propre identifiant, et la deuxième ligne du journal indique `failed` ainsi que la raison. Le visiteur reçoit une réponse distincte — « nous avons reçu la demande, mais nous n’avons pas pu notifier » — pas un faux succès. Le code de réponse différencie la cause : 502 signifie que le fournisseur a mal répondu, 503 que les identifiants manquent chez nous. À 3 heures du matin, la différence entre les deux décide si vous appelez quelqu’un ou non.

Pas sans gate. La publication exécute `npm audit` au niveau `high` et s’arrête sur des vulnérabilités de ce niveau si la poursuite n’est pas confirmée explicitement ; elle vérifie d’abord aussi la mémoire disponible du serveur, avec un seuil de 500 MB, car une construction lancée sur un serveur étroit laisse l’application arrêtée. La construction se fait à partir du propre : le répertoire de construction et les dépendances sont supprimés, l’installation se fait à partir du fichier de verrouillage. Ce qui est mis à jour automatiquement et ce qui passe par une vérification humaine se décide par projet, pas par défaut.

Par un script de vérification exécuté après la publication, qui ouvre chaque page produit et échoue s’il manque le code 200, l’ancre des questions, l’ancre de l’exemple ou l’adresse canonique. Il vérifie ensuite le sitemap — qu’il contienne chaque produit et ne contienne pas de variantes de langue qui ne peuvent pas s’ouvrir — et `robots.txt`, pour ne pas bloquer les ressources de rendu. Chaque vérification de la liste correspond à quelque chose qui s’est déjà cassé une fois. Le script est livré avec le projet.

Le processus redémarre automatiquement au-delà du seuil de 500 MB, avec 4 secondes de délai entre les tentatives et une augmentation exponentielle, mais il s’arrête après 10 redémarrages instables sur une courte période. C’est important : une boucle de plantage qui redémarre à l’infini paraît saine dans un tableau de bord et consomme le serveur en silence. Nous préférons que le processus reste arrêté et visible.

24 mois, appliqués par le code, pas seulement déclarés : le seuil est une variable avec la valeur par défaut de 730 jours, et les fichiers plus anciens sont supprimés à chaque nouvelle écriture, sans planificateur qui peut être oublié. Le répertoire a les droits `0700`, les fichiers `0600`, et le chemin se trouve en dehors du répertoire de version, afin que l’historique survive à la publication. L’adresse IP n’est pas conservée en entier : elle est tronquée à `/24` pour IPv4 et `/48` pour IPv6, en lisant le dernier saut dans l’en-tête, pas le premier — le premier est envoyé par le client et ne signifie rien.

Cela arrive, et ce sont généralement les plus coûteux. Le même passage dans le code qui a réparé le formulaire a mis au jour deux choses que personne n’avait signalées : la limite de requêtes pouvait être contournée complètement, parce qu’on lisait le premier élément de l’en-tête d’adresses redirigées — exactement celui que le client envoie ; et une route qui initiait des appels téléphoniques était ouverte anonymement, à nos frais, alors que le composant qui l’utilisait avait été démonté. Les deux ont été réparées et vérifiées en production. Ce que nous ne pouvons pas promettre, c’est de tout trouver ; ce que nous pouvons promettre, c’est de signaler aussi ce que vous n’avez pas demandé.

Ce n’est pas un service de sécurité avec surveillance non-stop et ce n’est pas un centre d’opérations. Nous ne garantissons pas un pourcentage de disponibilité sans une mesure qui le soutienne — et, pour que ce soit clair, à ce moment-ci nous ne publions pas un tel chiffre pour notre propre site. Nous ne prenons pas en charge la responsabilité d’une plateforme tierce à laquelle nous n’avons pas accès. Et nous ne traitons pas une page qui répond 200 comme une preuve que tout fonctionne : c’est exactement le problème à partir duquel tout ce qui est écrit ci-dessus a commencé.