Peut-on exporter le code d’un générateur de sites IA ?

Peut-on exporter le code d’un générateur de sites IA ?

Oui, chez Zugo. L’intégration GitHub envoie le code source du projet dans votre dépôt, et l’intégration Vercel permet ensuite de le déployer sur votre propre compte d’hébergement. L’export ne coûte aucun crédit. Ce n’est pas une formalité de sortie : c’est ce qui décide si votre projet reste transportable le jour où vous en aurez besoin.

La question mérite mieux qu’un oui, parce que la vraie inquiétude derrière n’est presque jamais technique. Ce que les gens veulent savoir, c’est s’ils construisent quelque chose qui leur appartient ou s’ils louent une page qui disparaîtra avec l’abonnement.

Que contient exactement l’export du code ?

Le projet tel qu’il est publié. Les fichiers de la page ou de l’application, les feuilles de style, les scripts, la structure des pages et les ressources qui vont avec. C’est le même ensemble que celui qui tourne sur votre-slug.zugo.run, déposé dans un dépôt que vous contrôlez.

Ce que l’export ne contient pas mérite d’être dit aussi clairement. Il n’emporte ni l’agent qui a produit le code, ni votre historique de descriptions, ni le mécanisme qui transforme une phrase en modification. Ces choses vivent du côté de l’outil et n’ont pas d’existence dans un dépôt Git. Vous récupérez le résultat, pas la machine à résultats.

C’est une distinction banale une fois posée, mais elle explique une déception fréquente. Quelqu’un exporte, ouvre le dépôt et cherche l’endroit où retaper une phrase pour changer la page. Cet endroit n’existe plus : après l’export, une modification redevient une modification de code, avec les outils et les compétences que cela suppose.

Pourquoi l’export compte-t-il avant même de vouloir partir ?

Parce qu’un projet qui ne s’exporte pas n’est pas un projet, c’est une location. Tant que le code ne peut pas sortir, chaque décision que vous prenez vous attache un peu plus à un prestataire unique, et la valeur de ce que vous avez construit dépend entièrement de sa politique tarifaire.

L’export change la nature de la relation même si vous ne l’utilisez jamais. Vous restez parce que l’outil vous fait gagner du temps, pas parce que vous êtes coincé. Pour une activité indépendante ou une petite structure, cette différence pèse plus lourd que n’importe quelle fonctionnalité, parce qu’elle protège le travail accumulé plutôt que le confort du mois en cours.

Il y a aussi un usage prosaïque : montrer le dépôt à quelqu’un. Un développeur consulté pour un devis, un associé technique, un client qui demande où vivra le code. Pouvoir répondre par un lien vers un dépôt ferme la discussion en une minute.

Combien l’export coûte-t-il en crédits ?

Rien. Les crédits paient la génération et la modification, pas la sortie ni la publication. Voici le tableau complet, parce que c’est la seule façon d’estimer un budget sans se tromper.

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

Retenez surtout que l’export ne pénalise pas votre budget. Vous pouvez le déclencher pendant que vous continuez à travailler dans l’outil, sans arbitrage à faire entre les deux.

Où va le code une fois exporté ?

Dans votre dépôt GitHub, et à partir de là, où vous voulez. Le chemin le plus court consiste à brancher Vercel et à déployer sur votre propre compte : l’hébergement passe alors sous votre contrôle, avec vos accès et votre facturation.

Le second chemin consiste à confier le dépôt à quelqu’un. C’est le scénario le plus fréquent quand un projet dépasse ce qu’un générateur fait bien : la logique métier devient trop spécifique, les demandes s’accumulent, et il devient moins cher de payer une reprise que d’enchaîner les modifications. Un développeur peut-il reprendre un projet créé par IA détaille comment se passe cette passation.

Le troisième chemin est celui qu’on oublie : garder le dépôt sans rien en faire. C’est une sauvegarde. Le code y reste lisible, daté, récupérable, et vous n’avez pas à décider aujourd’hui de ce que vous ferez dans un an.

