Dev & Code

Migrer une base de données entre deux schémas

Un agent qui écrit la migration, la teste et gère les cas tordus.

Claude CodeCodexAvancéSemi-autonome

Le besoin

Migrer des données est risqué : un mapping oublié ou un type mal converti et c'est la corruption silencieuse. Un agent qui voit les deux schémas et les données réelles écrit un script plus complet et pense aux cas que l'on oublie sous pression.

L'approche

On exige toujours un plan de retour arrière et un test sur copie avant la prod.

  • Comparer les deux schémas et établir le mapping champ à champ.
  • Écrire le script de migration avec gestion des valeurs nulles et des types.
  • Tester sur une copie, vérifier les comptages, prévoir le rollback.

Étape par étape

  1. 1

    Comparer

    L'agent établit le mapping entre l'ancien et le nouveau schéma.

  2. 2

    Écrire la migration

    Script avec gestion des types, nulls et cas limites.

  3. 3

    Tester et sécuriser

    Exécution sur copie, contrôle des volumes, plan de rollback.

Le prompt à donner

Voici l'ancien schéma et le nouveau. Écris le script de migration des données : mapping champ à champ, conversion des types, gestion des valeurs nulles et des doublons. Ajoute des vérifications de cohérence post-migration et un plan de rollback.

Le résultat

Une migration scriptée, testée sur copie et réversible, qui réduit fortement le risque de perte ou de corruption de données.

Le verdict NXUS

À ne jamais lancer en prod sans test sur copie ni rollback, même si l'agent semble sûr de lui. Avec ces garde-fous, c'est un vrai accélérateur.

Cas d'usage similaires

Apprends à piloter tes propres agents IA

Nos formations t'apprennent à transformer ces cas d'usage en automatisations concrètes pour ton métier.

Voir les formations