Créateur d'app IA avec Vercel : déployer sur votre compte

Créateur d'app IA avec Vercel : ce qui se branche vraiment

Oui, un projet généré sur Zugo peut partir sur votre propre compte Vercel. Zugo le publie d'abord sur votre-slug.zugo.run, puis l'intégration Vercel l'envoie chez vous, sous votre compte et votre facturation d'hébergement. Brancher Vercel ne dépense aucun crédit : les crédits paient la génération, pas la mise en ligne.

Reste à savoir ce que cette bascule apporte concrètement, et à quel moment elle devient utile plutôt qu'une case de plus à cocher. C'est tout l'objet de ce qui suit.

Que fait exactement l'intégration Vercel ?

Elle déplace l'hébergement du projet vers un compte que vous contrôlez. Avant, le site tourne sur l'infrastructure de Zugo, à une adresse en .zugo.run. Après, il tourne chez Vercel, dans un projet qui apparaît dans votre tableau de bord, avec vos réglages et vos éventuels collaborateurs.

Cette nuance compte parce qu'elle change le propriétaire de la mise en ligne. Tant que le projet vit sur .zugo.run, la publication dépend de Zugo. Une fois déployé sur votre compte, l'hébergement dépend de vous : vous voyez les journaux, vous gérez les domaines à ce niveau, vous décidez quand redéployer.

Pour un projet de test, cette autonomie n'apporte rien. Pour un projet qui commence à recevoir de vrais visiteurs, elle devient rassurante : la partie la plus visible de votre activité ne repose plus sur un compte que vous ne facturez pas vous même. C'est le même raisonnement que pour connecter votre propre domaine, et les deux étapes vont souvent ensemble.

Faut-il passer par GitHub avant de déployer sur Vercel ?

Les deux intégrations répondent à des besoins voisins mais distincts, et les confondre fait perdre du temps. GitHub sert à récupérer le code source dans un dépôt qui vous appartient. Vercel sert à faire tourner le résultat sur votre hébergement.

Vous pouvez vouloir l'un sans l'autre. Quelqu'un qui souhaite juste maîtriser sa production n'a pas forcément besoin de lire le code. À l'inverse, une personne qui veut archiver son projet ou le confier à un développeur a besoin du dépôt, pas nécessairement d'un changement d'hébergeur.

Dans la pratique, l'ordre le plus confortable reste : export GitHub d'abord, déploiement Vercel ensuite. Le code se retrouve à un endroit stable, et Vercel se comporte alors avec ce dépôt comme avec n'importe quel autre projet, ce qui est son fonctionnement habituel et pas une particularité de Zugo. Le sujet est détaillé dans récupérer le code de votre projet.

Combien de crédits coûte un déploiement ?

Zéro. Les crédits sont la monnaie de la génération, et il vaut mieux avoir le tableau complet en tête avant de planifier un budget.

Le plan gratuit donne 5 crédits, soit moins qu'une construction complète, donc il sert à essayer l'outil plus qu'à finir un projet. Pro coûte $25 par mois pour 200 crédits, ce qui représente environ 33 constructions, ou 66 modifications, ou 16 plateformes multipages. Business coûte $99 par mois pour 800 crédits.

Ce que Vercel facture de son côté dépend de votre compte chez eux et de votre trafic. C'est une dépense séparée, comme le prix du nom de domaine chez votre registraire. Elle ne passe jamais par les crédits.

Qu'est-ce que cela change au quotidien ?

Trois choses, dans l'ordre où vous les remarquerez.

La première est la visibilité. Vous voyez les déploiements et leur historique dans votre tableau de bord, donc quand une page se comporte bizarrement vous savez quand elle a changé pour la dernière fois. Cette information manque cruellement quand on cherche l'origine d'une régression.

La deuxième est le partage des accès. Une équipe, même de deux personnes, peut travailler sur le même projet d'hébergement sans se passer un mot de passe unique. C'est banal jusqu'au jour où la personne qui détient le compte part en vacances au mauvais moment.

La troisième est la réversibilité. Un projet dont le code vit sur GitHub et l'hébergement chez Vercel ne dépend plus d'un seul fournisseur pour exister. Vous pouvez continuer à générer des modifications sur Zugo, ou tout reprendre à la main, sans avoir à tout refaire.

Quelles limites faut-il connaître avant de brancher Vercel ?

Elles méritent d'être dites franchement, parce qu'elles décident souvent du calendrier.

Déployer chez vous vous rend responsable de ce qui tourne chez vous. Les quotas, la facturation de bande passante, les variables d'environnement, les certificats liés à vos domaines : tout cela devient votre terrain. Ce n'est pas difficile, mais ce n'est plus automatique.

Ensuite, la vérification en bac à sable que fait Zugo avant de vous livrer un projet porte sur la construction générée. Zugo lance le projet dans un environnement isolé et ne le remet pas s'il ne s'ouvre pas. Cette garantie ne s'étend pas aux réglages que vous modifiez ensuite dans votre propre compte d'hébergement.

Enfin, Zugo ne remplace pas une équipe de développement sur un produit complexe. Un hébergement à vous ne change rien à cette limite : une logique métier très spécifique se construit par modifications successives, et à un certain point il devient plus rationnel de continuer le code à la main. Les jeux, eux, restent générés en 2D et tournent dans le navigateur, quel que soit l'endroit où ils sont déployés.

Vercel, GitHub ou le lien .zugo.run : lequel utiliser quand ?

La bonne réponse dépend de la phase du projet, pas d'une préférence technique.

La séquence qui provoque le moins de complications suit cet ordre de haut en bas. Beaucoup de gens font l'inverse : ils branchent l'hébergement définitif avant d'avoir stabilisé le contenu, puis passent leurs deux premières semaines à redéployer des versions intermédiaires que personne n'attendait.

Une petite vitrine locale, un menu de restaurant, une page de réservation : ces projets vivent très bien sur le lien fourni plus un domaine, sans jamais toucher à Vercel. Le déploiement chez vous prend son sens quand plusieurs personnes interviennent, ou quand le site porte un chiffre d'affaires.

Comment vérifier que le déploiement s'est bien passé ?

Ouvrez les deux adresses côte à côte. Si le contenu diffère, ce n'est pas un bug mystérieux : c'est que les deux versions ne datent pas du même moment. Ce réflexe économise des heures de recherche dans la mauvaise direction.

Regardez ensuite le site sur un téléphone et sur un autre réseau que le vôtre. Les surprises apparaissent presque toujours à ce moment, pas sur l'écran où vous avez travaillé. Vérifiez aussi les formulaires, qui sont la partie la plus souvent oubliée lors d'un changement d'hébergement.

Enfin, notez quelque part la date du déploiement et ce que vous veniez de changer. Deux lignes suffisent. Le jour où un visiteur vous signale un problème, cette note vaut plus qu'une heure d'exploration à l'aveugle.

Par où commencer ?

Construisez d'abord, déployez ensuite. Générez le projet, corrigez le contenu par modifications tant qu'il bouge encore, et gardez le lien .zugo.run pendant toute cette phase : il existe exactement pour ça.

Quand le résultat vous convient, exportez le code vers GitHub, branchez Vercel, puis pointez votre domaine. Trois étapes, dans cet ordre, et vous obtenez un projet dont vous détenez le code, l'hébergement et le nom. Si vous partez de zéro, créer une application sans code reprend le parcours depuis la première description. Vous pouvez commencer sur zugo.dev avec le plan gratuit et ne brancher l'hébergement que le jour où le projet le mérite.