Les équipes d'ingénierie qui utilisent Conductor Cloud devraient conserver un dossier lisible des travaux d'agents inachevés avant de migrer leurs espaces de travail. L'annonce de Conductor du 4 novembre indique que Cloud passera en lecture seule le 13 novembre et fermera le 20 novembre, date à laquelle commencera la suppression des données utilisateur de Cloud. La tâche de gouvernance immédiate consiste à s'assurer qu'un autre ingénieur peut expliquer et poursuivre chaque modification active une fois l'espace de travail hébergé disparu.
La transition annoncée
Conductor indique qu'elle rejoint Meta. Son journal des modifications du 4 novembre confirme les dates concernant Cloud et précise que la version locale de Conductor bénéficiera de nouveaux modèles et de corrections de bogues critiques jusqu'au début de 2027. SiliconANGLE rend compte de l'acquisition de manière indépendante.
L'entreprise propose de transférer un espace de travail et ses conversations sur un Mac, ainsi que d'exporter les données du compte. Il s'agit de voies de migration annoncées, non d'une preuve que l'historique ou l'état de travail d'une équipe donnée a été transféré intégralement. Les vérifications ci-dessous sont des recommandations de Maetra à l'intention des responsables de plateforme et des responsables d'ingénierie. Elles ne décrivent pas une migration testée ni un format d'export Conductor garanti.
Attribuer une destination et un responsable
Commencez par les espaces de travail qui contiennent une modification active, une revue non résolue ou des informations nécessaires pour reconstituer une décision de mise en production. Attribuez à chacun un responsable d'ingénierie. Consignez si la destination prévue est un espace de travail local, une archive interne ou un autre environnement de développement approuvé.
Un simple téléchargement ne permet pas d'établir qui est responsable du travail. Le responsable de la reprise doit savoir quelle branche est la bonne, quelles modifications proposées sont acceptées et quelles suggestions d'agent restent sans revue. Lorsque plusieurs agents ont contribué, préservez le lien entre les espaces de travail et les modifications de dépôt concernées au lieu de traiter la dernière conversation comme l'historique complet.
Utilisez une fiche de passation concise : identifiant de l'espace de travail, dépôt, branche, commit actuel, modifications inachevées, pull request associée, responsable de la reprise et emplacement de l'archive. Marquez les champs qui ne peuvent pas être reconstitués. Un champ explicitement marqué comme inconnu donne au relecteur une raison d'enquêter ; un identifiant déduit peut créer une fausse confiance sur l'origine d'une modification.
Préserver le contexte qui explique les modifications du code
Un commit dans le dépôt peut préserver le code tout en perdant le raisonnement nécessaire à sa revue. Pour chaque modification inachevée significative, conservez la tâche confiée à l'agent, les contraintes pertinentes, la modification proposée et l'état de la revue humaine. Conservez les preuves de test déjà disponibles et distinguez-les d'une simple affirmation, dans une conversation, selon laquelle les tests ont réussi.
Ne conservez pas tout sans discernement. Les conversations et les fichiers de travail locaux peuvent contenir des éléments sensibles. Appliquez les règles d'accès et de conservation de votre organisation à l'archive, et rendez l'emplacement de cette archive visible pour les personnes qui en ont besoin. Le contrôle d'accès ne doit pas dépendre du fait qu'une personne se souvienne de l'ordinateur portable qui a reçu un téléchargement.
Évitez de copier des secrets d'accès actifs dans un document de passation. Si la destination doit accéder à un dépôt ou à un service, organisez cet accès via le mécanisme d'authentification approuvé et consignez l'identité responsable. Le dossier doit expliquer la dépendance sans exposer le secret lui-même.
Vérifier un transfert avant d'étendre la migration
Choisissez un espace de travail représentatif et utilisez la procédure de transfert ou d'export documentée par l'éditeur. Demandez ensuite à l’ingénieur qui reprend le travail d'inspecter l'état obtenu. Maetra recommande de vérifier les points suivants avant de considérer que cet espace de travail a bien été transmis :
- Le dépôt et la branche attendus sont présents, avec le commit de départ prévu.
- Les modifications non validées et les fichiers non suivis ont été pris en compte, lorsque c'est pertinent.
- L’ingénieur qui reprend le travail peut retrouver le contexte de la tâche et distinguer le travail relu des suggestions.
- Les preuves de test existantes peuvent être retrouvées, et toute réexécution est consignée comme un nouveau résultat.
- Les liens vers les pull requests, les tickets et le responsable désigné restent cohérents en dehors de l'espace de travail d'origine.
Ces vérifications évitent délibérément de présumer du contenu de l'export. Si un élément est absent, récupérez-le via une procédure disponible et prise en charge, ou consignez l'écart et décidez si la modification concernée doit faire l'objet d'une nouvelle revue. Un transfert qui s'ouvre correctement peut malgré tout laisser une part importante du travail sans explication.
Gardez l’espace de travail initial accessible pendant que le responsable de la reprise vérifie la passation. Puisque Cloud passera en lecture seule avant sa fermeture, planifiez votre date d'acceptation interne suffisamment tôt pour résoudre les problèmes. Les dates de service viennent de Conductor ; toute échéance interne antérieure relève du choix de migration de votre équipe.
Fermer délibérément l'ancien accès
Une fois la destination d'un espace de travail validée, examinez les voies d'accès associées à l'environnement retiré. Identifiez les connexions aux dépôts concernées, les identités de service et les configurations stockées localement. Décidez lesquelles restent nécessaires pour le travail en cours et lesquelles peuvent être supprimées selon vos procédures d'administration habituelles.
Ne supposez pas que l'acquisition, à elle seule, modifie les autorisations d'un client ou prouve que l'accès a pris fin. De même, le calendrier de suppression des données annoncé par une entreprise ne prouve pas que votre organisation a satisfait à ses propres exigences de conservation. Conservez une trace des décisions réellement prises par votre équipe et des vérifications qu'elle a menées à terme.
Le guide Maetra sur les preuves d'audit de l'IA aide à identifier l'historique qui mérite d'être conservé. Audit prend en charge un historique des modifications vérifiable, tandis que Discover prend en charge l'inventaire des agents et des capacités. Aucun des deux n'est un service de migration Conductor ni une promesse de récupération d'espaces de travail supprimés. Utilisez la documentation Maetra pour planifier une petite passation de preuves qui reste compréhensible après le retrait de l'outil d'origine.