Fermeture de Conductor Cloud : exportez avant le 20 novembre

Par précaution, terminez et vérifiez le transfert des espaces Conductor Cloud et les sauvegardes nécessitant l’accès au terminal Cloud avant le 13 novembre 2026. Téléchargez et vérifiez séparément l’archive du compte avant le 20 novembre 2026. Utilisez Transfer to local pour les espaces de travail et Settings → Account → Export data pour l’archive.

Dans son annonce de son arrivée chez Meta, Conductor confirme que les anciens échanges et l’export des données resteront accessibles pendant la période de lecture seule. L’annonce ne confirme pas que les transferts d’espaces ou les terminaux Cloud resteront disponibles pendant cette période. Le service Cloud fermera le 20 novembre, date à laquelle commencera aussi la suppression des données de ses utilisateurs.

Pour les utilisateurs actuels, Conductor en local peut laisser le temps de terminer les travaux en cours. Considérez-le comme une solution temporaire, pas comme votre seule sauvegarde ni comme un remplacement permanent.

Quelles dates retenir pour la fermeture de Conductor ?

Terminez les transferts et les sauvegardes nécessitant le terminal Cloud avant le passage en lecture seule. Distinguez cette précaution du délai annoncé pour exporter le compte. Au 2026-11-10, le calendrier officiel est le suivant :

Date	Ce qui change	Mesure à prendre
4 novembre 2026	Les nouveaux utilisateurs ne peuvent plus s’inscrire à Conductor ni télécharger l’application. Les utilisateurs Pro actuels peuvent continuer à utiliser gratuitement les fonctions Pro.	Organisez la migration à partir de votre installation et de votre compte actuels.
13 novembre 2026	Les espaces Cloud passent en lecture seule. Les anciens échanges et l’export restent accessibles, mais l’envoi de nouveaux messages devient impossible.	Terminez les tâches interactives auparavant. Par précaution, terminez et vérifiez aussi les transferts et les sauvegardes nécessitant le terminal avant cette date.
20 novembre 2026	Le service Cloud ferme et la suppression des données de ses utilisateurs commence.	Terminez et vérifiez l’export séparé du compte avant cette date.
Début 2027	La période promise d’ajout de nouveaux modèles et de correction des bugs critiques prend fin pour Conductor en local. Son arrêt progressif commence.	Supprimez vos dernières dépendances à l’application avant cette phase.

L’annonce prévoit également un remboursement pour les abonnés actifs. Vérifiez votre historique de facturation séparément : cette promesse ne prouve pas que l’argent a déjà été crédité sur votre compte.

Pour une migration en équipe, fixez le 12 novembre comme objectif interne. Il s’agit d’une marge recommandée, pas d’une date officielle d’arrêt des transferts. Ne prévoyez pas de pouvoir exporter le compte jusqu’à la fin de la journée du 20 novembre.

Exporter Conductor Cloud sans perdre le travail en cours

Utilisez les deux méthodes d’export et sauvegardez séparément les fichiers en cours tant que l’espace Cloud reste accessible. Vérifiez chaque copie avant de vous y fier. Ne supposez pas que l’archive du compte permet de restaurer les fichiers modifiés, non suivis ou ignorés par Git.

Relever l’état de chaque espace et sauvegarder les fichiers

Préparez un inventaire succinct avant tout transfert. Notez le nom de l’espace, le dépôt, la branche, le dernier commit, la pull request ouverte et la personne chargée de vérifier le résultat.

Suspendez les modifications et les commits des agents pendant ce relevé. Tant que les terminaux Cloud sont accessibles, exécutez ces commandes à la racine du dépôt de chaque espace. Terminez cette étape avant le 13 novembre. Le shell utilisé est Bash :

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

La première commande affiche l’identifiant du commit actuel. La deuxième affiche les informations de branche et les fichiers modifiés ou non suivis. La troisième résume les différences des fichiers suivis par rapport à ce commit. Git décrit ces comportements dans ses références sur les révisions, l’état du dépôt et les différences.

Enregistrez toute la sortie de la deuxième commande dans pre-transfer-status.txt, avec votre sauvegarde indépendante. Faites-le avant de créer des dossiers de sauvegarde dans le dépôt. Conservez aussi l’identifiant complet du commit et le nom de la branche. Pour les suppressions et les renommages, notez les chemins absents de l’état final de l’arbre de travail.

