Faire double le volume hebdomadaire de PR avec les Agents Cloud de Cursor
Faire a choisi Cursor comme plateforme pour ses agents de codage, en remplacement d’un système interne de Background Agent.
Faire a doublé le volume hebdomadaire de PR et ramené une migration de 18 mois à un seul ingénieur pilotant une flotte d’agents. Les agents cloud de Cursor ont rendu cela possible grâce à une parallélisation à grande échelle et à leur autonomie. Les agents cloud s’exécutent sans les contraintes de mémoire et de ressources d’une machine locale, et chacun dispose de son propre environnement de développement—comme un ingénieur—pour écrire du code, tester, vérifier son travail et livrer du logiciel.
Cursor est désormais la plateforme recommandée par Faire pour le développement agentique, en remplacement d’un système interne de Background Agent. L’équipe utilise également Cursor Automations pour lancer plus de 2 000 exécutions autonomes d’agents par semaine et gagner du temps sur des tâches répétitives comme le tri des signalements de bugs dans Slack, la correction des échecs CI et l’acheminement des revues de code.
Le cloud permet le parallélisme des agents à grande échelle
Exécuter plusieurs agents en parallèle sur une machine locale se heurte rapidement aux limites des ressources disponibles : chaque agent se partage la même puissance de calcul, et gérer 10 tâches en cours dans des terminaux distincts devient vite un travail à part entière. « Il existe des moyens de paralléliser les agents sur votre machine locale, mais c’est beaucoup plus compliqué », explique Luke Bjerring, ingénieur principal.
Au départ, Faire a essayé de résoudre ce problème en créant un système interne d’agent cloud appelé Samurai, qui s’exécutait sur une infrastructure auto-hébergée. Mais offrir une excellente expérience développeur demande un investissement considérable.
« Mettre en place nos propres serveurs représente un investissement important. Cela suppose de recruter les bons talents, d’amorcer des machines et de maintenir une infrastructure complexe. Nous préférons que les ingénieurs se concentrent sur la création de valeur pour nos utilisateurs finaux », explique Bjerring.
Faire s’est donc mis en quête d’une plateforme qui lui offrirait la flexibilité d’exécuter des agents cloud sur une infrastructure gérée ou sur des machines auto-hébergées. L’entreprise a choisi Cursor pour cette souplesse de déploiement, son intégration étroite avec des outils comme GitHub, la fiabilité de ses agents, son interface claire pour gérer des agents en parallèle et la fluidité des transferts entre le local et le cloud. Cursor est désormais la plateforme recommandée par Faire pour le développement agentique dans toute l’entreprise.
L’offre cloud de Cursor est bien meilleure que de faire tourner des agents locaux avec des worktrees ou 10 environnements distants auxquels on accède via le shell. C’est une expérience utilisateur fluide pour gérer plusieurs agents en parallèle.
Les environnements de développement donnent plus d’autonomie aux agents
La parallélisation n’est réellement utile que si les agents peuvent opérer comme des ingénieurs : récupérer les dépendances, accéder aux services internes, exécuter du code et vérifier les modifications. Sans environnement de développement configuré, un agent peut écrire du code, mais il ne peut pas mener son travail jusqu’au bout.
L’environnement de développement de Faire complique la configuration des agents cloud. Le backend et le frontend se trouvent dans des dépôts distincts, avec leurs propres dépendances de paquets internes, gérées via Gradle et Bazel, et protégées par des identifiants AWS distincts.
Pour réduire cette complexité, Faire utilise l’onboarding piloté par l’agent de Cursor : Cursor inspecte chaque dépôt, identifie la chaîne d’outils et les dépendances requises, puis génère une configuration d’environnement que l’équipe peut modifier et versionner. Pour les workflows qui exigent un contrôle plus strict, Faire peut définir et gérer des environnements de développement via Dockerfile.
Nous laissons Cursor gérer lui-même son onboarding sur chaque dépôt de notre base de code. Cela réduit fortement la charge liée au démarrage de nouvelles sessions et permet aux agents de traiter les tâches comme le ferait un ingénieur.
Les designers de Faire utilisent un outil interne appelé Playground pour transformer les design systems dans Figma en composants React dans le code. Avec un environnement de développement entièrement configuré, Cursor peut exécuter le serveur Playground, produire des composants React et enregistrer des démos vidéo afin que les designers puissent évaluer le travail de l’agent.
Faire utilise énormément Slack, et une grande partie du travail d’ingénierie commence par une question ou un signalement de bug dans un canal. Les ingénieurs font souvent appel à @cursor directement depuis des fils de discussion Slack, en transmettant le contexte de la conversation à un agent cloud qui peut investiguer et revenir avec une PR.
Une grande partie de notre travail naît d’idées et de discussions dans Slack. On peut voir le message, lancer @cursor dans le même contexte, et obtenir une PR quelques minutes plus tard. Cela m’aide à éviter de jongler entre les outils et les contextes pendant que l’agent fait le travail.
Agents programmatiques avec Cursor Automations
Au-delà de l’exécution d’agents parallèles, Faire avait besoin d’agents capables de prendre en charge de manière autonome des tâches d’ingénierie répétitives pour faire gagner du temps à l’équipe. Faire a mis en place plus de 25 Cursor Automations et exécute désormais plus de 2 000 exécutions d’agents autonomes par semaine, sans aucune sollicitation manuelle. Les cas d’usage les plus courants sont les suivants :
- Qualification des bugs signalés dans Slack. Les automatisations surveillent les canaux Slack désignés pour repérer les signalements de bugs. Lorsqu’un problème est signalé, un agent cloud est lancé pour enquêter, ouvrir une PR avec des correctifs et fournir un récapitulatif de son travail.
- Autoréparation des PR. Lorsqu’une PR échoue en CI, une automatisation se déclenche, enquête sur l’échec, pousse les correctifs et met à jour la PR.
- Routage des PR. Un agent attribue à chaque PR des labels selon l’auteur, le risque et la taille, puis l’oriente vers un workflow de revue de code adapté.
Le concept d’automatisations existe chez Faire depuis longtemps, mais leur mise en place était laborieuse et complexe. Cursor Automations permet à chaque utilisateur de déployer facilement des agents toujours actifs.
Automatiser les migrations legacy avec des agents parallélisés
Lorsque Faire a dû migrer une vaste application destinée aux détaillants de MobX vers la gestion d’état native de React, l’équipe a construit sur Cursor un système de coordination d’agents appelé Swarm.
D’abord, un scraper repère toutes les utilisations de MobX dans la base de code et enregistre la liste dans S3. Swarm lit ensuite cette liste et délègue les tâches de migration à des agents cloud de Cursor, chacun s’exécutant dans sa propre VM isolée sur l’infrastructure de Cursor. Lorsqu’un agent termine son travail et fusionne sa PR, Swarm lance le suivant.
Ce qui aurait représenté 18 mois de travail manuel pour une équipe entière est désormais orchestré par un seul ingénieur gérant une flotte d’agents cloud.
La valeur de Cursor vient de son excellente gestion du contexte et de sa capacité à diffuser des informations propriétaires utiles dans toute l’entreprise et la base de code. Toutes ces tâches qui prendraient des heures à un humain peuvent désormais être déléguées à un agent. Nous économisons d’énormes quantités de travail manuel.
Mettre en place des aperçus de build en moins d’une journée
L’application web de Faire est vaste et complexe, et pour voir le comportement du moindre changement, il faut souvent lancer l’application complète en local. Blair McAlpine, ingénieur senior au sein de l’équipe plateforme, voulait créer un outil de prévisualisation afin que, lorsqu’un développeur crée une PR, un sandbox se lance et que l’équipe puisse interagir avec les changements à distance.
McAlpine a utilisé Cursor pour planifier et exécuter le projet. Il a commencé en mode planification et a affiné un plan étape par étape, chaque étape correspondant à une PR distincte. Il a ensuite confié ce plan à un agent cloud. L’agent a tourné pendant deux heures et a produit cinq PR empilées, chacune mettant en œuvre une étape du plan.
Ce que McAlpine pensait prendre des semaines a été réalisé en moins d’une journée avec les agents cloud.
L’agent cloud a tourné en arrière-plan pendant que je travaillais sur d’autres sujets. En moins d’une journée, il est passé de builds de prévisualisation créés de zéro à un outil interne pleinement opérationnel.
Faire s’attaque désormais au prochain goulot d’étranglement. Avec une productivité de l’ingénierie qui approche les 2 à 3x, Faire cherche maintenant où ce même type d’effet de levier peut accélérer l’ensemble du processus de développement produit. « À mesure que les équipes tirent davantage parti des agents de codage, les contraintes se déplacent », explique Bjerring. « L’opportunité consiste maintenant à aider les équipes adjacentes à accroître elles aussi leur impact. Cela nous permet de réallouer les ressources au sein de notre périmètre actuel et de nous attaquer à des projets plus ambitieux. »
Si vous cherchez à paralléliser votre vélocité d’ingénierie avec des agents cloud, contactez-nous pour démarrer un essai Cursor.
