Comment exporter et auto-héberger une application créée par IA

Pour auto-héberger une application créée par IA, récupérez le code (un téléchargement ou une synchronisation vers un dépôt GitHub que vous possédez), recréez ses secrets sous forme de variables d’environnement, transférez ou recréez sa base de données, et déployez-la sur un hébergeur adapté à ce qu’elle est : un hébergeur statique pour une interface simple, ou une plateforme qui fait tourner des serveurs ou des conteneurs pour tout ce qui a un back end. Le code est généralement la partie facile. Les données, les secrets et les services que le créateur faisait tourner discrètement pour vous sont là où se trouve le travail.

Pourquoi exporter

Il existe de bonnes raisons d’emporter votre code avec vous, et d’autres moins bonnes.

Bonnes raisons :

• Propriété et assurance. Une copie du code dans votre propre dépôt vous protège si le créateur change ses tarifs, ses fonctionnalités ou ses conditions.
• Passation à des développeurs. Une équipe d’ingénierie voudra le code dans Git, avec ses outils habituels et son processus de revue.
• Exigences spécifiques. Localisation des données, fournisseur cloud particulier, politiques de sécurité de l’entreprise, ou infrastructure que le créateur ne propose pas.
• Montée en charge ou coût à une taille où faire tourner sa propre infrastructure est vraiment rentable.

Moins bonnes raisons : déplacer une petite application avec quelques utilisateurs pour économiser un petit montant mensuel. L’auto-hébergement vous transfère du travail : mises à jour, sauvegardes, supervision, correctifs de sécurité. Cela peut être le bon compromis ; faites-le en connaissance de cause.

Un juste milieu raisonnable : continuez à construire et à héberger là où vous êtes, mais synchronisez vers votre propre dépôt GitHub dès le début. Vous obtenez l’assurance sans le travail opérationnel. Si Git vous est nouveau, lisez ce qu’est GitHub.

Ce que contient et ne contient pas un export

Avant de compter sur un export, ouvrez-le et vérifiez. En général :

Les secrets sont exclus volontairement : une archive que vous pourriez envoyer par e-mail ou committer ne doit jamais contenir de clés actives. Les dépendances sont exclues parce qu’elles se reconstruisent à partir du fichier de verrouillage.

Étape 1 : récupérer le code

Deux voies courantes :

• Télécharger une archive du projet. Rapide, et suffisant pour un déménagement ponctuel ou une sauvegarde.
• Synchroniser vers GitHub. Mieux pour tout ce qui est continu : historique complet, clonage facile n’importe où, et la plupart des hébergeurs déploient directement depuis un dépôt GitHub à chaque envoi.

Dans les deux cas, clonez ou décompressez le projet sur un ordinateur (ou un environnement de développement cloud) et cherchez un README. S’il n’y en a pas, demandez à l’IA du créateur d’en rédiger un avant de partir :

Rédige un README pour faire tourner ce projet en dehors de cette plateforme : la pile technique, les versions d’exécution requises, les commandes d’installation et de build, la commande de démarrage et le port, chaque variable d’environnement lue par le code (noms et rôle, sans valeurs), et la manière dont les migrations de base de données sont lancées.

Ce seul prompt vous fait gagner des heures, car il force les éléments implicites de la configuration à être écrits noir sur blanc.

Étape 2 : d’abord le faire tourner en local

Avant de déployer quoi que ce soit, prouvez que l’application fonctionne seule :

1. Installez le runtime indiqué dans le README — Node.js, Python, Java, .NET — à une version compatible.
2. Installez les dépendances (npm install, pnpm install, pip install -r requirements.txt, ou l’équivalent).
3. Créez un fichier .env local avec les variables d’environnement, en utilisant si possible des clés de test. Gardez-le hors de Git. Ce que sont les variables d’environnement et les secrets explique l’idée.
4. Connectez-la à une base de données — un Postgres local, ou une base de développement gratuite d’un fournisseur managé.
5. Lancez les migrations, puis démarrez l’application et parcourez les principaux parcours.

Tout ce qui casse ici cassera aussi chez un hébergeur, et il est bien plus facile de déboguer sur votre propre machine. Surprises fréquentes : une URL en dur pointant vers l’aperçu du créateur, une variable d’environnement que le créateur injectait automatiquement et qui manque, ou un service (stockage de fichiers, redimensionnement d’images) qui n’existait que sur la plateforme.

Étape 3 : transférer les données

Si l’application a de vrais utilisateurs, les données comptent davantage que le code.

• Exportez la base de données. Pour Postgres, pg_dump produit un fichier que vous pouvez restaurer avec pg_restore ou psql dans la nouvelle base. Demandez à l’IA du créateur de l’exécuter si vous n’y avez pas accès directement, et de vous expliquer ce qu’elle a produit.
• Déplacez les fichiers envoyés. Si les utilisateurs ont envoyé des images ou des documents, ils sont stockés dans un espace de stockage d’objets distinct de la base. Copiez-les vers votre nouveau stockage (par exemple un bucket compatible S3) et mettez à jour les URL enregistrées si elles contiennent l’ancien hôte.
• Planifiez la bascule. Pour une application en ligne, l’approche simple consiste en une courte fenêtre de maintenance : arrêter les écritures, faire un dernier export, le restaurer sur le nouvel hébergeur, changer les DNS, puis rouvrir. Notez chaque étape à l’avance.
• Testez une restauration dans une base de test avant le vrai déménagement.