Ces commandes inspectent l’état ; elles ne sauvegardent pas le contenu des fichiers. Poussez les commits relus vers un dépôt distant approuvé, puis vérifiez que la branche et le commit y figurent. Notez son URL dans l’inventaire, sans y intégrer de secret. Pour les commits impossibles à pousser, effectuez la sauvegarde par bundle et son test de restauration avant le transfert. N’ajoutez pas des secrets ou des paramètres privés à Git simplement pour obtenir un état propre.

Inspectez .conductor/settings.toml, .conductor/settings.local.toml et .context lorsqu’ils existent. Conductor décrit ces emplacements dans sa documentation sur les scripts du projet, la configuration locale et les notes de transmission non commitées.

Notez les commandes de préparation, les versions requises des environnements d’exécution, les services externes et les noms des variables d’environnement. Restaurez les secrets depuis votre coffre de credentials approuvé, pas depuis un ticket de migration ou un prompt d’agent.

Avant de transférer un espace, créez une copie indépendante des fichiers nécessaires au travail en cours. Une méthode documentée est Sync to a local directory, qui maintient une copie de l’espace Cloud dans un dossier local. Une fois les fichiers présents, copiez-les vers un stockage de sauvegarde distinct et approuvé.

Conservez les chemins relatifs et joignez l’inventaire à la sauvegarde. Incluez les fichiers modifiés et non suivis nécessaires. Vérifiez séparément les fichiers ignorés dont vous avez besoin. Stockez les paramètres sensibles uniquement dans des emplacements autorisés pour ces données.

Ouvrez les fichiers copiés et comparez leur contenu avec la source encore accessible. Rapprochez la liste des fichiers de votre inventaire, notamment des suppressions et renommages enregistrés. Ne modifiez pas le dossier synchronisé et ne le considérez pas comme votre seule sauvegarde.

Si un petit fichier texte manque, enregistrez tout son contenu source dans un fichier local au même chemin relatif. Rouvrez cette copie et comparez-la. Si un fichier nécessaire n’a toujours pas de copie locale vérifiée, arrêtez le transfert de l’espace. Cela inclut les fichiers binaires omis par la synchronisation, comme repository.bundle. Contactez Conductor via les coordonnées de son annonce pendant que l’espace Cloud reste accessible.

Gardez les modifications suspendues jusqu’à la vérification des sauvegardes. Sinon, actualisez le relevé d’état et les copies après la dernière modification. Terminez et vérifiez les opérations de copie nécessitant le terminal avant le 13 novembre.

Sauvegarder les commits impossibles à pousser

Sauvegardez localement l’historique Git avant de transférer une branche contenant des commits que vous ne pouvez pas pousser. La commande bundle de Git peut regrouper les références du dépôt et leur historique de commits pour une restauration hors connexion. Conservez aussi les copies séparées des fichiers en cours.

Suspendez les nouveaux commits et les mises à jour de branches pendant cette capture. Exécutez cet exemple Bash à la racine du dépôt Cloud. Le dossier conductor-history-backup ne doit pas déjà exister :

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

Vérifiez que branches.txt contient chaque branche nécessaire et l’identifiant complet du commit indiqué dans votre inventaire. Copiez tout le dossier vers le stockage local approuvé avec la méthode précédente. Conservez cette copie hors du dossier synchronisé et vérifiez que repository.bundle lui-même est arrivé sur le Mac. Gardez pre-transfer-status.txt, l’inventaire et les fichiers sauvegardés avec cette copie.

Avant de transférer l’espace, testez la restauration depuis cette copie locale. Ouvrez Bash dans le dossier conductor-history-backup copié. Choisissez une destination restored.git qui n’existe pas encore :

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

Le clonage miroir restaure les références dans un dépôt nu distinct, sans copie de travail contenant les fichiers du projet. La comparaison des listes de branches ne doit montrer aucune différence. git fsck ne doit signaler aucun objet Git manquant ou corrompu.

Confirmez les noms de branches et les identifiants de commits attendus dans restored-branches.txt avant le transfert. Arrêtez-vous si une commande échoue ou si une branche nécessaire manque. Résolvez le problème de sauvegarde tant que le dépôt Cloud reste accessible.

