Déployer un projet de navigateur sur Vercel ou Netlify

Le cas évident est une machine où installer une CLI est peu pratique ou interdit. Un Chromebook, un ordinateur de salle de classe ou un poste d’entreprise verrouillé peuvent ouvrir un onglet, mais pas toujours installer Node.js, Git et la CLI du fournisseur. Un IDE de navigateur supprime déjà ces contraintes pour l’édition. Le déploiement est souvent la dernière étape qui renvoie le développeur vers un terminal ; le garder dans le même onglet ferme la boucle : le projet est édité, prévisualisé et publié sans toolchain local. Le second cas est la vitesse. Une landing page, un prototype ou une démo client peut avoir besoin d’une URL avant d’avoir besoin d’un dépôt ou d’un pipeline CI. Le panneau publie l’instantané courant et indique où il est en ligne. Cette commodité a une limite. Il s’agit d’un envoi direct, pas d’un pipeline de déploiement. Il ne surveille pas une branche, n’exécute pas de tests et ne promeut pas de builds entre environnements ; ces tâches relèvent de l’intégration Git ou de la CI. Le chemin navigateur sert à la première URL, pas à tout le processus de release.

La boîte de dialogue Deploy est une fine couche de contrôle au-dessus de deux API. Quand vous cliquez sur Deploy now, GB Coder construit le même paquet de fichiers que Download ZIP. Ce détail compte : il n’existe pas de second chemin d’empaquetage qui pourrait omettre une feuille de style ou oublier une bibliothèque externe. Un projet simple devient index.html, style.css, script.js et un README. Un projet React ou Vue devient une arborescence Vite avec index.html, package.json, vite.config.js, .gitignore, un README et les sources sous src/. Le résumé affiche le nombre exact de fichiers et la taille non compressée avant que quoi que ce soit ne quitte l’onglet. Vercel reçoit les fichiers en JSON inline sur son endpoint de déploiement. Netlify reçoit un ZIP comme corps brut de la requête. Vercel construit ou sert le projet ; Netlify publie les fichiers envoyés comme déploiement manuel. Aucun serveur LadeStack ne s’intercale et aucune CLI ne tourne sur votre machine. Le navigateur est le client, le fournisseur est l’hôte et le jeton est le seul identifiant. Un clic décrit l’interface, pas le travail : empaquetage, envoi, traitement distant et TLS se succèdent toujours.

Le paquet diffère parce que les deux types de projet demandent un traitement différent. Un projet HTML/CSS/JavaScript simple n’a pas de package.json. Vercel reçoit l’instruction de n’utiliser aucun framework et sert les fichiers en statique. Netlify publie le ZIP tel quel, ce qui convient aussi aux fichiers statiques. Il n’y a rien à installer ni à compiler, donc le premier déploiement est généralement rapide. Un projet React ou Vue contient un package.json généré, une configuration Vite et des sources. Sur Vercel, le fournisseur détecte Vite, installe les dépendances, lance le build de production et publie la sortie. C’est un vrai build cloud, pas une simulation dans le navigateur, et c’est pourquoi il peut prendre une minute ou plus. Vercel utilise aussi les versions enregistrées dans package.json, pas ce qui se trouvait dans l’éditeur. Le déploiement ZIP manuel de Netlify n’exécute pas de commande de build : la même arborescence source Vite est publiée telle qu’elle a été envoyée, sans compilation. Pour React ou Vue sur Netlify, utilisez l’intégration Git du fournisseur ; le parcours en un clic de Netlify ne publie que des fichiers statiques. Les bibliothèques externes et les réglages d’injection sont déjà dans le paquet. Si un build Vercel dépend d’un paquet privé, d’un binaire natif ou d’un service inaccessible depuis son image de build, le build échouera même si la prévisualisation fonctionne. Les logs indiquent dans quel cas vous êtes.

