Puis-je collaborer à plusieurs sur un projet Zugo ?

Puis-je collaborer à plusieurs sur un projet Zugo ?

Oui, à condition de collaborer sur les livrables plutôt que dans l'éditeur. L'édition simultanée façon document partagé ne fait pas partie des fonctions décrites de Zugo. Ce qui circule, c'est le lien publié en .zugo.run pour la relecture, et le code exporté vers GitHub pour un développeur.

Cette contrainte est moins gênante qu'elle n'en a l'air, et elle impose même une organisation qui produit de meilleurs résultats que le travail à plusieurs mains sur la même interface.

Que veut dire collaborer sur un projet généré ?

Trois activités très différentes se cachent derrière le mot, et les mélanger est ce qui fait échouer les projets à plusieurs. Il y a la décision, la génération, et la relecture.

La décision est humaine et se prend avant toute demande. Que vend-on, à qui, avec quel ton, quelles pages : deux personnes qui n'ont pas tranché ces points ensemble produiront deux directions différentes, et aucun outil ne réconcilie deux intentions.

La génération est une action unique, exécutée par une seule personne à la fois. C'est elle qui consomme des crédits, et c'est elle qu'il ne faut surtout pas dupliquer. Deux personnes qui demandent chacune leur version d'un même changement paient deux fois pour obtenir un résultat incohérent.

La relecture, elle, se partage sans aucune limite. Le projet publié vit à une adresse publique, et n'importe qui disposant du lien peut l'ouvrir sur son téléphone, dans le train, et vous renvoyer ses remarques. C'est là que la collaboration prend vraiment place.

Comment travailler à deux sans se marcher dessus ?

En nommant un pilote et en groupant les demandes. Cette règle tient en deux phrases et elle règle l'essentiel des frictions observées sur ce type de projet.

Le pilote n'est pas le décideur, c'est la main qui exécute. La distinction compte : dans une agence, le pilote est souvent le chef de projet, et la validation reste chez le client. Confondre les deux fait naître des allers-retours sans fin, parce que personne ne sait à quel moment une version est acceptée.

Le groupement des demandes est l'autre moitié de la méthode. Une modification traite un lot de corrections, pas une correction. Réunir douze remarques dans un même passage donne un résultat plus cohérent que douze passages successifs, et coûte nettement moins cher.

Combien de crédits consomme un travail à plusieurs ?

Le même barème que pour une personne seule, avec une différence qui saute aux yeux dès qu'on la met par écrit : la discipline de lot se voit directement sur la facture.

Le plan gratuit inclut 5 crédits, ce qui reste en dessous d'une construction à 6 : il sert à découvrir l'outil, pas à mener un projet à plusieurs. Pro coûte $25 par mois pour 200 crédits, soit environ 66 modifications, une réserve confortable pour un projet client avec plusieurs tours de relecture. Business coûte $99 par mois pour 800 crédits.

Sur un projet à deux ou trois personnes, prévoyez plus de modifications que de constructions. La génération initiale est rapide et bon marché : ce sont les allers-retours qui composent le budget réel, et c'est exactement là que la discipline de lot fait la différence.

Comment faire relire le projet par un client ?

En lui envoyant le lien publié et une consigne de relecture, pas une question ouverte. « Dis-moi ce que tu en penses » produit un avis d'humeur, « note tout ce qui est faux dans les textes, page par page » produit une liste exploitable.

Le projet publié vit sur une adresse en .zugo.run, accessible depuis n'importe quel navigateur, sans installation ni compte. Avant de vous le remettre, Zugo l'a lancé dans un bac à sable pour vérifier qu'il s'ouvre : une construction qui n'a pas démarré n'est pas livrée, donc le lien que vous partagez a déjà chargé au moins une fois.

Demandez les retours dans un seul document, numérotés, avec le nom de la page devant chaque ligne. Ce format vous permet de recopier directement les demandes dans votre modification suivante, sans traduction ni interprétation, et de montrer ensuite point par point ce qui a été traité.

Fixez enfin le nombre de tours à l'avance. Deux tours de recette et une validation finale suffisent à la grande majorité des sites, et l'annoncer dès le départ évite la relecture perpétuelle. Le déroulé des retouches est détaillé dans comment modifier un projet après la génération.

Comment passer le relais à un développeur ?

Par le code, pas par l'écran. Le projet s'exporte vers GitHub, ce qui donne à un développeur un dépôt qu'il peut lire, cloner et faire évoluer avec ses propres outils.

À partir de là, le déploiement peut basculer sur votre compte Vercel, la base de données et les comptes utilisateurs restent chez Supabase, les paiements chez Stripe et les e-mails chez Resend. Autrement dit, le développeur retrouve un ensemble de briques standards, ce qui est précisément l'intérêt de l'export.

Ce passage de relais mérite une règle simple : une fois le code repris à la main, arrêtez les générations sur le même projet. Deux sources de vérité qui avancent en parallèle finissent toujours par diverger, et la fusion coûte plus cher que le travail lui-même.

Les modalités exactes de l'export sont traitées dans puis-je exporter le code de mon projet, et le moment opportun pour faire appel à un professionnel dans puis-je faire appel à un développeur plus tard.

Où sont les limites honnêtes ?

Trois, énoncées sans détour, parce qu'elles conditionnent la façon dont vous organisez l'équipe.

L'édition simultanée n'existe pas comme un mode de travail partagé. Vous ne verrez pas le curseur d'un collègue se déplacer sur le même projet, et deux personnes qui génèrent en même temps sur le même projet obtiennent au mieux une confusion. Une seule main sur la manette, toujours.

Zugo ne remplace pas une équipe de développement sur un produit complexe. Sur un projet mené à plusieurs, cette limite arrive plus vite, parce qu'un groupe demande naturellement des fonctionnalités plus fines qu'une personne seule. Une logique métier très spécifique se précise par modifications successives, et l'export vers GitHub existe pour la suite.

Enfin, la vérification en bac à sable confirme que le projet démarre. Elle ne relit pas vos textes, ne vérifie pas vos prix et ne remplace aucune recette. Cette part du travail reste humaine, et c'est justement celle qui gagne le plus à être faite par plusieurs paires d'yeux.

Par où commencer ?

Mettez-vous d'accord à l'écrit avant la première génération : ce que fait le site, pour qui, les pages attendues et le ton. Une page de notes partagée suffit et remplace trois réunions.

Désignez ensuite le pilote, lancez la construction, publiez, et envoyez le lien avec une consigne de relecture claire. Regroupez les retours, traitez-les en une modification à 3 crédits par lot, et annoncez un nombre de tours limité.

Une construction simple prend environ une minute et une plateforme quelques minutes : sur un projet collectif, le temps se dépense en décisions, jamais en génération. Vous pouvez roder cette organisation sur le plan gratuit de zugo.dev avant d'engager un projet client entier.