OpenAI a présenté Pando, un nouveau backend Git qui assure désormais l’ensemble du développement dans son monorepo, c’est-à-dire un dépôt de code unique. Le client Git et le protocole restent inchangés : ingénieurs et agents Codex continuent d’exécuter les commandes git push et git fetch comme auparavant, seul le serveur a changé. Selon l’entreprise, la latence médiane des envois de code (push) a baissé de près de 80 %.
- OpenAI présente Pando, un nouveau backend Git qui remplace le serveur sans modifier le client.
- Pando réduit d’environ 80 % la latence médiane des envois de code.
- Il adopte une cohérence causale par branche et stocke les paquets sous forme de blobs immuables.
- Ces chiffres sont auto-déclarés, et Pando reste interne et non open source.
Pourquoi OpenAI a changé de backend
Les agents Codex ont multiplié les travaux menés en parallèle. Selon le graphique des commits publié par OpenAI, les commits sur la branche master ont progressé de 1 378 % au troisième trimestre 2026 par rapport au premier trimestre 2024, et l’estimation pour le quatrième trimestre 2026 atteint +2 442 %. Chaque envoi déclenche désormais de nombreuses récupérations de code par les outils d’intégration continue. Fin 2025, les récupérations et les envois ralentissaient, des fusions échouaient et la fiabilité est parfois descendue sous 90 %. L’entreprise en a conclu que le goulot d’étranglement venait de la manière dont elle servait Git, et non de Git lui-même.
Comment fonctionne Pando
Selon le billet d’ingénierie publié par OpenAI, Pando écarte deux hypothèses que la plupart des serveurs Git considèrent comme incontournables. La première concerne la cohérence à l’échelle du dépôt : les serveurs classiques ordonnent chaque mise à jour de référence pour l’ensemble du dépôt, de sorte que des envois sans lien entre eux doivent patienter. Pando adopte une cohérence causale, où chaque branche est traitée séparément et où les clients n’entrent en conflit que lorsqu’ils poussent la même référence. Le compromis est qu’un lecteur consultant plusieurs branches peut les voir à des moments différents.
La seconde hypothèse concerne la génération d’un paquet distinct pour chaque client. Les serveurs standard en créent un nouveau à chaque récupération, alors que Pando stocke chaque paquet envoyé sous forme de blob immuable, et enregistre une « version de référence » dans un magasin de métadonnées extensible. Un envoi nécessite un nombre constant de lectures et d’écritures de métadonnées, tandis qu’une récupération en exige un nombre proportionnel au logarithme de l’écart de versions à combler. Pour limiter la taille des envois, seule la branche principale est annoncée comme base pour les nouvelles branches. Dans le monorepo d’OpenAI, le paquet médian pèse moins de 20 KiB.
Les paquets sont ensuite distribués via packfile-uri, une fonctionnalité existante du protocole Git, et un service de livraison appelé Express les met en cache par région, avec un taux de succès supérieur à 99 %. Chaque envoi crée un paquet « L0 » que des processus en arrière-plan regroupent en paquets de plus en plus grands, jusqu’au niveau L4 pour le monorepo actuel. Ce mécanisme remplace la collecte des déchets traditionnelle de Git.
Des chiffres auto-déclarés
OpenAI indique que Pando traite près d’un pétaoctet de données Git par jour avec seulement quelques cœurs de processeur, et qu’il a servi plus de 57 To de paquets en une seule heure, dont plus de 99 % depuis le cache disque local. Sur des machines virtuelles cloud standard, clones et récupérations saturent des liens de 10 Gbit/s. L’entreprise a également mené des tests avec plusieurs milliers d’envoyeurs simultanés, sans dégradation selon elle. Tous ces chiffres sont auto-déclarés, et aucun benchmark indépendant n’a encore été publié.
Pando n’est pas open source, et OpenAI indique explorer des moyens de partager la technologie. Les lectures portant sur plusieurs branches n’ont pas de photographie unique du dépôt à un instant donné, et les envois répétés de branches empilées renvoient tout le contenu situé hors de la branche principale. Les correctifs apportés au client Git ont été remontés en amont, tandis que le backend reste interne pour l’instant.
