Corriger en toute sécurité des migrations de base de données cassées dans des apps générées par l'IA

Pourquoi les applications générées par l'IA se retrouvent avec des migrations cassées

Une migration de base de données est un petit script qui modifie votre base de données de manière contrôlée. Pensez-y comme à une « étape de recette » pour vos tables : créer une colonne, renommer un champ, ajouter un index. Les migrations doivent s'exécuter dans l'ordre pour que chaque environnement aboutisse au même schéma.

Les applications générées par l'IA cassent souvent cette chaîne parce que le code est produit vite, sans les habitudes de soin qu'ont les développeurs pour garder l'historique propre. Les outils peuvent générer des migrations automatiquement, les régénérer après une requête, ou copier des modèles d'un autre projet. Cela peut créer des fichiers qui semblent valides mais qui ne concordent pas entre eux.

Causes communes :

• Deux migrations qui tentent de modifier la même table de façons différentes
• Un fichier de migration modifié après avoir déjà été exécuté quelque part
• Noms ou timestamps de migration dupliqués qui s'ordonnent différemment selon les machines
• Migrations générées contre une base locale qui ne correspond pas à staging ou prod

Le « ça marche sur ma machine » arrive quand la base locale a des modifications manuelles en plus, des étapes manquantes, ou un ordre de migrations différent. Le code de votre appli correspond à votre schéma local, donc tout semble en ordre, jusqu'à ce que la production exécute la vraie chaîne et tombe sur une table manquante, une colonne dupliquée, ou une clé étrangère impossible à créer.

Ce problème survient généralement au pire moment : premier déploiement, quand un nouveau collègue lance l'installation depuis zéro, ou quand CI construit une base propre et exécute les migrations strictement.

Si vous avez hérité d'un prototype généré par IA avec des outils comme Lovable, Bolt, v0, Cursor ou Replit, c'est une des premières vérifications que FixMyMess réalise lors d'un diagnostic, car les problèmes de migration peuvent rester cachés jusqu'au jour du lancement.

Symptômes et risques à surveiller avant d'intervenir

Les migrations cassées apparaissent souvent au moment du déploiement, mais le vrai problème a souvent démarré plus tôt. Les apps générées par IA peuvent créer des migrations vite, puis continuer à éditer les modèles et le schéma d'une manière qui ne correspond pas à ce qui a déjà été exécuté dans d'autres environnements.

Les signes évidents sont difficiles à manquer : déploiements qui échouent avec « table introuvable » ou « colonne existe déjà », pages qui plantent parce qu'une requête attend un champ qui n'existe pas, ou tables manquantes que le code suppose présentes. Un autre motif courant est la duplication de colonnes (comme user_id et userid) ou des index créés deux fois sous des noms différents.

Les signes plus dangereux sont silencieux. Votre appli peut encore fonctionner, mais local, staging et production ne sont plus d'accord. Un environnement peut avoir un type de colonne plus récent, une valeur par défaut, ou une contrainte (comme NOT NULL) que les autres n'ont pas. Cela crée des bugs « ça marche sur ma machine » : une fonctionnalité passe les tests localement mais casse en production, ou pire, écrit de mauvaises données qui ne posent problème que plus tard.

Avant d'essayer de réparer des migrations cassées, surveillez ces risques :

• Perte de données due à l'exécution de migrations destructives sur le mauvais schéma
• Longue indisponibilité si une migration verrouille de grandes tables ou déclenche des backfills lents
• Rollbacks partiels où le code revient en arrière mais la base ne peut pas annuler proprement les changements
• Bugs cachés quand le code suppose un schéma qui n'existe que dans un seul environnement

Une bonne règle : si vous ne pouvez pas répondre clairement « quelles migrations ont été exécutées en prod, et dans quel ordre ? », arrêtez-vous. Ne lancez pas d'autres migrations à l'aveugle pour « voir si ça marche ». Cela élargit souvent la divergence entre environnements et rend la récupération plus difficile. Si vous avez hérité d'un prototype IA et que les erreurs s'accumulent, des équipes comme FixMyMess commencent souvent par un audit en lecture seule pour cartographier ce qu'il est sûr d'exécuter et ce qui nécessite une reconstruction contrôlée.

Commencez par un inventaire rapide : qu'est-ce qui existe et où

