Comment exporter et héberger soi-même une application créée par IA

Pour héberger soi-même une application créée par IA, sortez 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, déplacez ou recréez sa base de données, puis déployez-la sur un hébergeur qui correspond à ce qu'est l'application : un hébergeur statique pour une interface simple, ou une plateforme qui exécute 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, de toute façon

Il existe de bonnes raisons de garder 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 prix, ses fonctionnalités ou ses conditions.
• Transfert aux développeurs. Une équipe d'ingénierie voudra le code dans Git, avec ses outils habituels et son processus de révision.
• Exigences précises. Résidence des données, un fournisseur infonuagique particulier, politiques de sécurité de l'entreprise, ou infrastructure que le créateur n'offre pas.
• Mise à l'échelle ou coût à une taille où exploiter sa propre infrastructure rapporte réellement.

Moins bonnes raisons : déplacer une petite application avec quelques utilisateurs pour économiser un petit montant mensuel. L'auto-hébergement transfère du travail sur vos épaules : mises à jour, sauvegardes, surveillance, correctifs de sécurité. Ce peut être le bon compromis; faites-le simplement 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 une exportation

Avant de compter sur une exportation, ouvrez-la et vérifiez-la. En général :

Les secrets sont omis volontairement : une archive que vous pourriez envoyer par courriel ou valider dans Git ne devrait jamais contenir de clés actives. Les dépendances sont omises parce qu'elles sont reconstruites à partir du fichier de verrouillage.

Étape 1 : sortez le code

Deux voies courantes :

• Téléchargez une archive du projet. C'est rapide et suffisant pour un déplacement ponctuel ou une sauvegarde.
• Synchronisez vers GitHub. C'est préférable 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 infonuagique) et cherchez un fichier 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 exécuter ce projet hors de cette plateforme : la pile technologique, les versions d'exécution requises, les commandes d'installation et de compilation, la commande de démarrage et le port, chaque variable d'environnement lue par le code (noms et rôle, sans valeurs), et la façon d'exécuter les migrations de base de données.

Cette seule consigne vous fait gagner des heures, parce qu'elle force les parties implicites de la configuration à être écrites.

Étape 2 : faites-la tourner localement d'abord

Avant de la déployer quelque part, prouvez que l'application fonctionne seule :

1. Installez l'environnement d'exécution indiqué dans le README, par exemple Node.js, Python, Java ou .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, soit un Postgres local, soit une base de développement gratuite d'un fournisseur géré.
5. Exécutez les migrations, puis démarrez l'application et parcourez les principaux parcours.

Tout ce qui casse ici cassera aussi chez un hébergeur, et c'est beaucoup plus facile à déboguer sur votre propre machine. Surprises courantes : une URL codée en dur vers l'aperçu du créateur, une variable d'environnement manquante que le créateur injectait automatiquement, ou un service (stockage de fichiers, redimensionnement d'images) qui n'existait que sur la plateforme.

Étape 3 : déplacez les données

Si l'application a de vrais utilisateurs, les données comptent plus 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 d'accès direct, et de vous expliquer ce qu'elle a produit.
• Déplacez les fichiers téléversés. Si les utilisateurs ont téléversé des images ou des documents, ils sont dans un stockage d'objets distinct de la base de données. 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 production, l'approche simple consiste en une courte fenêtre de maintenance : arrêter les écritures, faire une dernière exportation, la restaurer sur le nouvel hébergeur, changer les DNS, puis rouvrir. Notez chaque étape d'abord.
• Testez une restauration dans une base de données temporaire avant le déménagement réel.

Si Postgres vous est inconnu, ce qu'est Postgres présente les notions de base.

Étape 4 : choisissez 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, et non un classement; vérifiez les fonctionnalités et les tarifs actuels sur leurs sites.

Vous aurez aussi besoin de :

• Une base de données gérée : beaucoup d'hébergeurs d'applications offrent Postgres, et des services dédiés comme Neon ou Supabase le fournissent seul. Un service géré en vaut la peine : les sauvegardes et les mises à jour deviennent la responsabilité de quelqu'un d'autre.
• Un stockage d'objets pour les téléversements, si l'application en a.
• L'envoi de courriels, les paiements et les fournisseurs d'IA : ceux-ci nécessitent généralement les mêmes clés d'API, configurées sur le nouvel hébergeur.

Soyons justes sur les compromis : les hébergeurs de plateforme (les quatre premières lignes) sont plus rapides à configurer 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 une charge stable et entièrement sous votre contrôle, mais vous êtes responsable des correctifs, du TLS, des sauvegardes, de la surveillance et de la reprise. Si personne dans l'équipe ne veut ce rôle, choisissez une plateforme. Pour les bases de ce que comprend l'hébergement, consultez ce qu'est l'hébergement web.

Étape 5 : déployez et basculez

1. Connectez le dépôt à l'hébergeur, ou poussez 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. Définissez les commandes de compilation et de démarrage ainsi que le port. Beaucoup d'hébergeurs transmettent le port dans une variable d'environnement PORT; l'application devrait l'écouter sur toutes les interfaces (0.0.0.0), et non seulement sur localhost.
4. Exécutez les migrations sur la nouvelle base de données.
5. Testez sur l'URL temporaire de l'hébergeur avant de toucher aux DNS.
6. Mettez à jour les services externes qui pointent vers votre ancienne URL : webhooks de paiement, URL de redirection OAuth pour la connexion, liens dans les courriels, origines autorisées.
7. Déplacez le domaine en modifiant les enregistrements DNS vers le nouvel hébergeur. Comment connecter un domaine personnalisé explique les enregistrements.
8. Gardez l'ancien déploiement en fonctionnement brièvement, jusqu'à ce que vous soyez certain, puis retirez-le.

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

Étape 6 : prenez en charge les opérations

Une fois l'auto-hébergement en place, ce que le créateur gérait devient votre responsabilité. Au minimum : sauvegardes automatiques de la base de données 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 faire passer un prototype IA en production détaille cette liste.

Liste de vérification de l'exportation

• Code dans un dépôt que vous possédez, avec un README couvrant l'exécution, la compilation et les variables d'environnement
• L'application fonctionne localement à partir d'un clone propre
• Base de données exportée et restauration testée; fichiers téléversés copiés
• Hébergeur choisi selon la forme de l'application, plus base de données et stockage gérés
• Toutes les variables d'environnement configurées avec les valeurs réelles sur le nouvel hébergeur
• Webhooks, redirections OAuth et liens de courriel mis à jour
• DNS basculés, ancien déploiement gardé brièvement, puis retiré
• Sauvegardes, surveillance et liste d'accès en place

Exporter depuis Mythex

Sur Mythex, vous possédez le code que vous créez. Avec le forfait Pro, vous pouvez télécharger le projet sous forme d'archive depuis Paramètres du projet → Exporter, ou connecter GitHub et pousser et tirer depuis votre propre dépôt; les forfaits gratuits permettent de consulter le code en lecture seule, mais pas de l'exporter ni de le synchroniser. Les secrets et node_modules sont omis des exportations : recréez donc vos secrets sur le nouvel hébergeur. La documentation couvre les étapes dans exporter et exécuter ailleurs et GitHub, exportation et importation. Vous pouvez aussi continuer à héberger sur Mythex et utiliser la synchronisation GitHub simplement comme votre propre copie et voie de transfert; si vous déménagez, dépubliez l'application Mythex une fois le nouvel hébergeur en ligne.

Questions