Comment Cursor a contourné les limites de Git à grande échelle

Cursor, l'éditeur de code IA, a dû résoudre un vrai problème de scalabilité de Git pour fonctionner correctement sur de très grandes codebases. Voilà ce qu'ils ont fait - et pourquoi ça intéresse tout dev senior.

Le cas concret

Imaginez une codebase de plusieurs millions de lignes - le genre qu'on trouve dans les grands groupes tech, les projets open source matures, ou les mono-repos de startup qui ont grandi vite. Git commence à avoir du mal : git status prend des secondes, les opérations courantes deviennent frustrantes. Maintenant ajoutez un outil d'IA (Cursor) qui doit comprendre l'état du repo en temps réel pour contextualiser ses suggestions. Le problème devient critique.

C'est exactement ce que Cursor a rencontré - et The Register détaille comment ils ont contourné les limites de scalabilité de Git.

Le problème de fond : Git n'est pas conçu pour l'IA

Git a été conçu par Linus Torvalds en 2005 pour gérer le noyau Linux - une codebase large mais avec un modèle d'utilisation humain : des développeurs qui committent, branchent, mergent. Git n'a pas été pensé pour un outil IA qui lit l'état du repo des dizaines ou centaines de fois par minute pour alimenter ses suggestions en temps réel.

Les goulots d'étranglement sont connus :

• Index Git : le fichier .git/index est relu entièrement à chaque opération de status, même pour un seul fichier modifié.
• Object store : la récupération d'objets par hash n'est pas optimisée pour les lectures massives et répétées.
• Filesystem hooks : sur Windows et macOS, les watchers filesystem ajoutent de la latence.

Ce que Cursor a fait : S3 comme source de vérité, NVMe local pour la latence

L'approche de Cursor révélée par The Register repose sur une architecture en deux niveaux : S3 (stockage objet cloud) comme source de vérité pour le repository, et des repos locaux sur NVMe (SSD haute performance) pour le travail sensible à la latence.

Concrètement, plutôt que de faire travailler l'IA directement sur le repo Git local avec ses limitations de scalabilité, Cursor maintient une copie canonique dans S3 et utilise des caches NVMe locaux pour les opérations qui exigent une réponse rapide. La synchronisation entre les deux niveaux est optimisée pour minimiser les lectures complètes de l'index Git.

C'est le genre de problème que les devs seniors connaissent bien : les abstractions standard tiennent jusqu'à un certain point, puis il faut descendre au niveau inférieur - ici, repenser complètement le modèle de stockage plutôt que d'optimiser à la marge les appels git.

Pourquoi ça intéresse tout le monde

La solution de Cursor a des implications au-delà de leur outil :

• Mono-repos : toute équipe qui travaille sur un mono-repo de taille significative rencontre ces problèmes. L'architecture S3 + NVMe locale est transposable.
• Git LFS : résout le problème des gros fichiers binaires, pas la scalabilité de l'index. C'est un problème ouvert que Cursor a contourné autrement.
• Outils IA sur codebase : tous les outils d'analyse statique, de code review assistée, ou de génération de code vont rencontrer ce problème en grandissant.