Avant d'essayer de réparer des migrations cassées, obtenez une image claire de ce que vous avez réellement. La plupart des désastres de migration viennent du fait que l'on suppose que local, staging et production sont identiques alors qu'ils ne le sont pas.

D'abord, nommez chaque environnement existant aujourd'hui. Cela inclut généralement au moins local (votre portable), staging (un serveur de test) et production (utilisateurs réels). Si vous avez des preview apps, d'anciennes bases staging, ou une seconde région de production, incluez-les aussi.

Ensuite, capturez le schéma courant dans chaque environnement tel qu'il est maintenant, pas tel que vous souhaiteriez qu'il soit. Utilisez ce que votre stack supporte : dump du schéma, commande d'introspection, ou export en lecture seule des tables, colonnes, index et contraintes. Sauvegardez ces sorties avec des horodatages pour pouvoir les comparer plus tard.

Puis rassemblez les sources de migrations et l'état des migrations :

• Le dossier complet des migrations du repo (y compris les anciens fichiers)
• La table de suivi des migrations dans la base (par exemple, une table qui enregistre quelles migrations ont été exécutées)
• Toutes notes ou scripts manuels utilisés pour modifier la base en dehors des migrations
• La commande exacte utilisée lorsqu'il y a eu échec (et qui l'a lancée)
• Le texte complet de l'erreur, plus quand elle survient (installation fraîche vs après pull des mises à jour)

Enfin, écrivez l'histoire de la panne en mots simples. Exemple : "Local fonctionne, staging échoue sur la migration 0042, production a une colonne supplémentaire ajoutée manuellement." Ce court récit évite les conjectures et accélère les étapes suivantes, surtout si vous faites intervenir de l'aide comme FixMyMess pour un audit.

Auditez l'historique des migrations pour conflits et modifications

Avant d'essayer de réparer des migrations cassées, vérifiez si votre chaîne de migrations est digne de confiance. Les apps générées par IA créent souvent des migrations rapidement, puis écrivent par-dessus des fichiers ou en génèrent de nouvelles sans respecter ce qui a déjà été exécuté en production.

Commencez par lire la liste des migrations de la plus ancienne à la plus récente et vérifiez si l'ordre est propre. Des écarts ne sont pas toujours fatals, mais ils sont un indice que des fichiers ont été renommés, supprimés ou régénérés. Surveillez aussi les IDs ou timestamps dupliqués qui pourraient faire que deux migrations revendiquent la même « place » dans l'historique.

Ensuite, recherchez des modifications d'anciennes migrations. Si une migration a été appliquée quelque part (staging ou prod) puis son fichier a été modifié, vous avez maintenant deux vérités : la base a une version, et votre repo en a une autre. Une vérification rapide consiste à comparer les dates de modification des fichiers, l'historique des commits, ou simplement à chercher des commentaires comme « fix » ajoutés à une migration ancienne.

Les merges de branches sont une autre source courante de conflit. Deux branches peuvent chacune ajouter la « prochaine migration », donc lors du merge vous vous retrouvez avec des migrations concurrentes qui prétendent être la suivante. Cela apparaît souvent comme deux nouveaux fichiers de migration créés à quelques minutes d'intervalle mais avec des contenus différents.

Enfin, supposez que des changements ont été faits manuellement dans au moins un environnement. Si quelqu'un a ajouté un index en production, patché un type de colonne, ou exécuté un extrait SQL, vos migrations ne le refléteront pas.

Checklist d'audit rapide :

• Confirmer que les IDs de migration sont uniques et strictement croissants
• Signaler tout fichier de migration ancien qui a été édité après sa création
• Identifier les migrations « parallèles » créées sur des branches séparées
• Noter tout changement de schéma présent dans la DB mais absent des migrations
• Écrire quels environnements diffèrent probablement (local, staging, prod)

Si cela semble confus, c'est normal pour des prototypes créés avec Cursor ou Replit. Des équipes comme FixMyMess commencent souvent par cet audit avant de décider de réparer ou de reconstruire la chaîne.

Détecter la dérive entre environnements sans deviner

La dérive de migration survient quand deux environnements (local, staging, prod) ont des schémas différents alors qu'ils devraient être identiques. Dans les apps générées par IA, cela arrive souvent après des « réparations rapides » faites directement dans une base, ou après des migrations éditées puis relancées.

