Ferry : une carte Jira bouge, une pull request arrive

Une carte Jira change de colonne. Quelques minutes plus tard, une pull request relue arrive sur la branche d'intégration. Entre les deux, personne n'a ouvert de terminal.

C'est Ferry. On l'a construit pour nous, on l'a publié sous licence MIT, et il fait avancer le site que tu es en train de lire.

Ferry ne s'invente pas un flux de travail : il se branche sur celui qui existe déjà. Chaque agent écoute une colonne du board, et c'est le déplacement de la carte qui le déclenche.

Le raffineur reprend un ticket vague et le rend implémentable. Le développeur écrit le code et ouvre la pull request. Le relecteur l'examine : il approuve, ou il demande des changements. L'itérateur reprend la main sur les demandes de changement. Le fusionneur merge, et referme le ticket.

Chaque étape repositionne la carte elle-même, ce qui évite le pire défaut de ce genre d'outil : un board qui ment sur l'état réel du travail. Ici le board est l'état, parce que c'est lui qui commande.

La plupart des outils de cette famille demandent un service qui tourne quelque part : une machine, un démon, un webhook à exposer, et la maintenance qui va avec. Ferry n'a rien de tout ça. Il s'exécute dans GitHub Actions, sous forme d'un workflow de routage qui appelle l'agent correspondant à la transition détectée.

La conséquence pratique compte plus que l'élégance : il n'y a pas de serveur à payer, pas de secret à faire circuler hors de GitHub, et pas de composant supplémentaire capable de tomber pendant la nuit. L'installation se résume à une commande, et le workflow installé se régénère en la rejouant.

Laisser des agents merger tout seuls n'a d'intérêt que si ce qu'ils produisent doit franchir les mêmes portes que le travail humain. C'est là qu'est le vrai sujet, et c'est la partie qu'on a le plus travaillée.

Les agents ouvrent leurs pull requests sur la branche d'intégration, jamais sur la production. La chaîne de qualité du projet — lint, tests, build — est une vérification obligatoire sur chaque pull request, sans exception pour l'automate. Et les fichiers de workflow de Ferry lui-même sont sous CODEOWNERS : un agent ne peut pas modifier les règles auxquelles il est soumis.

Ce dernier point est le plus important des trois. Un pipeline d'agents qui peut réécrire ses propres garde-fous n'a plus de garde-fous.

Ferry est publié sous licence MIT, sur GitHub et sur npm. On ne le présente pas comme un produit fini : c'est un outil qu'on a écrit pour notre propre usage et qu'on maintient parce qu'on s'en sert. Le meilleur test de régression qu'on lui connaisse, c'est ce site.

Le modèle utilisé par chaque agent se règle par configuration — un modèle solide pour le raffinage, la relecture et le merge, où se joue le jugement ; un modèle plus rapide pour l'exécution. C'est le genre d'arbitrage qu'on règle en une variable plutôt qu'en refondant la chaîne.