Mes outils triaient, ils ne réfléchissaient pas

Fin juin, j'en étais à mon deuxième outil de suivi en cinq semaines, et je préparais déjà le passage au troisième. Avec toujours la même impression : tourner en rond.

À chaque fois, je me disais que le problème venait de l'outil. Le tableau GitHub qui me bouffait mon quota d'API. Les notes Obsidian qui se marchaient dessus à la synchro. Alors je migrais, je réécrivais mes commandes, et deux semaines plus tard j'étais agacé pareil.

Le problème ne venait pas de l'outil.

Le premier de la liste#

J'avais huit commandes maison pour piloter mes projets avec Claude Code. /next-issue pour savoir quoi faire, /start-issue pour démarrer, /open-pr, /merge-pr, et quelques autres.

/next-issue, c'était ça : trier les tickets par priorité, puis par taille, puis par date. Et afficher le premier.

C'est tout. Il ne regardait pas ce qui bloquait quoi. Ni ce qui était à moitié fait. Ni ce qui débloquait le plus de choses derrière. Le modèle, lui, ne voyait jamais le backlog : un script Python avait déjà décidé, et il me lisait le verdict.

J'avais un modèle capable de raisonner sur un projet entier, et je m'en servais pour lire à voix haute la première ligne d'un tableau trié.

Le 1er juillet#

Ce jour-là, j'ai fait un paquet avec tout : mes huit commandes, le Python derrière, l'historique de mes migrations. Et une note, en gros : voilà mon process, il est trop binaire, démolis-le.

J'ai donné ça à une session vierge. Sans contexte, sans rien à défendre.

Elle a trouvé ce que je sentais sans arriver à le dire. Et un truc que je n'avais pas vu du tout : ma règle « CI verte avant de merger » n'existait que dans un texte. Le code, lui, envoyait le merge sans rien vérifier.

Une session pressée pouvait merger du rouge. Rien ne l'en empêchait, à part sa bonne volonté.

Tout à l'envers#

J'avais mis le jugement dans le code, et les règles dans la prose. Exactement l'inverse de ce qu'il fallait.

Le tri des tickets, c'est du jugement : ça dépend du contexte, et un modèle fait ça très bien si on lui montre les données. Je l'avais figé dans un sorted().

La CI verte, c'est une règle : ça ne se discute pas, et ça ne doit dépendre de l'humeur de personne. Je l'avais confiée à un paragraphe.

Foundry part de là. Le jugement dans les skills, les invariants dans le code.

Côté lecture, le Python renvoie tout le graphe du projet — les liens entre tickets, les critères d'acceptation, l'avancement — et ne décide rien. Le classement par priorité existe toujours, mais c'est un champ parmi d'autres. Le modèle peut passer outre, à condition de dire pourquoi.

Côté écriture, c'est l'inverse. Le merge passe par une porte, et la porte est en Python :

proven = any(c.status == "completed" and c.conclusion == "success" for c in checks)
...
"passed": (proven or waived) and not pending and not failing,

Il faut au moins un contrôle qui a vraiment réussi. Rien d'en cours, rien de rouge. Zéro contrôle, ça ne passe pas. Tous les contrôles ignorés, non plus : « personne n'a dit non » n'est pas un oui.

Arrêter de rediscuter#

L'autre moitié du « tourner en rond », c'était ça : rouvrir des décisions déjà prises. Tu tranches un choix d'architecture un mardi, et trois semaines plus tard une session toute fraîche te propose, très enthousiaste, l'option que tu avais écartée.

Maintenant chaque décision est écrite. Avant de toucher à un sujet, Foundry charge celles qui le concernent et les considère comme réglées. Une idée déjà refusée est refusée de nouveau, avec le numéro de la décision. Pour changer d'avis, il faut le faire exprès.

Quatre Français#

Depuis août, le travail est réparti entre quatre rôles. Je leur ai donné des noms de chez nous.

Lupin explore le dépôt. Il entre partout et ne touche à rien.

Eiffel construit, un ticket à la fois.

Maigret relit le diff avant le merge. Il arrive sans rien savoir de la conversation qui a produit le code, et il ne croit que ce qu'il voit.

Vauban ne se déplace que pour l'architecture.

Chacun tourne sur le modèle qui lui suffit. Pas besoin du plus cher pour aller lire trois fichiers.

Là où j'en suis#

Le premier commit date du 1er juillet. Le lendemain, j'en étais à la huitième version.

Deux mois plus tard : seize skills, environ 36 700 lignes de Python, 1 346 tests. Ça tourne sur Claude Code et sur Codex. Et ça pilote Orfeo, Luchamon et Souffle.

Trente-six mille lignes pour un outil perso. Moi qui répète « pas de sur-ingénierie » à longueur de journée.

Je ne l'assume pas. Mais ça fonctionne bien.

Dans les prochains articles : comment j'ai usé mes outils de suivi les uns après les autres, ce que veut dire « prouvé vert », et pourquoi presque toutes mes mesures sont revenues avec la mention « non concluant ».

— Pato