Contexte et adoption du pattern

En 2026, l’écosystème IA voit apparaître de nouveaux modèles d’ingénierie plus rapidement que les équipes ne peuvent les intégrer. Will Larson décrit une série d’adaptations chez Imprint : en janvier, tous les ingénieurs utilisent Claude Code quotidiennement ; en mars, l’ensemble du personnel passe à Claude Code ou Claude Cowork ; en avril, le développement local devient un goulot d’étranglement à cause du modèle checkout‑worktree, ce qui conduit à la création d’environ 10 espaces de travail locaux disposant chacun d’un dépôt complet. En juin, l’absence d’un système de gestion de tâches unifié pousse la migration de Jira vers Linear, avec un arrêt strict de Jira. En juillet, la visibilité accrue des tickets déclenche le déploiement d’un harnais orchestré nommé « Agent Fleet », inspiré du modèle « Minions » de Stripe.

Fonctionnement du Software Factory

Le pattern repose sur une boucle d’objectif large pilotée par un harnais d’agents. Un agent « linear‑project‑loop » lit un projet Linear, puis vérifie trois artefacts : un RFC hébergé dans Notion décrivant les objectifs, un tableau de bord Datadog et des requêtes Snowflake mesurant la progression. Si l’un de ces éléments manque, l’agent interagit avec l’utilisateur pour le créer. Ensuite, il analyse les métriques et les tickets, crée de nouvelles issues lorsque des travaux sont identifiés, met à jour l’état des tickets bloqués et exécute les tâches non bloquées : génération ou mise à jour de pull‑request, envoi de notifications de revue, ou formulation de questions de clarification. Lorsqu’une tâche se termine, l’agent reprend le cycle à partir du RFC si celui‑ci a été rafraîchi, sinon il recommence depuis le début.

Analyse technique et limites

Le modèle montre une forte dépendance à plusieurs services : l’accès à Datadog MCP et à Snowflake est indispensable pour le suivi des objectifs, tandis que Linear doit être le point unique de vérité pour l’état du travail. Cette chaîne de dépendances crée un risque de rupture : une indisponibilité de Snowflake bloque la mesure des indicateurs, ce qui empêche l’agent de décider des prochaines actions. De plus, le harnais local fonctionne actuellement sur une machine développeur, mais le plan prévoit son exécution dans l’« Agent Fleet », ce qui implique la gestion de la persistance d’état entre les nœuds et la sécurisation des jetons d’accès aux API tierces. Le pattern ne résout pas le problème de la granularité des métriques ; si les tableaux de bord Datadog ne reflètent pas les indicateurs métier, l’agent peut générer des actions non alignées avec les objectifs réels. Enfin, la création de ~10 espaces de travail locaux augmente la consommation de stockage et la complexité de synchronisation des branches, ce qui peut ralentir les builds CI/CD si les ressources ne sont pas provisionnées adéquatement.

Implications pour l’ingénierie logicielle

Le Software Factory pousse les équipes à externaliser la gestion de l’état du projet vers des agents autonomes, réduisant ainsi la charge cognitive individuelle. En automatisant la vérification des artefacts de suivi et la génération de tickets, il accélère le feedback loop entre le code et les métriques opérationnelles. Cependant, la réussite du modèle dépend de la maturité de l’infrastructure de monitoring et de la discipline autour d’un référentiel unique (Linear). Les organisations qui ne peuvent pas garantir un accès fiable à ces services risquent de voir leurs agents stagner ou produire des actions redondantes. Le pattern constitue donc une expérimentation avancée de l’orchestration IA, dont la viabilité à grande échelle reste à confirmer.