Limiter la première tâche d’un agent cloud Cursor à une correction vérifiable

Confier à Cursor un petit bug reproductible, puis attendre qu’il rende une PR à examiner par une personne, est une bonne première façon d’essayer un agent en arrière-plan. Une tâche adaptée à la délégation doit remplir trois conditions à la fois : le comportement attendu est clair, il peut être vérifié dans l’environnement distant et une seule personne responsable peut comprendre l’étendue des modifications. Si l’une de ces conditions manque, mieux vaut d’abord y remédier que continuer à allonger le prompt.

Cursor appelle aujourd’hui ce produit Cloud Agents, auparavant nommé Background Agents. Il travaille dans une machine virtuelle isolée dans le cloud, sans prendre le contrôle de votre répertoire de travail local actuel. Pour les tâches portant sur un dépôt, il modifie et remet le code sur une branche distincte. L’analyse du choix des tâches qui suit s’appuie sur la documentation officielle ; l’exemple n’a pas été exécuté.

Supposons qu’un projet possède un point de terminaison qui renvoie une liste : une requête vide valide devrait retourner un tableau vide, mais déclenche une exception. L’équipe a confirmé le comportement correct et dispose de tests pertinents. Cette tâche se prête mieux à la délégation que « améliorer la recherche », car l’agent peut partir d’un résultat observable pour rechercher la cause, modifier l’implémentation et ajouter un test de non-régression. La personne chargée de la revue peut également juger si la correction est juste.

Le même critère s’applique à l’ajout de tests pour des cas limites connus, à la correction d’exemples de documentation incohérents avec une interface existante et à la suppression de code dupliqué dans un périmètre bien défini. Toutefois, une refactorisation exige aussi des tests existants pour préserver le comportement observable de l’extérieur. En leur absence, il faut d’abord demander d’identifier les appelants et d’ajouter des tests, sans exiger en même temps une restructuration de grande ampleur.

La correction ci-dessus pourrait être déléguée avec les consignes suivantes :

• Reproduire l’exception déclenchée par le point de terminaison de liste lorsqu’il traite une requête vide valide. Commencer par ajouter un test de non-régression qui échoue avec l’ancienne implémentation.
• Corriger le résultat pour cette entrée afin de renvoyer une réponse réussie et un tableau vide. Conserver le traitement actuel des entrées invalides, sans modifier les paramètres de l’interface ni la structure de la réponse.
• Modifier uniquement l’implémentation et les tests concernés. Ne pas mettre à niveau les dépendances, ni modifier les contrôles d’autorisation, le schéma de la base de données ou la configuration de déploiement. S’il est nécessaire de dépasser ce périmètre, en expliquer d’abord la raison et s’arrêter.
• Exécuter les tests pertinents et les vérifications déjà prévues par le projet. Consigner les commandes, les résultats et les vérifications qui n’ont pas pu être exécutées. Remettre une PR en brouillon expliquant la cause profonde, les fichiers modifiés, les preuves de vérification et les risques restants. Ne pas la fusionner.

Il s’agit d’un exemple de tâche à des fins d’analyse, et non d’un script directement exécutable qui affirmerait l’existence de ces fichiers ou commandes. Pour une délégation réelle, il faut aussi préciser le dépôt, le commit de référence, l’entrée réelle permettant de reproduire le problème et les commandes de test du projet. Lors de la validation, il faut vérifier que le nouveau test couvre effectivement le bug initial, plutôt que se contenter de « tests réussis ». Si l’agent a supprimé les assertions ou modifié le test pour faire du comportement erroné le résultat attendu, un voyant vert ne signifie toujours rien.

La documentation de Cursor sur l’environnement indique que les agents cloud hébergés fonctionnent sous Ubuntu et peuvent être configurés avec l’aide de l’agent ou au moyen d’un Dockerfile. Les outils déjà installés en local, les fichiers non commités ou les connexions à des services privés ne peuvent donc pas être considérés comme déjà disponibles à distance. Avant de mettre la correction en file d’attente, vérifier que les dépendances peuvent être installées, que les tests peuvent démarrer et que les services nécessaires sont accessibles.

