Par Thomas Cohen, fondateur de Maestro
Quitter Replit : préparer la migration du code, des données et des comptes
Un inventaire complet et un protocole de reprise sur un second environnement, avec contrôles des fichiers, des utilisateurs et du retour arrière. Aucun essai de migration n’est présenté comme réalisé.
Quitter Replit demande de récupérer et de refaire fonctionner plusieurs éléments : le code, les données, les fichiers importés, les paramètres de connexion et la gestion des utilisateurs. Télécharger un dossier ou synchroniser un dépôt ne suffit pas à prouver que l'application peut vivre ailleurs. La preuve utile est un parcours complet sur un second environnement, avec des données reconnues et des comptes autorisés.
Nous suivons le cas fictif de Camille, qui exploite un carnet de demandes avec pièces jointes. Cet article fournit un protocole documenté et une fiche à remplir ; aucune application Replit n'a été migrée pour sa rédaction. Les cases « après migration » restent volontairement vides. La documentation éditeur a été consultée le 2 octobre 2026 ; votre projet et ses dépendances devront être inspectés avant toute bascule.
Décider ce qui doit réellement quitter Replit
Commencez par votre raison de partir. Camille veut faire entretenir son application par une autre personne et choisir son hébergement. Elle n'a pas besoin de changer simultanément le service de messagerie, la base et la gestion des utilisateurs si ces services sont déjà externes et utilisables indépendamment. Déplacer tout en une seule fois rendrait les erreurs plus difficiles à comprendre.
Dessinez une carte simple du projet : l'éditeur où le code est modifié, l'endroit où l'application fonctionne, la base, les fichiers et la connexion des comptes. Pour chaque élément, demandez s'il appartient au compte Replit, à un compte externe que vous contrôlez ou à un compte détenu par un tiers. La réponse détermine les actions possibles.
Écrivez le résultat recherché : « une autre personne autorisée peut publier une correction et les utilisateurs retrouvent leurs demandes ». Ajoutez les limites de l'interruption acceptable et la personne qui décidera du passage. Ces choix précèdent le choix du nouvel hébergeur.
Vous pouvez alors séparer trois mouvements : récupérer les fichiers du projet, faire fonctionner une copie ailleurs et déplacer l'usage réel. Réussir le premier ne prouve pas le deuxième. Réussir le deuxième avec des données fictives ne signifie pas que le troisième est prêt.
Faire l'inventaire des cinq ensembles à récupérer
La documentation Replit sur les versions du code décrit notamment le travail avec Git et GitHub. Celle sur les données et le stockage distingue les services destinés à conserver les informations et les fichiers. Utilisez ces repères pour localiser ce que votre application emploie effectivement.
Pour le code, relevez l'emplacement, la dernière version utilisable, les fichiers nécessaires au lancement et les dépendances. Pour les données, relevez le service, la base, les tables et la méthode d'export. Pour les documents, ajoutez leur stockage et la correspondance avec les demandes. Ne supposez pas qu'ils se trouvent dans le dossier du code.
Les paramètres sensibles forment un quatrième ensemble. Dressez leur liste par nom et utilité : accès à la base, messagerie, connexion des utilisateurs, stockage. Gardez leurs valeurs dans le système prévu pour les secrets. Une fiche d'inventaire partageable doit indiquer où ils sont gérés, sans devenir une collection de mots de passe.
Enfin, identifiez le système de comptes : où sont reconnus les utilisateurs, quels identifiants sont associés à leurs dossiers, et comment leurs droits sont déterminés. Ajoutez les tâches automatiques, adresses de retour et notifications. Chacun de ces éléments peut encore dépendre de l'ancien environnement après le déplacement du code.
Préparer un dossier d'essai qui révèle les oublis
Le dossier fictif comprend deux utilisateurs, trois demandes et deux documents. U01 est responsable et peut traiter tous les dossiers. U02 est demandeur et ne voit que les siens. M01 et M02 appartiennent à U02 ; M03 appartient à U01. M02 est clôturée. Les documents sont rattachés à M01 et M03, avec des noms et contenus différents.
Gardez ces références stables dans les exports et la copie de destination. Ajoutez à M01 un titre contenant un accent et à M03 une description sur plusieurs lignes. Notez une date précise et son fuseau. Ces détails permettent de repérer un changement de texte, une perte de sauts de ligne ou un décalage d'heure.
Avant la migration, consignez le nombre de demandes, leur statut, leur propriétaire et les fichiers attendus. Calculez si possible une empreinte de chaque document : c'est une valeur qui permet de comparer son contenu avant et après sans se fier seulement à son nom. Une personne technique peut préparer ce contrôle.
La fiche de migration téléchargeable contient ce jeu et les observations attendues. Il est conçu pour votre copie d'essai. Il ne prétend pas représenter un export obtenu depuis Replit ni une restauration déjà effectuée dans un autre service.
Récupérer le code et expliquer son lancement
Conservez une copie de la version qui fonctionne avant de préparer la suivante. Utilisez le mécanisme de récupération ou de synchronisation adapté à votre projet et vérifiez le contenu obtenu. Le dépôt doit contenir les fichiers indispensables, mais pas les secrets. Certains fichiers présents dans un environnement de travail peuvent ne pas être suivis dans l'historique.
Demandez ensuite une notice de lancement destinée à la personne qui reprend : langage et version attendus, dépendances, préparation de la base, paramètres nécessaires, lancement et procédure de publication. Une suite d'instructions compréhensible dans le seul contexte de votre ancienne conversation n'est pas une notice de reprise.
Faites effectuer le premier démarrage sur un environnement neuf avec des accès d'essai. Le but est de découvrir les dépendances implicites : un fichier oublié, un service réservé à Replit, un chemin propre à l'ancien environnement ou un paramètre qui n'était défini nulle part dans le projet récupéré.
Chaque difficulté doit produire une correction dans le dossier de reprise. Si la nouvelle personne doit deviner trois réglages, consignez ces réglages une fois trouvés. Évitez de considérer le démarrage comme réussi parce que la page d'accueil s'affiche : il reste à créer une demande, la conserver et ouvrir un document.
Reprendre les données et les documents séparément
Identifiez d'abord la base qui sert réellement les utilisateurs. La documentation Replit sur développement et production explique leur séparation et les différences entre infrastructures. Un export de la base de construction peut être cohérent et pourtant ne contenir aucun des derniers dossiers réels.
Sur la copie d'essai, récupérez les données avec une méthode adaptée au service identifié. Une sauvegarde destinée à être restaurée et un simple fichier de lignes n'emportent pas nécessairement les mêmes éléments. Demandez ce qui est inclus : structure, références, relations, règles, valeurs calculées et historique éventuel. Le choix dépend du projet, pas d'une recette universelle de migration.
Importez ensuite dans la destination d'essai et comparez les références, statuts et propriétaires du dossier fictif. Vérifiez les accents, les dates et les champs vides. Une égalité du nombre de lignes ne garantit pas que M01 appartient toujours à U02 ou que M02 reste clôturée.
Récupérez les documents eux-mêmes, puis recréez leur correspondance avec les demandes. Un ancien lien de téléchargement peut dépendre de l'ancien service ou expirer. Ouvrez chaque pièce depuis la nouvelle application avec le compte autorisé, puis comparez le contenu à l'original. Gardez les copies de départ jusqu'à la fin des contrôles et selon votre politique de conservation.
Traiter les comptes et les secrets comme une reprise distincte
La liste des utilisateurs ne suffit pas à recréer leur connexion. Selon le service utilisé, vous pourrez conserver le fournisseur d'identité, organiser un transfert pris en charge ou prévoir un nouveau parcours d'accès. Ne promettez pas que les mots de passe sont exportables. Déterminez la procédure avec la documentation du fournisseur concerné avant de prévenir les utilisateurs.
Le lien entre compte et dossier doit rester cohérent. Si U02 reçoit un nouvel identifiant dans la destination, prévoyez une correspondance contrôlée avec l'ancien. Associer des dossiers sur la seule ressemblance d'un nom serait dangereux. Testez ensuite que U02 retrouve M01 et M02, sans pouvoir lire M03.
Réinstallez les paramètres nécessaires dans l'environnement de destination à l'aide de son système de secrets. Préférez des accès limités au rôle prévu et séparez l'essai du fonctionnement réel. Les anciens accès ne sont supprimés qu'après la décision de bascule et le traitement du retour possible ; leur révocation fait partie du plan, pas d'un oubli après coup.
Examinez aussi les adresses attendues par les services externes. Une connexion peut encore revenir à l'ancien domaine. Une notification peut encore diriger vers Replit. Un traitement régulier peut continuer à tourner dans les deux environnements et produire un doublon. Ces dépendances méritent une ligne chacune dans l'inventaire.
Faire fonctionner la copie et provoquer les erreurs utiles
Exécutez le même parcours avec U01 et U02 dans la destination d'essai. Créez M04, fermez le navigateur, reconnectez-vous et retrouvez cette demande. Modifiez son statut avec le rôle autorisé. Ouvrez les documents et tentez l'accès à M03 avec U02 sur ce seul jeu de données autorisé : le refus attendu doit être constaté.
Testez une erreur d'enregistrement ou un fichier indisponible dans l'environnement d'essai. L'application doit expliquer ce qui s'est passé sans perdre silencieusement la saisie ni afficher une réussite inventée. La destination peut se comporter différemment même lorsque le code n'a presque pas changé.
Republiez ensuite une petite correction et vérifiez la conservation des quatre demandes. Vous examinez ainsi l'entretien du projet, pas uniquement son premier démarrage. Demandez à la personne qui reprend de réaliser cette opération avec la notice, puis corrigez la notice si elle reste dépendante d'une explication orale.
- Données : références, contenus, statuts et propriétaires conformes.
- Fichiers : documents ouverts et contenu comparé.
- Accès : opérations permises et refusées selon le compte.
- Entretien : correction publiée et données conservées.
- Reprise : méthode de restauration identifiée et exercice planifié ou effectué.
Chaque résultat doit être accompagné d'une date et d'une preuve. Une case « à vérifier » reste un travail à faire ; elle ne doit pas disparaître sous une conclusion générale « migration réussie ».
Préparer la bascule et le retour avec les nouvelles données
Choisissez le moment où l'ancien environnement cesse d'accepter les modifications. Pendant l'essai, de nouveaux dossiers peuvent avoir été créés. Ils doivent être inclus dans la reprise finale. Définissez comment vous récupérez ce dernier ensemble et comment vous vérifiez qu'aucune demande n'est restée entre les deux systèmes.
Pour Camille, un scénario à adapter consiste à fermer temporairement la saisie, réaliser la dernière copie, contrôler les résultats, puis orienter les utilisateurs vers la destination. Une organisation qui ne peut pas interrompre son activité aura besoin d'un mécanisme plus élaboré, à préparer avec la personne responsable de la migration.
Le domaine constitue une étape distincte. Conservez ses réglages précédents et adaptez les adresses de connexion et notifications. Pendant la propagation, évitez que deux versions acceptent simultanément des écritures indépendantes sans mécanisme prévu. Le principe est simple : à chaque instant, l'équipe doit savoir où saisir et quel ensemble de données fait foi.
Définissez le retour avant la bascule. Si M04 et M05 ont été créées dans la destination, rétablir seulement l'ancien hébergement les ferait disparaître du parcours. Le retour doit indiquer comment récupérer ces ajouts, qui résout les conflits et qui informe les utilisateurs. Une ancienne copie ne suffit pas à préserver le travail nouveau.
Fermer l'ancien environnement au bon moment
Après la bascule, faites vérifier les parcours critiques par les personnes qui les utilisent. Comparez les nouvelles demandes reçues avec les observations de l'équipe. Contrôlez que les notifications ne partent qu'une fois et que les documents récents sont accessibles. Conservez les traces nécessaires pour traiter un dossier manquant.
La fermeture de Replit vient après les décisions de conservation et la vérification de la reprise. Inventoriez ce qui doit être arrêté, révoqué, conservé ou transféré : application publiée, accès externes, tâches automatiques et abonnement éventuel. Ne confondez pas arrêter l'hébergement et supprimer définitivement les copies dont vous avez encore besoin.
Nous éditons Maestro et ne présentons pas cette procédure comme une migration accomplie. Elle sert à préparer une reprise vérifiable, avec ou sans notre outil. La fiche complète permet d'identifier ce qui manque encore. Vous pourrez parler d'une migration réussie lorsque le projet fonctionne dans sa destination, que ses données et accès sont contrôlés, et qu'une personne sait réellement l'entretenir.