Commencez par comparer le schéma lui-même, pas les fichiers de migration. Vous voulez un diff écrit clair de ce qui existe dans chaque environnement : tables, colonnes, types, index et contraintes (surtout clés étrangères et contraintes d'unicité). Ce sont ces différences qui expliquent généralement pourquoi un endpoint marche localement mais échoue en prod.

Une méthode pratique est d'exporter un instantané du schéma depuis chaque environnement (dump uniquement du schéma ou sortie d'introspection de votre ORM) et de les comparer côte à côte. Lorsque vous examinez le diff, concentrez-vous sur les objets qui changent le comportement :

• Colonnes manquantes ou supplémentaires que le code lit/écrit
• Différences de nullabilité ou de valeurs par défaut
• Contraintes d'unicité manquantes (des doublons soudainement autorisés)
• Clés étrangères manquantes (ou règles de cascade différentes)
• Différences d'index qui provoquent des délais sous trafic réel

Séparez les « différences attendues » de la vraie dérive. Les données d'amorçage, utilisateurs de test admin, et flags dev-only peuvent différer sans poser de problème. Les différences de schéma sont rarement « attendues ». Si le schéma diffère, supposez qu'un problème finira par apparaître.

Puis choisissez une source de vérité. C'est une décision, pas une supposition. En général, la production devrait l'emporter si elle sert des utilisateurs réels, mais parfois la prod est le bazar (par exemple, colonnes hotfix ajoutées manuellement en panique). Si vous essayez de réparer des migrations cassées, choisissez l'environnement avec le schéma le plus correct et complet, et documentez pourquoi.

Exemple : un prototype construit sur Replit fonctionne localement, mais l'inscription échoue en prod. Le diff montre que la prod manque un index unique sur users.email, donc des comptes dupliqués ont été créés et l'auth est devenue incohérente. Cette seule dérive de schéma explique les bugs de connexion aléatoires et indique exactement ce qu'il faut réparer en premier.

Étapes : un plan de récupération sûr à suivre

Les migrations cassées semblent urgentes, mais la précipitation est la manière la plus sûre de transformer un problème de schéma en perte de données. Le plan le plus sûr est volontairement ennuyeux : geler les changements, créer un point de restauration fiable, et répéter la réparation avant de toucher la production.

D'abord, figez les déploiements. Arrêtez les auto-déploiements, les jobs en arrière-plan qui appliquent des migrations au démarrage, et toute release « poussez juste ça ». Si l'application est orientée utilisateur, choisissez une fenêtre de maintenance et indiquez à votre équipe ce qui est bloqué : schéma de la base, modèles ORM, et tout code qui écrit dans les tables affectées.

Ensuite, faites une sauvegarde que vous avez réellement testée. Ne vous contentez pas des logs « sauvegarde réussie ». Restaurez dans une base séparée, exécutez une requête simple pour confirmer que les tables clés et les lignes récentes existent, et vérifiez que l'appli peut se connecter. Si vous ne pouvez pas restaurer, vous n'avez pas de sauvegarde exploitable.

Reproduisez maintenant l'échec dans un endroit sûr en utilisant une copie des données de production (ou un snapshot anonymisé). Exécutez la commande complète de migration exactement comme la prod la lance. Capturez la première erreur et le nom du fichier de migration, car la première défaillance est généralement l'indice réel.

Puis choisissez votre approche de récupération. Si le problème est petit (une colonne manquante, une migration éditée, ou une exécution partielle), réconciliez : écrivez une migration corrective qui fait passer le schéma de l'état actuel à l'état attendu. Si l'historique est embrouillé (modifications conflictuelles, IDs dupliqués, dérive entre environnements), reconstruisez : créez une base propre à partir du schéma courant et redémarrez la chaîne.

Avant de déployer, faites une exécution complète de bout en bout : partez d'une base vide, appliquez toutes les migrations, amorcez les données minimales, et exécutez un test de fumée. C'est à ce moment que vous attrapez la dérive « ça marche sur mon portable ».

Si vous essayez de réparer des migrations cassées dans un codebase généré par IA (Lovable, Bolt, v0, Cursor, Replit), des équipes comme FixMyMess démarrent souvent par ce même flux de répétition pour que le changement en production soit prévisible, pas héroïque.

