Adopter le modèle de l'usine logicielle : marcher, courir, voler

L’approche de l’usine logicielle (une boucle agentique fermée qui s’exécute dans le cloud) gagne en popularité, mais son adoption peut sembler intimidante. Dans cet article, je vais détailler les étapes « marcher avant de courir » pour réussir la transition des agents locaux interactifs vers un développement automatisé dans le cloud.

Marcher

De nombreux responsables d’ingénierie et ingénieurs de plateforme avec qui j’échange ont déjà commencé la phase « marche » de la construction d’une usine logicielle en créant des automatisations simples à l’aide d’agents cloud.

Pensez à ces automatisations comme à : Déclencheur → Activité de l’agent.

Par exemple :

• Reproduction et triage des tickets : laissez un agent examiner tous les nouveaux tickets créés, les reproduire et les étiqueter.
• Revue de code : Revue automatique des PR dès leur ouverture, avec ajout de commentaires.
• Surveillance : un agent qui répond aux alertes Sentry, débogue et corrige les problèmes.
• Auto-réparation du CI : réparer un CI cassé en identifiant les PR à annuler ou les conflits de fusion à résoudre.
• Mise à jour automatique de la documentation : mettre à jour la documentation destinée aux utilisateurs et générer des changelogs.
• Vérification : les agents browser-use et computer-use effectuent un contrôle qualité visuel et vérifient les modifications.
• Corrections de bugs simples : les agents identifient et corrigent les problèmes simples signalés par les utilisateurs.

Le point commun de toutes ces approches est qu’elles automatisent une partie discrète du cycle de vie logiciel. Commencer par des automatisations simples est une approche à faible risque et à faible coût, qui aide à développer une intuition sur la manière d’utiliser efficacement les agents pour des tâches plus complexes et multi-étapes.

Exemple d’automatisation pour la surveillance des alertes

Ces automatisations peuvent être construites à l’aide d’infrastructures maison (par exemple, en intégrant le SDK Claude Code dans un conteneur Docker et en connectant un serveur pour le déclencher), ou utiliser une plateforme générique d’automatisation d’agents cloud conçue pour exécuter des agents basés sur des déclencheurs. Elles peuvent également reposer sur une plateforme dédiée à une seule étape du cycle (par exemple, un revendeur de code agentique dédié ou un SRE IA).

Commencer par un patchwork d’automatisations ponctuelles est acceptable, mais la plupart des équipes finissent par atteindre les limites de cette approche.

Plus précisément :

• Selon la configuration, ces automatisations ne partagent pas nécessairement le contexte. Cela signifie que lorsque vous améliorez un aspect (disons, la revue de code), ces améliorations ne se répercutent pas sur les autres étapes, comme le triage et le QA.
• Il n’y a pas de vue globale permettant de savoir si ces automatisations ponctuelles améliorent réellement la productivité globale, ni de méthode systématique pour tester et améliorer les indicateurs clés qui vous importent, tels que le coût par PR, le temps de cycle, le taux d’automatisation, etc. Pour suivre ces métriques, vous avez besoin d’un système fonctionnant sur toutes les étapes du développement.
• Chaque solution ponctuelle crée sa propre charge de configuration et de maintenance. Elles élargissent la surface d’attaque à sécuriser. Elles ne disposent pas d’une interface unifiée pour l’observabilité. Les équipes finissent par vouloir une configuration centralisée, ainsi que des fonctions d’audit et de gouvernance.

Courir

Tous ces problèmes soulignent la nécessité d’une approche plus holistique. Les organisations ayant franchi la première étape se demandent : « Quel est le système dont nous avons besoin pour véritablement passer à l’échelle du développement agentique ? »

Plus spécifiquement, elles se posent les questions suivantes :

• Où le développement doit-il avoir lieu ? En local ou dans le cloud ? Via quelles interfaces ?
• À quoi ressemble un processus de développement automatisé réussi ? Quels sont les indicateurs clés ?
• Quelle est notre posture en matière de souveraineté IA ? L’importance de posséder nos données d’agents de codage est-elle cruciale ? À quel point devrions-nous dépendre des fournisseurs de modèles ?
• Comment prévoyons-nous d’améliorer notre processus de développement au fil du temps ? Comment maîtrisons-nous les coûts tout en accélérant nos livraisons ? Comment savons-nous que nous progressons ?
• Comment anticipons-nous l’avenir alors que les modèles et les agents s’améliorent ? Tenons-nous compte des risques réglementaires susceptibles d’affecter l’accès aux modèles ?
• Comment exactement les ingénieurs doivent-ils participer au processus de développement ? Et les designers, PM et autres contributeurs ?
• Comment sécurisons-nous le développement ? Quel est notre plan si notre processus de production logicielle est compromis ?

