# Revenir en arrière, redéployer ou annuler

Une mise en production s’est mal passée ? Ce guide remet en ligne une version précédente, relance un build, ou annule un déploiement en cours. Aucune de ces actions ne demande de nouveau commit.

**Résultat attendu** : ton domaine de production sert la version choisie, ou le déploiement en cours s’arrête.

**Avant de commencer** : une version précédente **Prête**. Un déploiement en erreur ne peut pas redevenir la production.

## Revenir à une version précédente

1. **Ouvre la liste des déploiements**

   Dans le projet, ouvre l’onglet **Déploiements**. Chaque ligne montre l’état, la cible et le commit, quand il est connu.

2. **Choisis la version à remettre en ligne**

   Ouvre un déploiement de production précédent, qui est **Prêt**, puis clique **Revenir en arrière**.

   Le retour est immédiat : aucun build ne tourne.

3. **Vérifie le site**

   **Vérification** : tes domaines de production répondent avec la version choisie. L’onglet **Vue d’ensemble** l’affiche comme production.

Les 10 productions prêtes qui ont précédé la production en ligne restent disponibles, quel que soit leur âge. Une production plus ancienne peut avoir été effacée : voir [Durée de conservation](/host/docs/concepts/deploiements/).

Le déploiement remis en ligne garde les variables qu’il a reçues à son build. Une variable modifiée depuis ne s’y applique pas. Pour appliquer une variable à la version remise en ligne, reconstruis-la : la section **Redéployer** plus bas explique comment.

## Mettre une preview en production

Depuis la page d’une preview prête, clique **Mettre en production**. Cette preview sert alors tes domaines de production, avec les variables de preview qu’elle a reçues. La console te le rappelle avant de confirmer.

Utilise cette action pour valider une version sur son adresse de preview, puis la passer en production sans la reconstruire.

## Redéployer

Redéployer reconstruit une version avec les variables d’aujourd’hui :

- **Projet relié à GitHub** : reconstruit le même commit dans GitHub Actions, avec les variables actuelles. Le bouton **Redéployer la production** le fait pour la production.
- **Projet envoyé par la CLI** : republie les fichiers du déploiement choisi, sans rien reconstruire. Pour une nouvelle version, relance `vercel deploy`.

### Redéployer sans cache

Pour un projet construit par Host, un admin peut reconstruire sans aucun cache. Utilise-le quand un build se comporte de façon étrange, ou après le retrait d’une dépendance douteuse.

1. Ouvre la page du déploiement.
2. Clique le bouton **…** à droite des actions.
3. Choisis **Redéployer sans cache**.

Host réinstalle les dépendances et refait les caches du framework. Le build prend donc plus de temps que d’habitude.

## Annuler un déploiement

Un déploiement **En file** ou **En cours de build** peut être annulé, avec **Annuler**. Un déploiement **Prêt** ne s’annule pas : reviens en arrière à la place.

**Vérification** : le déploiement passe à **Annulé**, et la production n’a pas changé.

## Si ça ne marche pas

- **Revenir en arrière** est absent : le déploiement n’est pas **Prêt**, ou il n’est pas de production.
- Une nouvelle production est **Prête** mais pas en ligne : elle n’a pas passé le contrôle avant la mise en production. La raison est sur la page du déploiement : voir [Déploiements](/host/docs/concepts/deploiements/).
- Le site répond encore avec l’ancienne version : le cache de ton navigateur ou de ton réseau peut retenir la page. Recharge la page sans cache, puis patiente quelques minutes.
- Pour comprendre le cycle de vie d’un déploiement, lis [Déploiements](/host/docs/concepts/deploiements/).