Google Jules ferme : comment sauvegarder son travail et migrer

Fermeture de Google Jules : quelles dates retenir ?

Google Jules, l’agent de développement de Google qui travaille en arrière-plan, passera en lecture seule après le 11 novembre, avant son arrêt définitif. L’avis de fermeture de Jules publié par Google est daté du 29 octobre 2026.

L’avis ne précise ni l’heure limite ni le fuseau horaire, et ne donne aucune échéance distincte pour l’API ou les licences. Il n’indique pas non plus de date de facturation ou de remboursement, ni de calendrier de conservation des données après la fermeture. Ces questions restent ouvertes : le tableau ne permet pas d’y répondre par déduction.

Pour un développeur qui n’a pas terminé un correctif, la priorité est de décider s’il le finalise dans Jules ou s’il reprend le patch et les exigences restantes dans une nouvelle tâche. Pour un responsable technique, il faut repérer les dépendances qui échappent habituellement à la revue de code : prompts récurrents, étapes de préparation du projet, permissions sur les dépôts et identifiants d’accès.

Si Jules travaille pour vous, agissez dès maintenant. Les équipes dont les modifications sont déjà fusionnées et qui n’ont aucun élément à récupérer dans Jules auront moins de choses à transférer. Celles qui évaluent des agents sans avoir de travail en cours dans Jules peuvent passer directement au choix du mode d’exécution ci-dessous. Attendre pour choisir un fournisseur à long terme peut se justifier ; attendre pour sauvegarder son travail, non.

Sauvegarder ce qui ne se trouve pas dans votre dépôt Git

Le code, les branches et les pull requests déjà présents sur GitHub y restent. L’export de Google couvre les éléments conservés par Jules : paramètres, variables d’environnement, planifications, connexions aux dépôts, éléments de mémoire, scripts de préparation, ainsi que les prompts, plans, journaux et patches des sessions. Consultez les instructions officielles d’export.

Une pull request, ou PR, est une proposition de modification du code. Elle peut conserver le patch sans garder la raison pour laquelle l’agent l’a choisi. Un script de préparation peut contenir l’installation du paquet qui manquait pour faire passer les tests ; un élément de mémoire peut expliquer pourquoi une refactorisation pourtant tentante a été écartée. Examinez ces informations avant d’en faire des consignes pour un autre agent.

Gardez l’export comme archive, puis préparez un dossier de reprise plus ciblé pour chaque tâche inachevée. Indiquez le dépôt et la branche, la modification attendue, ce qui est déjà fait, les critères d’acceptation restants et la commande qui permet de vérifier le résultat. Renvoyez vers les éléments utiles plutôt que de coller une conversation entière dans un nouveau prompt.

Une mise à jour de dépendance, par exemple, demande davantage qu’un simple « terminer la mise à jour ». Conservez le détail du problème de compatibilité encore présent, la liste des fichiers modifiés et le test qui reproduit l’échec. Le prochain agent reçoit ainsi une tâche bien délimitée, et la personne chargée de la revue peut identifier un résultat incomplet.

Comment exporter avec la procédure publiée par Google ?

La méthode de Google repose sur Jules Tools et le prompt d’export fourni. Installez l’outil, puis authentifiez-vous :

npm install -g @google/jules
jules login

Depuis votre répertoire personnel, lancez un agent de développement en ligne de commande et collez le prompt complet de l’avis de fermeture. Connectez d’abord GitHub pour récupérer les données des dépôts. Les fichiers sont enregistrés dans ~/jules-export ; gardez ce dossier privé, car env-variables.json contient les valeurs des identifiants d’accès. Les fichiers de chaque session comprennent notamment summary.md, les journaux d’activité et les diffs.

Un message de fin ne garantit pas un export complet. À la lecture de l’outil d’export publié par Google, on constate que le compteur de sessions dénombre les sessions répertoriées, même lorsque la récupération des détails d’une session échoue. Les erreurs sont signalées séparément. L’outil récupère aussi les commandes de préparation dans les sorties des sessions : vérifiez donc les fichiers réellement produits avant de considérer qu’un dépôt est prêt à être repris ailleurs. Ce constat vient de la lecture du script publié ; aucun export n’a été exécuté pour cet article.

