Votre premier projet : scaffolding, Dev Server, Git et GitHub

Vue d'ensemble

C'est la leçon où l'abstrait devient concret. Vous scaffoldez un vrai projet, le faites tourner dans votre navigateur et le mettez sous version control dans un repo GitHub privé. À la fin, vous avez une app qui tourne localement et un historique sûr et sauvegardé de votre travail - la fondation sur laquelle chaque projet ultérieur s'appuie.

Ce que vous allez apprendre

Vous scaffoldez un projet avec votre agent, lancez un Dev Server et le voyez sous localhost, comprenez ce que font vraiment Git et les commits, et poussez votre code dans un repository GitHub privé avec les secrets exclus en sécurité. Ce sont les gestes quotidiens de la construction, alors faisons-en dès maintenant de la mémoire musculaire.

Prérequis

Un setup d'agent fonctionnel, Node.js et un compte GitHub (gratuit). Les pages de fondamentaux sur Git, GitHub, le terminal et sur ce qu'est un Dev Server aident si un terme vous est nouveau ici - survolez-les puis revenez. Vous n'avez pas besoin de connaître les commandes Git par cœur ; l'agent exécute la plupart, mais vous devez comprendre ce qu'elles font.

Le problème

Les débutants restent coincés entre « j'ai une idée » et « ça tourne sur mon écran ». Ils ne savent pas comment démarrer un projet, ont peur du terminal et sont troublés par Git. Le résultat est un dossier plein de fichiers sans historique et sans backup, où un mauvais changement perd des heures de travail. Cette leçon comble ce fossé pour de bon.

Pas à pas : scaffolder et faire tourner

Au lieu d'apprendre un framework par cœur, demandez à votre agent de scaffolder un starter moderne et d'expliquer chaque étape. Un choix courant et accessible aux débutants est un projet basé sur Vite, mais la stack exacte compte moins que la compréhension du flux : créer le projet, installer les dépendances, lancer le Dev Server, ouvrir le navigateur.

# Scaffolder un nouveau projet Vite (votre agent peut l'exécuter pour vous)
npm create vite@latest my-first-app

# Entrer dedans et installer les dépendances nécessaires
cd my-first-app
npm install

# Lancer le Dev Server local
npm run dev

Le Dev Server affiche une adresse locale, souvent du genre http://localhost:5173. Ouvrez-la dans votre navigateur et vous verrez votre app tourner sur votre propre machine. « localhost » veut simplement dire « cet ordinateur » - rien n'est encore sur l'Internet public, ce qui est exactement ce qu'il faut pendant la construction. Modifiez un fichier, sauvegardez, et le navigateur se rafraîchit aussitôt. Cette boucle en direct fait que la construction web semble rapide.

Ce que Git fait réellement

Git est du version control : il prend des instantanés de votre projet appelés commits, pour que vous puissiez toujours revenir en arrière. Voyez-le comme un historique d'annulation illimité avec des étiquettes. Chaque commit consigne ce qui a changé et pourquoi, ce qui veut dire qu'un mauvais changement n'est jamais une catastrophe - vous revenez simplement au dernier bon commit. Cette seule habitude ôte la peur qui empêche les débutants d'expérimenter, car rien de ce que vous faites n'est définitif tant que vous ne le décidez pas.

# Commencer à suivre ce projet avec Git
git init

# Mettre tous les fichiers actuels en attente pour le premier instantané
git add .

# Enregistrer l'instantané avec un message descriptif
git commit -m "Initial project scaffold"

Tenir les secrets dehors avant de pousser

Avant de pousser un jour vers GitHub, assurez-vous que les secrets ne peuvent pas s'échapper. Un fichier .gitignore liste les choses que Git doit ignorer. Votre fichier .env - où vivent les clés API - et le dossier node_modules y ont tous deux leur place. Faites-le bien une fois et vous ne publierez jamais une clé par accident. Votre agent peut créer ce fichier, mais vous devez savoir en reconnaître un correct.

# .gitignore - dit à Git ce qu'il ne doit jamais suivre
node_modules
.env
.env.local
dist

La règle est absolue : les secrets vont dans .env, .env va dans .gitignore, et l'agent n'écrit jamais une clé dans du code committé. Si vous ne retenez rien d'autre de la sécurité de ce cours, retenez cela.

Pas à pas : pousser dans un repo GitHub privé

GitHub stocke votre repository dans le cloud : un backup, un historique, et plus tard ce à quoi votre déploiement se connecte. Créez le repository en privé pour que votre code business vous appartienne. L'agent peut faire l'essentiel, mais voici ce qui se passe sous le capot.

# Créer un repo PRIVÉ et pousser, avec la GitHub CLI
gh repo create my-first-app --private --source=. --push

# Ou, si vous avez créé le repo d'abord sur github.com :
git remote add origin https://github.com/yourname/my-first-app.git
git push -u origin main

Privé est le défaut que vous voulez pour tout ce qui est commercial. Les repos publics sont formidables pour l'open source, mais votre IP business devrait démarrer en privé et ne passer en public que délibérément, après un security review - un sujet que le Cours 5 traite en détail.

Erreurs fréquentes

Les douloureuses : committer un fichier .env avec une clé API active (désormais pour toujours dans votre historique, même si vous le supprimez plus tard) ; ne jamais lancer git commit, si bien qu'il n'y a pas d'historique où revenir ; créer un repo public pour du code business privé ; et paniquer au terminal au lieu de laisser l'agent exécuter les commandes pendant que vous lisez ce qu'elles font. Allez lentement, lisez chaque commande et committez tôt et souvent.

ROI business

Le version control est une assurance bon marché à l'énorme bénéfice. Une seule erreur réparable - annuler un changement cassant en quelques secondes au lieu de le reconstruire pendant des heures - rentabilise l'habitude bien des fois. Un repo privé protège l'IP sur laquelle votre business repose. Et une app qui tourne localement veut dire que vous pouvez itérer vite, ce qui est tout le sens de construire avec des agents.

Checklist

Vous êtes prêt à shipper dès que chacun de ces points est vrai. Ne sautez pas les points de sécurité des secrets - ils comptent plus qu'ils n'en ont l'air.

• Votre projet tourne localement et vous pouvez l'ouvrir sous localhost.
• Le projet est un repo Git avec au moins un commit.
• .env est dans .gitignore et ne contient de secrets dans aucun fichier committé.
• Le code est poussé dans un repository GitHub PRIVÉ.

Ressources

Les pages de fondamentaux sur Git, GitHub et le Dev Server sont votre référence si une étape était bancale. La checklist de setup Claude Code dans la bibliothèque de ressources consigne ces garde-fous en une liste réutilisable. Il reste une étape : passer ceci de votre machine à l'Internet public.

Votre mission

Scaffoldez un petit projet, faites-le tourner localement, faites au moins deux commits en changeant quelque chose, et poussez-le dans un repo GitHub privé avec un .gitignore correct. Confirmez sur github.com que votre .env est introuvable nulle part. Vous avez maintenant un vrai projet, sous version control et sauvegardé.

Prochaine leçon

Votre app tourne sur votre machine. La dernière leçon de ce cours la met sur l'Internet public : déploiement sur Vercel, connexion d'un vrai domaine et gestion du DNS et de Cloudflare, pour que n'importe qui dans le monde puisse visiter votre site.