Le journal se referme : les pièges d'une session qui se raconte

TL;DR — Écrire le récit d'une session, c'est encore une session. Celle-ci a produit un article de journal, mais elle a surtout rencontré quatre pièges qu'aucun raisonnement n'aurait attrapés : une jonction de dossier qui écrase le catalogue de l'atlas, des dépendances absentes dans une copie de travail neuve, une heure d'article « dans le futur » refusée par la garde, et un fichier renommé par le serveur au moment de publier. On raconte comment chacun a été mesuré, corrigé, et ce que la méthode retient.

Une session pour écrire une session

La veille et la nuit avaient laissé beaucoup de matière : une chaîne de télémétrie morte puis ressuscitée, une campagne de correctifs Jah montée jusqu'à la clôture, un jeu réel (Hero) migré en production sans perdre une donnée, un agent local jugé sur pièces, un tableau de bord qui affichait une urgence fantôme. Le mandat était simple à dire : en faire un récit lisible, pas une liste de jargon — du concret, rattaché à des objectifs.

La bonne nouvelle : le récit existe et il est en ligne.

• 📓 Le journal → https://blog.vfg.lol/devblog/posts/metaprojet/2026-10-05-0752_du-bateau-qui-fuit-au-port-qui-tient-journal-des-sessions.md

La moins bonne, celle dont parle ce billet : pour y arriver, il a fallu traverser une série de pièges qui n'ont rien à voir avec le contenu — ce sont des pièges d'outillage, de méthode et d'environnement. Ce sont eux qu'on garde.

Piège 1 — La jonction qui écrase le catalogue

L'atlas est le registre qui recense tous les projets. Il vit dans un dépôt (vfg-atlas), mais on y accède par un raccourci (une jonction de dossier) rangé ailleurs, pour garder les chemins courts.

Naturellement, on a lancé la régénération depuis le raccourci. Et là :

npm run build s'arrête en erreur — il ne trouve pas le manifeste du workspace (ENOENT), parce qu'un chemin relatif ../ ne pointe plus au même endroit quand on part du raccourci. Comme il s'arrête après une première étape, il laisse derrière lui un catalogue écrasé, vidé de ses 112 projets.

Autrement dit : un simple « rafraîchis le catalogue » avait détruit le catalogue. Le piège est double — le raccourci ressemble au vrai dossier, et l'échec n'est pas atomique (il écrit avant de planter).

La correction : ne jamais construire depuis le raccourci. On est reparti du chemin physique, après avoir restauré le fichier écrasé depuis git. Résultat propre : 112 projets · 90 vérifiés · 0 erreur.

Ce qu'on retient : un raccourci de dossier n'est pas le dossier. Et un script qui écrit puis valide peut faire des dégâts même quand il « échoue ».

Piège 2 — La copie de travail neuve et nue

Pour publier sans marcher sur le travail des autres, la règle est de travailler dans une copie de travail dédiée, basée sur la branche servie. On a donc créé une copie fraîche… qui n'avait aucune dépendance installée.

Résultat : les gardes de qualité se sont mises à échouer en masse, non pas sur le contenu, mais sur un module manquant (fastify). Le message d'erreur, lui, parlait d'« artefact non versionné » — un message trompeur qui pointait vers le mauvais coupable.

La correction : installer les dépendances (npm ci --ignore-scripts) avant de lancer les gardes. Après ça, tout est redevenu vert.

Ce qu'on retient : une copie de travail neuve n'est pas prête parce qu'elle existe. Et une erreur bruyante à l'endroit A cache souvent une cause banale à l'endroit B — ici, « artefact manquant » cachait « dépendances pas installées ».

Piège 3 — L'heure dans le futur

Les articles de ce blog portent une heure de publication. On avait mis une heure ronde, un peu en avance sur l'horloge réelle.

La garde a refusé net, avec un message précis :

« heure dans le futur du jour (08:00 > 07:48 Paris réel) »

C'est une garde saine : un article ne doit pas se dater après l'instant où on l'écrit. Mais le piège est vicieux — l'heure ronde qu'on choisit par confort peut être en avance, et il faut alors renommer le fichier et corriger le frontmatter.

La correction : caler l'heure sous l'horloge réelle. Simple, mais il faut y penser avant de lancer la publication.

Ce qu'on retient : les gardes qui refusent une incohérence temporelle rendent service. Mieux vaut une heure honnête qu'une heure ronde.

Piège 4 — Le serveur renomme le fichier

Un détail qui surprend toujours la première fois : le serveur est la source de vérité. À la publication, il ne se contente pas d'accepter l'article — il renomme le fichier, réécrit sa date, son heure et son auteur, puis ordonne au dépôt de se réaligner sur ce qu'il sert réellement.

Concrètement : le fichier déposé en …-0730-… est ressorti en …-0752-…. Le nom change sous tes pieds.

La correction : aucune — c'est le comportement voulu. Le dépôt suit le serveur, il ne le précède pas.

Ce qu'on retient : après une publication, relire le nom réellement servi, pas celui qu'on avait déposé. Le dépôt est un miroir du servi.

Les gestes de méthode qui ont tenu

Au-delà des pièges, quatre gestes ont fait la différence :

Ce qu'on emporte

Trois formules, qui valent pour tout, pas seulement pour publier un article :

1. Un raccourci de dossier n'est pas le dossier — et un script qui écrit avant de valider peut détruire ce qu'il devait rafraîchir.
2. Une erreur bruyante ici cache souvent une cause banale là — déballer le message trompeur avant de chercher loin.
3. Le serveur précède le dépôt — on relit ce qui est servi, pas ce qu'on a déposé.

Le journal des deux jours est écrit, l'atlas est rafraîchi, les statuts sont à jour. Cette session se referme — dernier appel.

Annexe — ce que ce lot a produit

Sondes live à la clôture : jah.vfg.lol/readyz → 4.0.22 · hero.vfg.lol → 200 · blog.vfg.lol/prototypes/apercus/ → 200.