La distinction compte pour le responsable qui valide la migration. « La commande s’est terminée » apporte moins de garanties que « le patch, la configuration et le contexte nécessaires sont présents ». Si un élément important manque, récupérez-le tant que vous avez encore accès au service, au lieu de demander au prochain agent de le reconstituer.

Que deviennent l’historique et l’API de Jules ?

Sauvegardez l’historique localement et supprimez les dépendances de vos automatisations à Jules. L’avis de fermeture ne promet ni import automatique de l’historique dans un autre agent ni maintien de l’API après l’arrêt du service.

La documentation publique de l’API Jules décrit les sessions et leurs activités : création de tâches, approbation de plans et envoi de messages, notamment. Il s’agit de dépendances d’exécution : un bot qui crée une session à partir d’une issue doit être remplacé, même si personne dans l’équipe ne consulte le site de Jules.

Recensez les scripts, fichiers de workflow et intégrations qui appellent Jules. Notez leurs entrées, le signal de réussite qu’ils attendent et l’endroit où ils déposent leurs résultats. Une migration limitée au prompt peut échouer si l’ancienne intégration attend un identifiant de session Jules ou interroge les activités de Jules pour détecter la fin du traitement.

La présence en ligne d’un guide de démarrage de l’API ne signifie pas que le service restera disponible plus longtemps. Faute de calendrier distinct pour les points d’accès, prenez celui du service comme limite de planification et transférez la création des tâches avant le passage en lecture seule. Il s’agit d’une recommandation opérationnelle, pas d’une échéance supplémentaire annoncée par Google pour l’API.

Pour l’historique, distinguez la conservation des informations de la possibilité de reprendre une session. Un plan sauvegardé aide un autre agent à comprendre la tâche ; il ne recrée pas l’environnement d’exécution du précédent. Terminez le travail ou laissez-le à un point de reprise documenté, afin qu’un autre développeur puisse reproduire l’étape suivante sans ouvrir Jules.

Que reprend Antigravity, et qu’est-ce qui est déjà disponible ?

Google explique vouloir intégrer les enseignements de Jules à Google Antigravity, sa plateforme de développement avec des agents. Dans l’annonce officielle de Jules, Google indique travailler à l’association d’une exécution autonome à distance, en arrière-plan, avec l’environnement de développement d’Antigravity. Aucune date de disponibilité n’est annoncée pour cet ensemble.

Le produit disponible permet déjà de travailler utilement en arrière-plan. L’application Antigravity gère des agents en parallèle, regroupe le travail dans des projets et exécute des tâches planifiées. La documentation Remote Control de Google décrit l’accès depuis un navigateur à des sessions qui tournent sur vos ordinateurs portables, vos postes de bureau ou vos serveurs.

La différence tient à la machine utilisée. Remote Control donne accès à une machine existante. À lui seul, il ne prouve pas que Google a mis en place un remplaçant hébergé de Jules. Une équipe qui veut faire tourner des tâches de maintenance pendant la nuit doit savoir quelle machine reste allumée, qui entretient ses dépendances et ce qui se passe si elle devient indisponible.

Pour migrer : ouvrez le dépôt dans Antigravity, reconstituez la configuration et les consignes nécessaires, puis lancez une petite tâche assortie d’un test clair. Si vous comptez sur l’accès à distance, vérifiez la machine cible et sa disponibilité. Ajoutez la planification récurrente une fois ce workflow validé en revue.

Choisissez Antigravity si son environnement de développement vous convient et si vous pouvez exploiter la machine qui exécutera les tâches. Si votre exigence est « le développeur ferme son ordinateur portable et personne n’a d’autre machine à entretenir », évaluez dès maintenant une solution hébergée, sans faire dépendre la bascule d’une fonctionnalité dont la date de sortie reste inconnue.

Consultez les tarifs d’Antigravity pour les questions d’accès et de quotas, et le comparatif Google Antigravity et Cursor pour choisir, séparément, l’environnement de développement adapté à votre travail quotidien.

Choisir un environnement d’exécution adapté aux tâches en arrière-plan