Les deux fournisseurs s’authentifient avec un jeton d’accès personnel. Ce n’est ni votre mot de passe de fournisseur ni un compte GB Coder. La boîte de dialogue renvoie vers la page de jetons du fournisseur choisi et explique la portée en termes simples. Un jeton Vercel peut publier sur tous les projets accessibles au compte ou à l’équipe ; lorsqu’un jeton limité à l’équipe existe, utilisez-le. Un jeton Netlify agit sur les sites accessibles au compte ; traitez-le donc comme global, sauf option plus restrictive. Créez le jeton pour cet usage, donnez-lui la durée de vie la plus courte possible et révoquez-le lorsque le projet n’en a plus besoin. GB Coder vérifie qu’un jeton est présent et que le paquet respecte les limites locales avant d’activer Deploy now. Le jeton reste en mémoire pour l’onglet par défaut. Remember on this device est une option : sur une origine sécurisée, le jeton est scellé avec AES-GCM avant d’être écrit dans localStorage ; sinon, la boîte de dialogue avertit qu’il serait stocké en clair. La portée et la révocation sont les contrôles les plus importants.

Ouvrez un projet, puis choisissez Deploy dans la barre d’outils ; sur un écran étroit, il se trouve dans le menu de débordement. Vercel est sélectionné par défaut, Netlify est à un clic. Le nom du projet est prérempli. GB Coder le passe en minuscules, remplace les caractères invalides par des tirets et affiche le nom d’hôte demandé, par exemple votre-projet.vercel.app. Collez le jeton, choisissez de le mémoriser ou non et vérifiez le résumé du paquet. Si le nombre de fichiers ou la taille dépasse la limite, la boîte de dialogue explique le problème et laisse le bouton désactivé. Cliquez sur Deploy now. Le fournisseur crée le projet ou le site, reçoit le paquet et commence à traiter le déploiement. Une fois le déploiement prêt, l’écran de succès affiche l’URL publique, le nombre de fichiers, la taille envoyée, le temps écoulé et un QR code pour ouvrir la page sur téléphone. Copy URL et Visit site servent au transfert, et Build logs ouvre les logs du fournisseur. Les noms de site Netlify sont globaux : un nom demandé peut donc être pris. Le fournisseur en attribue un autre et GB Coder indique l’adresse réellement en ligne, pas celle que vous avez saisie.

La barre de progression traverse l’empaquetage, l’envoi, le build, la sécurisation et l’état prêt. Sur Netlify, le libellé de build correspond au traitement du fournisseur, pas à une commande de build. C’est un rapport du client, pas une prédiction du fournisseur. Le pourcentage progresse pendant les deux premières phases puis reste sous 100 pendant que le fournisseur termine le travail distant. C’est volontaire : le travail distant peut prendre un temps imprévisible, et une barre qui filerait à 99 % mentirait. GB Coder interroge le fournisseur toutes les secondes et demie et met le message à jour lorsque l’état change. Une requête d’envoi a un délai limite de deux minutes. Le panneau cesse d’attendre après trois minutes de suivi du déploiement et renvoie vers le tableau de bord, car le déploiement peut encore se terminer alors que le navigateur ne regarde plus. Annuler, fermer la boîte de dialogue ou appuyer sur Échap interrompt la requête en cours et la boucle de suivi. Si le fournisseur a déjà accepté le déploiement, le déploiement peut continuer de son côté ; vérifiez le tableau de bord avant de supposer qu’annuler équivaut à un rollback. Les logs du fournisseur sont la source fiable lorsqu’un déploiement échoue.

Deploy again revient au formulaire ; il ne renvoie pas immédiatement le dernier paquet. C’est utile lorsque le projet a changé, que le nom doit être ajusté ou que le jeton a expiré. Vercel et Netlify empruntent ensuite des routes différentes vers la même adresse. Vercel crée un déploiement pour le projet nommé et cible la production. Les déploiements répétés avec le même nom mettent ce projet à jour, et l’alias de production est préféré à l’URL spécifique du déploiement, de sorte que l’adresse partagée reste normalement stable. Netlify a besoin d’un identifiant de site pour mettre à jour un site existant au lieu d’en créer un autre. GB Coder mémorise cet identifiant dans localStorage, associé au nom nettoyé. Si vous effacez le stockage du navigateur, changez de navigateur, modifiez le nom ou supprimez le site dans Netlify, le déploiement suivant ne retrouve pas l’ancien site et en crée un nouveau. C’est pourquoi renommer un projet Netlify peut laisser l’ancien site dans le compte. Les deux fournisseurs conservent l’historique, les domaines personnalisés, les contrôles d’accès et le rollback dans leurs tableaux de bord ; le panneau GB Coder n’expose que l’envoi et l’URL publique. Chaque déploiement ici est un déploiement de production ; il n’y a ni preview de branche ni sélecteur d’environnement.