Protégez le bundle, les listes de branches et les copies des fichiers en cours comme des données privées du dépôt. Répétez cette procédure pour chaque dépôt contenant du travail non poussé. Actualisez la sauvegarde après tout nouveau commit.

Transférer un espace, le vérifier, puis recommencer

Par précaution, terminez et vérifiez chaque transfert avant le 13 novembre. Sur le Mac, faites un clic droit sur un espace Cloud et choisissez Transfer to local. Les notes de version 0.93.0 décrivent le déplacement de l’espace et de ses conversations vers le Mac.

Une fois le transfert terminé, ouvrez l’espace local et relancez les commandes du relevé initial. Comparez la branche, le commit, les modifications en cours et le contenu avec l’inventaire et les copies vérifiées avant le déplacement. Ouvrez une ancienne conversation et la plus récente.

Vérifiez séparément les fichiers non suivis et la configuration du projet. La présence du dépôt ne prouve pas que tous les fichiers et toutes les dépendances de l’environnement ont été conservés.

Restaurez les dépendances selon la procédure documentée du projet. Exécutez ensuite le plus petit test ou contrôle de compilation utile. Examinez les écarts à partir de l’historique vérifié du dépôt distant ou du bundle, ainsi que des copies indépendantes. N’utilisez l’espace Cloud d’origine comme comparaison supplémentaire que s’il reste accessible.

Répétez l’opération pour tous les espaces utiles, y compris les expériences inachevées et les anciens travaux contenant des décisions importantes. Désignez une personne responsable de chaque vérification. Ne supposez pas qu’un collègue a déjà exporté le travail partagé.

Télécharger et inspecter l’archive du compte

Créez l’archive du compte même si les espaces sont déjà visibles en local. Ouvrez Settings → Account → Export data, puis enregistrez le téléchargement hors des répertoires de travail de Conductor. Terminez et vérifiez cet export avant le 20 novembre.

Conservez une autre copie dans le stockage de sauvegarde approuvé par l’équipe. Ouvrez l’export localement avec un outil adapté et vérifiez quelques enregistrements de projets et conversations représentatifs. Notez la date d’export et les éléments manquants.

Traitez cette archive comme une sauvegarde à inspecter, pas comme un format d’import garanti pour un autre outil de développement. Reconstruisez un environnement utilisable à partir du code vérifié, des fichiers sauvegardés séparément, des paramètres, des dépendances et des credentials.

Si Transfer to local est absent ou échoue, choisissez la méthode de récupération adaptée dans la section suivante. Utilisez le dépôt distant approuvé si vous y avez poussé les commits, ou le miroir vérifié si vous avez créé un bundle. Récupérez les éléments manquants depuis l’espace de travail Cloud d’origine uniquement si cet espace reste accessible. Exportez aussi le compte, sans y voir la preuve que le code en cours peut être restauré.

Notez la version de l’application, l’espace concerné et le message d’erreur exact. Utilisez le contact d’assistance indiqué dans l’annonce de Conductor avant l’échéance. N’envoyez ni credentials ni contenu confidentiel des conversations.

Pendant la période annoncée de lecture seule, les anciens échanges et les exports restent disponibles. Ne faites pas dépendre la récupération d’un nouveau message, d’un transfert ou d’un terminal Cloud encore utilisable après le 13 novembre.

Restaurer une copie de travail depuis la sauvegarde

Récupérez l’historique depuis le dépôt distant approuvé si vous l’y avez poussé, ou depuis restored.git si vous avez créé un bundle. Choisissez une seule méthode. Suivez ensuite les mêmes étapes pour restaurer les fichiers et reproduire les suppressions enregistrées.

Pour les commits poussés, ouvrez Bash dans un répertoire local de récupération approuvé. Saisissez l’URL du dépôt distant sans secret intégré. Utilisez le nom de branche sans refs/heads/ et l’identifiant complet du commit figurant dans l’inventaire. Utilisez votre authentification Git habituelle et un dossier recovered-worktree qui n’existe pas :

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

L’étape fetch récupère l’historique distant. git switch --create crée la branche locale voulue au commit enregistré, pas au dernier commit de la branche distante. Arrêtez-vous si l’authentification échoue, si le commit manque ou si une comparaison échoue. Retrouvez le commit manquant dans un bundle vérifié ou un espace Cloud accessible ; ne le remplacez pas par un autre.

