Warp a lancé Factories le mardi 18 août 2026, un système en nuage pour faire tourner des agents sur tout le cycle de développement plutôt que dans un seul éditeur. Une usine se définit en YAML versionné, et elle achemine le travail à travers des étapes de tri, de cadrage, d'implémentation, de relecture et de vérification, en gardant les humains aux points de décision. Les détails qui méritent votre attention ne sont pas les agents. C'est que le pipeline est du code relisible et réversible, que vous pouvez apporter votre propre inférence et votre propre calcul, et que le produit embarque un tableau de bord mesurant le coût par demande de fusion.
The short answer
Warp a lancé Factories le mardi 18 août 2026. Une usine est un pipeline YAML versionné qui fait circuler le travail entre des agents de tri, de cadrage, d'implémentation, de relecture et de vérification, orchestrés par un foreman qui choisit le modèle et le harnais par sous tâche. Le travail entre depuis Slack, Teams, Linear, Jira, GitHub et GitLab, ou via API, SDK et ligne de commande. Vous pouvez apporter votre inférence et votre calcul, auto héberger, conserver les données produites et imposer une rétention nulle. Le produit est en bêta fermée.
La plupart des outils à base d'agents supposent encore que le travail intéressant se passe dans un éditeur, avec une personne qui regarde. Warp Factories, lancé le mardi 18 août 2026, suppose l'inverse, et cette hypothèse mérite examen même si vous ne vous inscrivez jamais à la bêta.
La forme d'une usine
Une usine est un pipeline sur les phases ordinaires du travail logiciel : tri, cadrage, implémentation, relecture, vérification. Ce qui change, c'est que chacune de ces phases peut être prise en charge par un agent, les humains étant placés aux points de décision plutôt qu'à chaque étape.
La ligne par défaut livre quatre agents. Le tri évalue ce qui arrive et décide de quoi il s'agit. Le cadrage travaille avec un humain quand le besoin n'est pas assez clair pour être implémenté, c'est à dire la phase que la plupart des outils à agents sautent et paient plus tard. L'implémentation écrit le code, avec un usage de l'ordinateur qui lui permet de piloter une interface graphique. La relecture évalue le changement obtenu. Vous pouvez définir vos propres agents par dessus.
Au dessus se trouve un orchestrateur appelé foreman, qui achemine chaque élément le long de la ligne et sélectionne le modèle et le harnais pour chaque sous tâche. C'est la partie utile de l'abstraction. Les étapes veulent réellement des modèles différents, puisque le tri est une classification bon marché et l'implémentation non, et figer un modèle unique pour tout le pipeline est la façon la plus sûre de rendre ces systèmes coûteux.
Le travail entre depuis Slack, Teams, Linear, Jira, GitHub et GitLab, ou directement via une API, un SDK ou la ligne de commande. Il existe aussi une intégration Factory MCP, qui permet à un agent local comme Claude Code ou Cursor de pousser du travail dans une usine et de récupérer des tâches pour itérer en local, ce qui reconnaît raisonnablement que les gens continueront de travailler localement quoi que fasse le pipeline.
La décision de conception qui compte
Retirez les agents et un choix porte l'essentiel de la valeur : une usine se définit en YAML versionné, dans l'esprit de l'infrastructure en tant que code.
Cela ressemble à de la plomberie et n'en est pas. Aujourd'hui, la plupart des équipes qui font tourner des agents gardent leur vraie configuration dans des prompts collés dans des panneaux de réglages, dans un document quelque part, ou dans la tête de personne. Quand la qualité dérive, il n'y a pas de diff à lire et rien vers quoi revenir. On ne bissecte pas un prompt qu'on n'a pas versionné, et on ne relit pas un changement qui n'a jamais été écrit.
Mettre le pipeline dans un fichier corrige cela. Un changement du comportement de votre agent de relecture devient une demande de fusion, avec un auteur, une raison et un retour arrière possible. Vous pouvez comparer deux configurations en les extrayant toutes les deux. Vous pouvez bissecter une régression dans le pipeline comme vous le feriez dans l'application. C'est exactement l'argument qui a sorti la configuration des serveurs des mains pour la mettre dans des dépôts, et il tient ici pour les mêmes raisons.
La seconde décision à porter au crédit du produit, c'est que Warp n'impose pas le chemin des données. Vous pouvez apporter votre propre infrastructure d'inférence ou utiliser celle de Warp, auto héberger ou passer par l'hébergement Warp, et conserver les données produites par le système, c'est à dire les conversations d'agents, les évaluations et les mémoires. Les politiques de rétention nulle sont prises en charge, donc vos données ne servent pas à l'entraînement, et la plateforme accepte plusieurs modèles et harnais, y compris à poids ouverts, avec Claude Code, Codex et l'agent maison de Warp.
En environnement réglementé, c'est souvent toute la discussion. Le blocage sur l'adoption des agents n'y porte presque jamais sur la capacité, mais sur l'endroit où va le code, qui peut le conserver, et si ce chemin peut être décrit à un auditeur. Pouvoir répondre avec sa propre infrastructure vaut plus qu'un point de plus sur un classement de code.
Mesurez, sinon cela vous coûtera en silence
La partie du lancement que nous utiliserions en premier n'est pas un agent. C'est le tableau de bord, qui suit le coût par demande de fusion, la qualité du code et l'efficacité, avec des évaluateurs et la possibilité de comparer des configurations de modèles et de harnais entre elles.
Les pipelines d'agents échouent rarement bruyamment. Ils échouent en produisant un flux régulier de changements plausibles, qui semblent raisonnables, passent une relecture superficielle, et consomment la ressource la plus rare de l'équipe : l'attention des personnes expérimentées. Un pipeline qui génère quarante demandes de fusion par semaine dont six sont fusionnées n'est pas un gain de productivité, c'est un impôt de relecture avec des étapes en plus. Le coût par demande de fusion rapporté au taux de fusion est le chiffre qui vous dit dans quelle situation vous êtes, et l'avoir dans le produit plutôt que dans un tableur que vous ne construirez jamais fait la différence entre savoir et supposer.
Warp livre aussi des boucles d'auto amélioration, où des agents observateurs repèrent des pistes d'optimisation et ouvrent des demandes de fusion sur la définition de l'usine elle même. C'est la fonction la plus intéressante et la plus exigeante du lancement. Elle est cohérente, puisque la définition est du code et que des agents peuvent proposer des modifications de code. Elle signifie aussi que le système peut proposer de modifier les règles qui gouvernent son propre comportement, donc la barrière de relecture sur ces demandes doit être un vrai humain, tenu à une exigence supérieure à celle d'un changement ordinaire, et pas un tampon parce que le diff est court.
Limites honnêtes
Il s'agit d'une bêta fermée, à l'accueil limité et sans date de disponibilité générale, avec dix mille dollars d'usage offert aux organisations éligibles. Des crédits gratuits sont une offre d'essai raisonnable et aussi une forte incitation à faire tourner plus de travail d'agents que d'habitude, donc mesurez pendant l'essai plutôt qu'après.
L'affirmation qu'une usine de base se configure en cinq minutes environ est plausible pour la ligne par défaut et ne dit rien du travail d'ajustement à un vrai dépôt, qui est là où passe l'effort. Warp annonce environ trente pour cent de ses tâches internes passant par des usines, ce qui est un vrai point de mesure venant d'une entreprise d'outillage qui fait tourner son produit sur une base de code qu'elle connaît parfaitement. Votre proportion sur un service ancien à couverture de tests faible sera différente, et l'étape de vérification est exactement là où cette différence apparaîtra.
Le motif général est ce qu'il faut retenir de toute façon. L'outillage à base d'agents sort de l'éditeur pour aller dans des pipelines qui ressemblent à de l'intégration continue, définis en code et mesurés au coût par changement accepté. Que vous vous inscriviez ou non, cette forme mérite d'être comprise, et le premier pas ne coûte rien : écrivez ce que vos agents sont configurés pour faire aujourd'hui, et mettez le fichier sous gestion de versions.
Sources et pour aller plus loin
- Introducing Warp Factories, open, flexible infrastructure for building your software factory, Warp, août 2026
- Warp's new system is an out-of-the-box software factory for AI development, TechCrunch, 18 août 2026
- Warp launches AI software factories to automate coding workflows, Mezha, août 2026
Questions fréquentes
Qu'est ce qu'une usine Warp ?
C'est un pipeline de développement piloté par agents, défini en YAML versionné dans l'esprit de l'infrastructure en tant que code. L'usine par défaut contient un agent de tri qui évalue le travail entrant, un agent de cadrage qui travaille avec un humain sur le besoin quand il est flou, un agent d'implémentation qui écrit le code, et un agent de relecture qui évalue le changement. Un orchestrateur appelé foreman achemine chaque élément sur la ligne et choisit le modèle et le harnais pour chaque sous tâche. Vous pouvez ajouter vos propres agents. Le travail entre depuis Slack, Teams, Linear, Jira, GitHub et GitLab, ou directement via une API, un SDK ou une interface en ligne de commande.
Pourquoi définir le pipeline en YAML change quelque chose ?
Parce que cela transforme le bricolage de prompts en modification relisible. Si le comportement de vos agents vit dans un panneau de réglages, personne ne peut voir pourquoi la semaine dernière donnait de meilleurs résultats que celle ci, et il n'y a rien vers quoi revenir. S'il vit dans un fichier versionné, un changement du comportement de votre agent de relecture passe par le même chemin de diff, de relecture et de retour arrière que n'importe quel autre changement, et vous pouvez bissecter une régression dans le pipeline lui même. C'est la raison pour laquelle l'infrastructure en tant que code a supplanté la configuration manuelle des serveurs, et elle s'applique ici à l'identique.
Puis je utiliser mes propres modèles et garder mes données ?
Oui, et Warp insiste beaucoup sur ce point. Vous pouvez apporter votre propre infrastructure d'inférence ou utiliser celle de Warp, auto héberger ou passer par l'hébergement Warp, et conserver les données produites par le système, c'est à dire les conversations d'agents, les évaluations et les mémoires. Les politiques de rétention nulle sont prises en charge, ce qui interdit l'usage de vos données pour l'entraînement. Les usines fonctionnent avec plusieurs modèles et harnais, y compris à poids ouverts, et prennent en charge Claude Code, Codex et l'agent maison de Warp. Cette combinaison compte surtout en environnement réglementé, où le blocage sur l'adoption des agents porte d'ordinaire sur le chemin des données plutôt que sur la capacité.
Comment mesurer si l'automatisation fonctionne ?
Via un tableau de bord qui suit le coût par demande de fusion, la qualité du code et l'efficacité, plus des évaluateurs intégrés et la possibilité de comparer différentes configurations de modèles et de harnais entre elles. Il existe aussi des boucles d'auto amélioration où des agents observateurs repèrent des pistes d'optimisation et ouvrent des demandes de fusion sur la définition de l'usine. Le coût par demande de fusion est le chiffre à surveiller. Les pipelines d'agents échouent silencieusement en produisant des changements plausibles qui consomment du temps de relecture, et un taux de fusion associé à un coût par changement accepté est la mesure honnête de la rentabilité.
Pour qui est ce, et peut on l'essayer aujourd'hui ?
C'est en bêta fermée avec un accueil limité, et les organisations éligibles reçoivent dix mille dollars d'usage gratuit à l'inscription. Aucune date de disponibilité générale n'a été donnée. La cible annoncée, ce sont les équipes qui veulent des agents en développement, en test et en relecture sans construire l'orchestration elles mêmes, ce qui désigne en pratique les organisations d'ingénierie de taille modeste, les grandes ayant souvent déjà bâti quelque chose en interne. Warp affirme qu'environ trente pour cent de ses tâches internes passent désormais par des usines, ce qui est un point de mesure utile et aussi un chiffre de fournisseur sur son propre produit.