Prenons le cas d’une petite application que vous avez créée avec Claude, Cursor ou un autre outil d’IA et qui accueille déjà ses premiers utilisateurs. Le formulaire fonctionne, les inscriptions arrivent, vous commencez même à vous trouver un certain talent pour le développement. Sauf que, surprise, vous vous rendez compte qu’il manque un champ téléphone et que le bouton serait mieux un peu plus bas ; vous demandez alors à votre agent IA, l’outil qui modifie le code pour vous, de faire ces modifications, qu’il accompagne d’une petite « amélioration de l’architecture ». Si vous envoyez ce résultat directement sur le site en ligne, les bugs que vous auriez normalement corrigés avant de publier deviennent soudain visibles par tous vos utilisateurs, puisque vous n’avez pas essayé cette version à part.
Et c’est là que Git et GitHub deviennent intéressants : avec Git, vous pouvez conserver une version du code avant de demander à l’IA d’ajouter le champ téléphone, puis une autre après sa modification. Si vos utilisateurs ne peuvent plus se connecter à leur compte, vous avez alors les fichiers d’avant et d’après pour chercher ce qui a changé ; vous pouvez aussi retrouver le code qui fonctionnait. En envoyant ces versions sur GitHub, vous les conservez en ligne et vous pouvez montrer les changements à un développeur ou à un autre agent pour qu’il vous aide à les vérifier.
Vous allez reprendre ce formulaire pour conserver le code qui fonctionne, préparer l’ajout à part et le vérifier avant le déploiement sur le site public.
Dans cet article
C’est quoi GitHub ? Quelle différence avec Git ?
Les deux noms se ressemblent, mais désignent deux outils distincts. Git est le logiciel qui garde l’historique de votre projet, sur la machine où se trouvent ses fichiers. Sans lui, lorsque l’agent modifie le fichier du formulaire, le nouveau contenu remplace l’ancien et plus rien ne se souvient de ce qui fonctionnait la veille ; avec lui, vous désignez les états du projet à conserver, pour les comparer ou y revenir.
Cet historique reste toutefois sur une seule machine, où ni un développeur ni un outil extérieur ne peuvent le consulter. GitHub est la plateforme en ligne où vous en envoyez une copie. Le projet y est rangé avec son historique dans un dépôt, ou repository, public s’il est lisible par tous, privé s’il est réservé aux personnes et aux outils que vous autorisez ; pour une application qui a déjà des utilisateurs, choisissez-le privé.
Vous n’aurez pas de commandes à apprendre pour autant : votre agent peut exécuter ces gestes, et GitHub Desktop, une application gratuite, les présente sous forme de boutons. Votre part consiste à comprendre ce qu’on vous soumet avant de l’accepter, ce qui manquait le jour où l’« amélioration de l’architecture » est partie sur le site public.
Comment connecter Claude et ChatGPT à GitHub ?
Tant que votre projet n’est relié à rien, Claude ou ChatGPT n’en connaissent que les morceaux de code que vous collez dans une conversation. Or, avant d’ajouter le téléphone, vous voulez leur demander où se trouve le formulaire et ce que fait le code entre l’envoi d’une inscription et la connexion au compte. Pour y répondre, l’IA doit lire tous les fichiers du projet, ce que GitHub permet une fois que vous l’y avez autorisée.
Il faut donc que le projet se trouve sur GitHub, puis que vous donniez à l’IA le droit de l’y lire. Ce droit suffit pour se faire expliquer le formulaire ; pour le modifier, vous passerez ici par un agent de programmation, Claude Code chez Anthropic ou Codex chez OpenAI.
Envoyer d’abord le projet sur GitHub
Il vous faut un compte sur github.com, dont l’offre gratuite inclut les dépôts privés. La suite dépend de l’endroit où se trouve votre projet, avec une précaution commune : tout ce qui part sur GitHub reste dans l’historique du dépôt, même après suppression, si bien que vos mots de passe et vos clés d’accès ne doivent pas y être envoyés.
Mon projet est déjà sur GitHub
Vous le retrouverez parmi les dépôts de votre compte et pouvez passer à la liaison avec l’IA.
J’utilise un éditeur en ligne
Dans cet outil, qui fabrique l’application et la fait tourner depuis votre navigateur, cherchez un bouton GitHub : lorsqu’il existe, il crée le dépôt et y copie le code à votre place. Vérifiez seulement que mots de passe et clés restent à l’écart.
Mes fichiers sont sur mon ordinateur
Demandez à l’agent avec lequel vous codez d’écarter les fichiers qui contiennent ces mots de passe et ces clés, puis de placer le dossier sous le suivi de Git et d’y conserver une première version, puisque GitHub reçoit un historique et non un simple dossier.
GitHub Desktop envoie ensuite ce dossier : File > Add local repository lui indique où il se trouve, puis Publish repository en copie le contenu sur GitHub. Malgré son nom, ce bouton ne déploie rien sur votre site. Laissez cochée la case Keep this code private pour que le dépôt soit privé.
La première question à poser
Quel que soit l’outil relié, commencez par lui demander où se trouve le formulaire et comment il fonctionne, sans rien modifier. Sa réponse confirme qu’il regarde le bon projet et décrit ce qui fonctionne aujourd’hui, ce qui vous servira de point de comparaison pour ce qu’il proposera.
À quoi sert un commit Git ?
Avant de laisser l’agent toucher à ce formulaire, vous voulez mettre son état actuel à l’abri, car dès qu’il aura modifié un fichier et l’aura enregistré, ce fichier ne contiendra plus que son nouveau code. Un commit est un état du projet que vous demandez à Git de conserver dans son historique, accompagné d’un message qui dit ce qui a été fait. L’agent peut le préparer pour vous.
Vous en possédez déjà un, puisque la première version envoyée sur GitHub était un commit ; appelons-le « Formulaire fonctionnel ». Après l’ajout, « Ajoute le téléphone au formulaire » vous donnera un second état à comparer au premier si vos utilisateurs n’arrivent plus à se connecter. Soignez ces messages : quinze commits appelés « modifs » vous laisseront, le jour du bug, le plaisir de reconstituer vous-même votre propre travail.
Créer un commit ne l’envoie pourtant pas sur GitHub. Enregistrer un fichier, en faire un commit et l’envoyer en ligne par un push sont trois gestes distincts, que le schéma sépare dans le cas où l’agent travaille sur votre ordinateur.
Quelle différence entre push, pull et clone ?
Ce schéma ne montrait qu’un sens, de votre ordinateur vers GitHub. Dès qu’un agent travaille dans le cloud ou qu’un développeur vous aide, chacun possède sa propre copie du dépôt, appelée dépôt local même lorsqu’elle se trouve sur une machine distante, et GitHub devient le point par lequel ces copies s’échangent leurs commits. Le schéma distingue les trois échanges possibles.
Le push vous servira lorsque des commits auront été créés sur votre ordinateur, et le pull dans la situation inverse : une fois que Claude Code ou Codex a envoyé les siens sur GitHub, c’est votre dossier qui a du retard. Le clone sert le jour où le projet existe sur GitHub sans que vous en ayez de copie sur l’ordinateur devant vous, par exemple parce qu’il est né dans un éditeur en ligne.
Lorsque deux copies avancent chacune de leur côté, récupérez le travail des autres avant de reprendre le vôtre. Si les mêmes lignes ont tout de même été modifiées de façon incompatible, Git signale un conflit, et il faut décider ce qu’on garde de chaque version. L’IA peut vous y aider, mais demandez-lui ce qu’elle a conservé plutôt que de vous contenter de voir disparaître le message.
Pour retrouver ces échanges en ligne de commande : le chapitre de Pro Git sur les dépôts distants.
À quoi servent les branches et les pull requests ?
Jusqu’ici, les commits se suivent sur une seule ligne, dont le dernier arrivé devient la version actuelle du projet. Or vous allez demander un ajout dont personne ne sait encore s’il fonctionne : s’il rejoint cette ligne, la version actuelle devient celle où le téléphone n’a jamais été essayé.
Cette ligne est la branche principale, souvent nommée main. Pour préparer l’ajout sans y toucher, on en fait partir une seconde branche, par exemple ajout-telephone, qui démarre avec le code actuel et reçoit les commits de l’agent pendant que main reste intacte. Demandez-la avant que l’agent commence, s’il ne la crée pas de lui-même.
L’ajout ne doit pourtant pas rejoindre main sans que vous l’ayez regardé. C’est le rôle de la pull request, ou PR : une demande d’intégrer la branche dans main, ouverte sur GitHub par l’agent ou par vous une fois la branche envoyée, même si vous travaillez seul. Malgré son nom, c’est une autre opération que le pull de la section précédente. Le schéma suit le champ téléphone jusqu’à la fusion, ou merge, qui a lieu lorsque vous acceptez la PR.
La page de la PR réunit la description du travail et le diff, c’est-à-dire les lignes ajoutées et retirées, fichier par fichier. Si vous ne lisez pas le code, regardez d’abord combien de fichiers ont été touchés : un champ téléphone n’a guère de raisons d’en concerner vingt, et si c’est le cas, vous avez désormais un endroit où demander à l’agent ce qui lui a pris, avec le code sous les yeux. Faites ensuite expliquer les changements par un second agent de programmation capable de lire la PR, et relire par une personne compétente ceux qui touchent aux comptes ou aux paiements sans que vous compreniez pourquoi.
Pour essayer ce parcours : Hello World et GitHub flow.
Préproduction et production : où essayer votre code ?
La PR montre ce que l’agent a écrit, mais aucun diff ne dit si l’inscription fonctionne encore : pour le savoir, il faut remplir le formulaire, donc faire tourner quelque part la version de la branche. Votre site tourne chez un hébergeur, le service qui le fait fonctionner sur Internet, et y installer une version du code pour la mettre en service s’appelle un déploiement.
Aujourd’hui, votre code n’est déployé qu’à un endroit, le site que vos utilisateurs visitent, appelé la production ; y essayer la branche reviendrait à refaire l’expérience de l’introduction. Il vous faut une préproduction, c’est-à-dire une copie du site, à une autre adresse, où tourne la version de la branche pendant que la production garde l’ancienne. Le schéma montre ce que cette copie doit avoir en propre.
Une branche ne crée pas cette copie, puisqu’elle ne sépare que le code ; elle s’obtient du côté de l’hébergeur. Lorsque son intégration avec GitHub est configurée, Vercel peut par exemple fournir une adresse de prévisualisation pour une PR. Ailleurs, demandez à l’agent comment obtenir une copie d’essai.
Avant de vous servir de cette adresse, faites vérifier où elle écrit. Ni Git ni la nouvelle adresse ne garantissent la séparation des données, qui dépend de la configuration du projet : la copie doit ranger ses inscriptions dans sa propre base de données et utiliser son propre stockage, avec leurs identifiants, faute de quoi vos essais modifieront de vrais comptes.
Remplissez alors le formulaire avec un téléphone fictif, envoyez l’inscription, puis essayez de vous connecter avec ce compte. Si cela échoue, l’agent corrige son ajout sur la branche pendant que vos visiteurs gardent l’ancien formulaire. Si tout fonctionne et que la PR vous convient, vous pouvez fusionner puis déployer en production le code vérifié ; les comptes fictifs restent dans la base d’essai. Selon la configuration de votre hébergeur, la fusion dans main peut suffire à déclencher ce déploiement : demandez à l’agent ce qui le déclenche chez vous, et terminez vos vérifications avant de fusionner si c’est le cas.
Comment annuler une modification qui casse le projet ?
Vous avez essayé l’inscription et la connexion, mais pas tout le reste, et l’ajout peut casser en production quelque chose que vous n’aviez pas pensé à vérifier. Il faut alors rétablir le site pour vos utilisateurs avant de chercher la cause, donc retirer l’ajout de main. C’est ce que fait un revert : un nouveau commit qui annule celui que vous désignez, sans rien effacer de l’historique.
Si l’ajout est passé par une PR fusionnée sur GitHub, ouvrez sa page et cliquez sur Revert : avec les droits nécessaires et en l’absence de conflit, GitHub prépare une seconde PR qui annule la première, à relire puis à fusionner. Dans GitHub Desktop, ouvrez History, faites un clic droit sur le commit, choisissez Revert Changes in Commit, puis envoyez ce nouveau commit avec un push. Si un conflit apparaît, confiez la préparation de l’annulation à l’agent.
L’annulation ne répare le site public qu’une fois déployée à son tour. Vérifiez-le, puis essayez le formulaire, car des changements plus récents pouvaient dépendre de ce que vous venez de retirer ; l’agent pourra ensuite, à tête reposée, comparer les versions pour trouver la cause. Le revert ne ramène toutefois que du code : si le bug a effacé une inscription, remettre les anciens fichiers ne recrée pas ce compte, et les données de vos utilisateurs ont besoin de leurs propres sauvegardes.
Quels fichiers garder hors d’un dépôt GitHub ?
L’historique qui vient de vous tirer d’affaire a un revers : un mot de passe passé par erreur dans un commit y reste, même si vous supprimez sa ligne dans la version suivante. C’est la raison de la précaution prise avant le premier envoi, qui concerne les mots de passe, les clés d’API, ces codes qui donnent à votre application l’accès à un service, et les données de vos clients. Un dépôt privé n’en dispense pas, car il reste lisible par les personnes et les outils que vous y autorisez, à commencer par les agents que vous venez d’y relier.
Mots de passe et clés se trouvent d’ordinaire dans un fichier .env, ou dans les réglages de votre hébergeur. Pour que ce fichier ne parte pas avec le reste, l’agent prépare .gitignore, la liste des fichiers que Git doit laisser de côté ; le schéma montre le tri qui en résulte.
Le .env.example envoyé sur GitHub ne contient que des valeurs fictives, pour indiquer quels réglages le projet attend. Quant à .gitignore, il n’agit que sur les fichiers que Git ne suit pas encore : un fichier déjà ajouté continue d’être suivi et reste dans les anciens commits, d’où l’intérêt de faire ce tri avant le premier.
Si une clé est déjà partie sur GitHub, désactivez-la d’abord chez le service qui vous l’a délivrée et demandez-en une nouvelle, car c’est ce geste qui empêche quelqu’un qui l’aurait copiée de s’en servir. L’effacer ensuite de l’historique reste possible, mais GitHub précise que cette opération a des effets sur les autres copies du dépôt et peut être inutile une fois la clé désactivée ; faites-vous aider avant de la lancer.
Ce que vous pouvez demander à votre IA
Vous connaissez maintenant chacun des mots de la consigne qui suit : vous pouvez la lire avant de la coller, puis vérifier que l’agent a fait ce qu’elle demande pour l’ajout du téléphone.
Repère le formulaire dans le dépôt et explique-moi son fonctionnement avant de le modifier. Si des changements ne sont pas encore dans un commit, ne les écrase pas, et pars d’une version qui fonctionne.
Ajoute le téléphone sur une branche dédiée, sans y mettre de mot de passe ni de clé d’accès. Dis-moi à quelle adresse essayer le formulaire sans toucher au site public ni aux vraies données ; s’il n’existe pas de copie d’essai, explique ce qu’il faut préparer. Vérifie l’inscription et la connexion au compte.
Prépare les commits, envoie la branche et ouvre la PR si tu en as les accès. Présente les changements et ce que tu as vérifié. Explique ce qui déclenche le déploiement en production, puis attends mon accord avant toute fusion et tout déploiement.Ses règles générales vaudront pour les modifications suivantes : rangez-les à la racine du projet, dans le fichier que l’agent lit en démarrant, CLAUDE.md pour Claude Code ou AGENTS.md pour Codex. Notre guide Markdown (.md) explique comment écrire ces fichiers, et notre méthode pour retrouver les corrections d’un travail à l’autre montre comment les faire évoluer. Une consigne reste cependant une demande : si l’agent a le droit de fusionner ou de déployer, seule une limitation de ses accès l’en empêche réellement.
Ce guide accompagne la newsletter V&M sur la création d’une application avec l’IA.
