Comment sauvegarder son projet créé avec l'IA ?

Comment sauvegarder son projet créé avec l'IA ?

Un projet ne se sauvegarde pas en un seul geste, parce qu'il vit à quatre endroits. Exportez le code vers GitHub, sauvegardez la base de données depuis votre compte Supabase, conservez textes et images dans un dossier à vous, et rangez les accès dans un gestionnaire de mots de passe. Quatre copies, quatre responsables.

Que faut-il sauvegarder au juste ?

Rien de ce qui vous semble évident. Un projet publié donne l'impression d'être un bloc unique parce qu'il s'affiche à une seule adresse, alors qu'il est en réalité assemblé à partir de sources dispersées, chacune hébergée par un service différent.

La ligne la plus souvent oubliée est la troisième. Beaucoup de gens considèrent que leurs textes sont sauvegardés parce qu'ils sont en ligne, ce qui revient à confondre publication et archivage. Le jour où la page est écrasée par une mauvaise modification, le texte disparaît avec elle.

Comment exporter le code du projet ?

Par l'export vers GitHub, qui récupère les sources dans un dépôt qui vous appartient. C'est la sauvegarde la plus complète du projet lui-même : structure des pages, styles, composants et logique passent d'un coup dans un endroit que vous contrôlez entièrement.

L'intérêt dépasse la simple copie de secours. Un dépôt GitHub garde l'historique, donc vous pouvez comparer deux états et revenir en arrière. Il permet aussi de confier le projet à un développeur sans partager vos accès, ce qui est précisément le scénario où l'on découvre qu'on n'avait pas de sauvegarde.

Le déploiement sur votre propre compte Vercel complète la manœuvre. Le site tourne alors chez vous, avec vos réglages, indépendamment de l'outil qui l'a produit. Le détail de la procédure est décrit dans peut-on exporter le code.

Comment sauvegarder la base de données ?

Depuis Supabase, parce que la base vit dans votre compte et non dans le générateur. Cette séparation est une bonne nouvelle : vos données ne dépendent pas de l'outil de construction et suivent les règles du service que vous avez choisi.

Supabase propose ses propres mécanismes de sauvegarde et d'export, dont les modalités varient selon votre formule chez eux. Le geste utile consiste à ouvrir cette page dès la mise en production, à vérifier ce qui est réellement couvert et à noter la fréquence, plutôt qu'à le supposer.

Ajoutez-y un export manuel avant chaque changement de structure. Modifier une table sur une base qui contient déjà des clients est le moment le plus risqué de la vie d'un projet, et c'est aussi celui où une copie datée de la veille vaut toutes les précautions du monde.

Que faire des textes, des images et des accès ?

Les garder chez vous, dans un dossier ordinaire. Un document avec la version finale de chaque page, un sous-dossier d'images en pleine résolution, un fichier avec les mentions légales et les conditions de vente : cela paraît rudimentaire et cela sauve des semaines de travail.

Les accès méritent un traitement à part. Clés Stripe, identifiants Supabase, jeton Resend, accès au bureau d'enregistrement du domaine : ces éléments ne se notent ni dans un carnet ni dans un e-mail à soi-même, mais dans un gestionnaire de mots de passe, avec la personne qui prendra le relais en cas d'absence.

Pensez enfin à photographier votre configuration DNS avant toute modification. Une erreur sur un enregistrement rend le site injoignable sans qu'aucun code ne soit en cause. La procédure de branchement est détaillée dans brancher un domaine personnalisé.

À quelle fréquence faut-il sauvegarder ?

Selon le rythme de changement, pas selon le calendrier. Un site vitrine terminé et stable n'a pas besoin d'une copie hebdomadaire, alors qu'une application qui enregistre des commandes chaque jour en a besoin quotidiennement.

Trois repères simples suffisent. Avant toute modification importante, faites une copie. Après une mise en production réussie, faites-en une autre et datez-la. Enfin, gardez au moins une copie ailleurs que chez le fournisseur principal, ce que le monde technique résume par la règle des trois copies sur deux supports.

Cette dernière règle vaut aussi pour les données personnelles de vos visiteurs. Si vous stockez des contacts, des commandes ou des comptes clients, votre obligation de conservation et de sécurité au titre du RGPD ne disparaît pas parce que le site a été produit par un générateur.

Comment vérifier qu'une sauvegarde fonctionne vraiment ?

En la restaurant, une fois, pour de bon. Une sauvegarde jamais restaurée n'est pas une sauvegarde : c'est une hypothèse. Le test coûte une heure et remplace une certitude confortable par une preuve, ce qui n'est pas le même objet.

Le protocole tient en trois gestes. Récupérez le dépôt GitHub dans un dossier vide et vérifiez qu'il contient bien toutes les pages. Restaurez un export de base dans un projet Supabase de test et regardez si les tables sont complètes. Ouvrez enfin votre dossier de contenus et vérifiez que les images sont en pleine résolution.

Si l'un de ces trois gestes échoue, vous venez d'apprendre quelque chose d'utile à un moment où cela ne coûte rien. C'est exactement l'inverse de la situation où on l'apprend après un incident, sous pression et sans marge de manœuvre.

Combien coûte une reconstruction si tout est perdu ?

Le prix d'un projet neuf, en crédits, plus le temps que vous ne récupérerez pas. C'est la meilleure raison de sauvegarder, et elle se chiffre sans discussion possible.

Une construction coûte 6 crédits, une modification 3 crédits, une plateforme multipage 12 crédits pour les trois premières pages puis 3 crédits par page supplémentaire. Reconstruire un site de quatre pages avec une dizaine de retouches ramène donc à une quarantaine de crédits sur les 200 du plan Pro.

Le coût en crédits n'est pourtant pas le vrai sujet. Ce que vous ne rachetez pas, ce sont les textes affinés pendant des semaines, les photos retravaillées et les réglages trouvés à force d'essais. Ce contenu ne se régénère pas : il se recopie ou il se perd.

Par où commencer aujourd'hui ?

Par la copie la plus rapide à faire. Exportez le code vers GitHub maintenant, puis créez un dossier au nom de votre projet et déposez-y les textes de chaque page. Ces deux gestes prennent vingt minutes et couvrent l'essentiel du risque.

Ajoutez ensuite les deux réflexes qui manquent presque toujours : un export de base avant chaque changement de structure, et le rangement des clés dans un gestionnaire de mots de passe partagé avec une seconde personne.

Notez enfin la limite honnête du dispositif. Le générateur vérifie chaque projet dans un bac à sable avant de vous le remettre, donc une construction qui ne s'ouvre pas ne vous est pas livrée, mais cette vérification protège la mise en ligne, pas vos données. La sauvegarde reste votre responsabilité, quel que soit l'outil. Vous pouvez vérifier vos exports dès aujourd'hui depuis zugo.dev.