Interruption d’une longue tâche Muse Code : guide 2026

Une restauration fiable ne commence pas par la relance de l’agent. Elle commence par la preuve. Les notes officielles de Git recommandent le format porcelain pour obtenir un état exploitable par des scripts, tandis que les espaces de travail séparés permettent d’isoler une nouvelle tentative sans écraser la première. (git-scm.com)

Notre verdict : adapté si vous traitez une interruption comme un incident à qualifier ; inadapté si vous redémarrez immédiatement la même consigne sur le même répertoire, car vous risquez de répéter une écriture, un envoi ou une modification déjà effectuée.

Cet article s’adresse aux développeurs qui testent Muse Code sur de grands dépôts, aux ingénieurs de plateforme qui administrent des sessions distantes et aux responsables techniques qui doivent valider les changements produits par un agent.

Dernière mise à jour : 12 août 2026. Les informations sur le fonctionnement de récupération de Muse Code sont confrontées aux éléments officiels disponibles et doivent être revalidées après chaque changement de version. Les commandes Git citées sont vérifiées dans la documentation officielle de Git.

Le faux échec après une reprise

Le cas le plus coûteux n’est pas toujours le plantage complet. C’est la reprise qui semble réussir, mais qui rejoue une opération déjà terminée.

Dans un scénario typique, Muse Code modifie plusieurs fichiers, prépare un commit, appelle un outil externe, puis la connexion terminal se coupe. Après reconnexion, l’agent ne sait pas clairement si l’appel distant a abouti. Il relance donc la commande. Le résultat peut être un doublon de message, une seconde demande auprès d’une API, une nouvelle branche ou une migration exécutée deux fois.

Nous avons alors trois états différents :

• le processus local a disparu, mais les fichiers sont présents ;
• le processus est vivant, mais la requête modèle a échoué ;
• le modèle a répondu, mais l’outil appelé n’a pas confirmé son résultat.

Ces états ne se traitent pas de la même manière. Un terminal fermé n’implique pas que le travail soit perdu. À l’inverse, la présence de fichiers modifiés ne prouve pas que le dernier outil a terminé correctement.

La règle opérationnelle est donc simple : ne relancez pas la consigne cible avant d’avoir identifié le dernier événement confirmé et vérifié les effets secondaires associés.

Les symptômes séparés par cause

Session interrompue, fichiers conservés

Une coupure SSH, une fermeture du terminal ou un redémarrage de l’interface peut laisser le répertoire dans un état exploitable. Dans ce cas, l’objectif n’est pas de « reprendre à l’aveugle », mais de comparer le dernier événement enregistré avec les fichiers présents.

Commencez par capturer l’état Git sans le modifier :

git status --porcelain=v2 --branch
git diff --stat
git diff --name-status

Le format porcelain est conçu pour rester stable malgré la configuration utilisateur et pour être interprété par des scripts. La version deux ajoute notamment des informations sur la branche et l’état du dépôt. (git-scm.com)

Un résultat comme celui-ci n’est pas une preuve de réussite complète :

# branch.oid 8f21c7a
# branch.head feature/muse-recovery
1 .M N... 100644 100644 100644 4b11... 7a22... src/worker.ts
? logs/recovery-note.txt

Il indique seulement que le répertoire contient une modification et un fichier non suivi. Il faut encore savoir si ces changements correspondent à l’action annoncée par Muse Code.

Requête modèle échouée, outil déjà exécuté

Une réponse absente ne signifie pas nécessairement que l’action précédente n’a pas été exécutée. La requête peut avoir atteint le service, l’outil peut avoir écrit sur disque, puis le canal de réponse peut avoir expiré.

La vérification doit porter sur trois éléments :

• l’identifiant de l’appel ou de la tâche ;
• la réponse enregistrée par l’outil ;
• l’état observable du système cible.

Pour un commit, contrôlez l’historique et le pointeur courant :

git log -5 --oneline --decorate
git status --short
git show --stat --summary HEAD

Pour un message ou une API distante, recherchez un identifiant d’idempotence, une trace serveur ou un accusé de réception. Si le système externe ne fournit aucun identifiant stable, considérez l’action comme ambiguë. Une action ambiguë ne doit pas être répétée automatiquement lorsqu’elle est irréversible ou coûteuse.

C’est aussi la réponse à la question : pourquoi Muse Code répète-t-il parfois un outil ? Parce que l’agent peut distinguer l’intention de l’outil et la confirmation de son résultat, mais pas toujours prouver qu’un effet externe a été appliqué lorsque le retour est perdu. L’événement journalisé n’est donc pas équivalent à une transaction validée.

