Fermeture de Google Jules : exportez vos données et migrez

Exportez vos données Google Jules maintenant, puis recommencez après vos dernières sessions de programmation. Au 2026-11-01, Google indique que vous pouvez terminer vos sessions jusqu’au 11 novembre 2026. L’accès passera ensuite en lecture seule jusqu’à la fin de l’année. Jules fermera le 31 décembre 2026, selon l’annonce officielle.

La migration comprend deux étapes : conserver les données stockées par Jules, puis faire fonctionner une tâche dans l’outil choisi. Votre dépôt ne contient pas à lui seul les informations mémorisées, la configuration de l’environnement et l’historique nécessaires à cette seconde étape.

Que terminer avant le passage en lecture seule ?

Terminez les tâches en cours et conservez les modifications utiles avant le 11 novembre. Google annonce le passage en lecture seule après cette date, sans préciser l’heure limite ni le fuseau horaire.

L’annonce ne garantit pas non plus que les points de terminaison d’export resteront accessibles pendant toute cette période. Exporter avant le 11 novembre constitue donc une précaution, pas une échéance d’export annoncée séparément.

Le code, les branches et les pull requests déjà présents sur GitHub y restent. Examinez les sessions inachevées et publiez les modifications utiles lorsque cela convient. Conservez les correctifs exportés pour le travail qui n’a pas encore rejoint une branche.

Google indique que les enseignements tirés de Jules contribuent à Antigravity. Cette déclaration ne fournit aucune procédure de migration et ne garantit pas le transfert automatique de votre configuration.

Comment exporter vos données Jules ?

Utilisez le prompt d’export complet de Google avec un agent de programmation local en ligne de commande, ou CLI. Ce prompt comprend un script Python qui récupère la configuration du compte, les informations des dépôts et les enregistrements des sessions.

Préparez la CLI et un dossier privé

Utilisez Bash sous macOS ou Linux pour les commandes suivantes. Vous devez disposer de Node.js avec npm, de Python et d’un agent CLI installé.

Vérifiez les outils nécessaires :

node --version
npm --version
python3 --version

Le script publié nécessite Python 3.9 ou une version ultérieure. Cette exigence découle de son utilisation de str.removeprefix, introduit dans Python 3.9 selon la documentation Python.

Installez Jules Tools, puis authentifiez-vous :

npm install -g @google/jules
jules login
jules remote list --repo

Connectez-vous vous-même dans le navigateur avec le compte Google dont vous souhaitez récupérer les données Jules. La dernière commande doit afficher les dépôts associés à ce compte.

Si des dépôts manquent, résolvez ce problème avant l’export. Vérifiez la connexion et les autorisations des dépôts sur la page d’installation GitHub de Google Labs Jules.

Depuis votre répertoire personnel, créez un dossier d’export privé :

cd "$HOME"
umask 077
mkdir -m 700 "$HOME/jules-export"

Si ce dossier existe déjà, arrêtez-vous et renommez l’archive précédente avant de continuer. Gardez cette sauvegarde privée. Utilisez un nouveau dossier pour l’export final.

Lancez votre agent de programmation installé depuis le même shell. Pour Claude Code, exécutez claude. Son guide de démarrage explique l’installation et l’authentification si nécessaire.

Exécutez le prompt officiel complet

Ouvrez l’annonce de fermeture et développez Show the export prompt. Copiez le prompt entier, y compris son script Python, puis collez-le dans votre agent CLI.

Sous Linux, retirez du prompt la vérification préalable distincte qui utilise secret-tool lookup avant de l’envoyer. Cette commande écrit le secret enregistré sur la sortie standard, comme le montre le code de libsecret. Indiquez à l’agent que vous avez déjà vérifié la CLI Jules.

Laissez le script d’export lire les identifiants en interne. Ne demandez pas à l’agent d’afficher le jeton d’accès ou les valeurs de env-variables.json.

Demandez à l’agent d’enregistrer et d’exécuter le script fourni depuis votre répertoire personnel. Une fois l’opération terminée, demandez les compteurs affichés, les éventuelles erreurs et le chemin complet du dossier. La destination documentée est ~/jules-export.

