Perplexity a révélé le 12 octobre 2026, dans son blog d'ingénierie officiel, que Projects, la fonction déjà disponible dans Perplexity Computer, ne repose pas sur un simple dossier partagé. En dessous fonctionne un système de dépôts Git conçu spécifiquement pour la collaboration entre humains et agents : chaque projet correspond à un unique dépôt Git, et les agents interactifs d'un utilisateur, ses agents programmés et les agents d'autres collaborateurs versent tous leurs modifications dans ce même dépôt. Aucun nouveau modèle n'a été annoncé, mais l'article traite d'un problème inévitable dès que les agents assument des travaux de longue durée : où vivent les résultats, qui a changé quoi, et comment revenir en arrière en cas d'erreur.
Pourquoi Git, précisément
Le raisonnement de Perplexity est pragmatique. Une collaboration qui s'étend sur des mois exige trois propriétés : le travail doit persister d'une session à l'autre au lieu de disparaître avec le bac à sable ; les modifications simultanées de plusieurs personnes et agents ne doivent pas s'écraser silencieusement ; et chaque changement doit pouvoir être retracé et annulé. Ce sont exactement les problèmes que Git résout depuis des décennies. La différence tient à ce que les plateformes de code classiques ont été pensées pour des humains, et leurs écrans de revue, leur gestion de branches et leurs notifications sont un poids mort pour des agents. Perplexity ne conserve donc que la mécanique de stockage et de vérification de Git. Les agents n'attendent pas d'approbation humaine : le service Git contrôle mécaniquement chaque soumission au regard d'un contrat propre au dépôt et ne l'accepte comme nouvel état de référence que si elle le respecte. Quand deux agents se télescopent, la soumission tardive bâtie sur une base périmée reçoit un refus explicite ; l'agent rejoue alors ses changements sur le nouvel état et soumet à nouveau. En production, affirme Perplexity, moins de 2 % des soumissions sont ainsi rejetées, avec une latence médiane inférieure à 1,7 seconde et un 99e percentile sous les 8 secondes.
Comment les cinq pièces se répartissent le travail
Le système compte cinq composants. Chaque agent travaille dans son propre bac à sable isolé, où un petit outil en ligne de commande matérialise le dépôt localement et soumet le travail par unités significatives. Le plan de contrôle se contente de localiser les dépôts et d'émettre des identifiants de courte durée ; il ne touche jamais aux données. Le service Git exécute les opérations natives de clonage, de récupération et de réception, et décide quelle soumission devient le dernier commit accepté, l'état étant consigné dans DynamoDB. Les données des dépôts vivent sur un système de fichiers partagé fourni par AWS S3Files, ce qui rend les réplicas du service sans état et remplaçables. Une fois un commit accepté, des traitements en arrière-plan extraient texte et métadonnées des documents modifiés, afin que les agents puissent les interroger à la prochaine ouverture du projet. Pour économiser la bande passante, les bacs à sable ne téléchargent pas d'emblée des dépôts entiers : les gros fichiers apparaissent d'abord comme des pointeurs Git LFS, les agents lisent le texte extrait et ne récupèrent les originaux qu'en cas de besoin. Perplexity indique avoir essayé un système de fichiers virtuel fondé sur FUSE, abandonné après avoir mesuré une lenteur environ 400 fois supérieure sur les charges riches en fichiers. L'historique ne croît pas non plus sans limite : au-delà d'un seuil de commits conservés, l'historique ancien est compacté en un unique instantané de départ.
Ce que montrent les chiffres, et où s'arrêtent les preuves
Le test interne publié par Perplexity illustre bien l'intention du design. Sur 150 questions financières portant sur le même corpus de documents, un agent explorant les fichiers a obtenu 0,867 pour retrouver le bon document et 0,627 pour répondre correctement, contre environ 0,39 et 0,37 pour la recherche sémantique — soit environ 1,7 fois mieux sur les réponses, avec une latence inférieure d'environ 25 %. Se rattacher à un projet déjà ouvert prend environ 2,9 secondes, contre environ 8 secondes à froid. La mémoire à long terme de Computer, Brain, repose sur la même infrastructure de dépôts, ses pages de connaissances étant stockées sous forme de commits dans des dépôts séparés, de sorte que les mises à jour de la mémoire ne concurrencent jamais les modifications des projets. Deux réserves s'imposent : tous les chiffres sont auto-mesurés par Perplexity, sans reproduction par un tiers, et le corpus de test a été choisi par l'entreprise. Ils documentent donc une logique de conception, pas un verdict pour l'ensemble du secteur. La direction, elle, compte. À mesure que les agents passent de la réponse ponctuelle à des collaborations de plusieurs mois, la concurrence se déplace du modèle lui-même vers la persistance et la traçabilité de l'espace de travail. Le pari de Perplexity est que le contrôle de versions, inventé il y a des décennies pour des collaborateurs humains, est la fondation la plus rapide à emprunter pour les agents — et les agents adossés à la fondation la plus stable seront ceux à qui l'on confiera les tâches les plus longues.