Les journaux contre l’état du dépôt

Journal cohérent, reprise possible

La reprise est raisonnable lorsque les trois correspondances suivantes sont établies :

• le dernier événement indique une écriture ou une commande précise ;
• le diff local contient exactement cette modification ;
• aucun outil externe ne reste dans un état indéterminé.

Dans ce cas, demandez à Muse Code de reprendre depuis un point explicite, et non depuis la consigne originale. Une formulation utile décrit ce qui est déjà fait, ce qui ne l’est pas et ce qui doit être vérifié :

Le dernier événement confirmé est : modification de src/worker.ts,
tests non exécutés, aucun envoi externe confirmé.
Ne réécrivez pas les fichiers déjà modifiés.
Vérifiez le diff, exécutez uniquement les tests ciblés,
puis proposez les actions externes sans les exécuter.

Cette méthode réduit le risque de répétition, mais elle ne transforme pas le journal en mécanisme transactionnel. La précision de la restauration dépend toujours de la version utilisée, du type d’outil et de la conservation effective des événements.

Journal divergent, reprise interdite

La situation devient dangereuse lorsque le journal décrit un fichier, mais que le diff montre autre chose. Plusieurs causes sont possibles :

• une modification manuelle après l’arrêt ;
• un autre agent travaillant dans le même répertoire ;
• un script lancé en parallèle ;
• un fichier temporaire renommé ou supprimé ;
• une restauration partielle suivie d’une nouvelle écriture.

Dans ce cas, ne demandez pas à l’agent de « remettre le dépôt en ordre » directement. Conservez d’abord les preuves :

mkdir -p incident-muse
git status --porcelain=v2 --branch > incident-muse/status.txt
git diff --no-ext-diff --binary > incident-muse/worktree.patch
git diff --cached --no-ext-diff --binary > incident-muse/index.patch
find . -maxdepth 3 -type f -name '*log*' -print > incident-muse/log-files.txt

L’option --binary permet à git diff de produire un diff binaire applicable avec git-apply, ce qui est préférable lorsqu’un dépôt contient des ressources non textuelles. (git-scm.com)

Muse Code récupéré après interruption : que faire lorsque le code ne correspond plus à l’état attendu ? Traitez le dépôt comme une scène d’incident. Figez l’état, identifiez les acteurs ayant pu écrire, puis créez un nouvel espace de travail depuis un commit connu. Une réparation directe dans le répertoire ambigu détruit souvent la chronologie dont l’équipe a besoin.

Les sous-agents et les résultats périmés

Un sous-agent en arrière-plan peut terminer après la reconnexion du processus principal. Son résultat peut également avoir été calculé sur une base devenue obsolète.

Avant d’intégrer sa sortie, vérifiez :

• l’identifiant exact de la tâche ;
• le commit ou l’empreinte de fichiers utilisés comme base ;
• l’heure de création et l’heure de retour ;
• les tests exécutés ;
• les fichiers effectivement modifiés.

Un rapport disant « tests réussis » ne suffit pas si la branche a changé depuis son lancement. Les tests doivent être associés à une base identifiable. Pour une modification critique, relancez au minimum les tests déterminants dans l’espace de travail courant.

Un résultat ancien ne doit pas être fusionné automatiquement. Il peut encore servir de piste, de diagnostic ou de proposition de correctif, mais il faut le recalculer contre la version actuelle du dépôt.

Les points de contrôle avant une longue tâche

Checkpoint de code

Avant de lancer une tâche de grande ampleur, créez une référence simple :

git switch -c muse/point-de-depart
git add -A
git commit -m "checkpoint avant tâche Muse Code"
git tag -a muse-before-task -m "État avant exécution Muse Code"

Si le dépôt ne doit pas recevoir un commit de travail, utilisez au minimum une branche dédiée ou un espace de travail temporaire. Le but n’est pas de donner une illusion de sécurité : c’est de disposer d’un point de comparaison stable.

Checkpoint de contexte

Le journal doit enregistrer au moins :

• la consigne initiale ;
• le commit de départ ;
• les outils autorisés ;
• les commandes déjà exécutées ;
• les validations attendues ;
• les opérations nécessitant une confirmation humaine.

Évitez les notes vagues comme « étape terminée ». Préférez une entrée vérifiable :

[CONFIRMÉ]
Base : 8f21c7a
Action : écriture de src/worker.ts
Résultat : fichier présent, diff contrôlé
Tests : non exécutés
Effet externe : aucun accusé reçu
Reprise autorisée : inspection et tests seulement

Checkpoint d’environnement

