Git fête ses 21 ans en 2026. Créé par Linus Torvalds en quelques jours pour gérer les sources du kernel Linux, il a pris un virage inattendu : devenir le système de contrôle de versions universel de toute l’industrie logicielle. GitHub, GitLab, Bitbucket, les centaines de pipelines CI/CD — toute l’infrastructure du dev moderne orbite autour de lui. Chapeau pour la longévité.
Sauf que Git a un problème que personne n’aime trop admettre à voix haute : il ne passe pas à l’échelle. Microsoft a dû inventer Virtual File System for Git pour faire tourner le développement de Windows sur un repo de plusieurs dizaines de gigaoctets. Meta a créé Sapling, un fork interne adapté à ses besoins. Google n’utilise tout simplement pas Git en interne — Piper, leur système maison, est architecturalement différent. Quand les trois plus grosses boîtes tech du monde contournent l’outil plutôt que de l’utiliser, c’est un signal. C’est dans ce contexte que Lore a fait une entrée remarquée sur Hacker News : plus de 1100 points et près de 600 commentaires pour ce nouveau VCS open source, conçu dès le départ avec la scalabilité comme contrainte primaire.
TL;DR — Lore est un nouveau système de contrôle de versions open source qui prend la scalabilité comme fondation architecturale, pas comme feature ajoutée après coup. Le projet est encore jeune et l’écosystème reste à construire, mais l’approche est sérieuse et l’accueil de la communauté ne s’invente pas.
Git à grande échelle : le sale secret de l’industrie
Le problème n’est pas que Git est mauvais. C’est qu’il a été optimisé pour un cas d’usage précis : des repositories de taille raisonnable, un historique bien tenu, des équipes qui pratiquent le workflow fork/pull request. Pour 95 % des projets, ça marche. Mais pour les 5 % restants — monorepos de plusieurs giga, équipes de milliers de devs, projets qui cumulent dix ans de commits — c’est une autre histoire.
Les symptômes sont connus de quiconque a bossé sur un vrai gros projet. Le git clone qui prend un quart d’heure. Le git log qui rame sur 400 000 commits. Les merges catastrophiques sur des fichiers générés automatiquement. Les .gitignore de 200 lignes. Git LFS, les sparse checkouts, les shallow clones, les partial clones… chaque fonctionnalité ajoutée pour pallier une limite en crée deux nouvelles. À un moment, tu passes plus de temps à gérer ton VCS qu’à coder.
L’industrie a répondu à sa façon : en bricolant. Les monorepos à la Google ou Meta nécessitent des outils custom et des équipes entières dédiées à maintenir l’infra de versioning. C’est un luxe réservé aux très grandes structures. Les autres font avec les submodules (que tout le monde déteste), les workarounds, et l’espoir que leur repo ne grossisse pas trop vite.
Lore : repartir d’une ardoise vierge
L’avantage de créer un VCS en 2025, c’est de pouvoir regarder vingt ans de retours d’expérience sur Git et décider de ne pas reproduire les mêmes erreurs. Lore se donne exactement cette liberté. Pas de compatibilité ascendante à gérer, pas de décisions d’architecture des années 2000 gravées dans le marbre. Le modèle de données peut être repensé de fond en comble, avec les bons invariants dès le départ.
La promesse centrale du projet, c’est que la scalabilité n’est pas un add-on — c’est le point de départ. Le système de stockage des objets, la représentation des historiques, le protocole de synchronisation entre dépôts : tout est pensé pour tenir quand le volume monte. C’est le genre de décisions que tu ne peux pas vraiment rétroporter sur Git sans casser la compatibilité avec l’écosystème existant. Et l’open source est un choix important ici : les alternatives robustes pour les gros projets — Piper, Sapling — sont propriétaires, pas réplicables. Si Lore tient ses promesses, ce serait la première option vraiment accessible pour des équipes qui n’ont pas les moyens d’une GAFAM mais qui ont quand même des besoins de scalabilité sérieux, notamment celles qui développent une application sur mesure à forte croissance.
DÉCOUVREZ NOS RÉALISATIONS
MyLaser (DT Systemes)
Site e-commerce avec configurateur de decoupe laser pour DT Systemes a Sainte-Luce-sur-Loire (44). Upload de fichiers .dxf et devis instantane.
Voir le projet →Ce que l’architecture change concrètement
Lore repose sur un modèle de stockage adressable conçu pour paralléliser les opérations. Là où Git traite beaucoup d’opérations de façon séquentielle sur l’index, l’objectif est de distribuer la charge, notamment pour les opérations coûteuses : diffs sur de grands historiques, merges sur des arborescences massives, recherches dans des logs de centaines de milliers d’entrées.
Les structures de données sous-jacentes sont optimisées pour les requêtes fréquentes à grande échelle plutôt que pour la compacité maximale. C’est un trade-off conscient : tu consommes un peu plus d’espace disque, tu gagnes en vitesse de lecture. Pour des projets où l’historique est consulté des milliers de fois par jour par une CI/CD active — et dont les besoins d’hébergement et de performance sont critiques — ce n’est pas un détail.
Le protocole réseau est également repensé pour réduire les aller-retours lors de la synchronisation. Un git fetch sur un repo volumineux peut déclencher des négociations longues pour déterminer ce qui est déjà présent localement et ce qui manque. L’approche de Lore vise à compresser cette phase, ce qui se traduit par des syncs sensiblement plus rapides dans des environnements avec beaucoup de branches actives en parallèle.
Le vrai test pour tout nouveau VCS, c’est l’adoption par un projet open source majeur. Un Lore qui accueille le kernel Linux ou Chromium serait une démonstration bien plus éloquente que n’importe quel benchmark sorti en interne.
Jujutsu, Pijul, Fossil : Lore n’arrive pas dans le vide
Il serait malhonnête de présenter Lore comme le seul projet à challenger Git. Jujutsu (jj), développé par Google et open sourcé, propose un modèle de workflow radicalement différent tout en restant compatible avec les repos Git existants — il gagne doucement du terrain dans certaines équipes open source. Pijul prend un angle encore plus original : il utilise la théorie des patches et des CRDTs pour représenter l’historique, rendant certaines catégories de conflits de merge théoriquement impossibles. C’est intellectuellement fascinant, même si l’adoption reste de niche.
Lore se distingue de ces alternatives par son focus explicite sur la scalabilité, plutôt que sur l’ergonomie du workflow ou sur le modèle théorique des patches. Ce ne sont pas les mêmes combats : Jujutsu veut rendre Git plus agréable à utiliser au quotidien, Pijul veut résoudre les conflits de merge à la racine, Lore veut que ton repo de 100 Go soit aussi réactif qu’un repo de 100 Mo. Trois problèmes différents — et c’est une bonne nouvelle pour la diversité de l’espace VCS, qui en avait besoin.
Le vrai concurrent de Lore, ce n’est pas Git — c’est l’inertie de vingt ans d’outillage, de CI/CD, de plateformes et d’habitudes accumulées.
L’écosystème : le chantier qui prendra des années
C’est là que toute alternative à Git se heurte au même mur. Git n’est pas juste un outil — c’est une plateforme. GitHub, GitLab, Jenkins, GitHub Actions, les centaines de hooks et intégrations… L’écosystème représente probablement des milliards d’heures de travail accumulé. Migrer vers un nouveau VCS, c’est soit laisser tout ça derrière, soit reconstruire les équivalents depuis zéro. Aucune des deux options n’est triviale.
WESTCODE BY LEB
Studio web en Mayenne — On crée des outils numériques qui transforment
Lore devra se construire une migration path sérieuse et des intégrations avec les outils existants pour espérer une adoption au-delà des early adopters. Ça ne veut pas dire que c’est impossible — Git n’avait pas d’écosystème le premier jour non plus. Mais il a bénéficié d’un catalyseur exceptionnel : GitHub est arrivé au bon moment et a tout changé. Lore aura besoin de son propre déclencheur : un gros projet open source qui migre, une startup qui documente ses benchmarks, un éditeur qui intègre le support nativement. Ce sont des événements qui peuvent changer la trajectoire d’un projet en quelques mois.
Pour les équipes qui travaillent sur des projets à fort volume de code, surveiller Lore dès maintenant — même sans migrer — est une décision intelligente. Quand l’écosystème sera mûr, tu voudras ne pas partir de zéro sur la compréhension du projet.
Mon avis : trop tôt pour migrer, trop sérieux pour ignorer
Je ne vais pas te dire que Lore va « remplacer Git ». Ce serait du bullshit, et on n’est clairement pas là. Mais ce projet mérite une attention sérieuse, pas parce qu’il est propre et ambitieux, mais parce qu’il attaque un problème réel que l’industrie résout encore avec des rustines. Le score HN ne ment pas : 1100 points sur un projet aussi technique, c’est une communauté qui reconnaît que le problème existe et que quelqu’un travaille enfin dessus de façon structurée.
Ce qui me convainc le plus dans Lore, c’est moins la liste de fonctionnalités que le fait de partir du bon invariant. Concevoir la scalabilité comme contrainte primaire change fondamentalement toutes les décisions d’architecture qui suivent. Si cette fondation est solide, les fonctionnalités et l’écosystème peuvent se construire dessus. Si la fondation est bancale, aucune feature ne compensera. C’est le genre de pari architectural qu’on ne peut pas rejouer à mi-chemin.
Mon pari : dans deux ou trois ans, Lore aura soit été adopté par un projet open source majeur et ça changera la conversation, soit ses idées auront infusé dans des contributions faites à Git lui-même — ce qui serait presque aussi utile. Dans les deux cas, le fait que des développeurs sérieux passent du temps à repenser les fondements du contrôle de versions est une bonne nouvelle pour tout le monde. Git méritait depuis longtemps d’avoir de la vraie concurrence.
