Tu as un bouton à ajouter à ton site. Faut-il expliquer la demande à Grok Bot pour qu’il la transmette à Cursor ? Pour cette tâche seule, probablement pas. Mais si la mission commence par des retours utilisateurs et se termine par une fonctionnalité testée, le relais devient plus intéressant.

Entre les deux, il faut comprendre le besoin, retrouver les informations, vérifier le parcours et préparer la livraison. C’est sur ce travail autour du code que le duo mérite d’être regardé.

Avec Cursor Pro, Pro+ ou Ultra, l’accès à Grok Bot est inclus. Tu utilises le même compte, sans abonnement Grok Bot séparé. Reste à choisir des missions qui justifient de les faire travailler ensemble. [1]

Le lien concret passe par les Cloud Agents

Grok Bot peut déléguer des tâches de programmation aux Cloud Agents de Cursor. Ce sont des agents qui travaillent dans des environnements distincts, avec leurs propres accès et contrôles. Il ne s’agit donc pas de lui faire taper dans ta session Cursor ouverte. [2]

De son côté, Grok Bot dispose d’un ordinateur cloud persistant, d’un navigateur et de connexions à des applications. Tu peux lui confier le travail autour du code : consulter des informations, préparer une demande, utiliser un site, conserver le contexte d’une mission. [3]

Dans un workflow qui combine les deux, tu peux donc discuter principalement avec Grok Bot, lui faire déléguer une modification, puis examiner le résultat côté Cursor. L’image du « chef de projet » aide à comprendre cette répartition, mais elle décrit un rôle que tu lui donnes, pas une hiérarchie obligatoire entre les produits.

L’intérêt se joue surtout dans les passages entre les outils. Quand une demande commence dans un retour utilisateur et doit finir dans une modification testée, il y a davantage à faire que produire du code.

Un exemple simple : ajouter un bouton « Dupliquer »

Prenons une petite application de liste de tâches. Tes utilisateurs recopient chaque semaine les mêmes éléments et réclament un moyen de les dupliquer. Ajoutons au développement du bouton le travail de préparation et de vérification.

Le scénario qui suit illustre les capacités documentées, ce n’est pas le compte rendu d’un test réalisé. On suppose que le dépôt est connecté aux Cloud Agents, que leur environnement permet de lancer l’application et ses tests, et que Grok Bot peut accéder à une version de test. Ces accès se configurent, l’abonnement ne les crée pas. [4]

Tu donnes cette mission à Grok Bot :

Prépare l’ajout d’un bouton « Dupliquer » dans cette application. La copie reprend le titre et la description, avec le statut « à faire » et sans échéance. L’original ne doit pas changer. Fais préparer le code et les tests par un Cloud Agent Cursor. Reviens avec la proposition à vérifier. Aucun déploiement.

Le travail attendu se décompose ainsi :

Grok Bot prépare la demande. Il examine le parcours existant et relève les ambiguïtés. Faut-il ouvrir la copie immédiatement ? Où placer le bouton ? Tu tranches ce qui relève du produit avant de déléguer le développement.
Un Cloud Agent prépare la modification. Les Cloud Agents travaillent sur une branche séparée et peuvent fournir une proposition de changement, des tests et des éléments de démonstration. Tu demandes notamment de vérifier que l’original reste intact. [4][5]
Tu examines le résultat. Tu peux reprendre la branche dans Cursor, consulter la proposition sur le dépôt ou tester dans l’environnement distant. Le retour dans ton application Cursor n’est pas une étape imposée pour toute validation. [5]

Puis, une fois une préversion accessible, tu peux demander à Grok Bot de rejouer le parcours et de préparer un court message pour les testeurs. Tu conserves l’envoi et la mise en production derrière une validation.

Tu suis la demande avec le Bot, mais la proposition reste une modification que tu peux inspecter et refuser.

Dans l’autre sens : partir de Cursor, puis donner la suite à Grok Bot

Tu peux aussi commencer normalement dans Cursor. Le bouton est développé, une proposition de modification existe, et une préversion est disponible. À ce stade, le code ne demande plus ton attention immédiate, mais le parcours utilisateur et la préparation de la livraison restent à vérifier.

Tu transmets à Grok Bot les liens utiles et une consigne :

Voici la modification et sa préversion. Teste la duplication avec une tâche vide, une tâche terminée et une longue description. Compare le résultat aux critères fournis. Prépare les captures et un brouillon d’explication pour les utilisateurs. Signale ce que tu n’as pas pu vérifier.

