# Annuler et réinitialiser Chaque modification d'une configuration est un changement que vous pourriez vouloir reprendre, et la personne qui le fait n'a peut-être ni git, ni dépôt distant, ni aucune raison d'apprendre l'un ou l'autre. Le moteur tient donc l'historique lui-même. ## Le répertoire d'historique Sous `--watch`, chaque configuration que Sovrium **accepte et sert** est copiée entière dans le répertoire de données : ```text .sovrium/history/ 2026-09-22T21-18-51-411Z-9d950eca6a36/ app.yaml 2026-09-22T21-18-57-301Z-942914531bb5/ app.yaml config/pages.yaml ``` Chaque répertoire est une configuration acceptée, nommée d'après l'instant de son acceptation et l'empreinte de configuration que consigne le fichier de verrou. Un instantané contient le **graphe entier**, la configuration racine et chaque partiel `$ref`, aux chemins relatifs qu'ils occupent dans votre projet : le restaurer est donc une copie de répertoire et non une fusion, et une restauration qui doit fusionner est une restauration qui peut échouer à moitié. Trois règles décident de ce qui atterrit là, et chacune est la fonctionnalité même : - **Le démarrage compte.** Un instantané est écrit au lancement du surveillant, et pas seulement à la première modification. Sans lui, l'historique après un changement ne contient qu'une entrée, l'état que vous cherchez justement à quitter, et l'annulation n'a nulle part où aller. - **Seulement les configurations qui ont servi.** Une sauvegarde refusée n'écrit rien. C'est la liste des configurations qui ont tourné, non de celles qui ont été tentées, et une entrée qui n'a jamais démarré est une cible d'annulation qui casse l'application. - **Vingt sont conservées**, les plus anciennes écartées d'abord. `--watch` prend un instantané à chaque sauvegarde acceptée : une après-midi de travail en produit des centaines, et vingt dépasse de loin la poignée d'étapes que quiconque remonte à la main. Le surveillant est l'un des deux écrivains de cet historique. L'autre est l'outil d'écriture de configuration décrit dans [Votre configuration en MCP](/fr/docs/mcp-config), qui consigne l'état **précédant** sa propre modification : sans quoi un assistant travaillant sur un projet où rien ne tourne n'aurait aucun historique du tout, le surveillant étant la seule chose qui atteigne jamais l'état « accepté ». Il omet la copie lorsque l'entrée la plus récente contient déjà exactement ces octets, si bien qu'un projet sous surveillance obtient une entrée avant la modification et une après, plutôt que trois. À part cela, l'historique n'est écrit que sous `--watch` : un simple `sovrium start`, sans assistant attaché, ne crée aucun répertoire `history/`. ## En restaurer un Il n'existe délibérément pas de commande de restauration. Recopiez les fichiers de l'instantané par-dessus le projet : ```bash cp -R .sovrium/history/2026-09-22T21-18-51-411Z-9d950eca6a36/. . ``` Le surveillant voit les écritures et le chemin de rechargement ordinaire sert le résultat : l'annulation n'a donc besoin d'aucun code privilégié, et un shell, un script ou une personne munie d'un gestionnaire de fichiers font tous la même chose de la même façon. L'annulation de l'outil d'écriture de configuration est cette même copie : elle choisit l'instantané le plus récent dont les fichiers diffèrent de ce qui est sur le disque. Les instantanés sont opportunistes. Un historique impossible à écrire vous coûte un avertissement et rien de plus, car un démarrage qui échouerait pour cette raison serait une application perdue plutôt qu'une commodité perdue. Un `$ref` qui remonte **au-dessus** du répertoire de la configuration est sauté plutôt que copié hors du répertoire d'instantané : cela laisse cet instantané incomplet, de loin le moindre des deux problèmes. ## Dans l'application Sovrium [L'application de bureau](/fr/docs/desktop-app) lit ce même répertoire et en fait un bouton. **Revenir d'une version** remplace le fichier de configuration de votre dossier de projet par l'instantané précédent, et l'application recharge : c'est la copie que la commande ci-dessus effectue, avec l'horodatage affiché pour que vous voyiez vers quelle version vous revenez. Tant qu'un second instantané n'existe pas, il n'y a nulle part où revenir, et l'application le dit plutôt que de proposer un bouton qui ne ferait rien. **Réinitialiser au modèle** est l'autre direction, et elle ne fait pas partie de l'historique. Elle remplace votre fichier de configuration par une copie neuve du modèle dont le projet est parti, consigné au moment de l'échafaudage. Vos données, vos fichiers déposés et tout le reste du dossier ne sont pas touchés ; seul le fichier de configuration est remplacé, et chaque modification que vous ou votre assistant y avez faite est perdue. Un projet qui n'est parti d'aucun modèle n'a rien à quoi revenir, et le contrôle le dit à la place. Ni l'un ni l'autre n'atteint la console d'administration. L'historique ne contient aucune configuration candidate, chaque entrée étant une configuration qui a déjà démarré : ce n'est donc pas un registre de versions, et la console reste ce qu'elle est, une vue en lecture seule des données d'exploitation. ## Pages associées - [Cycle de vie du serveur](/fr/docs/cli-lifecycle) — `start`, `stop`, `reload`, et le fichier d'état. - [Votre configuration en MCP](/fr/docs/mcp-config) — le second écrivain de cet historique, et son annulation. - [L'application Sovrium](/fr/docs/desktop-app) — la fenêtre, et où vit un projet. - [Aperçu du CLI](/fr/docs/cli) — le mode surveillance, et les clés qui exigent un redémarrage.