Une publication au vert, une page absente : ce qu'on a corrigé chez nous
Le 28 août, notre chaîne de publication automatique a terminé au vert. La page annoncée répondait 404. Personne n'a été prévenu. La page est sortie avec 1 h 28 de retard, à la main. Voici la panne, ce qu'elle dit d'un automate qui se déclare content, et les 3 corrections qui l'empêchent de se reproduire en silence.
Le contexte
Ce cas n'est pas chez un client. Il est chez nous, sur ce site. Chaque article de blikt.io est écrit à l'avance, puis publié à date par une chaîne automatique : à 9 h 05, un robot déplace la page dans le site, met à jour la liste des articles et le plan du site, pousse le tout en production, attend que la page réponde, puis prévient le moteur de recherche. Le 27 août au soir, 3 pages étaient programmées, la première pour le lendemain.
Un test à blanc avait été fait la veille. Il avait répondu « rien à publier », ce qui était vrai ce soir-là, et il avait fini au vert.
Le problème
À 9 h 05, rien ne s'est passé. Le planificateur a sauté la première occurrence d'une tâche fraîchement créée, un comportement documenté mais que nous n'avions pas anticipé. Après 34 minutes d'attente, nous avons déclenché la chaîne à la main, à 10 h 18.
Cette fois, tout s'est enchaîné : la page a été déplacée, la liste mise à jour, le tout poussé en production. Puis la chaîne a attendu que la page réponde. Elle a essayé 40 fois, toutes les 15 secondes, pendant 10 minutes. Réponse : 404, quarante fois. Elle a alors envoyé l'adresse de la page au moteur de recherche, qui a accusé réception, et elle a terminé. Statut : vert.
Pendant ce temps, l'hébergeur avait bien reçu le code, et avait refusé de le déployer : le robot signait ses envois sous un nom que le compte d'hébergement ne connaissait pas. Ce refus s'appelle « bloqué », il ne s'appelle pas « erreur », et il ne prévient personne. Résultat : 0 alerte, un robot satisfait, une page absente, et une adresse inexistante déclarée aux moteurs de recherche.
C'est exactement le mécanisme que nous décrivons à nos clients quand nous parlons d'un agent qui tourne sans dire vrai. Cette fois, l'agent était le nôtre.
Ce qu'on a construit
Trois corrections, faites dans l'heure, toutes vérifiables dans le code de la chaîne.
- Le robot signe sous l'identité du compte. L'hébergeur reconnaît l'auteur et déploie. C'est la cause première.
- La chaîne échoue si la page ne répond pas. Après les 40 tentatives, si le code n'est pas 200, la chaîne s'arrête en erreur, avec un message qui dit où regarder. Le moteur de recherche n'est prévenu qu'après une vraie réponse 200. Un résultat absent n'est plus un succès.
- Un second passage à 9 h 35. Si le planificateur saute le premier, le second publie. Quand rien n'est dû, il répond « rien à publier » et n'écrit rien. 2 passages par jour, 0 doublon possible.
La page est sortie à 10 h 33, après la première correction. Les 13 adresses du site ont été renvoyées au moteur de recherche, cette fois avec des pages réelles derrière.
Les garde-fous
Le premier garde-fou existait déjà, et il a fait son travail : nous ne croyons jamais un statut. La consigne de la matinée était de constater la page en production, pas de lire le résultat du robot. C'est ce contrôle, fait à la main, qui a vu la réponse 404 derrière le vert.
Le second est nouveau : la chaîne teste maintenant le résultat, pas son propre déroulement. Elle a été rejouée à blanc après correction, et la page suivante, programmée le 1er septembre, passera par ce chemin.
Le troisième est un principe que nous appliquons chez nos clients et que nous avons dû nous réappliquer : un incident se consigne le jour même, avec son symptôme, sa cause et sa parade, dans un carnet que les prochains chantiers relisent. Celui-ci y est.
Les résultats constatés
| Mesure | Avant | Après |
|---|---|---|
| Page absente, chaîne au vert | possible, constaté le 28 août | impossible : la chaîne échoue sans réponse 200 |
| Adresse déclarée au moteur de recherche | 1 URL inexistante envoyée | envoi seulement après une réponse 200 réelle |
| Occurrence sautée par le planificateur | 1 h 28 de retard, publication à la main | second passage 30 minutes plus tard |
| Déploiement refusé par l'hébergeur | silencieux, vu par un contrôle manuel | identité reconnue, refus impossible |
| Signal reçu par un humain | 0 alerte | 1 échec visible dans le journal, avec la cause |
Le coût réel de cette panne tient en une ligne : 1 h 28 de retard sur une page, et une matinée d'un consultant. C'est peu. Ce qui aurait coûté cher, c'est de ne pas la voir : 3 pages programmées, puis une par semaine, publiées « au vert » dans le vide pendant des semaines.
La leçon vaut pour tout automate, le nôtre comme ceux que nous livrons : un statut de succès ne dit que l'absence de plantage. La seule preuve est le livrable, constaté là où il doit apparaître. Nous l'avions écrit dans un article publié le matin même. La chaîne qui l'a publié nous l'a rappelé. Notre charte dit la même chose en cinq lignes.
Les questions qu'on nous pose
Pourquoi une chaîne automatique peut-elle finir au vert avec une page absente ?
Parce qu'un statut de succès ne dit qu'une chose : le programme n'a pas planté. Ici l'hébergeur avait refusé de déployer, et ce refus s'appelle « bloqué », pas « erreur ». Aucune alerte n'est partie. La chaîne a même déclaré l'adresse au moteur de recherche, alors que la page répondait 404.
Un test à blanc suffit-il à valider une chaîne de publication ?
Non. Le nôtre avait répondu « rien à publier » et fini au vert, ce qui était exact ce soir-là. Il n'avait donc rien testé du chemin réel. Un test qui ne rencontre aucun cas à traiter ne prouve pas que le traitement fonctionne.
Comment rend-on une panne visible ?
En faisant échouer la chaîne sur le résultat, pas sur son propre déroulement. Après quarante tentatives, si la page ne répond pas 200, la chaîne s'arrête en erreur, avec un message qui dit où regarder. Et le moteur de recherche n'est prévenu qu'après une réponse réelle.
Que faire quand le planificateur saute une exécution ?
Prévoir un second passage. Ici, le planificateur a sauté la première occurrence d'une tâche fraîchement créée, un comportement documenté. Un second passage trente minutes plus tard publie ce qui reste dû. Quand rien n'est dû, il n'écrit rien, donc aucun doublon n'est possible.