# Mettre à niveau et revenir en arrière sur une application Sovrium

Les migrations de schéma sont **en avant seulement** — une migration publiée n'est jamais réécrite, et il n'y a pas de downgrade automatique. Une mise à niveau sûre s'accompagne donc toujours d'une sauvegarde restaurable.

## Mettre à niveau

Sauvegardez d'abord ([SQLite](/fr/docs/backup-restore-sqlite), ou un instantané de base sur Postgres), puis passez à la nouvelle version et redémarrez. La migration de schéma s'exécute au démarrage, dans une transaction, avant que l'app ne serve du trafic :

```bash
sqlite3 .sovrium/database.db ".backup '/backups/pre-upgrade.db'"
sovrium update            # installation du binaire ; ou : docker pull ghcr.io/sovrium/sovrium:latest
sovrium stop && sovrium start app.ts
```

Si la migration échoue, la transaction revient en arrière et le serveur refuse de démarrer sur un schéma incohérent — vous n'êtes jamais laissé à moitié migré.

## Revenir en arrière

Comme les migrations ne s'inversent pas, un rollback restaure les données d'avant la mise à niveau avec le binaire/l'image précédent :

```bash
sovrium stop
# réinstallez la version précédente (épinglez le tag / binaire d'où vous veniez)
cp /backups/pre-upgrade.db .sovrium/database.db && rm -f .sovrium/database.db-wal .sovrium/database.db-shm
sovrium start app.ts
```

Pour un **zéro interruption**, exécutez la nouvelle version comme seconde instance derrière votre proxy, vérifiez-la, puis basculez le trafic — en gardant l'ancienne instance jusqu'à ce que vous soyez confiant.

## Suite

- [Migrations de schéma](/fr/docs/migrations) — pourquoi les migrations publiées sont immuables.
- [Sauvegarder & restaurer SQLite](/fr/docs/backup-restore-sqlite) — la sauvegarde sur laquelle ce guide s'appuie.
- [Référence CLI](/fr/docs/cli) — `update`, `stop` et `start`.