Qu'est-ce que GitHub? Le contrôle de version pour les non-développeurs

GitHub est un site web qui conserve le code de projets logiciels avec tout leur historique, afin que vous puissiez voir chaque modification, annuler des erreurs et travailler sur le même projet avec d'autres personnes. Il repose sur Git, un logiciel gratuit qui enregistre des instantanés des fichiers d'un projet au fil du temps. Git est l'outil qui conserve l'historique; GitHub est la maison en ligne où cet historique est partagé, sauvegardé et discuté.

Si vous créez avec l'IA, GitHub sert surtout à deux choses : être propriétaire d'une copie de votre code en dehors de l'outil avec lequel vous l'avez créé, et le remettre à un développeur dans le format qu'il utilise déjà.

Pourquoi c'est utile quand on crée avec l'IA

Un générateur d'applications par IA écrit et modifie beaucoup de code très rapidement, et chaque modification n'est pas forcément une amélioration. Le contrôle de version vous aide à garder le contrôle.

• Annulez en toute confiance. Chaque modification enregistrée est un instantané. Si l'IA casse quelque chose, vous revenez à la dernière bonne version.
• La propriété. Le code dans votre propre compte GitHub vous appartient, même si vous changez d'outil, arrêtez de payer pour celui que vous utilisiez ou souhaitez un deuxième avis.
• Travailler avec des développeurs. Presque tous les développeurs utilisent Git au quotidien. Un dépôt leur permet de revoir ce que l'IA a écrit, de le corriger et de vous renvoyer des modifications.
• Déployer ailleurs. Plusieurs plateformes d'hébergement peuvent déployer directement depuis un dépôt GitHub.

Une analogie du quotidien : les modifications suivies et un disque partagé

Imaginez un document avec le suivi des modifications activé, stocké dans un disque partagé.

• Git, ce sont les modifications suivies : chaque changement est enregistré, avec son auteur, sa date et sa raison, et vous pouvez revenir à n'importe quelle version.
• GitHub, c'est le disque partagé : le document vit en ligne, d'autres peuvent en obtenir une copie, et il y a un endroit pour commenter et approuver.
• Une branche ressemble à une copie enregistrée sous le nom « brouillon — nouvelle section tarifs » : vous pouvez expérimenter sans toucher à la version sur laquelle tout le monde compte. Si l'expérience fonctionne, vous la fusionnez.

La différence avec un document tient à l'échelle. Une application compte des centaines de fichiers, et Git les suit tous ensemble : un instantané représente l'état de tout le projet à un moment donné.

Les termes Git et GitHub que vous rencontrerez

Deux points méritent d'être soulignés. D'abord, l'historique Git est permanent par conception : si un mot de passe a été versé puis envoyé, le supprimer dans un commit ultérieur ne le retire pas de l'historique. Ensuite, un commit n'est utile que par son message. « Corriger le double comptage des réservations quand deux personnes réservent en même temps » vous aidera plus tard; « mise à jour » ne vous aidera pas.

Exemple concret : confier une application créée avec l'IA à un pigiste

Vous avez créé un portail client avec un générateur d'applications par IA. Il fonctionne, mais vous voulez qu'un développeur pigiste ajoute une intégration délicate avec votre logiciel de comptabilité.

1. Reliez le projet à un nouveau dépôt GitHub privé et envoyez le code. Le dépôt contient maintenant le code et son historique.
2. Vérifiez ce qui s'y trouve. Ouvrez le dépôt sur GitHub. Il ne devrait y avoir aucun fichier .env ni aucune clé d'API dans le code. Les secrets restent dans les paramètres de votre plateforme et ne sont partagés avec le pigiste que séparément, si nécessaire. Voir variables d'environnement et secrets.
3. Invitez le pigiste comme collaborateur sur ce dépôt seulement.
4. Il travaille sur une branche nommée par exemple synchro-comptabilite, fait des commits au fil de son travail, puis ouvre une demande d'extraction (pull request) quand il a terminé.
5. Vous examinez la demande d'extraction. Même sans lire le code, vous pouvez lire la description, voir quels fichiers ont changé et poser des questions dans les commentaires.
6. Fusionnez lorsque vous êtes satisfait, puis récupérez (pull) les modifications dans votre générateur afin que vous et l'IA continuiez à partir de la nouvelle version.

Tout au long du processus, vous pouvez voir exactement ce qui a changé et l'annuler au besoin. C'est là toute la valeur du contrôle de version, en un seul flux de travail. Si vous hésitez encore à faire appel à un développeur, voir engager un développeur ou créer avec l'IA.

Erreurs courantes et idées reçues

• « GitHub et Git, c'est la même chose. » Git fonctionne sans GitHub; des solutions comme GitLab et Bitbucket hébergent aussi des dépôts Git.
• « GitHub fera tourner mon application. » GitHub stocke le code. Le faire fonctionner pour le public relève de l'hébergement web, un service distinct (même si certains hébergeurs déploient depuis GitHub).
• Verser des secrets dans le code. C'est l'erreur la plus dommageable et la plus fréquente. Utilisez .gitignore pour les fichiers .env, et renouvelez toute clé qui a déjà été envoyée.
• Une seule branche et aucun message. Acceptable pour des expériences en solo, mais donnez des messages clairs à vos commits et utilisez des branches pour tout ce qui est risqué.
• Modifier à deux endroits à la fois. Si vous changez le code dans GitHub et dans votre générateur d'IA sans récupérer les modifications entre les deux, vous créez des conflits. Choisissez un seul endroit pour modifier à la fois, et synchronisez avant de changer.
• Croire qu'un dépôt privé est une sauvegarde de tout. Il contient le code, pas le contenu de votre base de données ni les fichiers téléversés. Ceux-ci ont besoin de leurs propres sauvegardes.

Quoi demander à votre générateur d'IA

• « Ajoute un .gitignore qui exclut .env, les dossiers de dépendances et les fichiers de build. »
• « Écris un README qui explique comment installer l'application, quelles variables d'environnement sont nécessaires (noms seulement) et comment la lancer. »
• « Ajoute un .env.example avec chaque nom de variable et aucune vraie valeur. »
• « Utilise des messages de commit clairs et descriptifs pour chaque modification. »

Ces quatre demandes produisent un dépôt qu'un développeur peut prendre en main en quelques minutes. Pour transférer l'application sur vos propres serveurs, voir comment exporter une application créée par IA et l'héberger soi-même, et pour la renforcer avant d'accueillir de vrais utilisateurs, faire passer un prototype IA en production.

GitHub et Mythex

Mythex conserve l'historique pour vous sur tous les forfaits : après chaque tour réussi de l'agent, il enregistre un point de contrôle, c'est-à-dire un instantané Git auquel vous pouvez revenir. Avec le forfait Pro, vous pouvez connecter GitHub et envoyer ou récupérer le projet dans votre propre dépôt, ou télécharger le projet complet sous forme d'archive; les secrets et les dépendances installées sont exclus des exportations. Ici, GitHub sert à synchroniser le code, et non à vous connecter à Mythex. Voir GitHub, exportation et importation dans la documentation, et la page de tarification pour ce que comprend chaque forfait.

Questions