Factory AI : les Droids valent-ils le détour pour votre équipe ?

Qu’est-ce que Factory AI ?

Factory est une plateforme de développement logiciel dont les agents, appelés Droids, peuvent explorer un dépôt, proposer un plan, modifier des fichiers, lancer des vérifications et préparer une pull request : un ensemble de modifications à examiner avant de l’intégrer au code. Ces agents s’utilisent dans un terminal, un environnement de développement intégré (IDE), ou les interfaces de bureau et web de Factory. Le développement « agent-native » consiste à confier un résultat à obtenir, puis à examiner le travail produit, plutôt qu’à demander chaque modification séparément. Le produit vient compléter les modèles et les outils de développement : ce n’est ni un nouveau langage de programmation ni un modèle à entraîner soi-même. La page produit de Factory décrit ce périmètre.

Informations vérifiées le 21 octobre 2026, à partir des tarifs et de la documentation en ligne de Factory. Cette évaluation repose sur la documentation, des exemples détaillés et des calculs de coûts. Elle ne prétend présenter ni un benchmark de programmation ni un essai pratique.

À qui s’adresse Factory, et qui devrait garder son agent actuel ?

Factory peut convenir à un responsable technique qui veut harmoniser la délégation entre des développeurs utilisant différents éditeurs, ou changer de fournisseur de modèles sans reconstruire tous ses workflows. L’intérêt est moins évident pour un fondateur dont l’agent actuel gère déjà le dépôt, les tests et la revue de code avec peu de supervision.

Les solutions à comparer sont Claude Code, l’agent de développement d’Anthropic ; Codex, l’agent de programmation d’OpenAI ; et Cursor, à la fois éditeur et plateforme d’agents. La bonne comparaison porte sur ce que chaque achat change concrètement dans l’organisation du travail.

Ce sont des critères de choix, pas un classement de performances. Claude Code, Codex et Cursor dépassent déjà le cadre d’une fenêtre de chat ou d’un terminal. La présence de plusieurs interfaces ne suffit donc pas à donner l’avantage à Factory.

Factory AI ou Claude Code : lequel choisir ?

Factory mérite d’être envisagé si vous voulez faire des modèles Claude une option parmi d’autres dans un workflow plus large. Claude Code reste le choix le plus simple lorsque votre organisation dispose déjà d’instructions, d’intégrations et de pratiques de revue efficaces autour de cet outil. Exécuter un modèle Claude dans Droid ne revient pas à utiliser Claude Code : les outils, la sélection du contexte et le comportement d’exécution dépendent du produit qui héberge l’agent.

Un responsable dont les développeurs backend travaillent dans JetBrains et les développeurs frontend dans Cursor pourrait, par exemple, adopter Factory pour traiter une même file de tâches de maintenance. C’est une raison cohérente de l’ajouter à l’existant. Demander à toute l’équipe de changer parce qu’un autre modèle a produit une démonstration impressionnante ne l’est pas.

Remettez Factory à plus tard si le principal problème tient à des demandes floues, à des tests peu fiables ou à une file de pull requests que personne ne relit. Ces problèmes limitent aussi les Droids. Gardez Claude Code, Codex ou Cursor pendant que vous rendez le travail plus facile à vérifier. Le comparatif Codex et Claude Code traite de ce choix plus ciblé ; la sélection d’agents IA pour le développement élargit la comparaison.

L’évaluation qui suit repose sur quatre critères : la qualité du contexte, le contrôle de l’exécution, la continuité entre les interfaces et le coût d’une modification acceptée.

Factory Droid : garder son éditeur, préciser le travail attendu

Factory Droid peut fonctionner dans un éditeur existant. Il devient donc possible de mener un petit pilote sans changer d’éditeur. Dans VS Code, Cursor et Windsurf, l’intégration transmet le fichier actif, le texte sélectionné, les fichiers ouverts et les diagnostics, c’est-à-dire les messages d’erreur et d’avertissement de l’éditeur. Elle permet aussi de consulter les diffs dans l’interface native. Lancez droid dans le terminal intégré, puis utilisez /ide pour vérifier la connexion. La documentation IDE de Factory explique la configuration.