Faut-il exporter tout de suite ou attendre ?

Attendez que le contenu soit stable. Exporter au bout de la première construction produit un dépôt qui sera périmé après trois modifications, et vous obligera soit à réexporter, soit à tenir deux versions divergentes du même projet.

Le bon moment ressemble à ceci : les textes sont écrits, les images sont les bonnes, la structure des pages ne bouge plus, et vos changements suivants relèvent de la retouche. À ce stade, le dépôt représente vraiment le projet et pas une étape intermédiaire.

Il existe une exception nette. Si le projet est destiné à un client qui paie et qui a demandé le code dans son contrat, exportez dès que la livraison est acceptée, pas plus tard. Un engagement pris se tient au moment où l’on s’en souvient encore.

Que perdez-vous en quittant l’outil ?

Quatre choses, et il vaut mieux les connaître avant de couper l’abonnement plutôt qu’après.

La perte la plus concrète est la première ligne de la colonne de droite. Dans l’outil, changer un titre coûte 3 crédits et une phrase. Après l’export, c’est une modification de fichier, un commit et un déploiement. Ce n’est pas dramatique pour qui sait le faire, et c’est un mur pour qui ne sait pas.

La vérification en bac à sable disparaît elle aussi. Avant de vous livrer une construction, Zugo la lance pour vérifier qu’elle s’ouvre, et une construction qui ne s’ouvre pas n’est pas remise. Une fois le code chez vous, plus personne ne fait ce contrôle à votre place : c’est votre déploiement, donc votre relecture.

Comment décider entre rester et exporter ?

En regardant ce que vous prévoyez de faire les six prochains mois, pas ce que vous ressentez aujourd’hui.

Si vos changements à venir sont du contenu, des pages en plus, des retouches de mise en page et des ajustements de textes, rester coûte moins cher en temps comme en argent. Une modification à 3 crédits reste imbattable face à une intervention facturée à l’heure, et comment modifier un site après sa génération montre comment enchaîner ces retouches sans gaspiller.

Si vos changements à venir touchent des règles de gestion précises, des calculs particuliers, une intégration inhabituelle ou un volume de données important, exportez et faites reprendre. Zugo ne remplace pas une équipe de développement sur un produit complexe, et le nier vous coûterait plus cher que l’export.

Le cas mixte est le plus courant : le site vitrine reste dans l’outil, la partie applicative part chez un développeur. Rien n’oblige à traiter les deux de la même façon.

Quelles sont les limites honnêtes de l’export ?

Trois, dites sans détour.

L’export vous donne du code, pas de la maintenance. Une fois le dépôt chez vous, personne ne surveille les dépendances, les correctifs ou la disponibilité de l’hébergement. Beaucoup de gens confondent posséder et entretenir, et découvrent la différence au premier incident.

L’export ne rend pas autonome quelqu’un qui ne lit pas de code. C’est une assurance, pas une compétence. Si vous n’avez personne pour ouvrir ce dépôt, sa valeur est réelle mais différée : elle se déclenche le jour où vous engagez quelqu’un, et faut-il savoir coder pour utiliser un générateur IA situe ce qui reste faisable sans cette compétence.

Enfin, la forme du projet ne change pas en sortant. Un jeu généré est un jeu 2D qui tourne dans le navigateur, et il le reste après export : le dépôt ne le transforme pas en projet natif. La même logique vaut pour tout le reste, l’export déplace le code, il ne le réécrit pas.

Par où commencer ?

Construisez d’abord, exportez quand le projet mérite d’être figé. Cet ordre évite les dépôts fantômes remplis de versions abandonnées, et il vous laisse profiter de la vitesse de l’outil tant que le projet bouge encore.

Le jour où l’export devient utile, branchez GitHub, envoyez le code, et vérifiez que le dépôt s’ouvre bien chez vous avant de considérer l’affaire réglée. Vous pouvez tester tout le parcours sur zugo.dev avec le plan gratuit, puis décider en connaissance de cause si votre projet reste dans l’outil ou continue ailleurs.