Deux limites s’appliquent avant que la requête ne quitte l’onglet : 900 fichiers et 64 Mo de contenu non compressé. Elles restent sous les plafonds des fournisseurs pour qu’un envoi volumineux n’échoue pas au milieu d’une session de navigateur. Un site riche en médias devrait garder les grandes images et vidéos sur un CDN ou dans Git, pas dans le paquet du projet. Les erreurs sont séparées par cause. Un 401 signifie que le jeton a été refusé ; un 403 indique généralement un manque de droits sur le compte ou l’équipe ; un 413 ou 429 signifie que la charge est trop lourde ou que le fournisseur limite le débit ; un 422 signifie que le projet a été rejeté comme invalide ; un 5xx est généralement temporaire. Sur Vercel, un échec de build de framework est différent : l’envoi a réussi et le build a échoué, donc lisez les logs au lieu de coller un nouveau jeton. Un build Vercel qui a besoin de variables d’environnement est une autre frontière. La boîte de dialogue n’a pas d’éditeur pour cela. Définissez-les dans les paramètres du projet Vercel et redéployez ; le premier build peut échouer avant que le projet n’existe. Le déploiement ZIP manuel de Netlify n’a pas d’étape de build, donc cela ne s’y applique pas. Une limite de suivi de trois minutes n’est pas un déploiement échoué, seulement une attente interrompue.

Le déploiement est direct : le navigateur appelle api.vercel.com ou api.netlify.com avec votre jeton. Aucun proxy ne stocke l’identifiant et aucun compte LadeStack n’est requis pour utiliser le panneau. Les jetons sont limités à la session par défaut et ne sont scellés avec AES-GCM que si vous choisissez d’en mémoriser un sur une origine sécurisée. Cela protège contre un jeton lisible dans une sauvegarde de profil ou un bundle de support, mais pas contre du code malveillant sur la même origine tant que l’onglet est ouvert. Utilisez le jeton le plus restreint disponible, fixez une expiration et révoquez-le chez le fournisseur lorsque le travail est terminé. La propriété suit le jeton : le projet ou le site est créé dans le compte fournisseur qui le possède, selon ses conditions, quotas, logs et facturation. GB Coder reste local-first, mais déployer est une exportation explicite du projet vers le fournisseur. Le fournisseur reçoit la source du site et le résultat est une URL HTTPS publique par défaut ; protection par mot de passe, SSO et domaines personnalisés sont des fonctions du fournisseur. Conservez un ZIP ou une copie GitHub si le profil du navigateur est le seul autre endroit où le projet existe.

Utilisez ce chemin pour mettre rapidement en ligne un petit site : landing page, portfolio, démo de cours, prototype pour une revue client ou page de documentation statique. Il convient aussi lorsque le projet vit déjà dans GB Coder et que l’alternative consiste à exporter un ZIP, ouvrir un terminal et configurer une CLI sur une machine qui n’est pas la vôtre. Il convient mal à un monorepo, une application rendue côté serveur avec base de données, un build nécessitant des identifiants de registre privé, une équipe qui publie via des previews de branche et des approbations, ou des assets dépassant les limites d’envoi. Ces tâches relèvent de l’intégration Git du fournisseur, d’un pipeline CI ou d’un environnement de bureau. Les deux approches peuvent coexister : concevoir et itérer dans le navigateur, pousser la source vers GitHub lorsqu’elle mérite un historique, et laisser la CI publier le build de production. Une routine pratique : tester la prévisualisation en largeur téléphone, vérifier le résumé du paquet, déployer, ouvrir l’URL sur un second appareil et conserver le log. Pour essayer, ouvrez le tableau de bord des projets sur /app/projects, créez ou ouvrez un projet et choisissez Deploy. La référence de configuration se trouve dans la documentation.