Pour une session distante, conservez aussi la version de l’agent, la version du modèle, le nom de la machine, le chemin du dépôt et la méthode de connexion. Le modèle Muse Spark a été présenté par Meta comme un modèle multimodal avec prise en charge de l’utilisation d’outils et de l’orchestration multi-agents ; cela ne dispense pas d’identifier précisément le harnais et la version qui exécutent réellement la tâche. (about.fb.com)

Le terme Muse Spark 1.2 doit donc être documenté comme une combinaison modèle plus environnement d’exécution. Une différence de résultat peut venir du modèle, du terminal, des permissions ou du gestionnaire de session.

La procédure de récupération en cinq étapes

Première étape : geler l’action

Arrêtez les relances automatiques. N’effacez pas les journaux. Ne lancez pas de nettoyage global. Si un outil externe peut encore être actif, vérifiez son statut dans son propre système.

Deuxième étape : capturer les preuves

Archivez le journal d’événements, la sortie du terminal, les erreurs, le diff Git et la liste des processus. Ajoutez l’heure exacte de l’incident et le type de coupure : déconnexion, arrêt du processus, expiration de requête ou redémarrage de machine.

Troisième étape : identifier le dernier événement sûr

Classez chaque événement dans une des catégories suivantes :

• annoncé seulement ;
• outil appelé ;
• résultat retourné ;
• effet externe confirmé ;
• effet externe inconnu.

Seul le dernier niveau confirmé peut servir de base automatique à une reprise.

Quatrième étape : comparer le dépôt

Utilisez git status, git diff, l’historique et les fichiers temporaires. Si le dépôt contient des modifications non expliquées, ne les écrasez pas.

Cinquième étape : choisir l’issue

Continuez uniquement si la base et les effets externes sont cohérents. Revenez en arrière si une modification locale est clairement erronée et reproductible. Terminez l’incident si une action irréversible est ambiguë. Reconstruisez dans un nouvel espace de travail si la chronologie ne peut plus être prouvée.

Les quatre décisions possibles

Situation observée	Action recommandée	Niveau de contrôle
Journal, diff et outil externe concordants	Continuer depuis le prochain point explicite	Automatique limité
Code modifié mais effet externe inconnu	Suspendre l’outil et demander une confirmation	Humain obligatoire
Diff local incohérent avec le journal	Figer les preuves puis reconstruire	Aucun écrasement
Base de sous-agent périmée	Revalider contre le commit courant	Tests obligatoires

Cette grille répond à la question : comment récupérer Muse Code après un plantage ? Il n’existe pas une seule commande de réparation. La bonne procédure dépend de l’endroit où la preuve s’arrête.

Les coûts cachés d’une reprise aveugle

Une relance immédiate présente plusieurs coûts souvent sous-estimés.

Le premier est le coût logique. Une modification déjà appliquée peut être réécrite avec une nouvelle hypothèse, ce qui produit un diff plus large et rend la revue difficile.

Le deuxième est le coût externe. Une commande peut créer une ressource, publier un message, déclencher une construction ou modifier une base de données. Même si le code final paraît correct, l’environnement peut contenir des doublons.

Le troisième est le coût de permission. Après reconnexion, le processus peut s’exécuter avec un autre utilisateur, une autre clé SSH ou un autre répertoire courant. Une tâche partiellement réussie peut alors échouer à l’étape suivante pour une raison qui ressemble à un problème de modèle.

Le quatrième est le coût de preuve. Supprimer les fichiers temporaires et relancer l’agent peut faire disparaître la seule trace permettant de distinguer une coupure réseau d’une erreur d’outil.

Pour les environnements audio, vidéo ou design, ce point est encore plus sensible : les fichiers générés peuvent être volumineux, non suivis par Git ou liés à des logiciels externes. Il faut donc conserver les manifestes, les chemins de sortie et les horodatages avant toute nouvelle génération.

L’isolement par espace de travail

Lorsque la cohérence ne peut pas être démontrée, créez une copie de travail séparée :

git worktree add --detach ../muse-rebuild HEAD
cd ../muse-rebuild
git status --porcelain=v2 --branch

Git associe chaque espace de travail à des métadonnées distinctes, notamment pour HEAD et l’index. Cette séparation permet de reconstruire une tâche sans modifier le répertoire contenant les preuves de l’incident. (git-scm.com)

N’utilisez pas --force pour contourner une protection sans comprendre pourquoi Git refuse l’opération. Une protection de branche ou d’espace de travail peut précisément signaler qu’un autre processus utilise déjà la même base.

