Soixante-huit handoffs, six urgences : la carte de ce qui reste ouvert

TL;DR — Une liste dispersée oublie toujours le cas suivant. Ce billet raconte comment on a transformé un inventaire éparpillé (handoffs, tâches interrompues, urgences) en une carte mesurée, projet par projet : deux passes de mesure, six urgences transverses nommées, et un point d'articulation unique — le dublog du blog — qui bloque tout le reste. Le tout est publié au hub des présentations, avec une leçon de méthode en prime : une carte non versionnée n'existe pas.

Le problème : le travail se perd dans les listes, pas dans le code

Un dépôt qui vieillit accumule deux dettes. La première est visible : du code à corriger. La seconde ne l'est pas : des décisions en attente, des tâches commencées puis interrompues, des urgences que personne n'a nommées. Cette seconde dette ne casse aucun test. Elle pourrit en silence, répartie dans des dizaines de fichiers à format libre que personne ne relit d'un seul tenant.

Au dernier relevé, le méta-dépôt portait 68 handoffs — dont 11 ouverts et 26 au statut inconnu (plans de juin dormants, états d'autres machines, non prouvables d'ici). Le registre du blog portait, lui, sept sujets qui « attendent une phrase » — pas un travail, juste une décision humaine. À quoi s'ajoutent six urgences transverses qui ne dépendent d'aucun dépôt en particulier.

Rien de tout ça n'était lisible en une lecture. C'est ce qu'on a corrigé.

La méthode : deux passes, et « mesuré » qui bat « déduit »

La règle du workspace est simple et non négociable : un constat d'audit est daté et appuyé sur une commande rejouable, jamais déduit de la prose. Un handoff qui se déclare « clos » ne l'est pas parce qu'il l'écrit — il l'est parce qu'un git le prouve.

On a donc mesuré en deux passes :

1. Première passe — les sources canoniques : le STATUS du workspace, l'index des handoffs, les fiches d'audit du jour, l'audit push/pull des 49 dépôts, le registre des sujets ouverts du blog.
2. Seconde passe — les handoffs non lus : les treize du dépôt de l'agent local, ceux de la Citadelle, de vfg-system, du harnais fast-coder, de Fil/Chronowflow, du portail maison. Plus les divergences git détaillées et les worktrees en avance.

Le résultat a fait apparaître un fait que la prose cachait : la plupart des « urgences » ne sont pas des travaux, ce sont des décisions. Et une seule d'entre elles bloque les autres.

Six urgences, mais un seul verrou

Les six urgences transverses, nommées avec leur preuve :

• Le dublog du blog — deux clones divergent, et le manifeste pointe vers le moins à jour. C'est le verrou.
• Le push refusé du hub agentique — non fast-forward, parce qu'un collègue travaille dans le même fichier. On ne force pas : on décide.
• La rotation des secrets — quatre jetons d'infrastructure présents en clair, un jeton de bot exfiltré puis masqué. Rotation = fenêtre coordonnée, serveur + trois clients.
• L'instabilité d'un service de ledger sous la nouvelle version de Node — il re-crashe au démontage, une garde de quinze minutes le relance. Trancher : rétrograder, épingler, ou superviser.
• Un point d'API en 401 en production — ouvert depuis juin, le service répond mais pas sur cette route.
• Un service de chronologie en 502 — déclaré « en production », mesuré mort.

Le point d'articulation est le dublog. Il débloque à la fois le registre à publier, le sort d'un article en attente, et lève l'ambiguïté « quel clone est canonique ». Tant qu'il n'est pas tranché, plusieurs tâches du blog restent en pause. C'est ça, une carte utile : non pas lister tout, mais montrer ce qui dépend de quoi.

De la mesure à la carte : versionnée, puis servie

Une carte qu'on lit une fois ne sert à rien. Il faut qu'elle reste lisible — donc qu'elle soit à un endroit qu'on retrouve.

Deux gestes. D'abord versionner : la première version vivait dans un dossier d'aperçus local, ignoré par Git — donc éphémère. On l'a déplacée dans un dossier suivi du méta-dépôt, à côté de l'atlas. Ensuite servir : on l'a ajoutée au hub public des présentations, comme « Sujet 10 », et déployée. La carte est maintenant consultable en ligne, comme les autres.

Trois détails de méthode valent d'être écrits :

• Une page servie est publique. La carte citait, par son chemin réel, l'emplacement d'un jeton d'accès. Pour un document interne c'est un détail ; pour une page publique, c'est une fuite. On a produit une variante désensibilisée avant de publier — et vérifié par un scan que plus aucun motif de secret ne subsiste (deux correspondances restantes, toutes deux des faux positifs : le mot « redactés », un nom de fichier).
• Rebaser après un retard. Au moment de pousser, la branche servie avait pris vingt-deux commits d'avance. Réflexe mesuré : vérifier que aucun de ces commits ne touche le fichier qu'on modifie. Zéro commit, zéro conflit — le rebase est passé sans friction.
• Un 200 ne prouve pas la livraison. On a relu le contenu servi (le compteur du hub, la présence de la carte, le titre de la page), pas seulement le code HTTP.

Ce qu'on emporte

Trois leçons, écrites pour être réutilisées :

1. Le travail se perd dans les listes, pas dans le code. Un dépôt sans carte des décisions en attente vieillit plus mal qu'un dépôt avec des bugs.
2. Une carte non versionnée n'existe pas. Un artefact dans un dossier ignoré disparaît au premier nettoyage ; c'est un brouillon, pas un livrable.
3. Ce qui bloque, c'est une décision, pas un travail. Nommer les six urgences ne les ferme pas ; montrer que le dublog les débloque, si.

La carte est en ligne. Elle dit, en une page, ce qui reste ouvert, ce qui bloque, et à qui ça revient. Le reste — trancher le dublog — n'est plus qu'une phrase à écrire.