> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comment Publish met à jour votre base de données de production

> Découvrez comment Replit compare, valide et applique à la production les changements de schéma de votre base de données de développement lorsque vous publiez votre application.

Lorsque vous publiez une application qui utilise une base de données gérée par Replit, Replit met automatiquement votre base de données de production à jour par rapport à votre base de données de développement. Vous n'écrivez ni n'exécutez vous-même de migrations. Pendant la publication, Replit :

1. Compare le schéma de vos bases de données de développement et de production.
2. Génère le SQL nécessaire pour que la production corresponde au développement.
3. Vous demande de résoudre tout ce qui est ambigu, comme une colonne renommée.
4. Valide le SQL sur une copie de votre base de données de production.
5. Applique le SQL à la production une fois votre application construite et avant la mise en ligne de la nouvelle version.

> [!NOTE]
>
> Cela ne s'applique qu'aux bases de données que Replit gère pour votre application. Si votre application publiée se connecte à une base de données externe comme Supabase, un projet Neon que vous avez créé vous-même ou Amazon RDS, Publish ne modifie pas cette base de données. Utilisez plutôt le flux de migration de ce fournisseur.

## Étape 1 : Replit détecte les changements

La publication commence par une étape **Provision**. Si votre schéma de développement diffère de celui de la production, le volet Publish affiche **Development database changes detected** et commence à générer les migrations.

![Volet Publish affichant Development database changes detected](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/changes-detected.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=9213aa45a2b15109f3cffc451fb7efdf)

