Avant d’héberger un site IA ou Lovable : inventorier le dépôt

Un code présent dans Git ne répond pas encore à une question d’achat : que faut-il maintenir en fonctionnement ? Un site peut servir des fichiers statiques, exécuter un serveur ou dépendre de services externes malgré une page d’accueil simple.

Inventoriez le dépôt avant de choisir un plan. Le résultat utile liste composants, responsabilités et preuves manquantes. Cette méthode utilise un outil original sous MIT, avec 12 tests locaux vérifiés sous Node 22.23.3. Ses cas sont des manifestes synthétiques, pas des exportations réelles de Lovable ni des applications construites.

Si le dépôt vient de Lovable et que vous souhaitez l’héberger ailleurs, le guide pour héberger une app Lovable hors de la plateforme explique ce qui peut rester sur Lovable Cloud et ce qui exige une migration distincte.

Partir du projet concret

Selon la documentation Lovable, les projets créés depuis le 13 mai 2026 utilisent TanStack Start avec code serveur ; les précédents utilisent React et Vite avec sortie statique.

Ne décidez pas d’après le nom « React » ou une date seule. Notez commit, branche et sous-dossier ; examinez package.json, fichier de verrouillage, configuration et entrées serveur. Dans un monorepo, le manifeste racine peut décrire des outils de développement plutôt que l’application à publier. Identifiez son dossier.

Pour conserver une copie du code sous votre contrôle, consultez Git sync de Lovable. Une copie du code ne prouve pas que l’authentification, les données ou les fichiers externes soient inclus et fonctionnels.

Exécuter un inventaire limité

Utilisez Node 22.23.3, version testée, et conservez la licence. L’outil n’a ni dépendance externe ni fichier de verrouillage ; npm ci n’est pas nécessaire. Les manifestes de test contiennent des versions et commandes de repérage : n’installez pas leurs dépendances et n’exécutez pas leurs scripts.

git clone https://github.com/ocentelles/hostbrid-example-inventory.git
cd hostbrid-example-inventory
git checkout 150c8d09ea2fe0b511dbeac5cdd89e182d7f9b47
node --version
node --test test.mjs
node inventory.mjs fixtures/static
node inventory.mjs fixtures/external
node inventory.mjs fixtures/server
node inventory.mjs fixtures/ambiguous

node --version doit afficher v22.23.3 ; les tests doivent se terminer avec 12 réussites. Ces quatre cas produisent les candidats static, static avec indice de client externe, server et indeterminate. Un cinquième cas JSON malformé donne erreur et sortie non nulle : test négatif, pas application à installer.

Sur une copie stable, fiable et propre d’un dépôt vous appartenant :

node inventory.mjs /path/to/own/repository

Remplacez le chemin d’exemple par le vôtre. L’outil en ligne de commande (CLI) lit package.json à la racine jusqu’à 256 KiB et vérifie la présence d’une liste autorisée de noms de configuration. Il ne parcourt pas les dossiers, n’exécute pas les scripts, ne lit ni .env ni contenu du code ou de la configuration, ne contacte aucun service et n’envoie aucune donnée.

Lire le résultat comme une hypothèse

Extrait des champs du cas statique synthétique :

{
  "candidate": "static",
  "scripts_executed": false,
  "build_verified": false,
  "env_files_read": false,
  "source_contents_read": false
}

static et server sont des candidats fondés sur des indices. build_verified:false indique explicitement la preuve absente. indeterminate est utile lorsque l’information manque : ne forcez pas un achat statique pour masquer le doute.

Un Dockerfile ne prouve pas ce qui s’exécute dedans. Vite peut participer à une application serveur ; Next peut exporter du statique malgré un indice serveur conservateur. Adaptateur Astro, configuration renommée ou paquets chargés dynamiquement peuvent échapper à l’analyse. L’outil ne lit pas les commandes pour les classer et n’inspecte pas les sous-projets.

Séparer trois couches avant l’hébergement

Couche	Question à résoudre	Preuve suivante
Sortie web	Quels fichiers et quelles routes doivent fonctionner ?	Build propre, routes directes, fichiers associés et cas 404.
Processus serveur	Que faut-il garder actif pour les requêtes ?	Entrée de production, port, santé, variables et arrêt.
Backend externe	Qui exploite authentification, données, fichiers et fonctions ?	Inventaire des services et tests de chaque dépendance.

Un indice de client Supabase ne prouve pas un backend migré. Un frontend statique peut appeler un backend externe : coût et exploitation de ce service restent dans l’inventaire. Le guide officiel d’hébergement externe sépare frontend et backend ; déplacer PostgreSQL seul ne déplace pas authentification, storage, realtime ou Edge Functions.

Pour identifier Cloud géré ou votre propre Supabase, ouvrez les réglages Cloud : l’icône existe dans les deux cas. Lovable Cloud n’apparaît pas dans votre tableau de bord Supabase personnel. Suivez le diagnostic officiel du backend. Le CLI ne consulte pas ces réglages et n’identifie pas le compte propriétaire ; ne partagez ni tokens ni journaux.

Si vous conservez le backend, testez origines et callbacks, sessions, accès autorisés, objets privés et fonctions depuis le nouvel environnement. Pour envisager un transfert, ajoutez sauvegarde, restauration, comparaison et retour arrière ; conservez l’origine jusqu’à vérification. Ce sont des tâches à réaliser, pas des parcours démontrés par le CLI.

Le rapport n’est pas un audit de secrets

La sortie omet versions, commandes, chemins du projet et contenus ; le manifeste reste analysé en mémoire et certains noms affichés peuvent révéler des informations. Relisez le rapport avant partage. Ne collez pas .env, tokens, exportations de clients ou journaux complets dans une demande d’hébergement.

L’outil ne certifie ni absence de secrets, vulnérabilités ou dépendances. Il ne protège pas d’un système de fichiers hostile. Les clés Supabase distinguent publicables et secrètes : une clé privilégiée n’appartient pas au navigateur. Une revue supplémentaire du vrai code et de la sortie construite est nécessaire.

Transformer l’inventaire en décision

L’hébergement statique dans Projects est une option à examiner après vérification de la sortie statique. Pour un processus permanent, examinez les services Projects, un plan incluant des services avec quota disponible, environnement d’exécution et limites. Un VPS peut convenir pour contrôler le système et assumer mises à jour, réseau, suivi et sauvegardes. Cet inventaire ne démontre ni compatibilité TanStack, migration automatique ou services Docker gratuits.

Examinez les coûts par composant : hébergement, backend conservé, courrier, IA, domaine et exploitation. Après diagnostic, suivez la recette React statique, les contrôles serveur Node ou le diagnostic de formulaires selon les besoins réels. Ces étapes sont distinctes ; un cas synthétique ne remplace pas leurs tests.