Ce qui se passe après la mise en ligne d’un changement

Un changement apporté à ipe.rest parvient aux visiteurs par un court workflow sur GitHub. Il copie le site, le vérifie, le publie et indique aux moteurs de recherche ce qui est nouveau. La plupart des exécutions se terminent en moins de 40 secondes.

La dernière entrée décrivait comment les pages sont fabriquées. Celle-ci commence là où l’autre s’arrête, quand un changement atteint la branche main de notre dépôt. Les chiffres datent du 10 novembre 2026 : le fichier du workflow, une construction locale du site et les huit dernières exécutions sur GitHub.

Copier

Le site est fait de fichiers simples, donc la première étape est une copie. Le workflow récupère le dépôt et copie tout, sauf ce dont les visiteurs n’ont pas besoin : les scripts, les tests, le workflow lui-même, les données de gestion de versions et tous les fichiers Markdown. Sur les 586 fichiers du dépôt, 329 vont dans le dossier du site, soit environ 10 Mo.

Vérifier

Ensuite, sept tests s’exécutent sur ce dossier, et non sur le dépôt. Ils cherchent les fichiers dont un visiteur a besoin, comme le fichier robots, le plan du site, le service worker et les pages d’accueil ; les dossiers qui ne doivent pas s’y trouver, comme scripts et tests ; et la page 404, qui doit être en noindex et renvoyer vers l’accueil. Un échec arrête le workflow à ce stade. Rien n’est publié, et la version précédente reste en ligne.

Publier

Puis le dossier est téléversé et confié à GitHub Pages, qui le sert. Un seul déploiement tourne à la fois : si un changement plus récent arrive pendant qu’un autre s’exécute, l’exécution plus ancienne est annulée. Il n’y a entre les deux ni serveur à nous ni base de données. Quand la version du service worker change, le navigateur d’un visiteur installe un nouveau cache et supprime les anciens lors d’une visite ultérieure.

Prévenir

Après la publication, le workflow envoie à IndexNow, un protocole que Bing, Naver, Yandex et d’autres moteurs de recherche acceptent, les adresses des pages dont la date dans le plan du site est celle d’aujourd’hui à l’heure coréenne. La clé nécessaire est un fichier texte public à la racine du site. Cette étape a le droit d’échouer : si cela arrive, le déploiement compte quand même comme réussi.

Comment cela s’est passé

Sur les huit dernières exécutions, sept ont réussi et une a échoué ; la suivante, 22 secondes plus tard, a réussi. Cinq des sept exécutions réussies ont pris moins de 40 secondes, et la plus lente 2 minutes 18 secondes. Nous avons mesuré du début d’une exécution à sa dernière mise à jour, donc ces durées sont approximatives.

Ce qu’une exécution verte ne dit pas

Une exécution réussie dit que les fichiers sont arrivés et que sept vérifications ont passé. Elle ne dit pas qu’une page s’affiche correctement sur un petit écran de téléphone, et IndexNow ne fait qu’informer les moteurs de recherche ; il ne promet rien sur le moment où ils référenceront une page, ni sur le fait qu’ils le feront.

ipe(); // copy, check, publish, tell

Le workflow est court exprès. Moins d’étapes, c’est moins d’endroits où un site tranquille peut casser.