Tu as entendu parler de GitHub mille fois sans savoir vraiment à quoi ça sert. Moi pareil pendant 5 ans. Puis Claude Code est arrivé, et GitHub est devenu mon filet de sécurité, mon hébergeur indirect et ma bibliothèque d'outils gratuits. Voici pourquoi tu devrais l'utiliser · même si tu n'écris pas une ligne de code.
Sors de ta tête le cliché *« GitHub, c'est pour les devs »*. C'est faux. GitHub est un Dropbox spécialisé pour le code et les documents techniques, avec trois particularités qui changent tout :
Pour un entrepreneur qui utilise Claude Code, GitHub est devenu le jumeau indispensable. Claude modifie tes fichiers, toi tu valides, git capture l'état, GitHub le stocke en ligne. Si ton ordinateur prend feu demain, ton travail est sauvé. Si tu casses quelque chose par accident, tu reviens à la version d'avant en une commande.
GitHub, c'est la ceinture de sécurité de ton travail numérique. Tant que tu n'as rien d'important, tu peux t'en passer. Dès que tu commences à construire un site, un agent, une newsletter automatique · tu ne veux pas continuer sans.
Voici les 4 situations où j'ouvre GitHub comme non-dev, presque chaque jour.
Mon site (celui que tu lis) est un dépôt GitHub branché sur Vercel. Dès que Claude fait une modif et que je lance git push, Vercel détecte le changement et redéploie automatiquement en moins d'une minute. Aucun clic, aucune FTP, aucune config manuelle.
La combinaison GitHub + Vercel, c'est la manière la plus simple au monde de maintenir un site en ligne aujourd'hui. Tu ne gères rien d'autre que le contenu.
Claude travaille sur tes fichiers locaux. Si tu ne sauvegardes pas, une erreur disque ou un mauvais rm efface tout. Avec GitHub, chaque git commit capture une version · tu peux revenir à hier, à la semaine dernière, à il y a 3 mois.
Mon back-office admin a 13 modules. J'en casse un par semaine en voulant « juste améliorer un truc ». En 10 secondes, je reviens à la version d'avant, je corrige proprement, je re-commit.
Un dev publie son plugin sur GitHub. Tu le clones (git clone), tu l'installes, tu l'utilises. Tout l'écosystème Claude Code vit sur GitHub · Superpowers, les skills communautaires, les templates, les scripts de Simon Willison, les exemples d'agents.
Tu n'as pas besoin de comprendre le code · Claude te l'explique si tu lui demandes. GitHub est ta bibliothèque d'outils gratuits, avec 200 millions d'utilisateurs qui la nourrissent.
Un dev travaille sur ton projet en parallèle · il crée une pull request (proposition de modif), tu la relis, tu acceptes ou refuses. Tu ne mélanges jamais son travail avec le tien tant que tu n'as pas validé.
Même logique avec un agent GitHub (type github-app-playground qui tourne avec l'Agent SDK Claude). Il peut te proposer des corrections, toi tu décides.
Rien de compliqué · 5 étapes, 10 minutes en tout.
Va sur github.com, clique *« Sign up »*, choisis un nom d'utilisateur (il sera visible publiquement, prends ton vrai prénom ou ton handle habituel), email, mot de passe. Compte gratuit, suffisant pour 99 % des usages solo.
Git, c'est le logiciel qui communique avec GitHub depuis ton ordinateur. Sur Mac, il est souvent déjà là · teste avec :
git --version
Si ça répond avec un numéro, tu es prêt. Sinon, xcode-select --install et tu auras Git en bonus (sur Mac). Sur Windows, télécharge git-scm.com.
Dans ton terminal, dis à Git qui tu es (ça apparaîtra sur chaque commit) :
git config --global user.name "Ton Prénom" git config --global user.email "ton@email.com"
Sur GitHub, clique le bouton vert *« New »* en haut à droite, donne un nom à ton dépôt (par exemple mon-site), choisis *« Private »* (tu pourras le passer public plus tard), clique *« Create repository »*. GitHub t'affiche les commandes pour connecter ton dossier local.
Dans ton dossier local, tape :
git init git add . git commit -m "Premier commit" git remote add origin https://github.com/TON_USERNAME/mon-site.git git branch -M main git push -u origin main
C'est long la première fois. Après, ce sera seulement git add . → git commit -m "message" → git push. 3 commandes, ça devient automatique en 2 jours.
Tu n'as même pas besoin de mémoriser ces commandes. Dis à Claude « commit et push mes changements », il exécute. Il rédige même le message de commit tout seul en se basant sur ce qui a changé. Tu valides, c'est parti.
Git a 150+ commandes. Tu n'as besoin que de 5. Les autres, Claude les connaît à ta place.
| Commande | Ce que ça fait | Quand |
|---|---|---|
git status |
Dis-moi ce qui a changé depuis mon dernier commit | Avant de commit, pour vérifier que tu sais ce que tu sauves |
git add . |
Je prépare tous les changements pour le prochain commit | Juste avant commit, une fois que tu es content |
git commit -m "…" |
Je capture l'état actuel avec un message explicatif | À chaque étape importante (fin de feature, fin de session) |
git push |
J'envoie mes commits sur GitHub | Quand tu veux sauvegarder en ligne ou déclencher un déploiement Vercel |
git pull |
Je récupère les changements que quelqu'un d'autre (ou toi sur un autre PC) a poussés | Au début d'une session, si tu bosses sur 2 machines ou avec quelqu'un |
Cycle type de ta journée : git status (je regarde) → modifs via Claude → git add . → git commit -m "ce que j'ai fait" → git push. 4 commandes, 20 secondes, ton travail est sauvé en ligne.
git clone et git checkout
git clone URL · télécharge un dépôt depuis GitHub vers ton ordinateur. Tu l'utilises pour récupérer un outil open-source ou copier un projet d'exemple.
git checkout -b nouvelle-branche · crée une « branche » pour tester une grosse modif sans toucher à la version stable. Utile quand tu veux expérimenter sans peur. Claude gère ça tout seul si tu lui demandes.
Un jour, tu mets une clé API Resend dans un fichier .env, tu fais git add . sans regarder, tu push. Ta clé est publique sur GitHub, des bots la trouvent en quelques minutes, ta consommation explose.
La règle absolue · crée un fichier .gitignore à la racine de ton projet avec au minimum :
.env .env.local .env.* node_modules/ .DS_Store
Ces fichiers ne seront jamais envoyés sur GitHub. Demande à Claude *« crée-moi un .gitignore standard pour mon projet »*, il génère la bonne version.
1. Va sur le dashboard de ton service (Resend, Stripe, Anthropic…) et révoque la clé immédiatement. 2. Crée une nouvelle clé, mets-la dans ton .env.local. 3. Retire le fichier de l'historique Git (Claude te guide avec git filter-branch ou git rm --cached).
git push --force qui écrase tout
Si quelqu'un d'autre (un dev, un agent) a poussé des changements que tu n'as pas récupérés, et que tu lances git push --force, tu écrases leur travail sans possibilité de retour. Git te le signalera, ne force jamais sans comprendre pourquoi. La bonne réponse est presque toujours git pull d'abord.
Un repo public est visible par tout le monde sur Internet · parfait pour un outil open-source. Un repo privé est réservé à toi (et aux personnes que tu invites) · obligatoire pour un site en chantier, des données clients, ou un prototype confidentiel.
GitHub te demande toujours à la création. Par défaut, mets en privé. Tu peux toujours passer en public après, l'inverse est plus compliqué.
Voilà ce à quoi ressemble ma journée type avec les deux combinés.
claude dans le dossier de mon site. Claude lit mon CLAUDE.md et sait tout sur le projet.git add . && git commit -m "…" && git push.git revert, push, et le site revient à la version d'avant. Zéro stress.Tout ce workflow me prend 10 à 30 secondes une fois la modification faite. C'est pour ça que GitHub est indissociable de Claude Code chez moi · même sans écrire une ligne de code, je gère mon site comme un dev expérimenté, avec le filet de sécurité que ça implique.
Jamais quitter Claude Code sans avoir commit + push. Ça prend 5 secondes, ça garantit que peu importe ce qui arrive cette nuit (panne, bug Claude, coup de brosse du chat sur mon clavier), mon travail est sauf.
Si tu as une question précise sur GitHub ou un cas d'usage spécifique pour un entrepreneur non-dev, réponds à ma newsletter. Ça arrive dans ma boîte, je lis tout, je te réponds. Les retours terrain valent mille fois les articles génériques · y compris celui que tu viens de lire.
Chaque vendredi, je partage mes tests du moment · nouveaux outils, nouveaux workflows, nouveaux pièges découverts. Sans pub, désinscription en un clic.