Ici, le relais est explicite : tu fournis les liens et les critères. Il ne faut pas imaginer que toute ta conversation Cursor devient automatiquement la mémoire du Bot. Un lien vers du code ne suffit pas non plus à lui donner une application sur laquelle cliquer. [3][6]

Pour automatiser certains relais, la documentation prévoit des routines déclenchées par des événements, notamment des messages Slack ou des notifications GitHub. Ces intégrations du compte Cursor sont distinctes des plugins : installer un connecteur ne configure pas à lui seul le déclenchement. [7]

Transformer un signalement flou en correction vérifiable

Revenons à notre application. Un testeur écrit : « La duplication fait n’importe quoi. » Avant de corriger, il faut savoir ce qui s’est passé. Une copie absente ? Deux copies ? Une échéance conservée alors qu’elle devrait être vide ?

La reproduction de bugs est un cas d’usage documenté de Grok Bot : consulter un signalement, le reproduire dans un environnement de test et fournir les étapes, le comportement attendu, le résultat observé et des captures. [8]

Dans notre scénario, tu lui demanderais d’établir ce dossier avant de déléguer un correctif à Cursor. Si le problème n’est pas reproductible, demande ce qui manque avant de laisser un agent modifier le code.

Le gain recherché, c’est une meilleure demande de correction. Tu ne fais plus toi-même toute la traduction entre une plainte utilisateur et les informations nécessaires pour travailler sur le code.

Préparer une évolution à partir d’informations dispersées

Le même principe s’applique quand le besoin n’est pas encore défini. Plusieurs utilisateurs réclament une duplication hebdomadaire, mais d’autres veulent de véritables tâches récurrentes. Ce sont deux fonctionnalités différentes, avec des règles différentes.

Tu peux confier au Bot une mission de préparation : consulter les retours auxquels tu lui as donné accès, regrouper les demandes et proposer des critères. Les connexions aux applications lui donnent un moyen de récupérer ces éléments sans dépendre uniquement de ce que tu colles dans le chat. [3]

Tu valides ensuite le périmètre avant de demander une implémentation à Cursor. Par exemple : commencer par la duplication manuelle, garder les récurrences pour plus tard et ne pas toucher aux notifications.

Autre variante : préparer une adaptation à une API externe. Le Bot rassemble la documentation actuelle, relève les changements annoncés et produit un dossier de migration. Cursor peut ensuite recevoir une mission limitée sur le dépôt. Tu délègues la collecte et la préparation, pas le choix de ce que ton produit doit devenir.

Refaire les vérifications sans réécrire toute la méthode

Une fois le bouton livré, tu pourrais vouloir vérifier régulièrement qu’il fonctionne encore. Grok Bot distingue les skills, qui décrivent comment effectuer une tâche, des routines, qui définissent quand la lancer. Une méthode réussie peut ainsi devenir un contrôle récurrent. [7]

Pour notre application, la méthode pourrait être : créer une tâche de test, la dupliquer, contrôler les champs, vérifier l’original et conserver les preuves. La routine demanderait de rejouer ce parcours chaque semaine sur l’environnement prévu.

En cas d’échec, tu pourrais prévoir un rapport puis une demande de correction à un Cloud Agent, avec un point d’arrêt avant toute mise en production. Cette chaîne reste à configurer et à tester : une session expirée ne doit pas être interprétée comme un bug à réparer.

Ce mécanisme devient intéressant sur plusieurs petits produits. Tu gardes des contrôles définis et tu reçois des exceptions à examiner, plutôt que de devoir te souvenir de chaque vérification. Commence par une seule routine, avec un résultat que tu as déjà vérifié manuellement.

Garder le contexte, y compris quand tu quittes ton bureau

Un Bot peut conserver des préférences de travail, des informations importantes et des résumés de ses missions. Tu peux donc lui donner des règles durables : quelle application il suit, où trouver les critères et quelles actions nécessitent ton accord. Les informations changeantes doivent rester dans leurs sources. [9]

Dans notre exemple, sa description pourrait préciser : « Travaille uniquement sur la version de test. Pour toute duplication, vérifie que l’original reste intact. Ne fusionne aucune modification sans validation. » Cela évite de dépendre d’une consigne oubliée au milieu d’un échange.

Le suivi n’exige pas de rester devant ton ordinateur. Les applications mobiles de Grok Bot retrouvent les mêmes Bots et conversations, permettent de répondre ou d’approuver certaines étapes, et le travail cloud peut continuer quand l’application est fermée. [10]

L’usage concret serait de lire un rapport et de demander un ajustement depuis ton téléphone. Pas de considérer qu’une notification « terminé » remplace une revue sérieuse du changement.