Vérifiez l’archive avant de vous y fier

Vérifiez error_count et les fichiers attendus, même si le message final annonce un succès. Le compteur sessions inclut toutes les sessions répertoriées, y compris celles dont le téléchargement individuel a échoué.

L’export est conçu pour conserver les éléments suivants :

Éléments	Où les trouver	Étape suivante
Paramètres du compte, variables d’environnement et tâches planifiées	Fichiers JSON du compte, dont env-variables.json	Recréez les paramètres et secrets utiles dans l’outil choisi
Dépôts connectés	sources.json	Comparez la liste aux dépôts attendus
Informations mémorisées pour les dépôts, scripts de préparation et commandes de test	Dossiers propres à chaque dépôt, lorsque ces enregistrements existent	Vérifiez-les et adaptez-les avant utilisation
Prompts, plans, journaux d’activité et correctifs des sessions	Dossiers propres à chaque session, dont les fichiers lisibles summary.md	Conservez l’historique et récupérez le travail inachevé

Vérifiez que error_count vaut 0, puis examinez un échantillon de sessions anciennes et récentes. Contrôlez séparément votre session inachevée la plus importante. Confirmez la présence de son prompt, de son plan, de son journal d’activité et des correctifs attendus.

Le script récupère les scripts de préparation et les commandes de test dans les métadonnées des résultats des sessions. Si un fichier setup.sh nécessaire manque, consultez la configuration du dépôt dans Jules tant qu’elle reste accessible.

Ce dossier constitue une archive de la configuration et de l’historique. Conservez le dépôt GitHub séparément. Gardez toute l’archive hors des dépôts, car env-variables.json contient les valeurs réelles des variables d’environnement.

Quelle erreur d’export rencontrez-vous ?

Renouvelez l’authentification Google si tous les appels échouent. Vérifiez l’accès GitHub si seule la recherche des dépôts échoue. Les instructions de dépannage de Google distinguent ces deux cas.

Symptôme	Cause probable ou condition documentée	Correction et vérification
Tous les appels d’export renvoient 401	Le jeton d’accès a peut-être expiré. Selon Google, il reste valable environ une heure après la connexion.	Exécutez une commande Jules ou reconnectez-vous avec jules login. Vérifiez à nouveau les dépôts, puis relancez l’export.
ListSources renvoie 401 avec missing required authentication credential, alors que les autres appels fonctionnent	Google associe ce cas à l’absence de connexion GitHub.	Connectez GitHub, vérifiez l’accès aux dépôts et relancez jules remote list --repo.
Un dépôt attendu manque	La connexion du compte ou l’accès aux dépôts sélectionnés doit être vérifié.	Confirmez le compte Google et l’installation GitHub utilisés. Relancez l’export et examinez sources.json.
Un point de terminaison d’export renvoie 404 ou 400	Le script utilise des points de terminaison internes non documentés.	Notez l’appel concerné et son code de réponse. Consultez le prompt officiel actuel avant de réessayer. N’inventez pas d’adresses de remplacement.

Si vous n’avez jamais utilisé Jules avec des dépôts GitHub, le prompt de Google autorise à ignorer cette connexion. Il précise que l’export ne contiendra alors aucune donnée de dépôt. Si vous attendez ces données, établissez la connexion et vérifiez à nouveau les dépôts avant l’export.

Transférez la mémoire et la préparation vers votre nouvel agent

Migrez d’abord les connaissances durables du projet et une préparation reproductible de l’environnement. Gardez l’archive complète des sessions comme référence.

Transformez les informations utiles en instructions de projet

Comparez les informations mémorisées pour chaque dépôt au code actuel. Conservez les commandes de compilation valides, les contraintes d’architecture et les solutions aux problèmes récurrents. Supprimez les conseils périmés, les règles en double et les secrets.

Placez les instructions communes dans un fichier AGENTS.md à la racine du dépôt. Codex lit ce fichier, et OpenCode 2 l’utilise pour les instructions du projet. OpenCode 2 n’utilise pas CLAUDE.md comme solution de repli.

