Comment modifier un site créé par IA après la génération
Comment modifier un site créé par IA après la génération
On modifie un projet en décrivant le changement souhaité en langage courant. La modification retouche le site existant au lieu de le reconstruire, elle coûte 3 crédits contre 6 pour une construction complète, et son résultat dépend surtout de la précision de la demande, pas de la taille du site.
En quoi une modification diffère-t-elle d'une reconstruction ?
La différence tient en un mot : la mémoire. Une reconstruction repart de votre description initiale et produit un projet neuf, avec une mise en page qui peut changer partout. Une modification conserve l'existant et n'agit que sur ce que vous désignez.
Concrètement, si vous demandez de remplacer la photo d'accueil, le reste des pages ne bouge pas. Vos textes déjà corrigés restent en place, la structure de navigation aussi, et vous ne repassez pas une heure à retrouver les réglages que vous aviez validés la veille.
Cette distinction a une conséquence financière directe. Reconstruire pour changer un titre revient à payer 6 crédits là où 3 suffisaient, et à risquer de perdre des ajustements que vous aviez oubliés d'avoir faits. La règle pratique tient donc en une phrase : on reconstruit quand le concept change, on modifie dans tous les autres cas.
Il existe une exception. Si le projet a pris une direction franchement éloignée de ce que vous vouliez après cinq ou six retouches, repartir d'une description mieux écrite coûte souvent moins cher que de continuer à corriger un résultat bancal.
Comment formuler une demande de modification qui aboutit ?
En nommant l'endroit, l'objet et l'état visé. Les trois ensemble. « Sur la page d'accueil, remplace le bandeau bleu par une photo pleine largeur et place le bouton de contact juste en dessous » contient les trois. « Rends la page plus vivante » n'en contient aucun.
Le réflexe utile consiste à écrire sa demande comme on la donnerait à un graphiste qui ne connaît pas votre métier. Il ne devine pas que « plus sérieux » veut dire moins de couleurs chez vous, et il ne sait pas quelle section vous appelez « le haut de page ».
Autre habitude qui fait gagner du temps : grouper. Notez pendant deux jours tout ce qui vous gêne, puis envoyez trois demandes claires plutôt que douze petites. Chaque passage coûte le même prix, donc une demande qui règle quatre points vaut quatre fois mieux qu'une demande qui en règle un.
Les principes de rédaction sont les mêmes que pour la première description du projet, et ils sont détaillés dans comment écrire un bon prompt. Une bonne demande de modification est simplement un bon prompt plus court et mieux ciblé.
Combien coûte une modification, et comment ne pas gaspiller ?
Une modification coûte 3 crédits, une construction 6, une plateforme multipage 12 crédits pour les trois premières pages puis 3 crédits par page ajoutée. Le mode Hi-Fi double la note : 6 crédits pour une modification, 12 pour une construction.
| Formule | Prix mensuel | Crédits inclus | Ordre de grandeur |
|---|---|---|---|
| Free | $0 | 5 | Un essai complet |
| Pro | $25 | 200 | Environ 66 modifications |
| Business | $99 | 800 | Un rythme d'agence |
Les 200 crédits du plan Pro représentent aussi environ 33 constructions ou 16 plateformes multipages, selon la façon dont vous travaillez. Un projet mené proprement consomme beaucoup moins qu'on ne l'imagine, parce que la phase de retouche pèse peu par rapport à la phase de création.
Le gaspillage vient presque toujours du même endroit : reconstruire par réflexe. La deuxième source, c'est la demande floue qu'il faut relancer deux fois. Une minute passée à préciser sa phrase vaut souvent 3 crédits économisés, ce qui est un rendement horaire honorable.
Que faire quand la modification ne donne pas ce qu'on attendait ?
Ne pas relancer la même phrase. Si une demande a produit un résultat à côté, la répéter produira un résultat à côté, généralement différent mais pas meilleur. Il faut changer la formulation, pas insister.
La bonne réaction consiste à décrire ce que vous voyez, puis ce que vous voulez à la place. « Le bouton est passé sous le pied de page, remonte-le dans le bandeau d'accueil, à droite du titre » donne un point de départ et une cible, ce qui laisse beaucoup moins de place à l'interprétation.
Si deux tentatives échouent d'affilée, découpez. Une demande qui touche à la fois la mise en page, les couleurs et le contenu d'une section a trois occasions de partir de travers. Trois demandes successives, chacune sur un seul aspect, réussissent presque toujours là où la demande unique échouait.
Gardez aussi en tête la vérification automatique : avant d'être remis, chaque résultat est ouvert dans un bac à sable, et une version qui ne s'affiche pas ne vous est pas livrée. Vous ne recevez donc jamais une page blanche à la place de votre site.
Quelles modifications passent en un essai et lesquelles demandent plusieurs passages ?
Toutes les retouches ne se valent pas. Celles qui portent sur des éléments visibles et nommables aboutissent presque toujours du premier coup. Celles qui touchent à des règles de fonctionnement demandent une série de passages, et c'est normal.
| Type de demande | Exemple | À prévoir |
|---|---|---|
| Texte et contenu | Réécrire une section, corriger des tarifs | Un passage |
| Mise en page simple | Déplacer un bouton, inverser deux blocs | Un passage |
| Couleurs et typographie | Passer sur une palette sombre | Un passage |
| Ajout de page | Créer une page tarifs cohérente avec le reste | Un ou deux passages |
| Formulaire et envoi d'e-mail | Ajouter un formulaire relié à Resend | Deux passages |
| Règle métier spécifique | Tarif dégressif, calcul de disponibilité croisée | Plusieurs passages |
La dernière ligne est celle qu'il faut lire honnêtement. Une logique métier très particulière se construit par corrections successives, pas en une seule phrase, et prévoir trois ou quatre allers-retours dès le départ évite la déception du premier essai.
Peut-on modifier un projet déjà en ligne ?
Oui, et c'est le cas le plus fréquent. Un projet publié vit sur une adresse en .zugo.run ou sur votre propre nom de domaine, et les modifications s'appliquent au projet puis repartent en ligne à la publication suivante. Vous ne remontez pas un site à la main.
L'ordre recommandé reste le même que pour n'importe quel site vivant : regarder, noter, corriger, republier. Beaucoup d'utilisateurs gardent une version en ligne pendant qu'ils retravaillent, ce qui évite de montrer un chantier aux visiteurs pendant une journée d'ajustements.
Si le projet est relié à Supabase pour les comptes et les données, à Stripe pour les paiements ou à GitHub pour l'export du code, ces branchements survivent aux modifications. Vous ne les refaites pas à chaque retouche, et l'étape de mise en ligne est décrite dans comment publier son projet.
Quelles limites faut-il connaître avant de se lancer ?
Trois, et il vaut mieux les entendre au début qu'au milieu. La première : un produit complexe porté par plusieurs personnes reste un projet d'équipe de développement. La modification par description accélère la mise au point, elle ne remplace pas une architecture pensée.
La deuxième : les jeux produits sont en 2D et tournent dans le navigateur. On les retouche comme le reste, mais l'ambition doit rester dans ce périmètre. La troisième : la logique métier très spécifique se gagne par itérations, ce qui coûte du temps et des crédits.
Aucune de ces limites n'empêche de mener un projet sérieux, et la plupart des sites vitrines, boutiques simples et applications internes tiennent largement dedans. Pour situer le budget global avant de commencer, voyez combien coûte un site créé par IA, et pour tester une première modification sur un vrai projet, tout se passe sur zugo.dev.