Votre app Replit fonctionne en aperçu mais plante après publication ? La checklist du fondateur

Vous testez l’app dans Replit, vous envoyez le lien à quelqu’un, et on vous répond aussitôt que la connexion, l’enregistrement ou le paiement ne fonctionne pas. Avant de demander à Agent de reconstruire ces fonctionnalités, suivez cette checklist de déploiement en production Replit. Une différence entre les deux environnements peut expliquer l’échec sans nécessiter de nouvelle implémentation.

Pourquoi une app peut-elle fonctionner en aperçu Replit et échouer en ligne ?

L’aperçu Replit et l’app publiée sont des environnements distincts. L’app en ligne peut avoir une URL, une configuration, des données et un comportement d’exécution différents du projet que vous modifiez.

Le guide de publication de Replit explique que la publication crée un déploiement de production et que les modifications ultérieures ne le changent pas tant que vous ne republiez pas. Vérifiez d’abord que vous testez bien la release voulue. Notez l’URL publique, l’heure de la dernière publication, l’action qui échoue et si l’échec se produit aussi dans une session de navigateur neuve.

Ne rassemblez pas cinq captures d’écran sans rapport pour demander à Agent de réparer toute l’app. Choisissez un seul échec : par exemple, un nouveau client reçoit une erreur après avoir cliqué sur Enregistrer. Notez le résultat attendu, le résultat obtenu et l’heure. Vous disposez ainsi d’un élément précis à comparer avec les logs de l’application publiée.

L’app utilise-t-elle le bon type de déploiement ?

Le déploiement doit prendre en charge le type de programme exécuté par votre app. Un ensemble de fichiers statiques et une application full-stack n’ont pas les mêmes besoins d’hébergement.

En octobre 2026, la documentation sur les types de déploiement de Replit distingue les déploiements Autoscale, Static, Reserved VM et Scheduled. Vérifiez le type de déploiement dans les paramètres de publication et comparez-le aux besoins réels de l’application.

La même documentation indique que Static n’est pas compatible avec les apps créées avec Replit Agent, car ces apps ont besoin d’un backend. Si l’application a été personnalisée, faites confirmer les commandes de build et d’exécution par un développeur. Une machine plus puissante ne réparera pas une route serveur manquante ni une commande de démarrage incorrecte.

Les secrets de production requis sont-ils réellement disponibles ?

Vérifiez les identifiants et la configuration utilisés par l’app publiée, y compris leurs noms et l’environnement auquel ils sont destinés. Une clé disponible pendant le développement ne prouve pas que l’intégration en ligne est correctement configurée.

Le guide Secrets de Replit vous oriente vers Publishing → Adjust settings → Production app secrets. Il distingue aussi les secrets sensibles des valeurs de configuration non sensibles. Passez-y en revue les entrées requises, sans copier leurs valeurs dans un prompt de dépannage.

1. Demandez la liste des noms de variables requis, l’endroit où chacune est lue et si elle est utilisée au build ou à l’exécution.
2. Vérifiez que les entrées de production correspondent exactement à ces noms et appartiennent aux bons comptes fournisseurs.
3. Gardez les identifiants serveur sur le serveur ; une variable frontend ou un bundle navigateur n’est pas un coffre à secrets.
4. Republiez lorsque la plateforme ou le processus de build l’exige, puis refaites l’action d’origine sur l’URL publique.

L’app publiée lit-elle la bonne base de données ?

Identifiez la base de données en ligne avant de conclure que l’interface est cassée parce que des enregistrements de production manquent. Les données d’exemple visibles en développement ne sont pas forcément celles que lit l’app de vos clients.

Le guide des bases de données de développement et de production de Replit décrit des environnements séparés et des procédures de configuration différentes selon l’infrastructure actuelle ou historique. Inspectez la sélection de production dans l’outil Database ainsi que les paramètres de publication applicables à votre app. Ne supposez pas qu’un tutoriel écrit pour une autre génération de projet correspond au vôtre.

Prenons une app d’annuaire hypothétique. L’aperçu affiche dix entreprises, mais le site en ligne n’en affiche aucune. Avant de reconstruire le composant de liste, vérifiez si la production contient des fiches d’entreprises approuvées. Il manque peut-être simplement une importation de données ou une étape d’initialisation délibérée. Ne copiez que des données adaptées à un usage en production, et protégez les enregistrements clients existants avant toute importation ou modification de schéma.

En cas d’échec d’écriture, notez l’opération et l’erreur expurgée. Demandez à un développeur de distinguer un échec de connexion d’une table manquante, d’une contrainte ou d’un problème d’autorisation. Modifier la chaîne de connexion à répétition peut masquer le problème d’origine et, par mégarde, faire pointer le travail de développement vers les mauvaises données.

Les fichiers et les callbacks externes fonctionnent-ils sur le domaine public ?

Vérifiez où sont stockés les fichiers envoyés et quel domaine les services externes appellent. Les deux peuvent sembler corrects en aperçu tout en étant inadaptés à l’application publiée.

Pour les uploads, Replit App Storage fournit un stockage objet persistant. Examinez l’implémentation actuelle plutôt que de supposer que les fichiers écrits dans un dossier d’exécution offrent la persistance et les contrôles d’accès dont votre produit a besoin. Testez l’envoi, la récupération et la restriction d’accès d’un fichier après une release maîtrisée.

Pour les fournisseurs de connexion, les webhooks de paiement et les liens dans les e-mails, vérifiez avec chaque fournisseur concerné les origines autorisées, les endpoints enregistrés et les URL de retour. Ils doivent pointer vers le domaine publié voulu lorsque c’est nécessaire. Testez le parcours complet : quitter votre app, effectuer l’action chez le fournisseur et revenir sur un écran utile.

Tenez un petit inventaire des intégrations : service, environnement, chemin de callback public, nom du secret et responsable. Cet inventaire contient des informations de configuration, pas des valeurs secrètes. Il facilite grandement la revue des futurs changements de domaine et des passations.

Comment vérifier la correction en ligne ?

Reproduisez l’action d’origine sur l’URL publique, puis examinez les traces de production correspondantes. Une publication réussie signifie que la release s’est terminée ; elle ne prouve pas que chaque parcours client fonctionne.

Le guide Monitoring de Replit présente les statuts de requêtes, les temps de réponse, l’utilisation des ressources et les logs applicatifs. Servez-vous de l’horodatage de l’action en échec pour cibler l’investigation. Une forte consommation de ressources et une erreur applicative sont deux constats différents : diagnostiquez avant de modifier la capacité.

1. Utilisez un compte neuf sur le domaine publié et refaites exactement le parcours qui échouait.
2. Vérifiez que l’enregistrement ou le résultat d’intégration attendu existe après avoir rafraîchi la page.
3. Consultez la requête serveur ou le log correspondant, puis testez sans risque un cas d’échec voisin.
4. Refaites le parcours principal sur un téléphone et vérifiez que ce qui fonctionnait auparavant fonctionne toujours.

Et si le déploiement nécessite encore du développement ?

Si les vérifications de configuration ne résolvent pas l’échec, cadrez le développement autour de la frontière précise qui est cassée. Apportez une reproduction, les paramètres de déploiement, les erreurs expurgées et une carte des services impliqués.

Utilisez la checklist de mise en production d’un MVP IA, plus complète, avant d’élargir votre audience, ou le guide sur les boucles de correction si des prompts répétés provoquent des régressions. Pour vous faire aider à auditer et livrer la prochaine version, réservez un appel au sujet de votre app Replit. Nous déterminerons ensemble s’il vous faut une correction de configuration, une modification de code ciblée ou un plan de release plus large.