Pour une sauvegarde par bundle, ouvrez Bash dans votre répertoire local conductor-history-backup. Saisissez le nom de branche sans refs/heads/ et l’identifiant complet du commit de l’inventaire. Utilisez un dossier recovered-worktree qui n’existe pas :

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branch sélectionne la branche de la copie de travail. git branch --show-current vérifie son nom, et git rev-parse --verify HEAD vérifie son commit. L’état final ne s’affiche qu’après la réussite des deux comparaisons. Arrêtez-vous en cas d’erreur ou d’écart.

Après la réussite de l’une des méthodes, travaillez dans la nouvelle copie recovered-worktree. Copiez les fichiers modifiés, ajoutés et non suivis sauvegardés vers leurs chemins relatifs d’origine. Restaurez séparément les fichiers ignorés nécessaires. Laissez les sauvegardes originales intactes.

Utilisez pre-transfer-status.txt et le relevé des chemins absents de l’état final pour reproduire les suppressions et les renommages. Supprimez uniquement les chemins notés comme supprimés, après avoir confirmé leur absence dans l’état final sauvegardé. Effectuez ces suppressions seulement dans la copie de récupération. Pour un renommage, restaurez le fichier au nouveau chemin. Supprimez l’ancien chemin uniquement s’il n’existait plus dans cet état final.

Relancez les commandes du relevé initial à la racine de la copie restaurée. Rapprochez chaque chemin modifié de l’état sauvegardé et comparez les contenus avec les copies indépendantes. Cette procédure restaure le contenu de l’arbre de travail, pas l’état initial de l’index Git. Examinez les différences avant d’indexer les modifications ou de relancer l’agent. Ne poussez pas de commits vers le miroir de sauvegarde.

Utiliser Conductor en local comme solution temporaire

Gardez Conductor en local pour poursuivre le travail pendant que vous supprimez les dépendances à son interface d’espaces de travail. L’annonce promet de nouveaux modèles et des corrections de bugs critiques jusqu’au début 2027, puis un arrêt progressif. Cela ne repousse pas l’échéance Cloud du 20 novembre.

Vérifiez l’environnement d’exécution après le transfert. La documentation des espaces Cloud décrit un environnement Linux isolé auquel se connecte votre Mac. Une compilation réussie dans l’environnement Cloud ne prouve donc pas que les mêmes dépendances et commandes fonctionneront en local.

L’exécution locale ne signifie pas non plus que l’inférence du modèle se fait hors connexion. La documentation de confidentialité de Conductor indique que les requêtes aux modèles des espaces locaux vont au fournisseur configuré.

Tenez compte de la durée de vie différente des processus. Selon la FAQ Cloud, les sessions locales se terminent lorsque vous fermez Conductor ou éteignez le Mac. Un espace transféré ne remplace donc pas un processus qui continue à s’exécuter dans l’environnement Cloud.

Profitez de cette transition pour rendre le dépôt utilisable sans Conductor. Conservez les instructions de préparation, les commandes de test et les notes de transmission dans des fichiers du projet relus. Vérifiez les quotas du fournisseur ou la facture API séparément de la gratuité des fonctions Pro de Conductor.

Reprendre le travail en parallèle avec Claude Code, Codex ou OpenCode

Commencez par l’agent de développement que vous utilisez déjà, puis séparez les tâches avec des arbres de travail Git distincts. Un worktree est une autre copie de travail du même dépôt, généralement sur une branche différente.

Cette méthode convient aux développeurs qui peuvent exécuter leurs projets localement et relire les modifications avec Git. Elle recrée des répertoires de travail distincts, pas le service Cloud partagé de Conductor ni l’ensemble de son interface.

Choisir l’agent et vérifier l’authentification

Installez le CLI choisi hors de Conductor avant de transférer une tâche. Configurez l’authentification et vérifiez votre accès depuis cet outil. L’exemple avec deux agents différents nécessite Claude Code et Codex installés, avec un accès configuré et vérifié dans chacun. Pour une migration vers un seul agent, lancez le même CLI dans les deux arbres de travail.

Utilisez Claude Code pour conserver votre manière de travailler avec cet outil. Lancez claude dans le répertoire du projet et suivez les instructions d’authentification du premier démarrage.

Utilisez Codex CLI pour conserver votre environnement Codex. Lancez codex dans le répertoire du projet. Au premier démarrage, choisissez la connexion à ChatGPT ou une autre méthode disponible.