Reconstruire une chaîne de migrations propre (baseline, squash et reset)

Une chaîne de migrations propre rend les déploiements banals à nouveau. Si vous devez réparer des migrations cassées, ne commencez pas par supprimer des fichiers. Commencez par décider si vous stabilisez ce qui existe ou si vous créez un nouveau point de départ bien documenté.

Baseline : quand la créer (et quand ne pas la créer)

Créez une nouvelle migration baseline quand le schéma de production est correct, mais que l'historique des migrations est en désordre, édité ou hors d'ordre. L'objectif est de capturer le schéma actuel comme nouveau point de départ.

Ne baselinez pas si la production n'est pas fiable (changements manuels inconnus, tables manquantes ou problèmes de données). Dans ce cas, il faut d'abord réparer le schéma, puis baseliner.

Squash et reset : garder l'historique sûr

Si les migrations ont déjà été appliquées en production, évitez de réécrire l'historique en place. Traitez plutôt l'ancienne chaîne comme « legacy » et ajoutez un point de coupure clair.

Un schéma sûr :

• Figez l'état actuel : sauvegardez les données et enregistrez la version du schéma dans chaque environnement.
• Générez une seule migration « squashée » qui reflète exactement le schéma actuel.
• Marquez-la comme nouvelle baseline (par exemple, avec une note dans le repo et la doc de déploiement).
• Conservez les anciennes migrations dans un dossier séparé ou une section clairement étiquetée, mais ne les appliquez plus.
• Pour les nouveaux environnements uniquement, exécutez baseline + nouvelles migrations à partir de maintenant.

Imaginez un prototype où local a 42 migrations, staging 39, et prod des tables ajoutées manuellement. Écraser local à l'aveugle ne respectera pas prod. La bonne démarche est de baseliner depuis le schéma que vous avez choisi comme source de vérité (généralement prod), puis d'appliquer les changements futurs sous forme de nouvelles migrations.

Documentez la baseline en termes simples : la date, l'environnement source, l'instantané exact du schéma, et la règle pour les nouvelles installations. Des équipes comme FixMyMess ajoutent souvent cette documentation dans le cadre de la remédiation d'apps générées par IA, car les déploiements futurs en dépendent.

Tester et déployer la correction sans risquer les données réelles

Traitez votre correctif de migration comme une release, pas comme un patch rapide. L'endroit le plus sûr pour prouver que ça marche est un environnement staging qui ressemble à la production : même moteur et version de base, mêmes extensions, mêmes variables d'environnement, et une copie du schéma de production (idéalement un petit extrait anonymisé des données).

Avant de tester quoi que ce soit, prenez une nouvelle sauvegarde que vous pouvez réellement restaurer. Les plans de rollback échouent souvent parce qu'ils supposent que les down-migrations annuleront proprement les changements. Dans les incidents réels, le rollback le plus réaliste est la restauration d'un snapshot.

Assurez-vous que les migrations sont répétables

Une migration qui « marche une fois » peut toujours être dangereuse. Exécutez la chaîne complète de migrations sur staging, puis réinitialisez cette base staging et exécutez-la à nouveau. Vous voulez le même résultat à chaque fois.

Surveillez les signaux d'alerte comme des timestamps utilisés comme valeurs par défaut, des backfills non déterministes, ou des migrations qui dépendent du contenu actuel des tables.

Validez l'application, pas seulement le schéma

Après les migrations, démarrez l'appli et testez les flux importants : inscription/connexion, création et modification des enregistrements principaux, recherche/filtre, et les écrans d'administration. Lancez ensuite les jobs en arrière-plan et les tâches planifiées, car ils touchent souvent des colonnes renommées ou rendues non-null.

Gardez le déploiement petit et contrôlé :

• Annoncez une courte fenêtre de maintenance (même si vous visez zéro downtime)
• Appliquez d'abord les migrations, puis déployez le code qui attend le nouveau schéma
• Surveillez les erreurs et les requêtes lentes juste après la mise en production
• Soyez prêt à restaurer la base si quelque chose cloche

Si l'appli est générée par IA, revérifiez les hypothèses cachées sur le schéma dans le code. FixMyMess voit souvent des prototypes où l'UI marche localement mais la production échoue à cause de migrations manquantes, de fichiers de migration édités, ou de secrets qui changent le comportement entre environnements.

