# Mises à jour automatiques

Comment Oleafly construit, signe, vérifie et publie son flux de mise à jour multiplateforme.

Oleafly utilise le greffon de mise à jour de Tauri. Au lancement, l'application vérifie la dernière version GitHub et ouvre sa propre fenêtre de mise à jour quand une version plus récente est disponible. Les utilisateurs peuvent aussi lancer la vérification depuis le menu de l'application ou **À propos → Rechercher des mises à jour**.

## Flux de versions

Chaque build de plateforme crée des artefacts de mise à jour signés et un fragment `latest.json`. Le workflow de publication garde ces fragments séparés jusqu'à ce que les quatre builds soient terminés, puis fusionne les entrées propres à chaque cible en un manifeste canonique.

Le manifeste final doit contenir des entrées pour macOS Apple Silicon, Windows x64, Linux x64 et Linux ARM64. Il reste attaché à une version brouillon jusqu'à ce qu'un mainteneur exécute le workflow de publication protégé. Les applications installées ne voient pas le brouillon.

L'application télécharge `latest.json` depuis GitHub Releases. Avant l'installation, Tauri vérifie la signature de mise à jour auprès de la clé publique intégrée dans `src-tauri/tauri.conf.json`. Les artefacts manquants, non signés ou altérés sont rejetés.

Les notes de version proviennent de la section correspondante dans `CHANGELOG.md`. Le workflow extrait cette section et l'utilise à la fois pour le corps de la version GitHub et pour la fenêtre de mise à jour.

## Clés de signature

La clé publique de mise à jour est versionnée dans `src-tauri/tauri.conf.json`. La clé privée n'a sa place que dans les secrets GitHub Actions :

- `TAURI_SIGNING_PRIVATE_KEY`
- `TAURI_SIGNING_PRIVATE_KEY_PASSWORD`

Ne versionnez jamais la clé privée. Si elle est exposée, générez une nouvelle paire, mettez à jour le secret du dépôt et remplacez la clé publique intégrée. Les installations existantes font confiance à leur clé intégrée : une rotation exige donc un chemin de mise à jour manuelle planifié.

La signature du système d'exploitation est distincte de la signature de mise à jour. Les builds macOS utilisent la signature de code Apple et la notarisation quand les secrets de publication sont présents. Les builds Windows utilisent Azure Artifact Signing quand ses identifiants sont présents.

## Échec et retour arrière

Une vérification ou un téléchargement qui échoue laisse l'application installée inchangée. Un échec de signature bloque l'installation. L'application ne redémarre qu'après l'installation réussie du téléchargement vérifié.

Oleafly ne revient pas automatiquement en arrière après une mise à jour terminée. Pour revenir à une version antérieure, fermez l'application, sauvegardez les projets importants, téléchargez l'installateur officiel antérieur, vérifiez-le, puis installez-le par-dessus la version actuelle.

Voir [Publication d'Oleafly](/docs/engineering/releasing/) pour le processus de brouillon et de publication.