Utilisez OpenCode si vous configurez déjà vos fournisseurs avec cet outil ou souhaitez pouvoir choisir votre fournisseur. Lancez opencode, puis utilisez /connect et /models selon les instructions de configuration des fournisseurs.

Ne supposez pas que des credentials configurés uniquement dans Conductor seront accessibles au CLI indépendant. Vérifiez le compte actif, le fournisseur et le modèle avant d’autoriser une tâche réelle.

Pour un accès API distinct facturé à l’usage, BetterToken publie des guides propres à Claude Code et à Codex. Séparez la configuration de l’accès aux modèles de la récupération des espaces. Avant de transférer une tâche de production, utilisez la liste de vérifications du premier appel aux API de Claude Code et Codex.

Créer deux arbres de travail et vérifier toute la procédure

Partez de la racine de votre dépôt local vérifié, avec un commit connu comme point de départ. Cet exemple Bash crée deux branches depuis le HEAD actuel :

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

La référence Git sur worktree décrit la création de branches avec -b et l’affichage des arbres de travail avec list. Vérifiez que la sortie contient les deux nouveaux répertoires et leurs branches respectives.

Ce sont de nouvelles copies de l’état enregistré dans le commit. Elles ne copient ni les fichiers non commités ni l’état des conversations Conductor. Préservez le travail en cours à récupérer avant d’utiliser cet exemple.

Choisissez des noms de branches et de répertoires encore inutilisés. Si la création échoue, vérifiez les branches et arbres déjà créés avant de décider de relancer une étape. N’ajoutez pas --force simplement pour contourner l’erreur.

Les deux commandes de lancement suivantes supposent que Claude Code et Codex sont installés. Vous devez aussi avoir configuré l’authentification et vérifié votre accès dans chacun des deux outils. Ouvrez deux onglets de terminal, chacun à la racine du dépôt d’origine. Dans le premier, démarrez Claude Code :

(cd ../migration-docs && claude)

Dans le second, démarrez Codex :

(cd ../migration-tests && codex)

Avec un seul agent, utilisez la même commande installée dans les deux répertoires : claude, codex ou opencode. Évitez de lancer deux agents qui modifient les fichiers dans le même répertoire de travail.

Commencez chaque session avec ce prompt de vérification :

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

Le résultat attendu est constitué de deux rapports associés à des répertoires et branches différents. Chaque rapport doit citer les vrais fichiers du dépôt, sans inventer une commande de test générique. Gardez les contrôles d’approbation habituels activés : un prompt n’est pas une barrière de sécurité.

Lorsque ces vérifications réussissent, autorisez la préparation nécessaire et lancez un petit test existant dans chaque arbre de travail. Attribuez ensuite des tâches indépendantes, par exemple une correction de documentation et une amélioration distincte de test. Relisez chaque diff avant de créer un commit ou de fusionner les modifications.

À partir des conversations exportées, rédigez une courte note de transmission pour chaque tâche : objectif, contraintes, modifications terminées, travail restant et dernier résultat de test. Vérifiez les instructions et les hooks importés avant de les réutiliser. Le guide d’audit de la configuration des agents fournit une liste utile.

Ne confondez pas une nouvelle session CLI avec une restauration de l’historique de conversation. La documentation d’import d’OpenAI cite Claude Code et Cursor comme sources d’import pour Codex CLI. Elle ne confirme pas l’import direct d’une archive de compte Conductor.

Des arbres de travail distincts ne fournissent pas non plus des bases de données, comptes de service ou ports de développement distincts. Répartissez ces ressources avant de lancer des compilations en parallèle. Conductor distingue lui-même l’isolation des espaces de travail d’une barrière de sécurité.

Suivez le quota du fournisseur ou les frais API pour chaque session active. Par exemple, la documentation d’authentification d’OpenAI distingue la facturation par clé API des crédits inclus dans un abonnement ChatGPT. Ouvrir un onglet de terminal supplémentaire n’augmente pas le quota d’utilisation de l’abonnement.

Ne marquez la migration comme terminée qu’après avoir ouvert l’archive, retrouvé les fichiers et commits nécessaires, et validé une tâche locale. Gardez les espaces non résolus dans la liste de migration. Leur responsable doit les vérifier ou noter explicitement ce qui n’a pas pu être récupéré.