Prenons un responsable backend qui modifie la manière dont une application vérifie les droits d’accès aux comptes. La tâche utile ne se résume pas à « refactoriser l’authentification ». Elle consiste à repérer tous les points d’appel, préserver le comportement existant pour les utilisateurs actuels, proposer l’ordre des étapes de migration et identifier les tests capables de détecter une modification accidentelle des privilèges.

Cette description délimite le travail de l’agent et donne au responsable de la revue des critères pour le refuser. Un diff volumineux ne prouve pas, à lui seul, que la migration est correcte.

Comment Factory AI exploite-t-il une spécification ?

Le Spec Mode de Factory sépare l’analyse et la planification de l’implémentation. Il consulte le contexte pertinent et propose un plan avant de demander une approbation ; dans la CLI, Shift+Tab permet de passer du mode Normal au mode Spec. Le niveau d’autonomie est un réglage distinct : il détermine les actions qui peuvent se poursuivre sans nouvelle confirmation. La documentation des modes précise cette distinction.

Pour la migration des droits d’accès, commencez en Spec Mode et exigez un plan qui désigne les fichiers concernés, les hypothèses de compatibilité et les étapes de vérification. Refusez un plan qui propose de modifier les règles d’accès sans expliquer comment le comportement existant sera préservé. N’autorisez l’implémentation qu’une fois ces décisions clarifiées.

Voici une séquence concrète :

1. Demandez à Droid de repérer les points d’entrée des contrôles d’autorisation et les tests pertinents.
2. Demandez un plan qui préserve le comportement actuel et signale les exigences encore incertaines.
3. Examinez le plan, puis choisissez un niveau d’autonomie adapté au travail autorisé.
4. Vérifiez le diff et les résultats des tests avant d’ouvrir ou d’accepter la pull request.

L’intérêt est de disposer d’un point de validation avant que l’agent ne produise beaucoup de code. La limite : un plan plausible peut malgré tout être faux. Les critères d’acceptation doivent porter sur le comportement, pas seulement sur la présence de tests.

Une réserve concerne l’éditeur : Factory indique que son intégration JetBrains ne partage pas automatiquement les fichiers ouverts, les sélections, les diagnostics ni les diffs natifs de Droid. Un déploiement dans une équipe utilisant plusieurs éditeurs doit tenir compte de cette différence, sans supposer que l’expérience de VS Code se retrouve partout.

Changer de modèle sans reconstruire son workflow

Factory permet de choisir entre plusieurs familles de modèles tout en conservant l’interface Droid et la structure des tâches. C’est utile pour une équipe qui veut une façon cohérente de déléguer, sans lier tous ses workflows à un seul fournisseur de modèles.

Le catalogue de modèles de Factory répertorie notamment :

• Claude Opus 5.5 et Claude Sonnet 5.5 d’Anthropic.
• GPT-6.1 Sol et GPT-6 Astra d’OpenAI.
• Gemini 3.1 Pro de Google et Grok 4.7 de xAI.
• Des modèles ouverts, dont Mistral Large 4, Kimi K3 et DeepSeek V4.1 Flash.

Il s’agit d’un échantillon de modèles pris en charge, pas d’un classement de qualité ni d’une garantie que les règles de chaque compte autorisent tous ces modèles.

Prenons une file de mises à jour de dépendances. Confiez à chaque modèle candidat la même mise à jour, les mêmes consignes de test et les mêmes critères d’achèvement. Notez s’il termine la mise à jour, si les vérifications passent et combien d’interventions humaines sont nécessaires lors de la revue. Un modèle qui demande moins de supervision peut justifier une consommation plus élevée ; un modèle moins cher qui laisse régulièrement des tests en échec, beaucoup moins.

La comparaison doit conserver la même tâche et le même environnement. Changer simultanément le modèle, les instructions du dépôt et le niveau d’autonomie rend le résultat impossible à interpréter. Le catalogue de Factory comprend différents multiplicateurs d’utilisation et réglages de raisonnement : « le même nombre de prompts » ne constitue donc pas une mesure fiable de la consommation.

