Ton IA n'arrête pas de parler de Git. Faut-il s'en soucier ?
Ton outil d'IA parle de « commits », de « branches » ou de « push vers GitHub » comme si tout ça allait de soi.
Tu ne codes pas, donc tu peux facilement ranger ça dans la catégorie « technique que je n'ai pas besoin de comprendre ».
Je ne pense pas que tu puisses te permettre d'ignorer ce sujet. C'est la première chose que je regarde quand j'examine une app construite par IA pour quelqu'un : est-ce que ce projet garde un historique de ses changements. Pas pour que tu apprennes à « faire » du Git. Parce que sans ça, revenir proprement à une version précédente devient beaucoup plus difficile si ton agent IA fait un changement que tu n'avais pas demandé.
01 — C'est quoi, concrètement ?
Voici l'image la plus simple que j'aie trouvée : c'est l'historique des versions de Google Docs, appliqué à toute ton application.
Tu connais probablement déjà le principe : tu ouvres un Google Doc, tu cliques sur « historique des versions » dans un coin, et tu remontes tous les brouillons depuis la création du fichier. Google Docs enregistre les versions automatiquement. Git permet d'obtenir le même type d'historique pour un logiciel, mais cet historique se construit quand les changements sont enregistrés dans des commits.
Ça se passe en local : à chaque fois que ton agent IA (ou un développeur humain) commite un morceau de travail significatif, Git en garde une photo — ce qui a changé, quand, et une courte note expliquant pourquoi. Au bout de quelques semaines de développement, ça devient une vraie chronologie de ton app, pas juste son état actuel.
GitHub, c'est autre chose, et c'est le point à ne pas confondre : Git garde en mémoire l'historique. GitHub héberge et partage ce dépôt Git en ligne. Si Git est le suivi des modifications de Word, qui tourne sur la machine où travaille ton agent, GitHub est Google Drive — l'endroit où ce même document suivi est hébergé pour être accessible de partout, partagé avec quelqu'un d'autre, et pour survivre même si la machine d'origine disparaît. GitHub n'est pas lui-même l'historique de versions. C'est l'endroit où cet historique va se mettre à l'abri et devenir partageable.
Rien de tout ça ne demande d'ouvrir un terminal. Tout ce qui suit fonctionne via GitHub Desktop ou l'intégration GitHub intégrée à ton outil d'IA — quelques clics, aucune commande à retenir.
02 — Pourquoi s'en soucier si tu ne codes pas ?
Un agent de code autonome peut faire des changements que tu n'as pas explicitement demandés, ou dont tu ne remarqueras les conséquences que plus tard. Un historique de versions sert alors de filet de sécurité : il transforme « l'agent a cassé quelque chose et je ne sais pas quoi » en « voici ce qui a changé, et voici la version précédente ».
C'est l'une des premières choses que je regarde dans un Trust Report, parce que beaucoup d'autres questions deviennent plus simples dès qu'un historique fiable existe. Tout le reste — l'existence de tests, le fait qu'une vérification tourne avant qu'un changement parte en prod, l'exposition de secrets — se raisonne plus facilement une fois qu'on sait qu'il existe un historique auquel se comparer. Sans lui, un scan (ou une personne) ne peut même pas établir ce qui a changé entre « ça marchait hier » et « ça ne marche plus aujourd'hui ». Avec lui, cette question a une vraie réponse.
Il y a une deuxième raison, plus liée à la propriété qu'à la sécurité : à un moment donné, tu vas probablement confier ce projet à un développeur, prendre un associé technique, ou le montrer à un investisseur. Si la seule copie de l'historique de ton app vit dans le compte de ton outil d'IA, tu ne le contrôles pas vraiment — tu es invité dans le système de quelqu'un d'autre. Avoir le dépôt GitHub dans un compte ou une organisation que tu contrôles, avant que tout ça n'arrive, c'est ma recommandation, pas une règle du secteur que tout le monde suit. Mais c'est la différence entre confier un projet et confier un projet dont tu contrôles réellement le code source et l'historique.
03 — À quoi ressemble un projet bien structuré ?
Pas besoin de savoir lire du code pour vérifier l'essentiel. Cherche :
- Un dépôt existe, tout simplement. Quelque part, ce projet est suivi par Git — pas juste un dossier de fichiers sans historique derrière.
- Les commits sont significatifs, pas un seul gros paquet. Un historique utile contient des commits réguliers et compréhensibles dans le temps, plutôt qu'un seul énorme commit qui masque des mois de travail.
- Les changements en cours sont isolés d'une manière ou d'une autre — souvent avec des branches — au lieu d'envoyer chaque expérimentation directement vers la version en production.
- Un dépôt distant (« remote ») pointe vers GitHub — l'historique local ne reste pas coincé sur une seule machine ; il est sauvegardé et accessible en ligne.
- Toi (ou ton entreprise) contrôles le compte GitHub ou l'organisation sous lequel vit le dépôt — pas un compte qui appartient à ton outil d'IA, à un ancien prestataire, ou à personne en particulier.
Si tu n'as pas encore de compte GitHub ou de dépôt, les deux prennent quelques minutes, sans ligne de commande : créer ton compte GitHub explique l'inscription, et le guide de démarrage rapide pour créer un dépôt te guide pour en créer un. Ensuite, GitHub Desktop — ou le bouton « connecter à GitHub » intégré à ton outil d'IA — fait le reste.
Référence : l'expression « le Google Doc du code » utilisée par freeCodeCamp pour décrire Git est la première fois que j'ai vu cette analogie tenir la route pour un lecteur non-technique, et c'est celle à laquelle je reviens depuis.
04 — Que peux-tu demander sans risque à ton agent IA ?
Tu n'as besoin de vérifier aucun de ces points toi-même. Tu peux demander à ton outil d'IA de le faire pour toi — et la formulation exacte compte, parce que ne pas trouver de dépôt ne prouve pas qu'il n'existe pas. Si ton agent ne trouve pas de dépôt, la réponse honnête est « je n'en ai pas trouvé », pas « il n'y en a pas ». Copie-colle ce prompt tel quel :
Montre-moi si ce projet se trouve dans un dépôt Git. Si oui, montre la racine du dépôt, la branche actuelle, les commits récents, les tags et les remotes. Si tu n'en trouves pas, dis-moi simplement que tu n'en as pas trouvé — ne conclus pas qu'il n'y en a pas. Ensuite, explique-moi comment la dernière version fonctionnelle connue pourrait être restaurée. Ne fais aucun checkout, reset, revert, ni aucune modification.
Lis la réponse, n'agis pas encore dessus. Si ton agent trouve un vrai dépôt, des commits récents et un dépôt distant qui pointe vers GitHub, tu retrouves les principaux signaux décrits dans la section 3. S'il te répond qu'il n'a rien trouvé, c'est ton vrai point de départ — à comprendre avant de construire une semaine de plus dessus.
Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.