Passer votre application Replit en production
L'agent de Replit a construit votre application et la publie en quelques clics. Nous la rendons prête pour de vrais clients : données de production maîtrisées, accès sécurisés, tests et surveillance.
Vous vous reconnaissez ?
Ces situations reviennent chez la plupart des porteurs de projet qui nous arrivent avec une app Replit :
- Votre app est publiée, mais vous ne savez pas si elle est prête à accueillir de vrais clients
- Vous ne savez pas exactement ce qui sépare votre base de développement de votre base de production
- Une modification de la structure de la base faite pendant le développement va s'appliquer à la production à la prochaine publication
- Vous ne savez pas comment restaurer les données de production en cas de problème
- Vous ne savez pas qui peut lire ou modifier quoi dans votre base
- Le code n'existe nulle part ailleurs que dans Replit
- Un client B2B vous demande où sont hébergées ses données, et vous ne savez pas quoi répondre
Aucune de ces situations n'est un échec : Replit est conçu pour passer d'une idée à une application publiée sans rien configurer. La mise en production demande de reprendre la main sur ce que la plateforme fait automatiquement.
Ce que Replit fait déjà, et ce qui reste à votre charge
Replit réunit l'éditeur, l'agent qui construit l'application, l'hébergement et la base de données. Depuis 2025, les bases de développement et de production sont séparées par défaut, et l'agent ne peut pas modifier la base de production. Ce changement a été introduit après un incident largement relayé en juillet 2025, au cours duquel un agent avait supprimé une base de production.
Ce que la plateforme ne fait pas à votre place : définir qui a le droit de voir quoi dans votre métier, tester les parcours dont dépend votre chiffre d'affaires, vous alerter quand un client ne peut plus se connecter, et remplir vos obligations RGPD. Les points de restauration de Replit couvrent le code et, en option, la base de développement. D'après la documentation de Replit, ils ne restaurent pas automatiquement la base de production.
Ce que nous vérifions en priorité sur une app Replit
Les changements de structure de la base. Les modifications faites en développement, comme l'ajout ou la suppression d'une colonne, sont appliquées à la base de production lors de la publication. Une colonne supprimée pendant un essai peut donc disparaître de la production avec ses données. Nous relisons ces changements avant chaque publication et mettons en place des migrations contrôlées.
Les sauvegardes de production. Nous vérifions la méthode de restauration réellement disponible pour votre base de production et la durée de conservation de votre offre, puis nous testons une restauration avant d'en avoir besoin.
Les droits d'accès et les secrets. Nous vérifions que chaque utilisateur ne voit que ses propres données, en testant avec plusieurs comptes et en appelant l'API directement. Les clés sont stockées dans les secrets de Replit, jamais dans le code, et toute clé exposée est changée.
Le code. Nous connectons le projet à GitHub pour qu'il existe hors de la plateforme, avec son historique, puis nous ajoutons des tests sur les parcours critiques.
Rester sur Replit ou en sortir : nous vous aidons à décider
Pour une bêta ou un outil interne, rester sur Replit est souvent suffisant. Avec des clients payants, une équipe de développeurs ou des exigences d'hébergement, une sortie progressive devient pertinente.
La documentation de Replit ne précise pas la région d'hébergement des bases de données. Si vos clients exigent un hébergement en Europe, c'est un point à vérifier en priorité. Une sortie demande aussi de migrer séparément les données, les fichiers stockés et, le cas échéant, l'authentification fournie par Replit. Nous préparons cette migration et la testons sur une copie avant toute bascule.
Ce qui est inclus
Audit du code existant
Architecture, qualité du code, dépendances et failles de sécurité — un état des lieux écrit avant tout développement.
Sécurisation
Secrets sortis du code, authentification vérifiée, dépendances à jour, conformité RGPD si des données personnelles sont en jeu.
Mise en production
Tests automatisés, CI/CD, hébergement dimensionné et monitoring — pour déployer sans craindre chaque mise à jour.
Questions fréquentes
Oui. Replit fournit l'hébergement, une base PostgreSQL et la séparation entre développement et production. Ce qui manque généralement, ce sont des droits d'accès vérifiés, des migrations contrôlées, des sauvegardes testées et une surveillance. C'est ce que nous mettons en place.
En partie. Ils couvrent le code et, si vous le choisissez, la base de développement. D'après la documentation de Replit, la base de production n'est pas restaurée automatiquement par ce mécanisme : il faut une procédure de restauration dédiée, à tester avant d'en avoir besoin.
Pas directement : depuis 2025, l'agent ne peut modifier que la base de développement. En revanche, les changements de structure qu'il y fait sont appliqués à la production lors de la publication. C'est pourquoi nous relisons ces changements avant chaque mise en ligne.
Oui. Une fois le projet connecté à GitHub, le code peut être déployé chez l'hébergeur de votre choix. Les données, les fichiers stockés et l'éventuelle authentification Replit doivent être migrés séparément.
Oui, si vous restez sur Replit. Nous définissons avec vous les garde-fous, comme la relecture des changements de base et les tests à faire passer avant chaque publication, pour qu'une modification ne défasse pas ce qui a été sécurisé.
Chaque projet est chiffré sur devis après l'appel découverte et l'audit du code, selon la taille de l'app, l'état de la base et le périmètre visé. Le devis est fixé avant le démarrage.
Le détail complet de la méthode et du déroulé du projet est sur la page Vibe to Prod.
Pour préparer le terrain vous-même, lisez notre guide Combien coûte la mise en production d'un POC vibe-codé.