🛟Sauvegarde tout sur GitHub avant que l'IA ne casse ton projet · ton bouton annuler infini

Quand le besoin apparaît-il ? (le moment exact)

Le besoin apparaît précisément quand tu commences à construire une vraie app avec l'IA — pas quand tu discutes simplement avec elle. À ce moment-là, l'IA touche à plein de fichiers en même temps, et un jour tu lui demandes un petit changement et, sans le vouloir, elle casse trois choses qui marchaient. C'est là que tu découvres si tu avais un filet… ou pas.

Et il y a un deuxième frein, plus subtil : la peur d'expérimenter. Sans filet, tu demandes des changements timides pour ne rien casser — et les changements timides ne construisent rien de grand. Avec GitHub sauvegardé, tu oses : si ça tourne mal, tu reviens en arrière et voilà.

Qu'est-ce que Git et qu'est-ce que GitHub ? (une phrase chacun)

Git est le système qui sauvegarde des photos de ton projet dans le temps (chaque photo s'appelle un commit). GitHub est le cloud où tu envoies ces photos pour les garder en sécurité et pouvoir revenir à n'importe laquelle. Git vit sur ton ordinateur ; GitHub vit sur internet. Ensemble = sauvegarde + machine à remonter le temps.

Où vit ton projet ? Dossier local vs sandbox

C'est essentiel pour comprendre pourquoi GitHub t'est toujours utile, peu importe avec quoi tu construis. Les outils d'IA sauvegardent ton projet de deux façons, et dans les deux cas GitHub gagne :

Dossier local — des outils comme Claude Code travaillent sur un dossier de ton propre ordinateur. Pour le voir tourner, tu ouvres le localhost dans ton navigateur. Le projet est à toi et il est sur ton disque… mais si tu l'effaces par accident ou qu'une commande l'abîme, sans sauvegarde dans le cloud il n'y a pas de retour en arrière.

Sandbox propre — d'autres outils (comme NeuralOS, v0, Bolt et similaires) font tourner ton app dans leur propre environnement, et tu la vois déployée là même, sans gérer de dossiers. Ultra pratique. Mais ton code vit dans le compte de cette plateforme — si tu veux une copie qui soit vraiment à toi et qui survive quoi qu'il arrive, tu la mets sur GitHub.

La voie sans terminal · GitHub Desktop (recommandée pour commencer)

Si le mot "terminal" te rebute, c'est ta voie. GitHub Desktop est l'app officielle et gratuite de GitHub : elle fait tout avec des boutons. Tu vois la liste de tes changements, tu écris une note, et tu sauvegardes — sans une seule commande. Sa propre devise le dit : "concentre-toi sur ce qui compte au lieu de te battre avec Git".

À partir de là, chaque fois que l'app te montre des changements, tu écris une note courte en bas à gauche (le Summary), tu cliques sur Commit to main, puis sur Push origin. C'est un point de sauvegarde envoyé dans le cloud. Fais-le chaque fois que quelque chose fonctionne bien.

La voie avec commandes · 4 qui valent de l'or

Si tu préfères le terminal (ou si ton IA l'utilise pour toi), avec ces quatre commandes tu as 90% de ce dont tu as besoin. Ton IA les connaît par cœur — tu peux lui demander de les exécuter et de t'expliquer chacune.

git init
git add .
git commit -m "premier point de sauvegarde : le projet fonctionne"

git status

git add .
git commit -m "décris en quelques mots ce que tu as réussi"

git push

Le moment clé · revenir en arrière quand l'IA a cassé quelque chose

Voici le super-pouvoir. Imagine que ton app marchait, tu as demandé un changement, et maintenant elle est cassée. Si tu as sauvegardé un point quand ça marchait, la récupérer est trivial. Dans GitHub Desktop : menu History, clic droit sur le bon point → Revert changes. Avec la commande, tu as deux façons selon ce que tu veux :

git revert HEAD

Ce git revert est le plus sûr : il n'efface pas l'historique, il crée juste un nouveau point qui annule le dernier. Si tu veux seulement récupérer un fichier tel qu'il était à un point antérieur, tu demandes à ton IA : "rends-moi le fichier X tel qu'il était au dernier commit qui fonctionnait" et elle utilisera git checkout. La règle d'or :

Les branches · teste des folies sans peur (optionnel mais magique)

Une branche est une copie parallèle de ton projet où tu peux expérimenter sans toucher à la version qui marche. Tu veux que l'IA tente quelque chose de risqué ? Tu crées une branche, elle teste là, et si ça marche tu la fusionnes (merge) ; si ça tourne mal, tu l'effaces et il ne s'est rien passé. Ta version principale n'a jamais été en danger.

git checkout -b prueba-arriesgada

Le plus important · les 5 moments où tu sauvegardes TOUJOURS

Voici le vrai secret, et c'est ce que presque personne ne fait : GitHub ne se met pas en place une fois et c'est fini. Sa valeur est dans l'habitude. Si tu n'alimentes pas GitHub de façon constante, le jour où tu en auras besoin il n'y aura rien où revenir. Voici les cinq moments où sauvegarder ne se négocie pas — les mêmes qu'on utilise, nous qui construisons pour de vrai :

Sauvegarde propre · ne remplis pas GitHub de déchets

Un bon historique est un historique où chaque point signifie quelque chose. Deux règles simples pour que ton GitHub soit utile et pas une poubelle :

Erreurs typiques du débutant (et comment les éviter)

Le chemin le plus facile · laisse ton agent le faire par le chat

Si tu utilises un agent de code (comme Claude Code), presque tout se fait par le chat — tu n'as pas à apprendre de commandes. Voici ce que ton agent PEUT faire seul par message, et le peu qui te revient :

Prompt prêt · passe-le à ton IA et tout est configuré

Voici le prompt complet, du début à la fin. Copie-le, remplace ce qui est entre crochets, et colle-le à ton agent de code. Il te met GitHub en place, connecté et avec l'habitude de te rappeler de sauvegarder.

Je veux protéger mon projet avec GitHub même si je n'y connais rien à git. Guide-moi étape par étape et fais-le toi où tu peux. Mon projet s'appelle [NOM] ; je le construis avec [Claude Code / NeuralOS / un autre outil].

1) COMPTE : si je n'ai pas de compte GitHub, dis-moi exactement comment le créer sur github.com (gratuit) en étapes courtes.

2) DÉPÔT : dis-moi comment créer un dépôt NOUVEAU et PRIVÉ. Suggère-moi un nom en minuscules avec des tirets à partir du nom de mon projet. Si tu peux le créer toi-même avec ma permission, fais-le ; sinon, dis-moi les clics exacts et je te passe le nom ou l'URL.

3) NETTOYAGE : crée un .gitignore qui ignore .env, node_modules, les fichiers temporaires et tout secret, pour ne pas envoyer de déchets ni de mots de passe.

4) PREMIER POINT : initialise git, fais le premier commit avec un message clair et connecte-le et envoie-le vers mon dépôt privé.

5) HABITUDE : à partir de maintenant, chaque fois qu'on réussit quelque chose qui fonctionne, AVANT un changement important, et après avoir vérifié/corrigé des bugs, rappelle-moi de sauvegarder un point et demande-moi si on l'envoie dans le cloud. Utilise des messages de commit clairs que mon toi du futur comprendra.

6) SAUVETAGE : si quelque chose se casse, aide-moi à revenir au dernier point qui fonctionnait sans perdre mon travail, et explique-moi en une phrase ce qui s'est passé.

Fais-le simple. Si quelque chose ne peut être fait que par moi via le web, dis-le-moi avec les clics exacts.

L'outil officiel (gratuit et vérifié)