Si tu diriges une activité 100 % cloud, le clone local d’un dépôt GitHub finit souvent par devenir un doublon pénible : même code ici, même code là, disque saturé, versions qui divergent.
Avec des agents IA (assistants qui lisent et modifient le code pour toi), ce doublon devient encore plus coûteux. Plusieurs agents, une seule vérité : le cloud.
Cet article explique, en français simple, ce qu’on appelle le mode remote-first (ou GitHub-first), où l’on travaille via l’API et des Pull Requests, sans garder une copie permanente du projet sur la machine.
Comment ça s’appelle ?
En jargon courant, on parle de :
- remote-first / GitHub-first — la source de vérité est sur GitHub, pas sur ton disque ;
- API-driven Git — on lit et on écrit le dépôt via l’API GitHub ;
- PR-based workflow — chaque changement passe par une branche courte et une Pull Request (PR).
Ce n’est pas « éditer le disque dur de GitHub comme un NAS ». GitHub n’est pas un dossier Windows réseau. C’est un coffre de versions (commits Git).
Où sont les fichiers pendant l’édition ?
Voici le cycle réel :
- Lecture — GitHub envoie le contenu via l’API. L’agent le voit en mémoire, parfois dans un fichier temporaire (
tmp/) qui sera effacé. - Écriture — L’agent envoie un commit (souvent via une PR). GitHub enregistre une nouvelle version.
- **Branche principale (
main) — elle ne bouge que quand une PR est mergée**. Ouvrir une PR ne met pas encoremainà jour.
+------------------+ API +------------------+
| Agent / Cloud | -----------> | GitHub (coffre) |
| Shell (léger) | <----------- | commits + PRs |
+------------------+ contenu +------------------+
| |
| tmp jetable | main = merge
v v
pas de monorepo source de vérité
permanent local
Clone local vs remote-first : à quoi ça sert ?
| Clone local | Remote-first (API + PR) | |
|---|---|---|
| Objectif | Atelier sur ton disque : grep, builds, éditeur hors ligne | Coffre unique pour humains + agents IA |
| Disque | Copie complète (souvent des centaines de Mo / Go) | Quasi rien de durable ; parfois tmp/ |
| Multi-agents | Risque de copies divergentes | Tous voient le même GitHub |
| Doublon | Oui : local + GitHub | Non : GitHub seul |
**Quand main change** |
Après push + merge (selon ton flux) |
Après merge de PR |
Objectif du clone local : confort d’édition et d’exécution sur une machine (surtout quand un humain travaille longtemps hors ligne ou lance des tests lourds localement).
Objectif du remote-first : collab cloud, agents IA, machines frugales (Cloud Shell sans swap), une seule vérité.
Les deux sont valides. Pour une entreprise déjà 100 % cloud, le remote-first retire le doublon que tu ressentais comme une mauvaise idée.
« Disque GitHub » : quelle capacité, quelle écriture ?
GitHub n’est pas un disque de 500 Go pour y travailler comme sur Windows.
- Ce sont des dépôts Git avec des limites souples (ordre de grandeur : mieux vaut rester sous quelques Go par dépôt ; fichiers individuels idéalement sous ~100 Mo).
- Les gros médias (images blog, PDF…) vont plutôt sur un stockage objet cloud, pas dans Git.
- La « puissance d’écriture » du quotidien :
- avec clone → surtout le disque de la machine (ex. Cloud Shell ~5 Go persistants) ;
- sans clone → presque rien de durable sur la machine ; l’écriture utile est le commit enregistré chez GitHub.
En remote-first, tu n’« usines » pas un disque GitHub comme un SSD : tu ajoutes des versions dans le coffre.
Une entreprise 100 % cloud : une vérité, plusieurs coffres
Chez une entreprise déjà 100 % cloud, le découpage typique ressemble à ceci :
- GitHub (ou équivalent) — code, scripts, historique technique ;
- Tableur / CMS — contenus éditoriaux (source de vérité rédactionnelle) ;
- Plateforme de blog — publication publique ;
- Stockage objet — images et médias.
Le journal de machine (Cloud Shell ou VM légère) reste un carnet d’ops — pas une seconde copie du monorepo.
C’est cohérent avec une trajectoire d’entrepreneur constamment 100 % cloud : moins de copies, plus de coffres partagés.
En une phrase
Le clone local est un atelier ; GitHub remote-first est le coffre. Avec des agents IA, le coffre unique évite le doublon — et main n’avance qu’au merge.
Si tu construis déjà ton activité dans le cloud, ce mode n’est pas une mode : c’est simplement aligner les agents sur la même discipline que ton entreprise.