Choisissez l’environnement d’exécution avant de vous attarder sur la manière dont l’agent rédige. Cet environnement comprend la machine et les logiciels qui exécutent la tâche. Pour cette migration, la comparaison utile porte sur sa prise en charge : vous l’exploitez, le fournisseur l’héberge, ou votre automatisation l’utilise via GitHub Actions.

Les pistes suivantes reposent sur la documentation actuelle des fournisseurs. Ce sont des points de départ pour migrer ; elles ne supposent ni des fonctionnalités identiques ni un format d’import commun avec Jules.

OpenAI Codex Cloud : des tâches hébergées et une configuration réutilisable

OpenAI Codex Cloud est un agent de développement hébergé qui peut continuer à travailler lorsque votre ordinateur est en veille. Chaque tâche dispose de son propre espace de travail, et vous pouvez examiner les modifications et les résultats des tests avant de créer un commit ou d’ouvrir une PR. Le guide officiel de Codex Cloud décrit la procédure de configuration actuelle.

Pour migrer : dans ChatGPT, choisissez Work in > Cloud, puis créez ou sélectionnez un environnement. Connectez les dépôts GitHub, laissez Codex préparer le projet, examinez ses vérifications de configuration et publiez l’environnement. Lancez une tâche bien délimitée à partir du dossier de reprise Jules que vous avez préparé, puis vérifiez les modifications et les résultats des tests.

Le point de blocage est l’accès aux ressources depuis l’environnement. Un test réussi en local ne dit pas grand-chose d’une tâche cloud qui ne peut pas joindre votre registre de paquets ou un service indispensable. Renseignez les destinations réseau et les identifiants nécessaires dans les paramètres de l’environnement, puis vérifiez que le même test y réussit.

Choisissez Codex si vous cherchez avant tout une file d’attente de tâches hébergée avec une configuration de projet réutilisable. Pour le premier essai, prenez une tâche dont vous pouvez rapidement juger le résultat, plutôt qu’une réécriture sans périmètre précis. Le comparatif Codex et Claude Code aborde plus largement le choix du workflow, au-delà de la fermeture de Jules.

Claude Code : sessions cloud ou automatisation du dépôt

Claude Code, d’Anthropic, propose des sessions cloud qui continuent après la fermeture de votre ordinateur portable, ainsi qu’une intégration distincte à GitHub Actions pour les workflows du dépôt. Le parcours de migration dépend de ce que vous remplacez : la transmission interactive d’une tâche ou un déclenchement automatisé.

Pour les sessions cloud : connectez le dépôt, configurez la préparation de l’environnement cloud, ses accès réseau et ses variables, puis lancez une tâche au périmètre précis. Depuis un terminal Claude Code authentifié, claude --cloud lance le travail dans le cloud. Avec le parcours habituel de clonage depuis GitHub, poussez d’abord la branche afin que la session récupère les commits voulus. Consultez le guide des sessions cloud de Claude.

Les points de blocage sont les quotas partagés et les accès : les sessions cloud consomment le quota d’utilisation de Claude du compte, et les permissions de l’organisation peuvent les restreindre. Une configuration personnelle qui fonctionne chez un développeur ne prouve pas que le compte de l’entreprise peut exécuter la même charge de travail.

Pour GitHub Actions : un administrateur du dépôt peut exécuter /install-github-app dans Claude Code, suivre les étapes d’authentification et examiner la PR du workflow généré. Commencez par une demande explicite avec @claude, puis ajoutez la tâche récurrente ou déclenchée par un événement que vous souhaitez remplacer. Anthropic décrit les prérequis concernant l’application, les identifiants et le workflow dans son guide GitHub Actions.

Le point de blocage est ici la responsabilité du workflow. Quelqu’un doit maintenir les déclencheurs, les identifiants et les permissions, et savoir distinguer une erreur de configuration d’un échec de la tâche de développement. Choisissez Actions lorsque l’événement dans le dépôt constitue le point de départ naturel. Notre guide de Claude Code avec GitHub Actions détaille ce mode de fonctionnement.

L’agent de développement GitHub Copilot : garder la passation dans GitHub

L’agent de développement GitHub Copilot réalise les modifications et les tests en arrière-plan, dans le workflow de GitHub. Sa documentation actuelle distingue les environnements cloud isolés des environnements GitHub Actions : vérifiez donc celui qui a été sélectionné pour la tâche. Consultez Copilot sur GitHub.

