Fusionner deux bases de code : choisir une source de vérité et migrer proprement

Pourquoi deux bases de code générées par l'IA posent rapidement problème

Deux outils d'IA peuvent produire deux versions très différentes d'une même application en un week‑end. Peut‑être avez‑vous commencé par une v0 pour aller vite, puis reconstruit dans Replit quand ça devenait confus. Ou un coéquipier a essayé Lovable ou Bolt et a « corrigé » quelques écrans là‑bas. Chaque repo peut sembler crédible individuellement, donc il est tentant de garder les deux et d'y revenir plus tard.

C'est là que les ennuis commencent. Les prototypes divergent vite. L'interface peut sembler similaire, mais la logique sous‑jacente ne l'est souvent pas. Un repo stocke les rôles dans une table, l'autre les garde dans un blob JSON. L'un part du principe d'une connexion par e‑mail, l'autre d'un OAuth. Une semaine plus tard vous n'avez pas seulement deux bases de code. Vous avez deux ensembles d'hypothèses.

Les modes d'échec courants apparaissent vite :

• Le même bug existe deux fois, mais avec des symptômes différents.
• Les règles métier entrent en conflit (tarification, permissions, règles de statut), donc ce qui est « correct » dépend du repo que vous exécutez.
• Les modèles de données dérivent, rendant les migrations risquées et les rapports peu fiables.
• Les correctifs de sécurité atterrissent dans un seul dépôt, laissant l'autre comme un piège.

Tenter de fusionner deux bases de code ligne par ligne aggrave généralement la situation. Vous vous retrouvez à assembler des patterns incompatibles, à copier des flux d'authentification cassés et à importer des requêtes dangereuses ou des secrets fuités depuis le dépôt le plus faible. Le résultat est une troisième base de code plus difficile à comprendre que l'une ou l'autre d'origine.

Un bon résultat est simple : une seule base de code source de vérité, un seul chemin de déploiement et un seul endroit pour corriger les bugs. Vous pouvez toujours réutiliser de bonnes idées de l'autre repo, mais uniquement en migrant les fonctionnalités de manière intentionnelle. L'objectif n'est pas « tout combiner », mais « en choisir une en laquelle on a confiance, puis ne déplacer que ce que l'on peut vérifier ».

Ce que signifie « source de vérité » (et ce que ça ne signifie pas)

Une source de vérité est l'endroit unique où les nouveaux changements sont autorisés à atterrir. Si une fonctionnalité est déployée, elle l'est depuis là. Si un bug est corrigé, la correction va là. Tout le reste devient du matériel de référence, pas un second produit actif.

Cela ne veut pas dire que le dépôt choisi est parfait, propre ou même celui que vous préférez. Cela ne signifie pas non plus que vous supprimez l'autre repo dès le premier jour. Vous pouvez le garder pour des comparaisons ou pour comprendre ce que les utilisateurs attendent. La différence tient à la gouvernance : un seul repo avance.

Avant de choisir, définissez ce que couvre la « vérité » afin d'éviter les disputes plus tard. Dites‑le simplement :

• Comportement produit (fonctionnalités et flux UX clés)
• Modèle de données et migrations
• Authentification et permissions
• Configuration de déploiement et environnements
• Journalisation et gestion des erreurs

Puis imposez une règle que tout le monde suit : le dépôt gagnant est la seule voie modifiable. L'autre devient en lecture seule et le reste.

Fixez aussi une date limite pour la décision. Les prototypes générés par l'IA dérivent rapidement, surtout lorsque deux outils continuent de générer des fichiers. Un objectif pratique est de 24 à 72 heures : choisissez un dépôt, figez l'autre, puis migrez de manière intentionnelle. Si vous hésitez sur lequel est le plus sûr, un audit rapide peut révéler les problèmes à haut risque tôt, notamment autour de l'auth, des secrets et des écritures en base de données.

Une méthode rapide pour comparer deux bases de code sans expertise approfondie