Méthode	Avantage	Risque principal	Décision
Reprendre dans le même répertoire	Rapide	Écrasement ou répétition	Seulement si l’état est prouvé
Restaurer depuis un tag	Base claire	Perte des changements non archivés	Acceptable après capture
Créer un worktree détaché	Isolation et comparaison	Gestion de plusieurs chemins	Option préférée en cas de doute
Recommencer depuis zéro	Chronologie propre	Temps et coût de calcul	À réserver aux états indémontrables

Le format de journal recommandé

Un journal utile ne doit pas seulement raconter ce que l’agent voulait faire. Il doit permettre de vérifier ce qui s’est réellement produit.

Champ	Exemple	Utilité lors de la reprise
Identifiant de tâche	muse-2026-08-12-a	Relier agent, sous-agent et outils
Base Git	8f21c7a	Vérifier la version de départ
Action	Écriture de src/worker.ts	Comparer avec le diff
Résultat outil	Retour reçu ou absent	Mesurer l’incertitude
Effet externe	Confirmé, refusé ou inconnu	Éviter les doublons
Décision	Continuer, revenir, arrêter, reconstruire	Formaliser le seuil d’action

Ne présentez pas ce journal comme un système de transaction. Il s’agit d’une trace d’exécution. Sa valeur dépend de sa complétude, de l’ordre des écritures et de la capacité des outils à retourner un identifiant stable.

Les seuils de sortie de crise

Une équipe gagne du temps lorsqu’elle définit les seuils avant l’incident.

Continuer lorsque le dernier événement, le diff local et le résultat externe sont concordants.

Revenir en arrière lorsque la modification fautive est identifiée, sauvegardée et réversible par un commit ou un patch.

Arrêter lorsqu’une opération externe non idempotente peut avoir été exécutée, mais ne peut pas être vérifiée.

Reconstruire lorsque plusieurs agents ont écrit dans le même répertoire, lorsque le journal est incomplet ou lorsque la base du sous-agent est inconnue.

Ces seuils sont plus fiables qu’une instruction générale demandant à l’agent de « reprendre là où il s’est arrêté ». Cette formulation laisse à l’agent la responsabilité d’inférer un état qui doit être établi par des preuves.

Pourquoi un Mac distant reste préférable pour ces essais

Une station locale convient aux tâches courtes et interactives. Elle devient moins confortable lorsque la session doit rester ouverte, que plusieurs dépôts sont testés ou qu’une équipe doit reproduire exactement une interruption.

Un environnement distant mal préparé ajoute ses propres défauts : déconnexion SSH, veille, absence de conservation des journaux, répertoire partagé entre plusieurs agents et permissions différentes après redémarrage. Il peut aussi compliquer les essais audio, vidéo et design lorsque des logiciels macOS ou des interfaces graphiques sont nécessaires.

Pour une validation sérieuse, nous recommandons d’abord une reproduction dans un environnement isolé, puis la mise en place d’un nœud distant Mac avec journalisation, espace de travail dédié et accès contrôlé. La documentation Apple sur les notes de version de Xcode montre d’ailleurs que les assistants de code peuvent dépendre du redémarrage, de l’authentification et de l’état de l’environnement, pas uniquement du modèle utilisé. (developer.apple.com)

Option actuelle	Limites réelles	Quand la conserver
Mac local	Session difficile à partager, interruptions liées à la machine	Développement individuel court
Serveur Linux générique	Accès macOS et interfaces créatives limités	Automatisation sans dépendance macOS
Machine virtuelle	Performances et périphériques parfois irréguliers	Tests reproductibles ciblés
Mac distant loué par leapmac	Coût récurrent et dépendance réseau	Essais temporaires, équipes et longues tâches

La location n’est pas la meilleure réponse pour une charge stable et permanente, ni pour un projet qui exige un périphérique physique spécifique. En revanche, pour tester Muse Code, reproduire une coupure, comparer Muse Spark 1.2 et conserver un environnement propre sans immobiliser une machine personnelle, elle évite plusieurs compromis du Mac local : session non partageable, veille imprévisible et perte de continuité après fermeture du poste.

Pour sécuriser la première expérimentation, nous vous conseillons de commencer par une courte tâche isolée, de provoquer une coupure contrôlée, puis de vérifier que les journaux, le diff et la récupération correspondent à vos attentes avant de déplacer un dépôt de production. C’est à ce moment qu’un Mac distant fourni par leapmac devient pertinent : non pas comme remplacement universel d’un poste de développement, mais comme environnement temporaire et contrôlable pour les longues tâches, les tests d’agents et les workflows créatifs nécessitant macOS.