La plupart des responsables d’ingénierie et des équipes de plateforme qui réfléchissent sérieusement à ces questions optent pour une approche similaire à celle d’une usine logicielle cloud. Ils souhaitent :

• Un développement dans le cloud par défaut, car il est plus sécurisé de donner aux agents des environnements isolés (sandboxes) plutôt que de les laisser agir localement sans restriction.
• Une gouvernance centralisée des agents de codage et des outils et systèmes auxquels ils accèdent.
• Des traces complètes des actions effectuées par les agents, pour l’audit et la compréhension de la productivité.
• Une flexibilité concernant les modèles et les harnais, afin de minimiser les risques et d’optimiser les performances.
• L’intégration du développement dans tous les outils déjà utilisés par votre équipe (par ex. Slack/Teams, Jira, GitHub, etc.).
• Des solutions de secours permettant aux humains de reprendre la main, soit en pilotant des agents en direct, soit en ramenant le travail dans la boucle de développement interne.
• Une couche de contexte partagée qui fonctionne entre les agents à toutes les phases du développement.
• Une approche permettant les tests, les évaluations et les benchmarks afin que votre équipe ait confiance dans l’amélioration continue du système.

Une fois qu’une entreprise décide d’adopter une approche d’usine, la question devient : comment y arriver à partir de vos automatisations ponctuelles existantes ? Cela revient généralement à choisir entre (1) construire plus d’infrastructure autour de ces automatisations ou (2) migrer vers une plateforme comme Warp Factories, qui fournit l’infrastructure d’usine.

Notez que je ne présenterais pas cela comme une décision classique « build vs buy ». Quelle que soit la voie choisie, attendez-vous à ce que votre équipe interne fasse du développement, car pour qu’une approche d’usine fonctionne, cette usine doit être profondément intégrée au contexte et aux workflows de votre équipe. C’est davantage une question de savoir si vous construisez votre infrastructure d’automatisation entièrement de zéro, ou si vous collaborez avec des partenaires qui vous donnent un coup de pouce initial.

Par exemple, quelle que soit la voie choisie, vous devrez construire des compétences spécifiques à votre organisation et les ajuster à votre base de code. Vous devrez exposer et configurer des MCP spécifiques à l’organisation et des sources de contexte internes. En revanche, vous ne voudrez peut-être pas construire vous-même l’infrastructure cloud pour exécuter et gérer les agents, les piloter, transférer leur travail, mesurer leur efficacité, effectuer des utilisations de l’ordinateur, etc. La règle générale est de se concentrer sur la construction des éléments spécifiques à votre organisation, et non de ceux nécessaires à toute organisation.

Quelle que soit l’approche adoptée, je suggère que la plus grande étape de la phase courir est le déploiement d’une première usine de bout en bout sur une surface produit simple. Il peut s’agir de votre site marketing ou d’une application interne.

Commencer par un projet simple présente l’avantage de lancer une boucle complète avec peu d’enjeux et une complexité minimale. Ajouter plus de dépôts, de lignes de code, de dépendances de services, de parties prenantes humaines, etc., augmente la complexité et peut donner l’impression que vous n’êtes pas prêt pour l’automatisation. Il vaut mieux affiner une boucle simple en premier.

L’objectif est un système multi-agents qui passe par triage → spécification → implémentation → revue → vérification → surveillance. Plus en détail :

1. Un nouveau ticket arrive dans le système, via un humain ou un agent de surveillance.
2. L’agent de triage intervient pour comprendre et reproduire le problème. S’il détermine que la tâche est automatisable → il la transmet à l’agent d’implémentation. Si des spécifications sont nécessaires en raison de la portée → l’agent de spécification itère avec un humain pour élaborer une spec. Si c’est ambigu → obtenir l’avis d’un humain et relancer, ou décider de mettre le ticket en attente pour le moment.
3. [Si nécessaire] L’agent de spécification intervient, l’humain examine les specs, puis transmet à l’agent d’implémentation.
4. L’agent d’implémentation écrit le code.
5. L’agent de revue de code examine le code.
6. L’agent de vérification effectue une utilisation de l’ordinateur ou une autre vérification.
7. L’humain examine le code et la sortie de vérification. Si nécessaire, retournez à l’étape 2, 3, 4 ou 5.
8. CI / CD.
9. Livrer.
10. L’agent de surveillance intervient et crée des tickets si nécessaire, complétant ainsi la boucle.