Le dépôt, les dépôts dont il dépend et les sous-modules nécessitent les droits de lecture et d’écriture correspondants. Si la tâche dépend de composants disponibles uniquement sur l’ordinateur d’un développeur, ou si les tests doivent accéder à un service interne dont l’accès n’a pas encore été autorisé, il faut d’abord régler l’environnement et les permissions. Ne pas présenter un échec d’installation ou un délai réseau dépassé comme une vérification du code accomplie. Il est possible de réduire la tâche à une analyse de la cause et à des propositions de modification, ou d’utiliser un mode de travail local interactif ayant accès à l’environnement requis.

Pour la première tâche, mieux vaut choisir une correction qui ne nécessite ni données ni identifiants d’accès de production, et utiliser des exemples débarrassés de leurs informations sensibles ou des doublures de test. Si aucun environnement de vérification fiable ne peut être établi, la tâche n’est pas encore adaptée à une progression sans surveillance jusqu’à un état prêt à fusionner.

La documentation de Cursor précise que Cloud Agents dispose par défaut d’un accès à Internet et exécute automatiquement les commandes du terminal. Il peut ainsi continuer à lancer des tests, mais peut aussi subir une injection de prompt après avoir lu du contenu malveillant. Une branche distincte peut isoler les modifications du code, mais ne peut pas récupérer des données déjà envoyées à l’extérieur. Considérer que « quelqu’un examinera la PR à la fin » constitue une frontière de sécurité suffisante pendant l’exécution serait une erreur.

Avant le lancement, il convient de limiter les destinations externes autorisées et de fournir uniquement les permissions et les identifiants d’accès nécessaires à la tâche. Cursor propose Runtime Secrets, qui masque les valeurs dans les sorties d’outils, l’historique des conversations et les commits. Ces valeurs restent toutefois utilisables par les programmes sous forme de variables d’environnement et visibles aux utilisateurs qui interagissent avec cet environnement via le terminal. Masquer la sortie ne rend pas les identifiants d’accès inutilisables et ne remplace pas la limitation des permissions qui leur sont associées.

Les migrations de bases de données de production, les changements de règles de paiement ou d’autorisation, ainsi que les modifications importantes qui dépendent de décisions produit non tranchées ne sont donc pas de bons choix pour une première tâche sans surveillance. Il s’agit d’un conseil de sélection fondé sur l’étendue des conséquences, et non d’une affirmation selon laquelle le produit ne peut pas modifier ce code. Des personnes doivent d’abord établir les contraintes métier et les risques, puis découper le travail en petites modifications vérifiables indépendamment.

Le processus de remise décrit officiellement consiste à pousser une branche et à ouvrir une PR pour une revue humaine ; il est aussi possible de demander un brouillon. L’équipe doit s’en servir pour préciser les responsabilités : l’agent fournit les modifications et les preuves, tandis que la personne responsable décide si les exigences sont satisfaites, si les risques sont acceptables et s’il faut fusionner. Le message de fin de l’agent ne vaut pas autorisation de fusionner.

Lors de la revue, vérifier d’abord que le diff reste dans le périmètre initial, puis relancer les principaux tests de non-régression et les vérifications d’intégration nécessaires. Examiner les branches de gestion des erreurs, les appelants, les changements de dépendances et les éventuelles fuites de données dans les journaux. Les vérifications impossibles à exécuter doivent rester documentées dans la PR, avec une personne clairement désignée pour les compléter. Si les modifications s’étendent sans cesse, si les tests en échec sont contournés à répétition ou si de nouvelles décisions métier deviennent nécessaires, revenir à une discussion interactive et redécouper la tâche.

Le bénéfice d’un agent en arrière-plan dépend de la qualité de la remise. Commencer par une petite correction reproductible sans permissions de production, dont le résultat est clair et qui peut être examinée intégralement. N’élargir la délégation qu’après avoir éprouvé à la fois l’environnement et le processus de revue au cours de ce premier essai.