Pando : OpenAI rend Git plus scalable pour son monorepo

OpenAI a publié le 2 novembre 2026 Scaling Git at OpenAI, un article qui détaille Pando, son backend Git-compatible. L’enjeu est simple : garder Git fluide quand un monorepo reçoit beaucoup de branches, de pushes, de fetches et de contributions issues d’agents de code.

Pando alimente désormais tout le développement dans le monorepo d’OpenAI. L’entreprise affirme l’avoir construit sans interrompre le travail des équipes, ni changer leur manière d’utiliser Git.

Ce qui change concrètement

Pando n’est pas présenté comme un nouveau client Git. C’est un backend pour dépôts Git. OpenAI insiste sur un point clé : Pando conserve la compatibilité avec le protocole Git et les clients Git existants. Les ingénieurs et les agents peuvent donc l’utiliser dans des workflows déjà en place.

OpenAI explique avoir conçu Pando autour de deux objectifs. Le premier concerne les écritures : elles doivent être horizontalement scalables, avec une optimisation pour des pushes concurrents sur de nombreuses branches. Le second concerne les lectures : le système doit maximiser le débit pour saturer la bande passante disponible côté client lors des fetches.

Le choix le plus important touche à la gestion des branches. Pando coordonne les mises à jour de chaque branche indépendamment. Des branches non liées peuvent donc être traitées en parallèle. Dans un grand monorepo, cela évite qu’un push bloque inutilement d’autres travaux sans relation directe.

Autre point technique : Pando réutilise les packfiles Git entre plusieurs fetches. Au lieu de générer un packfile par client, le backend peut servir des packs déjà préparés. OpenAI affirme que Pando délivre désormais près d’un pétaoctet de données Git par jour, avec seulement quelques cœurs CPU. L’entreprise cite aussi plus de 57 téraoctets de packs Git servis en une heure, dont plus de 99 % des octets provenaient du cache disque local.

Côté résultats, OpenAI indique que Pando a réduit la latence médiane des pushes d’environ 5 fois. Plus loin dans son article, l’entreprise précise que le passage à Pando a réduit la latence du push médian d’environ 80 % et amélioré la fiabilité des merges. MarkTechPost reprend également cette baisse d’environ 80 % et souligne le rôle de la réutilisation des packfiles.

Comment l'essayer

Pando n’est pas annoncé comme un service public, ni comme un produit autonome. OpenAI ne communique pas de prix, de disponibilité commerciale, ni de procédure d’accès pour des entreprises externes. À ce stade, Pando est décrit comme le backend qui alimente le monorepo interne d’OpenAI.

Pour les utilisateurs, le lien indirect passe surtout par Codex. Le centre d’aide OpenAI indique que Codex est inclus dans les offres ChatGPT Free et Go, avec des limites d’usage variables selon le plan. Il précise aussi que Codex Cloud est disponible pour les comptes Plus éligibles, ainsi que pour tous les comptes Business, Enterprise, Healthcare et Education, sous réserve du déploiement et des paramètres du workspace.

En France, OpenAI indique que ChatGPT est actuellement supporté. Pour les organisations européennes, la page officielle sur la résidence précise que la data residency de ChatGPT est disponible en Europe, dans l’EEE et en Suisse. La même page indique que l’inference residency de ChatGPT est disponible en Europe, aux États-Unis et aux Émirats arabes unis.

Pour qui, et pour quoi faire

Le cas d’usage le plus parlant concerne une entreprise qui travaille dans un grand monorepo, avec plusieurs équipes produit, beaucoup de branches et des outils d’IA capables de produire ou préparer du code. Dans ce contexte, Git peut devenir un point de contention : les pushes, les fetches et les merges consomment de plus en plus d’infrastructure.

Avec une approche comme Pando, l’objectif n’est pas de demander aux développeurs de changer leurs habitudes. Les développeurs gardent Git. Les agents peuvent aussi interagir avec les dépôts via des workflows compatibles. C’est le backend qui absorbe mieux la concurrence sur les branches et sert plus efficacement les données déjà disponibles.

Exemple concret : une plateforme logicielle interne où des équipes backend, frontend, data et sécurité travaillent dans le même monorepo. Si plusieurs agents Codex préparent des modifications en parallèle, la pression se reporte sur les opérations Git. Un backend pensé pour les pushes concurrents et les lectures à haut débit aide à maintenir une boucle de développement plus stable.

Limites et points de vigilance

Pando ne signifie pas que toutes les entreprises doivent reconstruire leur backend Git. OpenAI décrit un besoin lié à son échelle, à son monorepo et au développement rendu possible par Codex. Une organisation plus petite peut ne jamais rencontrer ces limites.

Il faut aussi distinguer compatibilité et facilité de déploiement. Pando conserve le protocole et les clients Git, ce qui réduit le changement côté utilisateur. Mais OpenAI ne fournit pas de paquet prêt à installer, ni de feuille de route publique pour une adoption externe.

Enfin, la performance Git ne suffit pas à cadrer l’usage d’agents de code. Les permissions, les règles de branche, la revue humaine, la sécurité du dépôt, les paramètres de workspace et la résidence des données restent à vérifier avant tout déploiement large.

L'avis NXUS

Pando met en lumière un sujet très concret pour les DSI : les agents de code augmentent la pression sur les outils de développement existants. Le bon réflexe n’est pas de copier l’architecture d’OpenAI, mais de mesurer où les workflows ralentissent déjà : fetches, pushes, merges, revues ou CI.

Si tu pilotes une équipe tech, commence par instrumenter les temps d’attente autour du dépôt et des pipelines. Ensuite, encadre l’usage des agents avec des règles claires de branches, de validation et de permissions. Pour structurer cette démarche côté organisation, le guide NXUS sur les agents IA en entreprise peut aider à poser les bons cas d’usage et les limites de gouvernance.

Sources

• OpenAI
• OpenAI
• OpenAI
• OpenAI
• MarkTechPost