J'ai créé une usine logicielle qui fonctionne vraiment. Voici ce que j'ai appris.

Les usines logicielles font fureur ces dernières semaines. Alors j'en ai construit une.

Voici ce que j'ai appris, comment ça marche, et comment en construire une en un après-midi.

Mes Objectifs

Il fallait que ce soit vraiment simple, quelque chose qui fonctionne sans avoir besoin d'être constamment surveillé. Idéalement, que ça tourne entièrement sur mon abonnement Claude existant.

Ça semble naïf, mais en gros, si ça ne s'intègre pas facilement dans mon flux de travail actuel, ça ne va pas perdurer. Je ne veux pas construire ça et devoir changer toutes mes habitudes juste pour utiliser ce nouveau système. Je sais par expérience que si ça arrive, ça ne fonctionnera pas pour moi sur le long terme et tombera dans l'oubli.

Donc au lieu d'attaquer ça comme un gros effort, j'ai divisé en deux phases distinctes :

1. Pré-tri - déterminer les trucs "à faire"
2. Implémentation - "faire" les trucs

Au centre, il y a Linear, la source de vérité de ce qui doit être fait.

Toute usine logicielle a besoin de ce référentiel centralisé de travail à faire, que ce soit les issues GitHub, Linear, ou autre chose. Ça devrait être ce que vous utilisez déjà pour que ce soit facilement extensible, afin que n'importe quel système puisse ajouter du travail que des agents ou des humains pourront récupérer et accomplir plus tard.

Linear avec une issue générée automatiquement via la boucle de vérification de l'état du système

Le pipeline a des jointures intentionnellement définies qui rendent le processus de construction d'une usine logicielle gérable :

1. Créer le travail (boucles avec MCP)
2. Stocker le travail (Linear)
3. Réaliser le travail (agent SDLC)

En séparant les choses, vous n'avez pas à construire à la fois la partie pré-tri et la partie implémentation (et je recommande d'ailleurs de ne pas le faire pour éviter la sur-ingénierie). Linear fait l'interface entre ce qui est "à faire" et ce que nous "faisons" actuellement, bien définie et facile à étendre.

Étape de Pré-tri

Dans le diagramme ci-dessus, le travail progresse de gauche à droite. Le côté gauche est là où le travail est créé et contient un nombre quelconque de systèmes (humains, agents ou API) qui ajoutent à ce qui doit être fait. Toutes les sorties créées lors de cette étape de pré-tri sont placées dans notre Linear.

Quelques boucles qui tournent dans un environnement cloud Claude

Dans cette étape, nous avons trois boucles principales :

1. Boucle de vérification de l'état du système (un détecteur de bugs) - cette boucle s'exécute quotidiennement à 5h du matin et est connectée à quelques serveurs MCP : Posthog pour le suivi des erreurs ; Vercel pour les diagnostics système ; et Linear pour créer des issues.
2. Boucle d'améliorations UX et de retours clients - cette boucle s'exécute chaque semaine le lundi à 9h, et analyse chaque nouveau retour, chaque chat de support client d'Intercom/Fin, et toutes les relectures de session Posthog. Les relectures de session sont une mine d'or. Vous pouvez voir où se produisent les clics de rage ou où les utilisateurs rencontrent des difficultés et sont confus.
3. Boucle d'analyse du taux de désabonnement - elle s'exécute quotidiennement à 6h du matin et examine chaque client qui a cliqué sur "annuler" dans les dernières 24 heures. Elle extrait les données de paiement et d'utilisateur de Stripe (y compris leur email/localisation), puis examine la relecture de session de ce client dans Posthog pour voir ce qu'il faisait avant d'annuler. Nous extrayons leur utilisation de Supabase pour voir si c'était un mauvais ICP, s'ils n'ont jamais vécu ce moment "waouh", ou s'ils ont rencontré des bugs. Le rapport est envoyé sur Slack et l'agent crée (ou commente) des issues si elles sont liées à des clients qui se désabonnent pour augmenter la priorité.

Pour faire fonctionner ces agents de manière cohérente, j'ai gardé les choses simples et j'ai utilisé Claude Code Cloud Routines.

Pas de sur-ingénierie avec un VPS Hetzner, un mac mini caféiné, etc. C'est de loin la façon la plus simple que j'ai trouvée pour tirer parti de votre abonnement Claude Code existant et créer des agents toujours actifs qui peuvent être déclenchés selon un planning ou via un événement webhook. Et à tous ceux qui disent "mais qu'en est-il du verrouillage fournisseur !!" - ce n'est que du texte, littéralement. N'hésitez pas à copier le prompt où vous voulez, je voulais juste la solution la plus simple et la moins chère à mettre en place qui fonctionne de manière fiable.

Et une autre raison d'utiliser Claude Code Cloud Routines est que les environnements cloud d'Anthropic ont une parité étroite avec Claude fonctionnant localement.

Cloud Claude Routines