En interne chez Warp, notre usine de phase courir automatise environ 75 % des modifications apportées à warp.dev, notre site marketing. Contrairement à Warp Terminal (65k étoiles GitHub, près d’un million de développeurs actifs, 1M de lignes de Rust natif), notre site marketing est une application assez simple. Notez que par « automatiser », j’entends passer de l’entrée humaine à une fonctionnalité livrée entièrement via l’usine, avec un minimum d’interventions humaines hormis la description du changement souhaité, soit dans Slack, soit dans notre gestionnaire de tâches.

Vol

Ce n’est que lorsque vous avez mis en place la boucle de base sur un projet simple que vous devez passer à l’échelle sur des projets plus complexes. La mise à l’échelle des usines nécessite une infrastructure plus robuste.

Plus précisément, à mesure que vous montez en échelle, certains goulots d’étranglement apparaissent :

• Faire fonctionner les environnements de développement distants sur de grands projets est difficile. Plus de dépôts, de lignes de code, de dépendances de services rendent l’automatisation plus ardue.
• À mesure que vous accumulez plus de compétences, de code, etc., il devient plus difficile de savoir si les changements apportés à vos usines ont un impact positif sur le développement ou s’ils ne font que créer du bruit.
• Vous courez naturellement des risques de coûts plus élevés lorsque les agents travaillent sur des bases de code plus complexes, car vous avez besoin de modèles plus puissants et les agents doivent tourner plus longtemps. Le routage des modèles et le choix du harnais deviennent plus importants.
• La sécurité et l’audit deviennent plus critiques à mesure que vous appliquez l’approche usine à des applications utilisateur essentielles.
• Plus de parties prenantes signifie plus de coordination humaine et de validations. Vous voudrez une solution d’usine permettant des entrées multi-utilisateurs et des pistes d’audit.
• Inévitablement, les PR commenceront à s’accumuler, donc vous aurez besoin d’une stratégie définie pour déterminer ce qui est soumis à une revue de code, comment vous utilisez la vérification et le QA agentiques.
• Vous voudrez des outils plus robustes pour fermer la boucle, en vous assurant que les changements livrés en production sont de haute qualité, ne plantent pas, etc.

À mon avis, faire fonctionner des usines à grande échelle sera l’un des défis d’ingénierie logicielle les plus intéressants des prochaines années ; l’ingénierie logicielle devient de l’ingénierie d’usine. Les organisations qui rendront leurs usines robustes, fiables et auto-améliorantes pourront livrer davantage à moindre coût et bénéficieront d’un avantage concurrentiel.

Pour faire vraiment ronronner une usine, il faut un investissement significatif. Chez Warp, nous considérons cela comme la construction complète de votre pile d’usine :

Je couvre chacune de ces couches en détail dans cet article :

https://x.com/zachlloydtweets/status/2097739116720910619

Quelques points clés à noter qui pourraient ne pas être évidents :

• Usines-as-code : l’un des choix clés que vous pouvez faire est de définir vos usines sous forme de code. Cela permet de tester différentes configurations d’usines pour voir lesquelles sont les plus efficaces, offrent la meilleure qualité, etc.
• Multi-modèle & multi-harnais : assurez-vous que vos usines sont capables d’utiliser les derniers modèles, tant frontier que open-weight, et d’utiliser différents harnais d’agents de codage comme Claude Code et Codex.
• Propriété des données : assurez-vous de stocker et de posséder toutes les données générées par votre usine - c’est la matière première pour améliorer ses opérations.

Dans une usine parfaitement huilée, la caractéristique clé est qu’il s’agit d’un système en boucle fermée, mesurable et améliorable. Ce devrait être l’objectif. Dans un tel système, tout le monde travaille à partir du même contexte, publiquement, de manière entièrement auditée et observée. Les agents eux-mêmes observent les compétences et la configuration qui pilotent le système et suggèrent des améliorations. Les ingénieurs de plateforme peuvent étendre le système pour l’intégrer à tous les systèmes internes. Les responsables d’ingénierie peuvent voir les métriques de productivité et comprendre quels changements sont apportés pour les améliorer. Tout cela fonctionne empiriquement, pas au feeling.

Chez Warp, nous nous rapprochons de cette vision. Chaque jour, nous travaillons tous publiquement, ajustons notre usine, réduisons les coûts et améliorons le débit et la qualité.

Notre mission est de fournir aux meilleures équipes d’ingénierie du monde les outils pour construire, mesurer et optimiser leurs propres workflows en utilisant n’importe quel modèle et harnais sous-jacent sur une infrastructure ouverte. Ces capacités aideront les équipes à livrer un meilleur logiciel plus rapidement et plus efficacement.

Warp Factories est actuellement en accès anticipé. Les entreprises qualifiées obtiennent 10 000 $ d’utilisation de l’usine.