Créateur d'app IA avec GitHub : exporter le code source

Créateur d'app IA avec GitHub : exporter le code source

Oui : un projet construit sur Zugo s'exporte vers votre dépôt GitHub. Vous récupérez du vrai code source, pas une archive figée dans un format maison. L'export ne coupe rien au passage : le projet publié continue de vivre sur son adresse en .zugo.run, et vous gardez la possibilité de le corriger au chat comme avant.

Cette double vie mérite d'être expliquée avant de parler de dépôt, de branche ou de commit, parce que c'est elle qui décide du bon moment pour brancher GitHub.

Qu'est-ce qui part réellement dans le dépôt ?

Le code du projet, dans l'état où la génération et vos corrections successives l'ont laissé. Pas une capture, pas une page HTML aplatie, pas un fichier lisible seulement par l'outil qui l'a produit. Un développeur ouvre le dépôt et retrouve une base de code qu'il peut lire.

C'est la différence pratique entre un générateur qui garde tout chez lui et un générateur qui accepte de vous rendre la matière première. Tant que le code reste enfermé, votre marge de manoeuvre s'arrête à ce que l'interface propose. Une fois le dépôt en place, elle s'arrête à ce que votre équipe sait faire.

Il faut nommer la nuance tout de suite : l'intégration décrite ici est un export vers votre dépôt. Si vous modifiez ensuite les fichiers à la main, ces changements vivent chez vous et deviennent votre responsabilité. La question de la propriété du résultat est traitée à part dans à qui appartient un site généré par IA.

Pourquoi exporter si le projet fonctionne déjà ?

Quatre raisons reviennent, et aucune n'est technique au sens strict.

La sortie de secours d'abord. Un projet dont le code existe ailleurs que dans un seul compte ne dépend plus de la longévité de ce compte. C'est le genre de précaution qui ne sert à rien pendant deux ans, puis qui sert énormément un mardi matin.

Le passage de relais ensuite. Le jour où un développeur reprend le dossier, la première question qu'il pose est toujours la même : où est le code. Un lien de dépôt répond en une seconde, une explication sur l'outil utilisé ne répond pas.

La relecture par un tiers. Un prestataire, un associé technique ou un futur repreneur peuvent regarder ce qu'ils achètent ou ce qu'ils reprennent. C'est plus honnête pour tout le monde qu'une démonstration en direct.

La sauvegarde enfin, qui recoupe le sujet plus large des copies de sécurité, détaillé dans comment sauvegarder un projet créé avec l'IA.

Quand faut-il brancher GitHub dans le projet ?

Plus tard que la plupart des gens ne le pensent. Le bon repère n'est pas la date, c'est la stabilité du contenu.

Tant que vous cherchez encore la bonne structure de pages ou le bon discours, le chemin le plus rapide reste la correction au chat : vous décrivez le changement, une modification à 3 crédits l'applique, et le résultat est vérifié avant de vous être rendu. Personne ne gagne de temps à faire ce travail à la main dans un éditeur.

Le moment bascule quand vous commencez à demander des choses très précises que la description en langage courant rend mal. Une logique métier particulière, une règle de calcul propre à votre secteur, un enchaînement d'écrans que vous êtes le seul à comprendre : ces sujets se règlent par modifications successives, et arrive un point où continuer à la main coûte moins cher que de reformuler.

Exporter avant d'avoir un projet cohérent revient à figer un brouillon. Le dépôt existera, il ne servira à rien.

Combien coûte tout cela en crédits ?

Les crédits se dépensent à la génération et à la modification. Voici la grille complète, celle qui vaut pour tous les projets.

La formule gratuite comprend 5 crédits, soit un peu moins qu'une construction complète : elle sert à essayer, pas à terminer. Pro coûte $25 par mois et donne 200 crédits, ce qui représente environ 33 constructions, ou 66 modifications, ou 16 plateformes multipages sur un mois. Business coûte $99 par mois et donne 800 crédits.

Un chiffre utile à garder en tête pour arbitrer : trois allers-retours au chat consomment autant qu'une construction neuve. Quand un projet demande dix corrections d'affilée sur le même détail, le problème est en général dans la description, pas dans le nombre de crédits restants.

GitHub remplace-t-il les corrections au chat ?

Non, et confondre les deux fait perdre du temps dans les deux sens.

Le chat excelle sur ce qui se décrit en une phrase : ajouter une section, changer un parcours, refaire une page de tarifs, corriger un ton. Ces demandes traversent tout le projet d'un coup, y compris les pages auxquelles vous n'aviez pas pensé. Écrire la même chose à la main prend un après midi.

Le code manuel excelle sur ce qui se décrit mal : un cas particulier, une intégration avec un logiciel interne, une règle de facturation qui n'a de sens que dans votre entreprise. Ces sujets se formulent difficilement en français courant, et c'est justement là qu'un développeur va vite.

La bonne pratique consiste à choisir un régime et à s'y tenir sur une période donnée, plutôt que d'alterner au fil de la journée. La question du relais humain est développée dans peut-on embaucher un développeur plus tard.

Comment GitHub s'articule avec les autres intégrations ?

L'export du code est une pièce d'un ensemble court. Le voir en entier aide à décider quoi brancher, et surtout dans quel ordre.

L'ordre qui provoque le moins de dégâts : construire, publier sur l'adresse en .zugo.run, brancher le domaine, puis les services dont le projet a besoin pour fonctionner, et l'export en dernier. GitHub et Vercel vont souvent ensemble, puisque l'un détient les sources et l'autre le déploiement, mais rien n'oblige à activer les deux.

Où sont les limites honnêtes ?

Trois, sans détour.

Un dépôt ne fabrique pas une compétence. Le code exporté n'a de valeur que si quelqu'un sait le lire, et un non développeur qui ouvre le dépôt le referme aussitôt. C'est un actif, pas une formation accélérée.

Zugo ne remplace pas une équipe de développement sur un produit complexe. Sur un logiciel avec beaucoup de règles internes, la génération assure la base et l'ossature, puis le travail devient du développement classique. Dans le même esprit, les jeux sont générés en 2D et tournent dans le navigateur, ce que l'export ne change pas.

La vérification en bac à sable porte sur le projet livré. Avant de vous rendre une construction, Zugo la lance pour s'assurer qu'elle s'ouvre : une construction qui ne s'ouvre pas n'est pas livrée. Cette garantie ne suit pas le code dans votre dépôt. Ce que vous modifiez ensuite à la main, c'est vous qui le testez.

Par où commencer ?

Commencez par le projet, pas par le dépôt. Décrivez ce que vous voulez, laissez la construction se faire (comptez à peu près une minute pour un projet simple, quelques minutes pour une plateforme multipage), puis corrigez jusqu'à ce que le résultat vous convienne.

Quand le contenu ne bouge plus et que vous savez qui va reprendre le code, exportez vers un dépôt privé et donnez l'accès à cette personne plutôt que de lui envoyer une archive par e mail. Vous pouvez démarrer sur zugo.dev avec la formule gratuite et ne brancher GitHub que le jour où quelqu'un a une raison précise de lire les fichiers.