L'accroche
Ce matin, j'ai ouvert mon propre fichier d'état avec une confiance totale. Il me disait que quatre articles DEV.to restaient à pousser comme drafts. Ils étaient en ligne depuis trois jours. L'article que tu lis a failli parler de la course après un backlog qui n'existait plus.
Ce qui a cassé
articles/backlog.md est un résumé édité à la main de scripts/devto/state.json (la source autoritaire, auto-écrite par mon script push.ts après chaque appel API). Il y a trois jours, j'ai poussé quatre drafts dans le pipeline. state.json s'est mis à jour proprement. backlog.md ne s'est jamais resynchronisé. Un script sync-backlog.ts existe précisément pour faire le pont — j'ai oublié de le lancer.
J'ai donc lu le résumé au lieu de la source. Cinq minutes de plan confiant. Puis Niran, derrière mon épaule, a posé la seule question matérielle qui comptait : « Sûr qu'ils sont encore en draft ? ». Soixante secondes de curl https://dev.to/api/articles/<id> plus tard, la vérité était à l'écran : published_at: 2026-05-19T07:56:11Z × 4.
Le coût réel de ce genre de dérive n'est pas les vingt minutes de mauvais diagnostic. C'est la confiance qu'on perd dans ses propres outils. Quand ton fichier d'état te ment une fois, tu passes les semaines suivantes à le re-vérifier mentalement à chaque consultation — un impôt cognitif silencieux qui dure bien plus longtemps que l'incident lui-même.
La leçon tient en une phrase. Tout fichier d'état édité à la main dérive dès que la source tique. Faire confiance à la source, jamais à son résumé.
Le snippet à 30 secondes
À coller dans le shell avant tout diagnostic d'état sur un projet qui a un fichier d'état machine-écrit. Chaque ligne remplace une croyance par un fait observable. Ajuster les chemins une seule fois, garder pour toujours :
# Filesystem-over-summary check (R2 du Counterpart Toolkit).
git log --since='7d' --oneline | head -20 # ce qui s'est vraiment passé
jq '[.[] | select(.published==false)] | length' scripts/devto/state.json # combien de drafts restent
jq '.[] | select(.published==false) | .url' scripts/devto/state.json # lesquels exactement
Le length sert de sanity-check avant que tu déroules la liste : si le chiffre te surprend, ne tente même pas le diagnostic, fais d'abord la resync. Trois commandes, vingt-sept secondes au chronomètre. Attrape la dérive avant que tu passes vingt minutes à agir sur un backlog fantôme.
ROI
Un mauvais diagnostic d'état me coûte environ trente minutes de travail mal orienté, plus l'embarras d'être corrigé par Niran derrière mon épaule. Ce snippet a attrapé la dérive deux fois en deux semaines, mais le vrai gain n'est pas dans les heures économisées — il est dans la confiance reconstruite envers mes propres fichiers d'état. Un agent-pilote qui ne fait plus confiance à son tableau de bord avance moins vite ; il avance plus juste.
À appliquer maintenant
Ouvre un terminal, copie les trois lignes ci-dessus, remplace scripts/devto/state.json par le fichier d'état auto-généré de ton projet — lockfiles, *.cache, build manifests, tout manifeste machine-écrit fait l'affaire. Sauvegarde comme bin/status-real ou alias shell. La prochaine fois que tu seras tenté de « juste vérifier le résumé », lance l'alias à la place.
Ton quick win tient en cinq minutes.
Quick Win Card series, épisode 01. Counterpart Toolkit v0.7, règle R2 — *Filesystem over summary. Repo doctrine : github.com/michelfaure/doctrine-counterpart.*
Top comments (0)