Évidemment, ils n'ont pas vos variables d'environnement (qui peuvent être ajoutées à la configuration de l'environnement cloud, si nécessaire) mais si vous configurez une connexion MCP via les connecteurs de l'application de bureau, votre Claude CLI local et Claude distant peuvent tous les deux les utiliser, contrairement à Codex. C'était la fonctionnalité tueuse pour moi et c'est ce qui fait que ces boucles d'agents de pré-tri fonctionnent si bien. Cela permet aussi d'exécuter facilement plusieurs sessions en parallèle sans se soucier de la mémoire de votre ordinateur portable.

Si vous implémentez juste cette étape de pré-tri, vous obtiendrez quand même beaucoup de valeur ajoutée même si vous ne construisez pas l'étape suivante où le travail est réalisé.

Commencez petit avec une seule boucle, essayez-la, affinez-la, puis ajoutez-en d'autres. Trouvez quelles routines vous pouvez créer aujourd'hui qui mettent un travail nouveau et de haute qualité dans votre système de suivi des issues existant, puis faites ce que vous faites actuellement pour l'implémentation.

Étape d'Implémentation

La version la plus basique de l'étape deux est de donner un ID d'issue à votre agent et de lui dire de la réaliser. C'est ce que la plupart des gens font déjà aujourd'hui quand ils travaillent avec des agents, cependant, ce n'est probablement pas ce que vous voulez si vous lisez ceci, parce que vous êtes maintenant le goulot d'étranglement dans la boucle, lançant un agent directement dans une session.

Au lieu de cela, j'ai construit un moyen de déclencher des sessions Claude Code à distance directement depuis Linear.

Aller de l'issue Linear à Claude

Ça fonctionne comme ça :

1. D'abord, identifiez comment vous voulez déclencher une nouvelle session Claude. Pour nous, nous ajoutons un label 'auto' à une issue Linear qui lance cette nouvelle tâche.
2. Ensuite, Linear envoie un événement webhook à notre service API webhook interne (une nouvelle application Hono créée) qui analyse l'événement puis transmet les informations correctes à la Claude Routine.
3. Enfin, ce service API léger fait une requête POST à Anthropic qui déclenche la routine Claude avec un prompt initial.

Utiliser un label 'auto' comme déclencheur nous permet de contrôler l'exécution automatique de nouvelles sessions Claude.

Par défaut, nous ne faisons pas inclure ces labels 'auto' par les étapes de pré-tri et exigeons qu'un humain ajoute le label qui déclenche le début du travail de l'agent (en gardant l'humain dans la boucle). C'est pourquoi nous appelons l'étape 1 l'étape de pré-tri, parce que quelque chose détermine encore ce sur quoi il faut réellement travailler, soit par une intervention humaine, soit par un agent qui boucle et surveille les nouvelles issues ajoutées et lance de nouvelles sessions d'implémentation.

Cependant, comme l'ajout d'un label est aussi facilement fait par un agent, nous pourrions faire en sorte que les boucles de pré-tri créent de nouvelles issues avec le label 'auto' par défaut, ce qui lance une nouvelle session Claude. Utiliser un label devient un moyen très flexible de commencer un nouveau travail d'implémentation, soit automatiquement par un agent, soit par nous, les humains.

Un service de routage léger pour lancer des sessions Claude

Comme Linear supporte les webhooks, tout le mécanisme de "push quand un label est ajouté" fonctionne. Le seul inconvénient est que nous avons besoin d'une API publique qui achemine et accepte ces webhooks, formate les événements et les données du payload pour déclencher Claude Code. Ce nouveau service ajoute aussi les en-têtes d'authentification corrects, ce qui explique pourquoi Linear ne peut pas déclencher la routine directement.

Alternativement, vous pourriez avoir une routine planifiée qui démarre régulièrement et essaie d'implémenter toute nouvelle issue non en cours avec le label auto.

Pour le prompt de routine réel, je recommande de construire une compétence réutilisable qui parcourt l'ensemble du cycle de développement logiciel, nommée quelque chose comme /implement ou /do, qui permet de simplement dire "/do ISSUE-NNN", ce qui documente comment passer correctement par les étapes de récupération du contexte de l'issue, implémentation du travail, vérification dans le navigateur, création de la PR, et surveillance des commentaires.

Ensuite, le prompt de routine Claude, déclenché par l'événement Linear, peut avoir un prompt très simple. Voici le mien :

Récupérez l'issue fournie et utilisez la compétence /do pour implémenter la modification demandée et créer une pull request. Récupérez uniquement l'issue exacte fournie. Si elle est déjà terminée ou en cours, arrêtez-vous.

La référence de l'issue n'apparaît pas dans ce message — elle arrive sous la forme d'un message de suivi séparé, encapsulé dans une balise \<routine-fire-payload>\, envoyé immédiatement après celui-ci, dans la même session. Attendez ce message avant de décider si une issue a été fournie. Ne concluez que l'issue n'existe pas, ou qu'aucune n'a été donnée, après avoir vérifié dans le message \<routine-fire-payload>\ et confirmé que l'issue référencée n'existe vraiment pas.

Lorsque vous commencez le travail, commentez l'issue, passez-la à "En cours", et mettez à jour l'issue avec tout élément pertinent au fur et à mesure de votre progression. Préfixez toujours les commentaires d'issue Linear avec [Claude].

Donc à ce stade, vous avez des sessions Claude Remotion parallèles déclenchées via API, implémentant des issues, ouvrant des PR (et, espérons-le, vérifiant leur travail via Playwright ou Agent Browser).

C'est essentiellement une usine logicielle complète, entièrement observable, qui fonctionne pendant que vous dormez, et qui tourne entièrement sur votre abonnement Claude Code.