Erreurs courantes qui aggravent les problèmes de migration

La façon la plus rapide de transformer un chantier de migration en vraie panne est de "patcher jusqu'à ce que ça marche" sans savoir ce qui a été exécuté où. Quand vous essayez de réparer des migrations cassées, l'objectif n'est pas seulement de faire démarrer l'appli. C'est de ramener chaque environnement à un historique identique et compréhensible.

Un piège courant est d'éditer une ancienne migration déjà exécutée en production. Votre code indique désormais une chose, mais la prod a déjà effectué une autre opération. Un collègue effectue une installation fraîche, staging suit une chaîne différente, et vous voilà avec deux timelines qui ne pourront jamais concorder.

Une autre erreur est de « réparer la dérive » en changeant manuellement la base d'abord. Par exemple, quelqu'un ajoute une colonne manquante directement en prod pour arrêter les erreurs, mais les fichiers de migration ne correspondent toujours pas. L'appli semble OK pendant un jour, puis le prochain déploiement tente d'ajouter la colonne à nouveau, échoue, et bloque toutes les migrations suivantes.

Voici des erreurs récurrentes dans les apps générées par IA :

• Considérer les down-migrations comme filet de sécurité alors que personne n'a testé le rollback sur des données réelles
• Passer outre contraintes et index parce que l'appli « marche » sans eux, puis subir des requêtes lentes et des données corrompues
• Appliquer des correctifs rapides comme supprimer une ligne de la table de migrations pour faire taire une erreur
• Renommer tables ou colonnes en dehors des migrations, puis se demander pourquoi les modèles ORM dérivent
• Mélanger changements de schéma et backfills de données dans une seule migration, rendant les échecs plus difficiles à récupérer

Les correctifs rapides masquent souvent le symptôme mais maintiennent la dérive. Vous pouvez passer l'erreur immédiate, mais l'environnement suivant (ou le prochain poste de développeur) casse d'une nouvelle façon.

Si vous avez hérité d'un prototype d'outils comme Lovable, Bolt, ou Replit, supposez que les migrations ont été générées à la hâte. Des équipes comme FixMyMess commencent généralement par confirmer ce qui a été exécuté en production, puis reconstruisent une voie propre sans réécrire l'historique en place.

Checklist rapide avant de presser "déployer"

Si vos migrations ont été générées par un outil IA, supposez qu'il existe des écarts. Une checklist calme vous aide à éviter l'erreur qui fait le plus de mal : découvrir le problème en production.

Avant de toucher la production

Faites une sauvegarde, puis prouvez qu'elle fonctionne. « Sauvegarde prise » n'est pas équivalent à « restauration testée ». Restaurez dans une base fraîche, ouvrez l'appli, et confirmez que les tables clés et les enregistrements récents apparaissent.

Ensuite, faites un diff de schéma entre tous les environnements importants (local, staging, production). Vous voulez savoir ce qui diffère avant d'exécuter quoi que ce soit. Si la production a une colonne en plus ou manque un index, notez-le.

Choisissez une source de vérité unique et soyez explicite. Décidez si c'est le schéma de production, une branche de migration spécifique, ou un environnement connu comme bon. Mettez ce choix dans vos notes pour que personne ne « corrige » le mauvais côté en plein déploiement.

Prouver que la chaîne de migration est sûre

Exécutez la séquence complète de migrations sur une copie similaire à la production. Cela signifie une copie des données prod (ou des données anonymisées de même forme), la même version de moteur de base, et la même commande de migration que vous utiliserez en déploiement. Surveillez les verrous longs, les contraintes qui échouent, et les différences « ça marche sur ma machine ».

Avant de déployer, assurez-vous que votre plan inclut validation et rollback :

• Validation : connexion basique, quelques lectures/écritures clés, et vérification rapide des tables/compteurs critiques
• Rollback : étapes claires pour revenir à la version précédente de l'appli et restaurer la base si nécessaire

Exemple : si staging est « en avance » sur prod parce qu'un outil IA a créé une migration supplémentaire localement, faites une pause et réconciliez d'abord cette différence. Déployer avec cette dérive conduit généralement à un échec de déploiement ou, pire, à des incohérences silencieuses de données.

