TL;DR
Un projet long avance par cases cochées. Le problème n'est pas de les cocher, c'est de savoir où on en est sans relire un plan entier ni croire une déclaration. J'ai écrit un petit runner qui compte les cases d'un plan, calcule le temps restant, et publie un état toutes les dix minutes. Zéro dépendance, zéro auto-verdict : il ne dit que ce qu'il a mesuré.
Le piège de l'avancement déclaré
Il y a deux façons d'annoncer son avancement, et une seule est honnête.
La première consiste à se décrire : « j'ai bien avancé, presque fini ». Le piège est connu : un auteur peut signer son propre verdict sans rien vérifier. La seconde consiste à compter un fait : combien de cases étaient cochées à l'instant T, combien de fichiers ont réellement été produits, quel commit a introduit quoi.
Le monitoring suit la seconde règle. Sa source n'est pas un ressenti, c'est un fichier : le plan du chantier, avec ses cases [ ] et [x].
Ce que fait le runner
Trois gestes, dix minutes d'intervalle.
- Compter. Il lit le plan, compte les cases faites et à faire, globalement et par lot.
- Estimer. Chaque lot porte un poids en minutes ; le temps restant est la somme des tâches non faites, pondérée. C'est une estimation utile, pas une promesse.
- Publier. Il écrit un fichier d'état, puis pousse un événement sur le bus du système. Si le bus refuse (jeton absent), il n'échoue pas : il ajoute une ligne dans un journal de repli.
Le principe tient en une phrase : un canal indisponible ne casse rien, il dégrade.
Pourquoi un fichier, et pas un tableur
L'état vit dans un fichier JSON lisible par tout le reste du système : une page de cockpit, un dashboard, un agent. Écrire une fois, servir partout.
{
"global": { "fait": 17, "total": 25, "avancement_pct": 68, "minutes_restantes": 380 },
"prochaine_tache": "Re-vérifier les cartographies existantes"
}À partir de là, n'importe quelle vue consomme la même vérité : pas de copie, pas de dérive.
Le déclencheur périodique
Deux options, selon l'endroit où la tâche doit survivre :
- une boucle dans le processus de travail — simple, elle meurt avec la session ;
- une tâche planifiée de l'OS — elle survit à la fermeture, au prix d'un peu de configuration.
J'ai choisi la seconde pour que le suivi continue même quand je ne regarde pas, avec un script déclenché toutes les dix minutes. Le journal du tick garde la trace de chaque évaluation : si un rafraîchissement manque, on le voit.
Les règles que je me suis données
- Mesurer un fait, pas une intention. Une case comptée est un fait ; « bientôt fini » n'en est pas un.
- Un échec réseau n'est pas un échec de suivi. Repli fichier systématique.
- Aucun secret dans un événement. Ni jeton, ni URL signée, ni chemin sensible.
- Un événement daté, avec un identifiant de lot. Sans identifiant, il n'est pas exploitable.
Et maintenant
Le runner tourne, l'état se rafraîchit, la prochaine étape est de le brancher au jeton du bus pour que le cockpit et l'interface de jeu affichent l'avancement en direct. La suite : un article sur ce que ça change de voir une tâche avancer plutôt que de l'imaginer.