La publication migre les tables, colonnes, index, contraintes, vues, enums, séquences et politiques de sécurité au niveau des lignes. Certains objets ne sont pas repris ; consultez [Objets de base de données non pris en charge](https://docs.replit.com/fr/help/troubleshooting/databases.md#objets-de-base-de-données-non-pris-en-charge).

## Étape 2 : Répondre aux questions sur les changements ambigus

Certains changements de schéma peuvent avoir deux significations. Lorsque Replit ne peut pas déterminer votre intention, il s'interrompt avec **Detected potential conflicts, please review** et vous demande de choisir. Choisissez une option et sélectionnez **Submit**.

### Renommage ou nouveauté ?

Si une colonne a été supprimée et une autre ajoutée sur la même table, Replit demande si l'ancienne colonne a été renommée.

* **Yes, rename column** conserve les données existantes sous le nouveau nom.
* **No, create new column** ajoute une colonne vide et supprime l'ancienne avec ses données.

![Invite demandant si une colonne supprimée doit être renommée en une colonne nouvellement ajoutée](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-column-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fe35615b66e1cc80a57b0198926d5406)

La même question apparaît pour les tables, enums, séquences, vues et schémas.

![Invite demandant si une table supprimée doit être renommée en une table nouvellement ajoutée](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/rename-table-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=f3bfb9ba5604a051e845ae3617e42270)

> [!WARNING]
>
> Choisir **create new** pour ce qui était en réalité un renommage est la façon la plus courante de perdre des données de production lors d'une publication. Si vous avez un doute, annulez la publication et demandez à Agent ce qui a changé.

### Contrainte d'unicité sur une table contenant des données

Si vous ajoutez une contrainte d'unicité à une table qui contient déjà des lignes en production, Replit vous indique combien de lignes la contrainte va vérifier.

* **Add the constraint as-is** fait échouer la migration si des lignes existantes la violent. Vous pouvez alors corriger les données et publier à nouveau.
* **Remove all rows, then add the constraint** vide d'abord la table. Cette option n'est pas proposée lorsque d'autres tables référencent celle-ci via une clé étrangère.

![Invite demandant comment ajouter une contrainte d'unicité à une table qui contient déjà des lignes](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/unique-constraint-prompt.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0a399148516559f9f2711cc335254df2)

## Étape 3 : Examiner le SQL généré

Une fois les questions résolues, le volet affiche **Generated migrations to apply to production database** avec le SQL exact que Replit va exécuter. Lisez-le avant de continuer.

![SQL de migration généré affiché dans le volet Publish](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/generated-migrations.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=d8737c76546c059cdfcf0adead1e9e29)

Deux signaux indiquent qu'une migration demande une attention particulière :

* **Avertissement de perte de données.** Lorsqu'un changement pourrait supprimer des données d'une table contenant des lignes en production, le volet devient orange et liste chaque table concernée avec son nombre de lignes. Les changements qui déclenchent cet avertissement incluent :
  * Supprimer ou recréer une colonne ou une table
  * Changer le type d'une colonne ou son caractère obligatoire
  * Ajouter une colonne obligatoire
  * Ajouter ou recréer des index et des contraintes
* **Avis d'interruption.** Lorsqu'un changement n'est pas compatible avec la version de votre application en cours d'exécution, Replit arrête l'application avant d'appliquer la migration afin que les utilisateurs ne puissent pas écrire dans la base de données en plein changement. Développez **What's happening?** pour plus de détails.

![Migration avec un avertissement orange de perte de données listant les tables concernées et un avis d'interruption](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/data-loss-warning.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=fc53902e5f2c4db51429cfc04f0e2746)

> [!NOTE]
>
> La liste d'avertissement n'inclut que les tables qui contiennent des lignes en production. Un `DROP TABLE` sur une table vide n'affiche aucun avertissement ; lisez donc le SQL même lorsque le volet n'est pas orange.

## Étape 4 : Replit valide la migration

Replit crée une copie temporaire de votre base de données de production et exécute le SQL dessus. Le volet affiche **Validating database migrations...** puis **Database migrations validated successfully**.

![Volet Publish affichant que les migrations de base de données ont été validées avec succès](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validated.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=7127c8d7f2e63d87be279b5a0fff4e69)

Si le SQL échoue sur la copie, le volet affiche **Migrations failed validation, please review** avec l'erreur de la base de données et trois façons de continuer :

| Option | Ce qu'elle fait |
| - | - |
| **Ask Agent to investigate and fix the development schema** | Agent lit le SQL en échec et l'erreur, compare votre schéma de développement à une vue en lecture seule de la production, et corrige le côté développement. La production n'est pas modifiée. Publiez à nouveau une fois terminé. |
| **Cancel deployment and retry once your schema conflicts are resolved** | Arrête la publication. Rien ne change en production. |
| **Copy your development database schema & data to production** | Remplace le schéma **et les données** de votre production par ceux du développement. Cela ne peut être annulé que via la [récupération de données](https://docs.replit.com/fr/features/data-and-storage/data-recovery.md). Ne l'utilisez que pour les applications sans données de production à conserver. |

![Volet Publish affichant l'échec de validation des migrations avec trois options de résolution](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/validation-failed.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=0ece6685e16081c9d3525121441ee5a0)

> [!NOTE]
>
> Les applications utilisant une base de données [Databricks Lakebase](https://docs.replit.com/fr/connectors/warehouses/databricks.md) ignorent cette étape de validation. Le volet vous demande d'examiner vous-même le SQL généré avant d'approuver.

![Volet Publish indiquant que la validation par aperçu n'est pas disponible pour Lakebase](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/lakebase-skipped.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=b6ad241f4884be8f6d085d53511e7beb)

## Étape 5 (facultatif) Prévisualisez votre application sur la copie migrée

Une fois la validation réussie, vous pouvez sélectionner **Create preview deploy** pour construire votre application sur la copie migrée de la production. Lorsque la construction est terminée, sélectionnez **View preview** pour l'ouvrir.

![Volet Publish pendant la construction d'un déploiement d'aperçu](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-building.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=18d331eba4d12dd001b6084d20481bac)

![Volet Publish avec les boutons View preview et Approve and publish](https://mintcdn.com/replit/zZK4j3xeOuUOp6xy/images/databases/publish-database-changes/preview-ready.png?fit=max\&auto=format\&n=zZK4j3xeOuUOp6xy\&q=85\&s=1ed89987ab33ff747694a9460681cc4a)

Utilisez l'aperçu pour parcourir les parties de votre application concernées par le changement de schéma. L'aperçu utilise les données copiées ; ce que vous y faites n'affecte donc pas la production. Les aperçus expirent **2 heures** après leur création ; créez-en un nouveau si vous avez besoin de plus de temps.

## Étape 6 : Approuver et publier

Sélectionnez **Approve and publish** pour continuer. Replit envoie le SQL exact que vous avez examiné avec la demande de publication : ce que vous avez vu est ce qui est exécuté.

La publication se poursuit ensuite par les étapes restantes. La migration s'exécute **après la fin de la construction de votre application et avant la promotion de la nouvelle version** :

1. Vérifications de sécurité
2. Construction
3. Migration de base de données appliquée à la production
4. Regroupement et promotion de la nouvelle version

Comme Replit applique la migration à ce moment-là, la commande de build de votre application et son code de démarrage ne doivent jamais modifier le schéma de la base de données. N'ajoutez pas d'instructions `drizzle-kit push`, `db:push` ou `CREATE TABLE IF NOT EXISTS` à la commande de build du déploiement ni au point d'entrée de votre serveur. Elles s'exécuteraient à chaque publication, en dehors de l'examen et de la validation décrits ci-dessus.

> [!WARNING]
>
> Une fois que vous avez approuvé, la migration ne peut plus être rappelée depuis le volet Publish. Si vous devez annuler un changement de schéma après la publication, effectuez le changement inverse en développement et publiez à nouveau, ou utilisez la [récupération de données](https://docs.replit.com/fr/features/data-and-storage/data-recovery.md).

Si vous demandez à Agent de republier au lieu d'utiliser le volet Publish et que vos schémas de développement et de production diffèrent, la republication est bloquée et vous êtes redirigé vers le volet Publish pour examiner la migration.

## Modifier la production manuellement

Pour des corrections ponctuelles, vous pouvez exécuter du SQL directement sur la production depuis le volet Database : sélectionnez **Production** dans le sélecteur de base de données, puis utilisez la console SQL. Consultez [Travailler avec vos données](https://docs.replit.com/fr/features/data-and-storage/work-with-your-data.md#exécuter-des-commandes-sql).

Replit compare toujours les bases de données réelles, pas votre fichier de schéma ; toute modification manuelle fait donc partie de la comparaison de la prochaine publication. Si vous ajoutez à la main en production une colonne qui n'existe pas en développement, la prochaine publication proposera de la supprimer.

## Prochaines étapes

* [Bases de données de développement et de production](https://docs.replit.com/fr/features/data-and-storage/development-and-production.md) : Comprenez en quoi vos deux bases de données diffèrent.
* [Récupération de données](https://docs.replit.com/fr/features/data-and-storage/data-recovery.md) : Restaurez les données de développement ou de production.
* [Objets de base de données non pris en charge](https://docs.replit.com/fr/help/troubleshooting/databases.md#objets-de-base-de-données-non-pris-en-charge) : Objets que Publish ne peut pas migrer.