Un article par dépôt : réparer, assainir, automatiser

TL;DR

Le journal ne montrait plus les évolutions des projets. La cause n'était pas un manque d'articles : les statuts de nos dépôts étaient gelés depuis trois mois, et le robot censé les publier tournait au vert… en ne collectant rien. On a mesuré, réparé la couverture (11 dépôts sur 21), assaini le contenu (qui fuyait des chemins de poste et des noms de secrets), publié 21 articles, et branché une tâche quotidienne. Ce texte documente la chaîne complète — y compris l'échec de déploiement qu'elle a provoqué, et pourquoi c'était une bonne nouvelle.

Le symptôme, et ce qu'il cachait

Un doute simple, exprimé par FG : « j'ai l'impression de ne pas voir tous les articles — il doit y avoir au moins un article par évolution des dépôts ».

C'était vrai, et mesurable. Trois faits :

• Les statuts étaient gelés. Les articles « STATUS — tel dépôt » servis par le blog dataient tous du 29 juin. Rien depuis trois mois.
• Le robot tournait au vert. Le workflow de collecte quotidien affichait success depuis le 7 juillet. Mais il collectait zéro fichier. Un vert qui ne dit rien.
• La couverture était partielle. Le collecteur suivait 11 dépôts, alors que 21 portent un fichier de statut dans le workspace.

Le troisième point explique les deux premiers par un enchaînement classique : une liste écrite à la main qui n'a pas suivi la croissance du parc. Onze noms de dépôts figés dans le code, pendant que le nombre de projets doublait.

Premier geste : mesurer avant de croire

Avant de toucher quoi que ce soit, un inventaire. Un scan des 21 fichiers de statut a révélé deux choses que personne n'avait vues parce que rien ne les publiait :

• 98 chemins de poste — des D:\…, des /opt/…, des préfixes de dossiers internes.
• 22 noms de variables sensibles — et pas des moindres : des jetons de bot, des clés SSH, des secrets de session.

Aucun de ces fichiers n'avait fuité, précisément parce que la chaîne était en panne. La panne avait protégé. Réparer sans assainir d'abord aurait transformé un bug de visibilité en incident de sécurité.

C'est la leçon la plus importante de ce chantier : avant d'automatiser une publication, vérifier ce qu'elle va publier. Un article par dépôt, c'est bien — un article par dépôt qui expose l'arborescence du poste, c'est pire que rien.

Deuxième geste : assainir, et refuser plutôt que masquer

L'assainissement masque :

• les chemins — un lecteur extérieur n'a pas besoin de savoir où vit le fichier sur un disque ;
• les noms de variables — [variable d'environnement] suffit à comprendre, et ne donne pas la liste des cibles ;
• les hôtes internes — adresses locales et réseau privé ;
• les préfixes d'organisation — la hiérarchie de dossiers n'intéresse personne.

Et une règle fail-closed : si un fichier contient une valeur de secret en clair, l'article n'est pas publié. On ne la réécrit pas en silence. Un assainisseur qui « nettoie » une valeur donnerait la fausse assurance qu'aucune n'a fuité — exactement le genre de vert trompeur que ce dépôt combat depuis des mois.

Masquer un nom, refuser une valeur : la frontière est nette, et elle est dans le code.

Troisième geste : la couverture, sans piéger le piège

Étendre la couverture a demandé deux corrections que la mesure a mises au jour :

• Les copies de travail n'étaient pas des dépôts. La découverte ramassait les worktrees — ces copies isolées par branche — et produisait soixante articles parasites. Un worktree est un poste de travail, pas un projet : le publier dupliquerait un même statut par branche active.
• Le même dépôt portait deux noms. Certains dépôts ont un nom court et un alias historique. Dédoublonner par nom court laissait passer le nom long comme un second dépôt : deux articles pour un projet. La seule clé fiable est le dossier réel.

Ces deux pièges ne sont pas des détails : ils montrent qu'une liste « automatique » peut être plus fausse qu'une liste écrite à la main si l'on ne mesure pas ce qu'elle ramasse. Onze était trop peu ; soixante-quinze était pire.

Quatrième geste : automatiser au bon endroit

Ici, une vérité structurelle. Le robot GitHub ne peut pas faire ce travail. Un runner d'intégration ne voit que le dépôt qu'il construit — il n'a aucun accès aux autres dépôts du poste. Il pouvait donc tourner au vert indéfiniment sans jamais voir un seul statut.

L'automatisation doit vivre là où les dépôts existent : sur le poste. Deux façons de la déclencher :

• à la main, une commande qui collecte et publie ;
• toute seule, une tâche planifiée quotidienne.

Cette dernière a été installée et exécutée une fois pour de vrai : code de sortie zéro, vingt-deux dépôts suivis. C'est ce qui distingue une automatisation qui existe d'une automatisation qu'on a écrite.

L'échec de déploiement — et pourquoi c'était une bonne nouvelle

Le déploiement a été refusé. La garde de publication a trouvé, dans un article de statut, un lien vers le dossier d'audits — un chemin qui ne doit jamais être servi publiquement.

C'était la garde qui faisait son travail, et elle a fait mieux que le code : mon assainisseur couvrait les chemins et les noms de variables, mais pas les liens. La faille a été trouvée par un contrôle, pas par un lecteur. Corrigée, testée, republiée — et le déploiement est passé.

Retenir ceci : l'échec était à l'étape de vérification, avant toute synchronisation. La production n'a jamais été touchée. Un refus au bon endroit coûte une heure ; un refus au mauvais endroit coûte un incident.

Ce qui tourne maintenant

• Vingt et un articles de statut publiés — un par dépôt, en ligne, vérifiés.
• Une chaîne assainie — plus aucun chemin, nom de variable ni lien interne dans un statut publié.
• Une garde qui refuse — une valeur de secret en clair bloque la publication.
• Une tâche quotidienne — elle lit les statuts, ne réécrit que ce qui a changé, assainit, publie.

Et la règle de fond, qui vaut au-delà de ce chantier : un compteur se mesure sur la source de vérité, jamais sur le dernier relevé. Onze dépôts « suivis » n'étaient pas onze dépôts réels. Le journal, lui, doit montrer chaque évolution — c'est sa seule raison d'être.