Pour migrer : vérifiez que votre offre et les règles de votre organisation autorisent l’accès, sélectionnez le dépôt et la branche, puis confiez à Copilot une tâche avec des critères d’acceptation et la demande d’ouvrir une PR. Examinez les modifications proposées et les résultats des tests avant de fusionner. Reprenez la même description d’issue que dans l’inventaire Jules pour vérifier que le remplaçant y a bien répondu.

La limite dépend de l’environnement d’exécution : les sessions GitHub Actions modifient un seul dépôt, tandis que les sessions en environnement cloud isolé peuvent intervenir sur plusieurs dépôts. Dans les deux cas, elles travaillent sur une seule branche et ouvrent une seule PR par tâche. Si la migration nécessite des modifications coordonnées sur plusieurs branches, découpez-la en tâches pouvant être examinées séparément.

Choisissez Copilot si la revue du code et l’attribution des tâches passent déjà par GitHub. La passation reste ainsi proche de l’issue et de la PR, mais il faut tout de même reconstruire l’environnement et les consignes jusqu’ici conservés dans Jules.

Le raccourci trompeur : exporter ne suffit pas à migrer

L’erreur serait de comprendre « Jules rejoint Antigravity » comme un programme de transfert des comptes. Les déclarations de Google décrivent une orientation produit et un export de données. Elles ne promettent pas que vos sessions actives, vos planifications ou vos éléments de mémoire réapparaîtront dans une solution de remplacement prête à fonctionner.

Autre raccourci : considérer l’accès par navigateur comme la preuve d’une exécution dans le cloud. Un navigateur peut piloter une machine que vous exploitez ou une machine hébergée par un fournisseur. Les interfaces peuvent se ressembler alors que la responsabilité de maintenir le travail en cours diffère.

Adoptez un critère de validation concret : la solution de remplacement doit reproduire la configuration nécessaire, terminer une tâche délimitée, rendre ses vérifications accessibles et livrer une modification que l’on peut examiner. Ne la choisissez pas simplement parce qu’elle reconnaît le même dépôt ou propose un plan plausible. Un plan aide à juger de la compréhension de la tâche ; un workflow qui aboutit démontre que la migration fonctionne.

Pour un responsable technique, cela réduit le périmètre de la décision. Il n’est pas nécessaire de trancher tous les futurs choix d’outils de développement avant la fermeture. Il faut une solution vérifiée pour les tâches qui s’arrêteraient autrement, avec un responsable capable de diagnostiquer les échecs.

Les actions à mener cette semaine

Commencez par faire fonctionner une première solution de remplacement, puis étendez-la au reste des tâches en attente.

• Recenser : listez les dépôts Jules, les sessions inachevées, les tâches récurrentes et les programmes qui appellent l’API. Attribuez un responsable et une destination à chaque tâche qui doit continuer.
• Sauvegarder : exécutez la procédure d’export de Google, examinez les erreurs et les fichiers importants, puis conservez l’archive d’origine dans un espace privé.
• Terminer ou préparer la reprise : passez en revue les patches en attente et laissez, pour chaque tâche à poursuivre, une branche, une exigence et un test compréhensibles.
• Reconstruire : configurez les dépendances, les consignes, les accès réseau et les identifiants de l’environnement d’exécution choisi. Ne placez pas les valeurs secrètes dans les notes habituelles des tâches.
• Valider : faites passer une petite tâche par toutes les étapes : préparation, réalisation, tests et revue humaine. Vérifiez le comportement en cas d’échec, au-delà de la PR réussie.
• Basculer : transférez les déclencheurs récurrents seulement lorsque la solution de remplacement fonctionne. Désactivez les soumissions en double et supprimez les accès obsolètes lorsqu’ils ne sont plus nécessaires.

Dès lundi, choisissez un dépôt actif, exportez son contexte Jules et menez une petite tâche jusqu’à la revue avec la solution de remplacement. Vous aurez ainsi une méthode de migration éprouvée à reproduire avant que le service n’accepte plus de nouvelles tâches.

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur les évolutions des outils de développement.