Cédric Rittié

← Retour au blog
githubdeploy

GitHub expliqué aux utilisateurs d'IA qui veulent déployer

Tu génères du code avec l'IA. GitHub, c'est ce qui le transforme en quelque chose de réel. Le guide pour comprendre les 5 concepts qui séparent ton prototype local d'un site en ligne.

Le problème

Tu as passé une heure avec Claude Code ou Cursor. Tu as un site, un outil, une app qui tourne sur ton écran. Tu es content. Mais ça ne tourne que chez toi. Personne d'autre ne peut le voir.

Pour le mettre en ligne, tout le monde te dit la même chose : "push sur GitHub". Et c'est là que tu décroches. Pas parce que c'est dur. Parce que personne ne t'a jamais expliqué ce que c'est.

GitHub, c'est la pièce qui relie ton IA à la mise en ligne. Sans lui, ton projet reste un prototype sur ton ordi. Avec lui, il devient un site, un outil, un produit accessible par n'importe qui.

Cet article t'explique les 5 concepts à connaître. Pas plus.

A qui s'adresse cet article ?

  • Tu utilises Claude Code, Cursor, ou un autre outil IA pour générer du code
  • Tu as un projet qui tourne en local et tu veux le mettre en ligne
  • Tu n'es pas dev et tu n'as jamais utilisé GitHub

Si tu es développeur, tu n'apprendras rien ici. C'est fait exprès.

GitHub, c'est quoi ?

GitHub, c'est un endroit où tu stockes ton projet et où tu suis chaque modification. C'est tout.

Pense à Google Docs. Tu écris un texte, quelqu'un le modifie, tu vois l'historique des changements, tu peux revenir en arrière. GitHub fait la même chose, mais pour tous les fichiers de ton projet : le code, les images, la configuration, le contenu.

La différence avec Google Docs : sur GitHub, chaque modification est explicite. Tu ne sauvegardes pas en continu. Tu décides quand tu fais un point d'étape, tu décris ce que tu as changé, et tu l'enregistres. C'est plus structuré, et c'est exactement ce qui le rend puissant.

L'autre différence majeure : GitHub se connecte à des outils de déploiement comme Vercel. Tu push ton projet sur GitHub, Vercel le détecte et le met en ligne automatiquement. C'est le pipeline que j'ai décrit dans mon premier article.

Les 5 concepts à retenir

Tout GitHub tient en 5 mots. Avec ça, tu comprends ce qui se passe quand Claude Code te dit "je push sur GitHub".

1. Le repo

Un repo (repository), c'est un dossier de projet sur GitHub. Ton site web, ton outil interne, ton app : chacun a son repo. Tout est dedans : le code que l'IA a généré, les images, les textes, la configuration.

Quand tu démarres un projet avec Claude Code, la première chose à faire c'est de créer un repo. C'est la fondation. Sans repo, pas de sauvegarde, pas de déploiement.

2. Le commit

Un commit, c'est un point de sauvegarde. Tu as demandé à Claude de modifier la page d'accueil, le résultat te plaît, tu fais un commit. C'est une photo de ton projet à cet instant, avec un message qui décrit le changement.

Exemples concrets :

  • "Ajout de la page tarifs"
  • "Correction du lien cassé dans le footer"
  • "Refonte du texte de la homepage"

L'historique des commits, c'est la mémoire du projet. Qui a changé quoi, quand, et pourquoi. Et surtout : si Claude casse quelque chose (ça arrive), tu reviens à un commit précédent en une commande. C'est ton filet de sécurité.

3. La branche

Une branche, c'est une copie parallèle du projet dans laquelle tu peux travailler sans toucher à la version en ligne.

Ton site tourne en production, il est en ligne, tout va bien. Tu veux ajouter une section "témoignages clients". Tu crées une branche, tu travailles dessus avec Claude, tu testes. Si c'est bon, tu l'intègres. Si c'est raté, tu supprimes la branche. Le site en ligne n'a jamais bougé.

La version officielle, c'est la branche main. Tout le reste, c'est du travail en cours.

4. La Pull Request (PR)

Une Pull Request, c'est une demande pour intégrer tes modifications dans la version principale. Tu as bossé dans ta branche, le résultat te plaît, tu ouvres une PR.

La PR montre exactement ce qui a changé : les lignes ajoutées en vert, les lignes supprimées en rouge. C'est une étape de validation avant la mise en ligne.

Quand tu travailles seul, la PR peut sembler superflue. Mais elle a un avantage concret : les outils comme Vercel génèrent une URL de preview pour chaque PR. Tu vois exactement le résultat avant de toucher au site en production.

5. Le merge

Merger, c'est appliquer les changements de ta branche dans main. Une fois ta PR validée, tu merges, et tes modifications sont en production.

Si ton repo est connecté à Vercel, le merge déclenche automatiquement un déploiement. Tu merges, le site se met à jour. C'est tout le pipeline.

En pratique, avec Claude Code

Tu n'as pas besoin de retenir des commandes. Claude Code fait tout ça pour toi. Voici à quoi ressemble une session type :

  1. Tu dis à Claude : "crée une branche et ajoute une page contact"
  2. Claude crée la branche, écrit le code, te montre le résultat
  3. Tu valides, tu lui dis "commit et push"
  4. Claude fait le commit avec un message clair, pousse sur GitHub
  5. Tu ouvres la PR sur GitHub (ou tu demandes à Claude de le faire)
  6. Tu vérifies la preview Vercel
  7. Tu merges, c'est en ligne

Le workflow complet, de l'idée au site à jour, sans taper une seule commande Git.

Pourquoi c'est indispensable

Sans GitHub, chaque projet IA est un brouillon jetable. Tu génères, tu perds, tu recommences. Pas d'historique, pas de retour en arrière, pas de déploiement.

Avec GitHub, ton projet a une mémoire, un filet de sécurité, et un chemin vers la production. C'est la différence entre "ça marche sur mon ordi" et "tiens, clique sur ce lien".

Tu n'as pas besoin de maîtriser Git en ligne de commande. Tu n'as pas besoin de comprendre le rebase ou le cherry-pick. Tu as besoin de comprendre repo, commit, branche, PR, merge. Cinq mots. Et maintenant tu les connais.