Quand il faut fusionner deux bases de code, ne commencez pas par débattre de celui qui « a la meilleure apparence ». Vérifiez d'abord lequel se comporte comme un vrai logiciel sous des contraintes de base : exécuter, builder, déployer et échouer de manière prévisible.

Une fiche d'évaluation simple force une comparaison honnête. Donnez à chaque repo un score 0–2 (0 = échoue, 1 = fragile, 2 = solide) pour :

• S'exécute localement après une installation propre (sans étapes manuelles secrètes)
• Se build et se déploie de manière répétable
• Contient au moins quelques tests significatifs (ou on peut en ajouter rapidement)
• Évite les rustines (URLs codées en dur, configs copiées, contournements aléatoires)
• Produit des erreurs claires exploitables (pas d'échecs silencieux)

Ensuite, scannez les signaux d'alerte que vous pouvez repérer sans être spécialiste sécurité : secrets commis au repo, contournements d'auth « temporaires », SQL brut construit à partir d'entrées utilisateurs, ou routes API sans vérification d'accès. Si un dépôt a une authentification visiblement cassée ou des risques d'injection, supposez que le problème est plus profond qu'il n'y paraît.

Regardez enfin la structure et l'hygiène du build. Un repo plus sain a généralement une organisation évidente (UI, backend, migrations), les variables d'environnement au même endroit et une façon claire de lancer et déployer. Si la logique est dupliquée dans des fichiers aléatoires, les noms incohérents ou plusieurs fichiers de config concurrents, vous en paierez le prix plus tard.

Faites aussi un test de maintenabilité simple : une nouvelle personne peut‑elle trouver où se passe la connexion, où sont stockées les données et où vivent les principales routes API en 30 minutes ? Sinon, les bugs reviendront après les « corrections ».

Étape par étape : choisissez le dépôt gagnant et figez l'autre

Garder deux repos actifs double vos bugs et décisions. Le chemin le plus rapide est de choisir un dépôt comme source de vérité, puis de traiter l'autre comme donneur de fonctionnalités uniquement.

Choisissez la base la plus sûre et la plus simple à livrer, même si l'UI est moins soignée. La sécurité signifie moins d'inconnues, moins de raccourcis et moins d'endroits où un changement en casse trois autres.

Si vous êtes bloqué, évaluez les deux dépôts sur quelques vérifications concrètes :

• Quelqu'un de nouveau peut‑il l'exécuter localement sans enquête ?
• L'auth fonctionne‑t‑elle de bout en bout (inscription, connexion, réinitialisation, déconnexion) ?
• Les secrets sont‑ils gérés en sécurité (non codés en dur ou exposés) ?
• Le modèle de données est‑il cohérent (un schéma clair, peu de hacks) ?
• Peut‑on le déployer sans corrections manuelles ponctuelles ?

Quand vous avez choisi, figez l'autre dépôt. Pas de nouvelles fonctionnalités, pas de « corrections rapides », pas de reconstruction parallèle. Mettez‑le en lecture seule pour qu'il ne puisse pas ramener l'équipe dans un développement à double réalité.

Ensuite, rédigez une courte liste des éléments indispensables à garder depuis le dépôt perdant. Décrivez des résultats, pas des écrans : « les utilisateurs peuvent exporter des factures », « les admins peuvent rembourser », « les clients peuvent mettre à jour leur moyen de paiement ». Cela devient votre backlog de migration.

Documentez enfin vos non‑négociables en un seul endroit : utilisateurs, paiements, permissions et les flux centraux qui maintiennent l'activité. Exemples :

• Les utilisateurs existants doivent se connecter avec le même e‑mail.
• Pas de double facturation.
• Seuls les admins peuvent voir les données clients.

Étape par étape : migrer les fonctionnalités sans copier les bugs

L'approche la plus sûre est ennuyeuse : déplacez un flux utilisateur fonctionnel à la fois et prouvez qu'il fonctionne avant de passer au suivant.

Commencez par la plus petite tranche verticale que vous pouvez livrer de bout en bout. Choisissez un flux qui touche UI, backend et données, mais reste contenu (par exemple : inscription, créer un élément, le voir dans une liste). Cela révèle rapidement les hypothèses sur le routage, la forme des API et la base sans vous entraîner dans une infinité de cas limites.

Porter le comportement, pas le code

Traitez l'ancien dépôt comme une spécification, pas comme un fichier source à copier. Lisez ce qu'il fait, puis réimplémentez ce comportement proprement dans le nouveau dépôt. Copier des fichiers est la façon d'importer des globals cachés, des requêtes non sécurisées et des hacks « ça marche sur ma machine ».

Boucle pratique :

• Notez les entrées attendues, sorties et messages d'erreur pour le flux.
• Recréez les endpoints et l'UI en vous basant sur ce comportement.
• Maintenez les changements de modèle de données au minimum jusqu'à stabilisation.
• Ajoutez un petit feature flag (même un toggle de config) pour activer/désactiver le nouveau flux.

Une fois la tranche fonctionnelle, migrez la fonctionnalité suivante de la même façon. Gardez les migrations petites et les pull requests ciblées. Migrer deux fonctionnalités non liées en même temps rend difficile l'identification de la cause d'une régression.

Vérifiez après chaque déplacement

Après chaque fonctionnalité, effectuez les mêmes contrôles rapides :

• Exécutez le flux deux fois (nouvel utilisateur et utilisateur existant).
• Vérifiez que les données écrites en base correspondent à l'attendu.
• Confirmez qu'aucune nouvelle erreur ou avertissement n'est apparu dans les logs serveur.
• Confirmez que vous pouvez revenir en arrière (rebasculer le toggle).

Si un dépôt a des invitations de coéquipiers, ne copiez pas le code d'invitation tel quel. Recréez le comportement d'invitation (qui peut inviter, ce qui est envoyé, comment l'acceptation fonctionne), puis vérifiez qu'il n'expose pas de tokens dans les logs.

Zones à haut risque : auth et migrations de données

Quand vous fusionnez deux bases de code, les parties les plus susceptibles de casser en production sont l'authentification et les données. Elles peuvent sembler « finies » dans une démo, mais de petites différences entre dépôts peuvent verrouiller des utilisateurs, exposer des données ou corrompre des enregistrements.

Authentification : prouvez‑la de bout en bout

Auditez l'auth avant de migrer des fonctionnalités non essentielles. Ne vous contentez pas de vérifier qu'une page de connexion existe. Vérifiez la boucle complète : connexion, stockage de session, déconnexion et le comportement des erreurs.

Les vérifications de base sur l'auth doivent couvrir :

• La connexion fonctionne avec de vrais comptes, pas seulement des utilisateurs de démo.
• Les sessions persistent après un rafraîchissement et expirent quand il le faut.
• Les tokens de reset de mot de passe fonctionnent et ne peuvent pas être réutilisés.
• Les callbacks OAuth correspondent aux bons domaines et chemins de redirection.
• Les rôles et permissions correspondent à l'intention réelle (admin vs membre vs invité).

Un échec courant durant la migration : le Repo A utilise des sessions par cookie tandis que le Repo B utilise des tokens en localStorage. Les deux peuvent « fonctionner » seuls, mais les mélanger crée des déconnexions aléatoires et des protections cassées.

Migrations de données : cartographiez le modèle, puis migrez en sécurité

Avant de migrer des fonctionnalités, décrivez le modèle de données en langage clair : tables ou collections, champs requis, relations et ce qui peut être null. Si un même concept porte des noms différents (userId vs owner_id), considérez‑le comme un problème de migration, pas un simple chercher‑remplacer.

Planifiez les migrations comme une mise en production contrôlée :

• Prenez une sauvegarde que vous pouvez restaurer rapidement.
• Répétez sur staging avec un volume de données réaliste.
• Définissez le rollback (et ce que cela signifie si des données partielles ont déjà été movées).
• Migrez par petits lots quand c'est possible.
• Validez les totaux et vérifiez ponctuellement des enregistrements critiques (utilisateurs, paiements, permissions).

Vérification sur un calendrier serré : les tests dont vous avez vraiment besoin

La rapidité compte, mais sauter les contrôles de base, c'est livrer le même bug deux fois. L'objectif n'est pas une couverture parfaite, mais la confiance que la nouvelle source de vérité fonctionne pour de vrais utilisateurs.

Commencez par verrouiller un ensemble minimum de vérifications de bout en bout. Ce sont les flux qui prouvent que l'app est utilisable et sûre pour l'argent :

• Inscription et onboarding (selon votre processus réel)
• Connexion, déconnexion et réinitialisation de mot de passe
• Le flux central pour lequel les utilisateurs paient
• Paiements et remboursements (si vous en avez), y compris un paiement échoué
• Une action admin ou de paramétrage qui modifie les données

Ajoutez ensuite quelques contrôles automatisés peu coûteux qui attrapent les régressions tôt :

• Lint et formatage
• Vérifications de types (si vous utilisez TypeScript)
• Un petit nombre de tests unitaires là où la logique est stable

Gardez staging proche de la production. Utilisez les mêmes noms de variables d'environnement et la même méthode de chargement, et alignez le type de base de données. Un échec classique est « ça marche sur staging » parce que staging utilise SQLite alors que la production utilise Postgres.

Pendant la vérification, tenez un court journal de bugs : ce qui a cassé, où cela a été corrigé et ce qui aurait permis de le détecter plus tôt (un test, une règle de linter, une variable d'env manquante). Cela évite que le même bug réapparaisse lors des migrations suivantes.

Pièges courants qui recréent le même désordre

La plupart des équipes se mettent en difficulté quand elles traitent la fusion comme un exercice de « meilleur des deux ». Si les deux repos ont été produits rapidement par différents outils d'IA, ils partagent souvent les mêmes points faibles, simplement à des endroits différents.

Ces pièges ont tendance à recréer le bazar :

• Faire une énorme fusion, puis passer des semaines à démêler conflits et logique dupliquée.
• Copier‑coller des fichiers entiers pour déplacer des fonctionnalités et importer des patterns non sécurisés (secrets codés en dur, SQL dangereux, contrôles d'accès manquants).
• Changer l'UI et le backend en même temps, si bien qu'on ne sait plus quelle modification a causé la régression.
• Laisser les dépendances dériver, puis les builds échouent sur une machine propre ou en CI.
• Considérer le déploiement comme une étape finale, puis découvrir tard que les variables d'env, les migrations ou les hypothèses d'hébergement ne correspondent pas.

Petit exemple : vous copiez une page de connexion « fonctionnelle » du Repo B dans Repo A. Elle a l'air correcte, mais apporte aussi un helper qui logge des tokens dans la console et saute les vérifications de session côté serveur. Vous avez réparé l'écran, mais réintroduit la faille de sécurité.

Garde‑fous pour avancer :

• Déplacez une tranche fonctionnelle à la fois et ajoutez un point de contrôle avant la suivante.
• Réimplémentez le comportement minimal dans le dépôt gagnant plutôt que de copier les fichiers.
• Verrouillez les versions runtime et des paquets tôt, puis vérifiez des installations propres.
• Faites un « dry run » de déploiement dès que la première fonctionnalité migrée est en place.

Liste de contrôle rapide avant de vous engager

Avant de fusionner deux bases de code en un seul chemin, faites une pause et assurez‑vous que vous pouvez vivre avec la décision pendant quelques semaines. L'objectif est un shipping prévisible et moins de surprises.

D'abord, rendez le dépôt perdant sûr à conserver sans qu'il continue d'évoluer. Si des gens peuvent encore y pousser des corrections rapides, vous vous retrouverez à nouveau avec deux versions de la réalité.

Utilisez ceci comme porte d'entrée :

• L'ancien repo est gelé (lecture seule), clairement marqué comme archivé, et vous avez enregistré le dernier commit ou tag connu comme bon.
• Le dépôt choisi se build depuis zéro sur une machine propre avec des étapes écrites (install, vars d'env, build, exécution), et ces étapes fonctionnent deux fois de suite.
• Le déploiement est répétable et vous pouvez revenir à la build précédente.
• Inscription et connexion fonctionnent de bout en bout pour nouveaux et anciens utilisateurs, y compris réinitialisation et expiration des sessions.
• Aucun secret n'est commis et les variables d'environnement sont documentées.

Une manière concrète de valider le dernier point : exécuter les trois parcours utilisateurs principaux sur staging (par exemple : inscription, accomplir la tâche principale, payer ou exporter), en utilisant des comptes de test et un volume de données proche de la production.

Exemple : choix entre une v0 et une reconstruction Replit

Un fondateur se retrouve avec deux versions de la même app. La première est une v0 qui a belle allure et la plupart des écrans, mais qui est surtout frontend. La seconde est une reconstruction complète sur Replit qui permet de se connecter et de sauvegarder des données, mais l'UI est brute et une partie de la logique est dupliquée.

L'objectif n'est pas de fusionner ligne par ligne, mais de choisir un dépôt comme source de vérité, puis de déplacer seulement les éléments qui méritent de rester.

Ils comparent les deux repos avec quelques vérifications :

• Lequel a une authentification fonctionnelle de bout en bout (inscription, connexion, déconnexion, expiration) ?
• Lequel a un modèle de données plus propre (noms clairs, moins de champs ad hoc) ?
• Lequel se déploie sans étapes manuelles ou clés secrètes disséminées dans le repo ?
• Lequel contient moins de « fixes magiques » (IDs codés en dur, routes admin cachées, timeouts aléatoires) ?

Ici, le repo Replit l'emporte parce que l'auth fonctionne et que le modèle de données correspond mieux aux besoins métier. La v0 devient une référence design uniquement.

La migration se fait fonctionnalité par fonctionnalité. Plutôt que de copier toute l'UI de la v0, l'équipe reconstruit les écrans clés comme composants dans le repo Replit, connectés au backend existant. Ils commencent par les flux à plus forte valeur : onboarding, tableau de bord principal et l'action quotidienne des utilisateurs.

Avant de déclarer la migration terminée, ils valident le comportement, pas seulement l'apparence. Les rôles et permissions doivent correspondre, les formulaires doivent avoir les mêmes champs requis et les états d'erreur doivent être clairs (mot de passe erroné, champ manquant, sauvegarde échouée).

Prochaines étapes : arriver à une seule base de code livrable

Si vous devez fusionner deux bases de code, le moyen le plus rapide d'arrêter le chaos est de mettre en pause le travail sur les fonctionnalités et de faire un court audit écrit. Vous ne jugez pas le style de code ; vous identifiez ce qui est sûr à livrer et ce qui cassera plus tard.

Notez ce que vous savez aujourd'hui :

• Les bugs utilisateurs les plus douloureux (quoi, où, comment reproduire)
• Les plus grands risques (sécurité, perte de données, coûts surprises)
• Les fonctionnalités à garder absolument (et ce qui peut attendre)
• Ce qui fonctionne déjà en production (même si c'est moche)
• Ce qui bloque le déploiement (vars d'env, étapes de build, migrations manquantes)

Puis prenez une décision : corriger et migrer, ou reconstruire depuis zéro avec les mêmes exigences. Si un dépôt a un modèle de données stable et des déploiements prévisibles, il gagne souvent même si l'UI est en retard. Si les deux dépôts sont fragiles, une reconstruction propre peut coûter moins cher que de traîner deux ensembles de problèmes.

Faites intervenir de l'aide dès que vous voyez des signaux d'alerte comme des secrets exposés, une auth cassée, une propriété de base de données floue ou des déploiements qui ne marchent que sur une machine.

Si vous avez hérité de prototypes générés par l'IA et voulez une seule base de code prête pour la production, FixMyMess (fixmymess.ai) est conçu pour cette situation exacte. Ils peuvent diagnostiquer les deux repos, réparer la logique cassée, durcir la sécurité, refactoriser l'architecture embrouillée et préparer l'app au déploiement. Si vous n'êtes pas sûr du dépôt à choisir, commencer par leur audit de code gratuit peut vous donner un plan clair et peu dramatique avant de vous engager.