Quand rester uniquement dans Cursor

Pour une modification déjà claire et centrée sur le dépôt, le détour par Grok Bot peut être superflu. « Change ce libellé », « Ajoute ce test », « Corrige cette fonction » : tu as déjà le contexte technique sous la main. Un intermédiaire peut ajouter des échanges au lieu d’en enlever.

Il faut aussi éviter une comparaison faussée où Cursor serait incapable de naviguer, d’utiliser des outils ou de coordonner du travail. Ses Cloud Agents disposent eux-mêmes de capacités de navigation et de connexions MCP. [5]

Cursor a également annoncé Projects le 10 septembre 2026, en bêta et en déploiement progressif : un coordinateur, du contexte partagé et des tâches récurrentes autour d’un projet logiciel. L’orchestration n’est donc pas une exclusivité de Grok Bot. [11]

Le critère utile, c’est le travail à prendre en charge autour du dépôt. Lorsque la mission traverse les retours clients, les outils métier, le navigateur et le développement, le duo mérite un essai. Lorsqu’elle tient déjà dans une demande de code claire, commence par le plus direct.

Les limites à régler avant de déléguer

L’accès à Grok Bot est inclus avec Cursor Pro, Pro+ et Ultra, mais la quantité d’usage hebdomadaire varie. Une consommation supplémentaire peut être facturée par Cursor lorsque l’usage à la demande est activé. Son plafond n’interrompt pas forcément une exécution déjà commencée. Les Cloud Agents ont aussi leurs règles de facturation : ne suppose pas qu’une délégation soit sans coût parce que l’accès au Bot est inclus. [1][4]

Côté accès, fournis un dépôt autorisé, un environnement exploitable et des comptes de test. Définis les actions qui demandent un accord, notamment la fusion, le déploiement ou l’envoi de messages. Auto Review aide à contrôler les opérations, mais ce contrôle repose lui-même sur un modèle et ne remplace pas des permissions limitées. [12]

Autre détail important : tous les Bots d’un même utilisateur partagent un ordinateur cloud. Créer un Bot par projet ne sépare donc pas automatiquement les fichiers et les sessions. Et Grok Bot conserve des données de travail : un réglage excluant l’entraînement n’équivaut pas à une absence de stockage. [12]

Pour ton premier essai, demande un résultat observable : lien vers la modification, tests réellement exécutés, preuves et éventuels blocages. Mesure le temps que tu as dû consacrer au résultat, y compris les corrections et la revue. C’est plus parlant que le nombre d’agents lancés.

Essaie le relais sur une vraie petite mission

Prends une évolution qui demande aussi du travail hors du code. Fais préparer la demande par Grok Bot, délègue une modification limitée à Cursor, puis reviens au Bot pour vérifier le parcours sur une préversion accessible.

Tu sauras assez vite où le relais t’aide : moins d’informations à recopier, un signalement mieux préparé, une vérification que tu n’as pas eu à refaire toi-même. Ou, au contraire, des échanges supplémentaires qui ne servent à rien.

Garde ce qui te retire du travail sans rendre le résultat plus difficile à contrôler. Pour notre bouton « Dupliquer », une copie correcte, un original intact et une preuve valent davantage qu’une conversation où tout le monde annonce que c’est terminé.

Le vrai changement, ce n’est pas que Grok Bot puisse appeler Cursor

Pris séparément, Cursor sait déjà très bien travailler sur du code, et Grok Bot sait déjà naviguer, utiliser des applications, garder du contexte et exécuter des missions dans le cloud. Le truc nouveau, c’est le relais entre les deux.

Tu peux partir d’un besoin encore flou, laisser Grok Bot récupérer le contexte et préparer la mission, envoyer la partie développement à un Cloud Agent Cursor, puis reprendre le résultat pour le vérifier ailleurs. Et tu peux faire l’inverse : partir d’un changement produit dans Cursor, puis confier à Grok Bot les vérifications, la collecte d’informations ou les étapes qui suivent le code.

Ça ne rend pas toutes les tâches meilleures par magie. Pour modifier trois lignes dans un dépôt, passe directement par Cursor. Mais dès qu’une mission commence avant le code ou continue après lui, le pont devient beaucoup plus intéressant.

C’est probablement là que je testerais le duo en premier : pas pour ajouter un agent de plus dans la boucle, mais pour voir combien de passages manuels entre mes outils je peux réellement supprimer sans perdre le contrôle.

Et c’est finalement la seule métrique qui m’intéresse : est-ce que le relais me retire du travail, ou est-ce qu’il m’ajoute juste une nouvelle interface à surveiller ?