Le Bring your own key (BYOK) consiste à configurer ses propres identifiants de fournisseur de modèles ou un endpoint compatible. Factory prend en charge les modèles personnalisés propres à l’utilisateur, y compris les configurations locales. Sa documentation BYOK précise toutefois une limite importante : ces modèles personnels sont disponibles dans la CLI et l’application de bureau, mais pas dans les interfaces web ou mobiles hébergées.

La conséquence pour l’achat est concrète. Factory peut faciliter le changement de modèle au sein d’un workflow, mais il faut vérifier que le modèle prévu est accessible depuis l’interface où le travail sera exécuté. Un pilote avec un modèle local ne valide pas automatiquement la délégation depuis le web.

Examiner le travail délégué sur ordinateur et sur le web

L’application de bureau de Factory est utile lorsque le résultat doit être inspecté visuellement à côté de la conversation. Sa page produit cite les diffs de code, documents, présentations, feuilles de calcul, PDF et sites web en ligne parmi les contenus prévisualisables. Elle mentionne aussi les commentaires associés à des lignes de code ou à des éléments sélectionnés. L’application est disponible sur macOS et Windows. Factory Desktop décrit également la continuité des sessions entre les interfaces de bureau, web, mobile et CLI.

Pour un fondateur technique qui modifie une page de paramètres de compte, le workflow est simple : décrire le comportement attendu, inspecter le rendu, rattacher ses retours à l’élément concerné et examiner les modifications de code avant la mise en production. Le retour visuel aide à situer une demande comme « ce message d’erreur doit apparaître à côté du champ e-mail ». Il ne prouve ni que le serveur refuse une mise à jour invalide ni que les paramètres d’un autre utilisateur restent inaccessibles.

Cette distinction compte lorsqu’on délègue. La personne qui valide l’interface et celle qui vérifie le comportement de l’application peuvent être différentes. Demandez à la fois la modification visible et les éléments prouvant que le comportement sous-jacent fonctionne. Un aperçu convaincant ne doit pas être le seul critère d’achèvement.

Factory répertorie aussi des connecteurs pour des outils comme GitHub, Linear, Slack et Sentry. Ils peuvent apporter du contexte dont l’accès est autorisé, mais connecter un outil de suivi ne rend pas un ticket ambigu plus précis. La tâche a toujours besoin d’un responsable, d’un périmètre et d’un résultat clairement défini.

L’exécution à distance introduit une autre distinction : l’interface où l’on examine le travail n’est pas l’ordinateur qui l’exécute. Les Droid Computers gérés par Factory sont des environnements persistants qui conservent les fichiers, les paquets installés, les services et la configuration d’une session à l’autre. Factory documente séparément une option Remote Control pour une machine que vous administrez déjà. La documentation des Droid Computers présente les deux possibilités.

La persistance est utile lorsque la préparation de l’environnement coûte cher. Elle signifie aussi que quelqu’un doit être responsable de son état. Factory précise explicitement que reconstruire un Environment ne met pas à jour un Droid Computer créé auparavant à partir de son instantané. Un responsable plateforme doit donc vérifier l’état de la machine avant de considérer qu’une exécution réussie sera reproductible ailleurs.

Une usine logicielle IA commence par une tâche reproductible

Factory devient plus intéressant lorsque Droid traite une file de tâches bien définies sans qu’un développeur ait à démarrer chaque conversation à la main. Droid Exec est son mode sans interface interactive : une commande non interactive qui exécute une tâche et renvoie un résultat à un script ou à un système d’intégration continue (CI). Son comportement par défaut est la lecture seule ; les modifications et les commandes plus étendues nécessitent des réglages d’autonomie explicites. La documentation d’Exec couvre les formats de sortie, les répertoires de travail et les worktrees Git isolés.

Une analyse de dépôt qui fournit des éléments vérifiables par le mainteneur constitue un bon premier workflow. Après avoir installé Droid et vous être authentifié, lancez cette commande depuis un dépôt :

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

Il s’agit d’un exemple de commande, pas d’une exécution réalisée pour cette évaluation. À lui seul, le résultat ne prouve pas l’état de la couverture de tests : les appels dynamiques, les tests d’intégration et le code généré peuvent fausser une conclusion trop simple. La sortie constitue une liste de travaux possibles à soumettre au mainteneur.