Si Postgres vous est inconnu, ce qu’est Postgres couvre les bases.

Étape 4 : choisir où l’héberger

Adaptez l’hébergeur à la nature de l’application. Les noms ci-dessous sont des exemples de fournisseurs connus dans chaque catégorie, en septembre 2026 ; il ne s’agit pas d’un classement. Vérifiez les fonctionnalités et les tarifs actuels sur leurs sites.

Il vous faudra aussi :

• Une base de données managée — beaucoup d’hébergeurs d’applications proposent Postgres, et des services dédiés comme Neon ou Supabase le fournissent seul. Le managé en vaut la peine : les sauvegardes et les mises à jour sont le travail de quelqu’un d’autre.
• Un stockage d’objets pour les envois, si l’application en a.
• L’envoi d’e-mails, les paiements et les fournisseurs d’IA — ils nécessitent généralement simplement de configurer les mêmes clés d’API sur le nouvel hébergeur.

Pour être honnête sur les compromis : les hébergeurs de plateforme (les quatre premières lignes) sont plus rapides à mettre en place et à maintenir, mais vous avez moins de contrôle et les coûts peuvent augmenter avec le trafic. Un serveur virtuel est souvent moins cher sous charge stable et entièrement sous votre contrôle, mais vous assumez les correctifs, le TLS, les sauvegardes, la supervision et la reprise après incident. Si personne dans l’équipe ne veut ce travail, choisissez une plateforme. Pour les bases de l’hébergement, voir ce qu’est l’hébergement web.

Étape 5 : déployer et basculer

1. Connectez le dépôt à l’hébergeur, ou envoyez une image de conteneur.
2. Configurez les variables d’environnement dans le tableau de bord de l’hébergeur — chacune de celles du README, avec les valeurs réelles.
3. Configurez les commandes de build et de démarrage et le port. Beaucoup d’hébergeurs transmettent le port via une variable d’environnement PORT ; l’application doit l’écouter et écouter sur toutes les interfaces (0.0.0.0), et pas seulement sur localhost.
4. Lancez les migrations sur la nouvelle base.
5. Testez sur l’URL temporaire de l’hébergeur avant de toucher aux DNS.
6. Mettez à jour les services externes qui pointent vers l’ancienne URL : webhooks de paiement, URL de redirection OAuth pour la connexion, liens dans les e-mails, origines autorisées.
7. Déplacez le domaine en mettant à jour les enregistrements DNS vers le nouvel hébergeur. Comment connecter un domaine personnalisé explique les enregistrements.
8. Gardez l’ancien déploiement actif un moment, jusqu’à être sûr, puis supprimez-le.

L’étape 6 est celle qu’on oublie le plus souvent : les connexions et les paiements qui échouent en silence après un déménagement viennent généralement d’une URL de callback qui pointe encore vers l’ancien hôte.

Étape 6 : reprendre la main sur l’exploitation

Une fois auto-hébergée, l’application prend en charge ce que le créateur gérait pour vous. Au minimum : sauvegardes automatiques de la base avec une restauration testée, suivi des erreurs, alertes de disponibilité, mises à jour des dépendances, et une liste de qui a accès à chaque compte. Comment passer un prototype IA en production détaille cette liste.

Liste de contrôle de l’export

• Code dans un dépôt que vous possédez, avec un README couvrant l’exécution, le build et les variables d’environnement
• L’application tourne en local à partir d’un clone propre
• Base exportée et restauration testée ; fichiers envoyés copiés
• Hébergeur choisi selon la forme de l’application, plus base managée et stockage
• Toutes les variables d’environnement configurées avec les valeurs réelles sur le nouvel hébergeur
• Webhooks, redirections OAuth et liens d’e-mail mis à jour
• DNS basculés, ancien déploiement conservé brièvement puis supprimé
• Sauvegardes, supervision et liste d’accès en place

Exporter depuis Mythex

Sur Mythex, vous possédez le code que vous créez. Avec l’offre Pro, vous pouvez télécharger le projet sous forme d’archive depuis Paramètres du projet → Exporter, ou connecter GitHub et envoyer et récupérer les modifications vers votre propre dépôt ; les offres gratuites permettent de consulter le code en lecture seule, mais pas de l’exporter ni de le synchroniser. Les secrets et node_modules sont exclus des exports : recréez vos secrets sur le nouvel hébergeur. La documentation détaille les étapes dans exporter et exécuter ailleurs et GitHub, export et import. Vous pouvez aussi continuer à héberger sur Mythex et n’utiliser la synchro GitHub que comme copie personnelle et moyen de passation ; si vous déménagez, retirez l’application Mythex une fois le nouvel hébergeur en ligne.

Questions