Déployer une application Google AI Studio avec GitHub et un autre hébergeur

Google AI Studio peut générer une application web avec une interface React et du code serveur Node. Son aperçu ou son lien partagé permet de la tester, mais ne déploie pas ce code chez votre propre hébergeur. Google propose le déploiement sur Cloud Run ; si vous souhaitez gérer le code dans GitHub et le publier avec un autre fournisseur, vérifiez d’abord les éléments qui dépendent de Google.

Ce guide décrit le parcours documenté Google AI Studio → GitHub → Hostbrid Projects. Nous n’avons pas connecté de compte AI Studio ni publié l’application d’un client pour certifier une migration automatique ; chaque projet doit être testé séparément.

1. Vérifiez que vous avez créé une application web

Dans le mode Build, Google AI Studio peut créer une application web full-stack ou une application native Android. Ce parcours concerne l’application web. Si vous avez choisi Android, un hébergement web ne crée pas une application installable et ne la publie pas dans le Play Store.

Avant de déplacer quoi que ce soit, examinez le code et vérifiez que vous comprenez ses dépendances et son démarrage. Dans AI Studio, reliez le projet à GitHub depuis Settings → GitHub ou téléchargez le code sous forme de ZIP. La synchronisation GitHub est bidirectionnelle : les modifications peuvent aller d’AI Studio vers le dépôt et du dépôt vers AI Studio. Le ZIP contient du code à examiner localement ; ce n’est pas un envoi direct dans le panneau Projects.

2. Vérifiez les services dont l’application dépend

Ne transformez pas une application full-stack en site statique uniquement pour la faire compiler. Consultez package.json, repérez les scripts d’installation, de build et de démarrage, et vérifiez la présence de routes serveur, Firebase, authentification, stockage ou intégrations Google Workspace.

Projects publie des projets reliés à Git et propose aussi des services Node ou Docker, mais la documentation publique ne certifie pas de recette de migration automatique pour une application full-stack AI Studio. Un backend peut nécessiter de déployer séparément l’interface et le service, puis de vérifier leurs ressources et l’offre requise. Avant de vous engager, confirmez comment ses processus, routes et variables s’intègrent à l’architecture disponible. Cela ne configure pas non plus vos comptes externes : si vous utilisez Firebase, OAuth ou une base de données externe, vérifiez identifiants, domaines, règles et URL de retour depuis le nouveau domaine.

Si vous n’avez qu’une sortie HTML statique, consultez le guide de publication d’un site HTML créé par IA. Pour un processus Node, lisez aussi comment publier une application Node.js.

3. Reliez le dépôt à Projects

Si l’interface est statique ou si le projet dispose déjà d’une configuration de build compatible, connectez GitHub dans Hostbrid Projects et sélectionnez le dépôt. Définissez comme branche de production celle que vous souhaitez publier. Chaque push sur cette branche peut lancer un déploiement ; vérifiez aussi que la connexion GitHub est toujours autorisée. Si vous avez téléchargé un ZIP, extrayez-le d’abord, vérifiez .gitignore et les fichiers à envoyer — surtout .env — puis créez un dépôt Git ; Projects connecte des dépôts et n’accepte pas directement le ZIP.

Laissez Projects détecter le projet et vérifiez les paramètres avant le premier déploiement. Si nécessaire, définissez la commande d’installation, la commande de build, le dossier de sortie ou le sous-dossier du monorepo. Ne copiez pas de valeurs génériques sans vérifier les scripts réels. Pour une sortie statique, indiquez le dossier réellement créé par le build. Si l’application comprend des processus serveur, vérifiez quel service les exécute et comment ils se connectent à l’interface ; un build statique seul ne publie pas d’endpoints Node.

Après avoir publié l’interface et configuré séparément les services nécessaires, testez l’URL HTTPS, ouvrez directement une route interne et contrôlez les appels du navigateur vers le backend. Un build réussi ne prouve pas que OAuth, la base de données ou les appels Gemini fonctionnent en production.

4. Configurez la clé Gemini comme secret

AI Studio peut configurer GEMINI_API_KEY comme secret serveur. Ne supposez pas que ce réglage est transféré au nouvel hébergeur. Ajoutez la clé dans les variables d’environnement de Projects et lisez-la depuis le serveur. Ne la mettez pas dans le code React, une variable VITE_*, un fichier versionné dans Git ou les journaux.

Google précise que pour héberger ailleurs une application téléchargée en ZIP, il faut configurer GEMINI_API_KEY dans l’environnement d’hébergement. Les appels à l’API Gemini ont leurs propres limites et coûts éventuels ; changer d’hébergeur ne les supprime pas. Vérifiez aussi le comportement lorsque Google renvoie une erreur ou qu’un quota est atteint.

Si la clé se trouve déjà dans le JavaScript publié

Considérez toute clé serveur arrivée dans le navigateur comme compromise. Créez une clé de remplacement et mettez à jour le secret serveur ; déployez-la et vérifiez son fonctionnement, puis désactivez rapidement la clé exposée. En cas d’abus actif, désactivez-la immédiatement, même si l’application cesse de fonctionner jusqu’au déploiement du remplacement. Vérifiez l’activité, les quotas et la facturation : supprimer un fichier ou un commit n’invalide pas une clé copiée. Retirez-la du code frontend et des variables publiques. Vite intègre au bundle les valeurs préfixées par VITE_ : ce préfixe ne permet donc pas de conserver un secret.

Pour vérifier la correction, créez un nouveau build et inspectez les fichiers JavaScript et cartes de sources servis publiquement, ainsi que les requêtes réseau du navigateur. Recherchez localement l’ancienne clé ; ne la collez pas dans un scanner en ligne et ne la montrez pas dans une capture. Vérifiez que l’interface appelle votre serveur et que celui-ci lit le secret depuis une variable d’environnement Projects. Le backend doit valider les requêtes et limiter l’accès, la fréquence et l’usage ; un proxy ouvert ne ferait que transférer l’abus vers votre compte. Si la clé a été poussée dans Git, retirez-la aussi de l’historique et des journaux, tout en gardant la rotation comme mesure d’invalidation.

5. Testez les intégrations et reliez votre domaine

Testez l’application sur son domaine HTTPS temporaire avant de modifier le domaine définitif. Vérifiez la connexion, les URL de retour OAuth, la lecture et l’écriture des données, les autorisations, les fichiers téléversés et chaque appel Gemini. Si une intégration était connectée automatiquement dans AI Studio, testez-la à nouveau dans le nouvel environnement au lieu de supposer que sa configuration est conservée.

Une fois les tests réussis, reliez le domaine et vérifiez de nouveau le certificat HTTPS, les routes, les API et l’authentification. Si l’application requiert des services gérés, du réseau, du stockage ou une charge soutenue qui ne convient pas à Projects, comparez les offres et limites actuelles avant la migration.

Le résultat dépend du dépôt et de ses services. GitHub facilite le transfert et la vérification du code ; il ne copie pas automatiquement les secrets, utilisateurs, données, quotas d’API ni réglages OAuth.

Sources : Google AI Studio Build · Clés API Gemini · Variables d’environnement Vite · OWASP : gestion des secrets · Guide Projects de Hostbrid