L’étape suivante consiste à laisser Droid réaliser une modification de tests approuvée et bien délimitée, sur une branche ou un worktree distinct, puis à lancer les vérifications du dépôt. La validation ne doit pas reposer sur les seules explications de l’agent. Le résultat de la CI et la décision de la personne chargée de la revue doivent déterminer si le travail est terminé.

Un obstacle discret à l’automatisation peut facilement passer inaperçu : une règle de commande dont la décision effective est ask exige toujours une approbation avec le niveau d’autonomie High, alors qu’une tâche lancée en une seule exécution ne peut pas recueillir d’approbation interactive. Augmenter l’autonomie ne suffit donc pas nécessairement à débloquer une automatisation. Factory documente droid rules check pour prévisualiser les décisions des règles avant l’exécution. Il faut résoudre ce problème de configuration de manière réfléchie, pas désactiver toutes les vérifications d’autorisation.

Pour les travaux plus importants, Mission Mode coordonne les agents exécutants et la validation. Il exige le niveau d’autonomie High ou l’option de contournement non sécurisée décrite dans la documentation. Avec les offres individuelles, les Missions peuvent être mises en pause lorsque les limites d’utilisation sont atteintes. Commencez par des tâches ordinaires au périmètre limité avant de promettre qu’une migration importante s’achèvera sans supervision.

Le bénéfice est la reproductibilité : les mêmes modalités de prise en charge, les mêmes limites d’autorisation et les mêmes éléments de vérification à chaque exécution. La difficulté est de désigner un responsable de l’exploitation. Quelqu’un doit gérer les dépendances, les identifiants, le périmètre des tâches et les échecs. Le comparatif des plateformes d’usine logicielle aide à faire le choix suivant si cette organisation compte davantage que chaque session de programmation prise isolément.

Prix de Factory AI : choisir l’offre qui répond au workflow

Factory Teams est le choix le plus direct pour une petite équipe qui veut centraliser la facturation. Business devient l’offre à examiner lorsqu’il faut une consommation mutualisée encadrée par contrat, une gestion des identités ou des règles d’administration. Passer d’une offre individuelle à Teams ne signifie pas que ces contrôles sont inclus.

Voici les conditions mensuelles de la page de tarifs de Factory, vérifiées le 21 octobre 2026 :

La page de tarifs ne publie aucun quota de tokens. L’utilisation est exprimée uniquement en multiples de Pro. Ces multiples ne garantissent pas un nombre de tâches, et rien ne permet de les convertir de façon fiable en pull requests acceptées. La documentation des offres pour organisations précise que chaque utilisateur Teams dispose des limites d’utilisation de Pro ; Business et Enterprise reposent sur une consommation mutualisée régie par les conditions du contrat.

Cinq utilisateurs Teams coûtent $260 par mois : $60 + 5 × $40. Dix coûtent $460. Si une équipe de cinq utilisateurs acceptait, à titre d’hypothèse, 20 pull requests de Droid dans le mois, la part de l’abonnement représenterait $13 par pull request acceptée. C’est un calcul, pas une prévision de capacité ; il faut ajouter les dépassements d’utilisation, les ressources de calcul et le temps de revue avant de comparer le coût total.

Le problème vient souvent d’une offre qui ne couvre pas les besoins du workflow. Pro ne fournit pas les contrôles d’entreprise indiqués pour Business. Teams n’est pas présenté comme donnant à chaque utilisateur le volume d’utilisation de Plus. En outre, la documentation des offres individuelles mentionne les Droid Computers gérés dans Pro, tandis que la page commerciale les ajoute avec Plus. Pour établir le budget, retenez la page de tarifs et faites confirmer ce qui est effectivement inclus avant de dépendre de ressources de calcul gérées.

Quelles limites peuvent bloquer le déploiement ?

Les limites les plus importantes de Factory concernent la cohérence entre les interfaces et les offres. Elles peuvent bloquer un déploiement même lorsqu’une session de programmation individuelle semble concluante.