Si vous avez hérité d'un codebase IA confus, FixMyMess commence souvent ici : un audit gratuit qui confirme la source de vérité, cartographie la dérive, et vérifie le plan de récupération avant toute modification en production.

Exemple : récupérer un prototype qui a dérivé entre local et prod

Un fondateur publie un prototype construit par IA qui marche sur son portable. Puis le déploiement en production échoue sur la migration 012 avec une erreur « colonne existe déjà ». L'appli ne démarre pas, et chaque re-déploiement répète l'échec.

Après un premier examen, le problème n'est pas un seul mauvais fichier. Deux branches ont chacune introduit un changement légèrement différent sur la même table (par exemple, les deux ont ajouté un champ status à users, mais l'une l'a laissé nullable et l'autre a mis une valeur par défaut). Localement, le développeur a appliqué la chaîne d'une branche. En production, un déploiement antérieur a appliqué l'autre. Maintenant l'historique des migrations et le schéma réel divergent.

La manière la plus sûre de sortir de là est de traiter la production comme source de vérité, baseliner depuis le schéma de production, et n'évoluer qu'en avant.

Voici ce que cela donne en pratique :

• Figer les déploiements et prendre une sauvegarde complète (et confirmer la restauration)
• Inspecter le schéma de production et la table des migrations pour voir ce qui a réellement été exécuté
• Créer une migration baseline qui correspond à la production telle qu'elle est aujourd'hui (pas de changement, juste alignement)
• Écrire une nouvelle chaîne d'évolutions propres qui applique les changements manquants en petites étapes explicites

Puis vous validez l'appli avec des flux réels, pas seulement « les migrations se sont exécutées ». Dans cet exemple, vous testez connexion (sessions, réinitialisation de mot de passe), facturation (webhooks, factures), et les tableaux de bord dépendant de la table modifiée.

C'est un schéma courant lorsque vous devez réparer des migrations cassées dans des apps générées par IA : ne forcez pas la production à correspondre à un historique local désordonné. Faites correspondre l'historique à la production, puis ajoutez des migrations sûres et uniquement vers l'avant. Si vous n'êtes pas sûr du schéma correct, FixMyMess peut auditer le code et la trajectoire des migrations avant que vous n'appreniez à la dure en production.

Étapes suivantes : stabiliser les migrations et savoir quand demander de l'aide

Après avoir remis les migrations en ordre, l'objectif est la constance ennuyeuse. Commencez par décider si vous avez besoin d'une petite réparation (une mauvaise migration, un fichier manquant, un ordre erroné) ou d'une reconstruction complète (l'historique a été édité, les environnements divergent, et vous ne pouvez pas faire confiance à ce que signifie « latest »). Si vous voyez encore des surprises après un test propre sur une base fraîche, orientez-vous vers une reconstruction.

Une façon simple d'éviter les problèmes récurrents est d'écrire un court « contrat de schéma » que tout le monde suit. Gardez-le dans le repo comme note simple. Il n'a pas besoin d'être sophistiqué, mais il doit être clair.

• Ne créer que de nouvelles migrations, ne jamais éditer les anciennes après leur publication
• Chaque migration doit être réversible (ou expliquer pourquoi elle ne l'est pas)
• Une personne détient la responsabilité du merge final quand plusieurs branches touchent la base
• Les changements de schéma en production se font uniquement via des migrations, pas via la console manuelle
• Une installation fraîche (empty DB -> latest) doit marcher en CI avant le déploiement

Si votre appli a été générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit, attendez-vous à plus de dérive cachée que d'habitude. Le code peut créer des tables au démarrage, amorcer des données à des endroits inattendus, ou diverger silencieusement entre SQLite local et Postgres en production. Traitez la base de données comme une partie première de l'appli, pas comme un détail.

Sachez quand demander un deuxième avis. Si vous avez de vraies données clients, plusieurs environnements en désaccord, ou que vous n'êtes pas sûr qu'une « correction » pourrait supprimer des colonnes ou réécrire des contraintes, faites une pause. FixMyMess peut exécuter un audit gratuit du code pour pointer les problèmes de migration et proposer des corrections sûres avant tout engagement, ce qui est souvent plus rapide que d'essayer au hasard sous la pression des délais.