Pour un projet npm contenant package-lock.json et un script npm test fonctionnel, voici un exemple minimal :

- Install dependencies with `npm ci`.
- Run `npm test` after code changes.
- Keep generated files out of manual edits.
- Report failing checks and unresolved setup requirements.

Ces règles précisent l’installation, les tests, les fichiers à ne pas modifier manuellement et les problèmes à signaler. Intégrez les instructions vérifiées aux fichiers existants plutôt que de remplacer leur contenu.

Pour Claude Code, ajoutez cet import dans le fichier CLAUDE.md à la racine du dépôt. Conservez les instructions spécifiques à Claude déjà présentes :

@AGENTS.md

La documentation de Claude sur la mémoire décrit cette organisation avec un fichier partagé. Démarrez une nouvelle session et utilisez /context pour vérifier que CLAUDE.md figure dans Memory files.

Avant d’autoriser les modifications, demandez à l’agent d’identifier les commandes nécessaires à la préparation et aux tests. Vous vérifierez ainsi l’utilité des instructions transférées. Pour organiser ces connaissances à plus long terme, consultez le guide sur la mémoire des agents de programmation.

Recréez l’environnement d’exécution

Adaptez le script de préparation exporté à l’environnement cible et à son cycle de démarrage. Avant de l’exécuter, vérifiez les répertoires de travail, les versions des environnements d’exécution, les registres de paquets, l’accès aux secrets et les services.

Pour les sessions cloud Claude Code, ouvrez l’éditeur d’environnement et sélectionnez Setup script. Utilisez Choose file pour charger le script vérifié. Le guide des environnements cloud décrit les étapes de préparation. Les variables configurées pour la session ne sont pas encore définies pendant l’exécution du script de préparation. Ne supposez donc pas que leur accès fonctionne comme dans Jules.

Pour Codex Cloud, créez un environnement pour vos dépôts GitHub en suivant le guide actuel des environnements cloud. Fournissez les commandes d’installation et de test vérifiées. Utilisez Install script pour les dépendances et Start skill pour démarrer les services. Vérifiez l’environnement préparé, publiez-le, puis lancez une nouvelle tâche.

Pour Claude Code ou OpenCode en local, recréez l’environnement sur votre machine ou dans un conteneur de développement, ou devcontainer. Vous pouvez enregistrer les commandes d’installation vérifiées dans .devcontainer/setup.sh. Dans le fichier existant .devcontainer/devcontainer.json, donnez à postCreateCommand la valeur bash .devcontainer/setup.sh. La référence Development Containers précise quand cette commande s’exécute.

Transférez les valeurs secrètes via les paramètres de secrets de l’environnement cible. Ne copiez pas env-variables.json dans les instructions du projet et ne le commitez pas avec le script de préparation.

Enfin, exécutez la commande de test récupérée dans un environnement neuf. Corrigez les erreurs de préparation avant de demander à l’agent de modifier le code de l’application.

Recréez les tâches planifiées après un essai manuel

Recréez chaque tâche récurrente à partir de son prompt et de son calendrier exportés. Conservez le dépôt, la branche prévue, le fuseau horaire, les exigences d’environnement et le résultat attendu.

Pour Claude Code, les tâches planifiées dans le cloud sont en aperçu expérimental, ou research preview, au 2026-11-01. Elles sont disponibles avec les offres Pro, Max, Ultra, Team et Enterprise, sous réserve des restrictions de l’organisation.

Ouvrez la page des tâches planifiées de Claude et choisissez New task. Certains comptes affichent New routine. Saisissez le prompt, sélectionnez le dépôt et l’environnement cloud, puis définissez le calendrier. Lancez Run now, puis examinez History en suivant le guide des tâches planifiées.

Pour les tâches locales liées à Codex, utilisez Scheduled dans l’application de bureau ChatGPT. La documentation actuelle de la planification exige que l’ordinateur et l’application restent actifs lorsqu’une tâche nécessite des fichiers locaux. Codex CLI ne fournit pas l’interface de gestion Scheduled. Cette exigence concerne l’exécution locale ; distinguez-la de l’exécution hébergée de Codex Cloud.