La prise en charge d’un éditeur ne garantit pas les mêmes fonctions. JetBrains ne dispose pas du partage automatique des fichiers, des sélections et des diagnostics décrit pour les éditeurs de la famille VS Code. L’Agent Panel de Zed ne restaure pas les sessions Factory Droid précédentes. Une équipe qui adopte Droids comme standard doit donc prévoir un accompagnement propre à chaque éditeur et une méthode pour rétablir le contexte. Factory documente ces différences.

Le BYOK personnel ne suit pas l’utilisateur sur le web ou le mobile hébergés. Un modèle configuré localement peut être au cœur de votre décision en matière de coût ou de traitement des données. Cette configuration n’est pas disponible dans toutes les interfaces de Factory. Validez le parcours d’exécution à distance envisagé avant d’acheter sur la seule foi d’une démonstration locale. La restriction est explicite.

Les multiples d’utilisation ne garantissent pas une capacité prévisible. La documentation des offres individuelles décrit des fenêtres glissantes indépendantes de 5 heures, 7 jours et 30 jours. Un abonnement plus élevé ne transforme pas ces fenêtres en quota de tokens publié ni en garantie d’achèvement. Si une échéance client dépend d’une exécution sans supervision, discutez d’une capacité contractuelle au lieu d’extrapoler à partir d’un court pilote. Les règles d’utilisation individuelle de Factory indiquent aussi que les Missions se mettent en pause lorsqu’une limite est atteinte.

L’accès aux ressources de calcul gérées doit être confirmé. L’écart entre Pro et Plus compte pour un fondateur qui prévoit d’exécuter du travail ailleurs que sur son ordinateur portable. Le tableau des offres de cette évaluation repose sur la page de tarifs en ligne ; la documentation contradictoire ne prouve pas qu’une mise à niveau est offerte. Vérifiez également les conditions liées aux ressources de calcul séparément de l’utilisation des modèles, au lieu de considérer que « agents cloud » signifie une infrastructure entièrement incluse.

Les règles d’autorisation ne constituent pas une isolation au niveau du système d’exploitation. La documentation de Factory sur l’autonomie le précise. Une commande autorisée n’est pas nécessairement inoffensive, et une instruction en langage naturel demandant d’éviter la production ne crée pas de séparation réseau. Pour un pilote, utilisez les accès et l’environnement adaptés à la tâche ; pour imposer des règles à l’échelle de l’organisation, évaluez les contrôles des offres sur devis.

Ces limites plaident pour une adoption ciblée. Utilisez Factory sur un workflow dont l’environnement, le modèle, les autorisations et le responsable de la revue sont connus. Étendre l’usage à tous les dépôts avant d’avoir tranché ces points crée un travail de coordination qui peut annuler le bénéfice de la délégation.

Notre avis sur Factory AI : quand l’adopter ?

Factory mérite sa place s’il réduit le travail humain nécessaire pour transformer une tâche définie en modification acceptée. Le choix des modèles, la multiplicité des interfaces et l’exécution à distance ne sont utiles que s’ils améliorent ce résultat.

Ajoutez-le aux côtés de votre agent actuel lorsqu’une file commune de maintenance, un workflow entre plusieurs éditeurs ou une comparaison méthodique de modèles ne trouve pas de solution satisfaisante dans l’existant. Remplacez l’agent en place pour cette catégorie de tâches uniquement lorsque des travaux comparables montrent une baisse de l’effort de revue ou du coût total, sans affaiblir les vérifications d’acceptation. Passez votre chemin s’il fait doublon avec un workflow déjà bien pris en charge par Claude Code, Codex ou Cursor.

Pour passer à l’action dès lundi, lancez une petite évaluation sous la responsabilité d’un référent qui répond du résultat :

Factory est un candidat crédible pour cette évaluation. Sa documentation décrit un système d’agents étendu et configurable. Elle ne démontre pas que vos développeurs livreront un meilleur travail en remplaçant simplement l’agent qu’ils connaissent par Droid.

Questions fréquentes

Recevez la checklist d’audit des workflows IA en entreprise via la newsletter pour préciser la tâche, les autorisations, le responsable de la revue et le coût d’exploitation avant d’étendre le déploiement d’un agent.