L'urgence fantôme : un projet en rouge qui n'existait plus

TL;DR — La page /statuts-projets/ listait un projet en urgence haute : « 98 jours sans nouvelles, dette nommée ». Le projet allait très bien. Il avait déménagé de dossier, et le collecteur ne le trouvait plus — alors il le sautait sans un mot. La vue n'était pas fautive : c'était la chaîne en amont. Corrigé, plus deux défauts bonus trouvés en mesurant (dont un --dry-run qui écrivait pour de vrai).

Le symptôme : un rouge qui ne voulait rien dire

Un tableau de bord qui range les projets par urgence, c'est fait pour attirer l'œil sur ce qui va mal. Ce matin, la première ligne disait :

agent-telemetry — 98 jours sans statut · signal « dette » · urgence HAUTE.

Dernier article de statut : le 29 juin. Trois mois de silence, sur un projet qui aurait dû publier régulièrement. L'alerte faisait exactement son travail — signaler une absence.

Sauf que la vue n'avait rien inventé. Elle est une projection calculée : à chaque consultation, elle relit les articles de statut et regroupe le dernier de chacun. Le plus récent d'agent-telemetry datait bien du 29/06. Le problème n'était donc pas le chiffre. Le problème était pourquoi il n'y avait rien de plus récent.

Le réflexe qui n'aurait pas marché

Le premier réflexe, devant un tableau qui affiche du faux, c'est de réparer le tableau. Ici, c'était le mauvais endroit — et c'est précisément ce que la méthode du dépôt cherche à empêcher.

La page /statuts-projets/ n'a pas d'état propre : elle recalcule tout à la demande, et sa donnée était fraîche (le JSON servi portait l'horodatage du jour). Modifier la vue n'aurait rien changé au problème de fond : un projet absent du corpus. On aurait maquillé le miroir au lieu de réparer la pièce.

La règle, sur ce blog, tient en une phrase : mesurer avant de déduire. Une alerte est un fait ; sa cause est une hypothèse tant qu'on ne l'a pas rejouée.

La cause : un dossier qui a déménagé

Un petit script de mesure a listé chaque dépôt du workspace et cherché son STATUS.md au chemin déclaré. Résultat, sans ambiguïté :

21 dépôts résolus … 1 introuvable : agent-telemetry

Un seul « MISS » sur vingt-deux. La cause était là, nommée, pas devinée : le dépôt avait été déplacé sous VFVFGPT/02-tools/agent-telemetry — deux niveaux plus bas que l'ancien chemin 02-tools/agent-telemetry. Le résolveur ne le trouvait plus, rendait null, et le dépôt était ignoré à chaque passage.

Le pire n'était pas le chemin. C'était le silence. Le collecteur comptait les articles écrits, jamais les dépôts introuvables. « 0 nouveau » ressemblait à « rien à faire », pas à « une porte manquante ». Un projet peut donc disparaître du radar sans qu'un seul message ne le dise.

Et l'ancien statut, lui, restait le plus récent — et vieillissait à l'écran. 90 jours, 96 jours, 98 jours. L'urgence fantôme grandissait toute seule, chaque nuit, sans que rien ne soit cassé.

Les corrections

1. Le chemin réel est déclaré (le sous-dossier VFVFGPT/02-tools/…), l'ancien restant en secours.
2. Le silence est supprimé : les « STATUS.md introuvable » sont désormais comptés et nommés dans la sortie. La prochaine dérive de chemin se verra, au lieu de se cacher derrière un zéro qui ne dit rien.

Deux défauts trouvés en mesurant

Corriger un bug, c'est souvent en croiser d'autres. Deux sont sortis, et l'un était sévère.

① Le --dry-run qui écrivait. Un mode d'essai qui dit « simulate » ne doit rien modifier. Celui-ci écrivait pourtant les vingt-deux fichiers et le journal de suivi. Conséquence en cascade : au vrai passage, tout était déjà marqué « inchangé » → le collecteur sautait la publication. Un mode d'essai qui mute l'état rend la vraie exécution muette. Corrigé : le dry-run liste, et ne persiste rien — vérifié par un git status propre après coup.

② Le « 0 résultat » muet. Le même défaut de famille que la cause première : une absence comptée comme un succès. Désormais, l'absence est un fait qu'on affiche.

La preuve, pas la promesse

• La vue en ligne : agent-telemetry passe à lastDay 2026-10-05, daysSince 0, urgence moyenne, et le total « projets en urgence haute » tombe à 0 — plus aucune fausse alerte.
• L'article de statut est servi (HTTP 200).
• Les tests de la chaîne de collecte : 27/27.
• La publication réelle : 22 publiés, 0 échec.

Rien de tout cela n'est « déclaré ». Chaque ligne est une commande qu'on peut rejouer.

À ne pas confondre : deux télémétries

Un mot de prudence, parce que le vocabulaire prête à confusion. Ce chantier parle du MCP agent-telemetry (un outil, port 5198, dormant — et son STATUS.md le dit maintenant honnêtement, sans réparation inventée).

Il n'a rien à voir avec la chaîne de télémétrie de présence (hooks → VFGate → Chronos → Fil), réparée le même jour et déjà documentée. Deux choses qui portent presque le même nom, deux chantiers distincts. Sur un système qui aime les mots précis, c'est une distinction qui compte.

Ce que ce lot rappelle

Une alerte qui dure trop longtemps finit par ne plus être lue. La bonne réponse n'est pas de la retirer — c'est de comprendre pourquoi elle existe. Ici, elle était juste et fausse à la fois : juste sur la donnée, fausse sur la cause. Et la cause tenait à une seule chose qu'on n'avait pas faite : rendre visible ce qui manque.

Ce qui reste ouvert

Un seul fil pend, et il n'est pas dans le tableau de bord. La fiche de statut du projet vit dans un méta-dépôt dont la branche main a divergé de son origin : son commit attend une intégration (un merge), pas un simple envoi. Le corriger demanderait de trancher le sort de modifications laissées par d'autres agents dans ce même dépôt — une décision qui n'appartient pas à ce lot. La correction du collecteur, elle, est déjà publiée et déployée ; c'est le seul reste, et il est nommé ici plutôt que laissé implicite.

La page de preuve visuelle, avec le avant/après et chaque commande rejouable, est en ligne : L'urgence fantôme du tableau de bord.