Trois outils de suivi en six semaines

GitHub Projects a tenu treize jours. Mon vault Obsidian, vingt-cinq.

Entre le 24 mai et le 1er juillet, j'ai déménagé deux fois tous mes tickets. Pas par plaisir. À chaque fois, l'outil a cassé sur un truc que je n'avais pas vu venir, et à chaque fois c'était lié à la même chose : ce n'est plus moi qui écris dans le tracker. C'est un agent. Et un agent, ça écrit beaucoup.

GitHub Projects : treize jours#

Le plan était raisonnable. Le code est sur GitHub, les PR aussi, autant y mettre le tableau. Un seul endroit, zéro compte en plus.

Sauf que mes commandes pilotaient GitHub Projects en GraphQL, et que GraphQL a un quota : 5 000 points par heure. Avec un agent qui lit le tableau, déplace une carte, relit, met à jour un champ, le quota partait en une demi-heure de session.

Et le pire, c'est qu'il est partagé. Les commandes gh pr passent par le même. Donc une fois le tableau à sec, je ne pouvais plus ouvrir une PR non plus.

Tu veux merger, et GitHub te répond de revenir quand le quota sera rechargé. À cause d'un kanban.

Le 6 juin, j'ai tout sorti.

Obsidian : vingt-cinq jours#

L'idée suivante me plaisait vraiment. Un ticket, c'est une note Markdown avec un en-tête : statut, priorité, taille. Le tableau, c'est une vue Obsidian qui regroupe les notes par statut. Tout est en local, versionné dans git, lisible sans réseau. Aucun quota. Aucun service à qui demander la permission.

La migration s'est faite en une journée : 156 tickets et 23 décisions d'architecture de Luchamon, importés par script. Sept PR mergées le même jour pour recâbler le reste.

Première perte au passage : les priorités et les tailles. Dans GitHub Projects, ces champs ne sortaient qu'en GraphQL — celui-là même que je fuyais. J'ai tout remis à la valeur par défaut, et retrié à la main ensuite.

Puis les ennuis ont commencé, et ils venaient tous du même endroit. Un vault Obsidian est fait pour un humain qui écrit de temps en temps. Le mien avait trois écrivains : moi, mes commandes, et un bout de CI qui mettait la note à jour quand une PR mergeait. Résultat : des collisions git, et une synchro mobile qui se prenait les pieds dedans.

Le jour même de la migration, il a fallu corriger un premier bug : la CI fermait le ticket côté GitHub avant d'avoir enregistré la note. Si l'enregistrement échouait, le ticket était fermé d'un côté et ouvert de l'autre.

J'adorais le principe. J'ai tenu vingt-cinq jours.

YouTrack : le 1er juillet#

Troisième essai, et cette fois un vrai tracker, avec une vraie API faite pour qu'on tape dessus. 94 tickets pour Orfeo, 248 pour Luchamon dont 154 archivés, 34 décisions d'architecture.

Mais j'avais retenu deux choses des fois d'avant.

Garder les anciens numéros. YouTrack renumérote tout à l'import. J'ai ajouté un champ avec l'identifiant d'origine. Les anciens commits et les anciennes PR pointent encore vers quelque chose.

Vérifier que je peux repartir. Avant de retirer quoi que ce soit du vault, j'ai fait le chemin inverse : ressortir tout YouTrack en Markdown, et comparer. Si l'outil me déçoit dans six mois, je sais que mes tickets ne sont pas otages.

YouTrack a eu ses surprises aussi. Le tableau ne se remplit pas par l'API : il faut cocher une case dans l'interface, puis rattraper l'existant à la main. Et en août, j'ai découvert que la recherche plafonnait à mille résultats sans prévenir. Mais rien qui donne envie de déménager.

Le vrai changement, ce jour-là#

Le 1er juillet, il s'est passé deux choses. La bascule vers YouTrack. Et le premier commit de Foundry.

Ce n'est pas un hasard. À la troisième migration, j'ai fini par voir ce qui me coûtait : pas le déplacement des tickets, que des scripts font en une journée. Ce qui me coûtait, c'était de réécrire toutes mes commandes à chaque fois, parce que chacune parlait directement à l'outil du moment.

Alors dans Foundry, le tracker est une prise. D'un côté, le pipeline et les skills, qui ne connaissent que des tickets, des décisions et des états. De l'autre, un adaptateur qui traduit pour l'outil réel. Le document fondateur le dit dès le premier jour : changer d'outil plus tard, c'est écrire un adaptateur, pas tout réécrire.

Il y a même un adaptateur GitHub Projects dans le dépôt. Vide, pour l'instant. Il est là pour prouver que la prise existe.

Et le mien, tant qu'à faire#

Évidemment, j'ai aussi essayé de construire mon propre tracker. Fin août, branché sur Foundry comme les autres, avec une vraie base de données et de vraies garanties d'écriture.

Je l'ai mis de côté. Trop lourd. Maintenir un tracker en plus de l'outil qui s'en sert, c'était un projet de trop.

Ce que j'en garde#

Trois règles, apprises en payant.

Un agent écrit bien plus qu'un humain. Un outil de suivi qui tient très bien avec moi peut tomber en une demi-heure avec lui.

On garde toujours les anciens identifiants, et on teste la sortie avant de fermer la porte derrière soi.

Et l'outil de suivi ne doit jamais être câblé en dur. Je ne sais pas si YouTrack sera le dernier. Je sais juste que le prochain ne me coûtera pas une réécriture.

— Pato