Pour OpenCode 2, l’exemple officiel de CI utilise une exécution autonome et des identifiants de fournisseur transmis comme secrets de CI. Une fois OpenCode 2, le fournisseur et le modèle souhaités configurés, commencez par cette vérification :

opencode run --standalone "Read AGENTS.md and identify the setup and test commands. Do not edit files."

Cette commande demande de lire AGENTS.md et d’identifier les commandes de préparation et de test, sans modifier les fichiers. Examinez la réponse dans la sortie du workflow. Avec GitHub Actions, commencez par workflow_dispatch pour un lancement manuel, puis ajoutez un déclencheur schedule. GitHub décrit les deux dans sa référence des événements de workflow. Les workflows planifiés s’exécutent depuis la branche par défaut.

Avant d’autoriser des modifications sans surveillance, examinez les changements de permissions d’OpenCode 2. Vérifiez que la tâche peut effectuer les actions nécessaires sans demande interactive inattendue.

Désactivez l’ancienne tâche récurrente lorsque sa remplaçante a passé les vérifications. Évitez de laisser les deux calendriers agir sur le même travail. Lors des premières exécutions, recherchez les modifications en double, les échecs répétés et une consommation imprévue.

Quelle alternative à Jules choisir ?

Commencez par un agent hébergé si votre priorité est de poursuivre le travail après avoir fermé votre ordinateur portable. Privilégiez la CI si le contrôle de l’environnement et du fournisseur de modèles compte davantage qu’une interface fournie par le service.

Ces recommandations reposent sur les fonctionnalités documentées au 2026-11-01 :

Votre besoin	À essayer en premier	Ce qui peut changer le choix
Tâches hébergées sur des dépôts avec un environnement réutilisable	Codex Cloud	Si l’environnement ne peut pas joindre les services nécessaires ou reproduire la compilation, évaluez un runner que vous contrôlez
Tâches de programmation récurrentes avec une gestion intégrée	Sessions cloud Claude Code avec les tâches planifiées dans le cloud	Si l’accès à l’aperçu ou la politique de l’organisation bloque la planification, utilisez une solution de CI approuvée
Contrôle de l’accès aux modèles et de l’exécution	OpenCode 2 sur votre runner de CI	Choisissez un agent hébergé si vous ne souhaitez pas gérer la configuration des workflows, les identifiants et les permissions
Accès distant à une machine de développement existante utilisant les outils Google	Antigravity Remote Control	Le processus en arrière-plan documenté exige que la machine hôte reste allumée. Sinon, choisissez une exécution hébergée

Le mode Remote Control documenté d’Antigravity fonctionne sur votre machine. Évaluez ce mode d’exécution avant de considérer l’orientation de Google comme une solution de remplacement de l’environnement hébergé de Jules.

Pour une utilisation en CLI, BetterToken documente les connexions API de Claude Code et d’OpenCode. Distinguez cet accès aux modèles des exigences propres au compte, à l’exécution hébergée et à la planification de chaque outil.

Comparez les coûts avec la même tâche d’essai. Incluez la consommation du modèle, les abonnements obligatoires et les frais du runner applicables à la solution choisie. Un export ne permet pas de déterminer quel outil sera le moins cher.

Validez une tâche avant de terminer la migration

Choisissez une modification limitée avec un résultat attendu précis. Pour évaluer un nouvel outil, utilisez la même révision du dépôt, les mêmes exigences de préparation et la même commande de test.

Vérifiez que l’agent charge les instructions, prépare l’environnement, termine la tâche et laisse un résultat vérifiable. Pour une tâche hébergée, confirmez que l’exécution continue sans votre session locale. Pour une tâche planifiée, examinez une véritable exécution programmée après l’essai manuel.

Utilisez la liste de vérification des tâches réalisées par un agent pour contrôler les modifications et les résultats des tests dans les systèmes qui font référence.

Après vos dernières sessions Jules, effectuez un nouvel export et vérifiez-le à nouveau. Conservez ensemble l’archive privée, les instructions de projet vérifiées et les preuves du résultat obtenu avec le nouvel outil dans votre dossier de migration.