Le sandbox SPACE de Perplexity passe à l’open source, mais l’échelle de production reste à prouver

Perplexity a publié en open source son sandbox SPACE tout en soutenant qu’une infrastructure fiable pour les agents dépend encore d’un travail de production complexe. Le sandbox Perplexity SPACE fournit des ordinateurs isolés où Perplexity Computer peut exécuter du code sans exposer les systèmes environnants. Cette publication est donc plus importante qu’une simple mise à disposition de code source.

Le PDG Aravind Srinivas a annoncé cette publication le 19 octobre 2026 et a décrit les sandboxes eux-mêmes comme une commodité. Toutefois, son billet d’annonce établissait aussi une distinction entre créer un sandbox et en exploiter des millions. Perplexity affirme que SPACE prend en charge les capacités de sandbox utilisées par Computer, bien que cette affirmation d’échelle n’ait pas été vérifiée de manière indépendante.

L’enjeu n’oppose donc pas l’open source au code fermé. Il s’agit d’une opposition entre une infrastructure auto-hébergée et une exécution managée soutenue par une expérience opérationnelle. E2B et d’autres fournisseurs de sandbox font désormais face à une alternative ouverte crédible, tandis que Perplexity doit démontrer que la publication de son code transmet un savoir-faire de production significatif.

Le sandbox Perplexity SPACE ouvre la couche d’exécution

Perplexity a dévoilé les mécanismes qui offrent à ses agents des espaces de travail isolés, et non l’intégralité du produit Perplexity Computer.

SPACE signifie Sandboxed Platform for Agentic Code Execution. Son dépôt SPACE public décrit une plateforme permettant d’exécuter du code d’agent ou d’utilisateur dans des microVM Firecracker isolées.

Une microVM est une petite machine virtuelle conçue pour démarrer avec moins de surcharge qu’une VM serveur conventionnelle. Elle fournit à chaque charge de travail sa propre frontière de noyau, ce qui offre généralement une isolation plus forte qu’un conteneur standard partageant un noyau.

Les applications communiquent avec SPACE via une API HTTP. Elles peuvent créer des environnements Linux, lancer des commandes, recevoir leur sortie, conserver un environnement, le suspendre, le réactiver ou le supprimer.

Ce cycle de vie est important, car un agent exécute rarement une seule commande avant de disparaître. Un flux de travail de recherche ou de programmation peut installer des paquets, créer des fichiers, exécuter un programme, examiner les erreurs et réessayer.

SPACE conserve ces actions connexes dans un même environnement accessible en écriture. L’application contrôle ce que l’agent tente de faire, tandis que la plateforme gère la machine, les processus et la connexion de sortie.

Le projet est principalement écrit en Rust, mais les clients n’ont pas besoin d’intégrer une bibliothèque Rust. Ils interagissent via HTTP et reçoivent la sortie des commandes en direct grâce aux événements envoyés par le serveur, un mécanisme de diffusion unidirectionnel standard.

Perplexity a publié le dépôt sous licence Apache License 2.0. Celle-ci autorise l’utilisation commerciale, la modification et la redistribution, sous réserve des conditions de la licence.

Le dépôt est plus substantiel qu’un simple démonstrateur. Il contient des composants de service, des définitions d’API, des modèles Firecracker, des tests smoke, une configuration Kubernetes locale et un déploiement de référence AWS.

Sa documentation publique couvre également les pools chauds, les snapshots, la récupération du cycle de vie, l’observabilité, les politiques de réseau sortant et le comportement de compatibilité. Ce sont des préoccupations opérationnelles qui apparaissent lorsqu’une équipe dépasse le stade d’un exécuteur de code élémentaire.

Lors de son examen, le projet avait attiré environ 1 600 étoiles GitHub et 132 forks. Ces chiffres témoignent d’un intérêt initial des développeurs, mais ne démontrent ni une adoption en production ni la qualité de la sécurité.

Perplexity Computer reste un produit distinct, de niveau supérieur. L’entreprise décrit Computer comme un orchestrateur capable de rechercher, analyser, créer, programmer et coordonner des flux de travail plus longs entre différents outils.

Sa présentation officielle de Computer indique que le produit achemine les tâches entre plus de 20 modèles. SPACE concerne l’environnement d’exécution qui sous-tend certaines parties de ce flux de travail, plutôt que sa planification, le routage des modèles, les connecteurs ou l’interface utilisateur.

Cette distinction évite un malentendu facile. Installer SPACE ne reproduit pas Perplexity Computer. Il fournit aux développeurs une couche d’infrastructure sur laquelle ils peuvent bâtir leurs propres agents et espaces de travail capables d’exécuter du code.

Cette publication crée la tension centrale de l’article, car le code d’infrastructure ne constitue qu’une partie d’une plateforme opérationnelle. La rigueur de déploiement, la planification des capacités, la réponse aux incidents, la revue de sécurité et le support restent en dehors d’un Git clone.

Pourquoi Perplexity ouvre SPACE maintenant

Cette publication transforme l’architecture d’exécution interne de Perplexity en effort public de normalisation, alors que les plateformes d’agents choisissent encore leur infrastructure.

Les agents d’IA doivent de plus en plus faire davantage que renvoyer du texte. Ils génèrent des programmes, transforment des fichiers, testent des logiciels, analysent des jeux de données et créent des artefacts nécessitant un véritable environnement d’exécution.

Exécuter ce travail sur un serveur applicatif crée un risque évident. Les commandes générées par un modèle peuvent supprimer des fichiers, consommer des ressources, inspecter des secrets ou effectuer des requêtes réseau non intentionnelles.

Un sandbox jetable sépare l’environnement d’exécution de l’agent du service environnant. Si la tâche échoue, l’opérateur peut détruire l’environnement sans reconstruire l’application principale.

L’idée de base n’est pas nouvelle. Ce qui a changé, c’est la fréquence et la variété des actions des agents. Un service de production peut devoir créer de nombreux environnements isolés, diffuser des sorties, se remettre de défaillances, imposer des limites et récupérer continuellement des capacités.

Srinivas a formulé directement cette distinction. Son annonce qualifiait les sandboxes de commodité tout en affirmant que leur service à un trafic de production exige un travail méticuleux sur de nombreux petits détails.

Cette affirmation positionne SPACE dans deux directions à la fois. Perplexity abaisse la barrière à la possession de cette infrastructure tout en présentant son historique opérationnel comme une raison de faire confiance à sa conception.

Le passage à l’open source donne également à Perplexity une influence sur la manière dont les développeurs relient les agents à la puissance de calcul. Une API largement adoptée peut avoir de l’importance même lorsque de nombreux utilisateurs choisissent un hébergement managé plutôt que l’auto-hébergement.

SPACE inclut un composant de compatibilité E2B, ce qui est particulièrement révélateur. La compatibilité réduit les frictions de migration pour les applications déjà écrites pour une interface de sandbox établie.

Cette approche met la pression sur les fournisseurs spécialisés. Les développeurs peuvent envisager d’exécuter SPACE eux-mêmes, de le modifier pour une infrastructure privée ou d’utiliser ses interfaces comme backend alternatif.

La pression ne se limite pas à E2B. Modal, Cloudflare, Daytona et les plateformes cloud généralistes traitent tous certains aspects du problème d’exécution distante à travers des abstractions différentes.

Certains mettent l’accent sur une expérience développeur managée. D’autres privilégient le calcul serverless généraliste, la distribution géographique, les espaces de travail persistants ou la flexibilité de déploiement.

Perplexity entre sur ce terrain avec un autre atout. L’entreprise affirme que SPACE répond aux besoins d’exécution d’un produit d’agents destiné aux consommateurs et aux entreprises, plutôt que d’exister seulement comme service d’infrastructure autonome.

Cette association avec la production donne à SPACE une visibilité immédiate. Elle relève toutefois aussi le niveau de preuve exigé, car les développeurs compareront le projet public aux affirmations de Perplexity sur son fonctionnement interne.

Cette publication profite également aux acheteurs d’entreprise qui évaluent des systèmes d’agents. Ils peuvent examiner l’architecture, vérifier les chemins de données, tester les restrictions de réseau sortant et envisager un déploiement dans leur propre environnement.

L’inspection n’élimine pas le risque. Elle donne aux équipes de sécurité une implémentation concrète à évaluer au lieu de s’appuyer entièrement sur des descriptions de produit.

Pour Perplexity, des contributeurs externes peuvent identifier des défauts, ajouter des modèles de déploiement et élargir la compatibilité. Le développement public peut aussi rendre SPACE plus crédible en tant qu’infrastructure partagée plutôt que dépendance propriétaire.

Le pari stratégique est clair. Perplexity veut que la couche d’exécution devienne ouverte et remplaçable, tout en conservant sa différenciation produit dans l’orchestration, les modèles, les interfaces, l’accès aux données et la compétence opérationnelle.

Si cette division se maintient, l’ouverture de SPACE ne réduira pas l’avantage de Computer. Elle élargira le nombre de développeurs construisant autour d’une architecture que Perplexity utilise déjà.

Dans le cas contraire, les concurrents accèdent à une partie significative de la pile technologique de Perplexity sans hériter du coût de son développement. La qualité du transfert opérationnel déterminera donc si cette publication crée un levier ou une fuite de valeur.

Comment Perplexity SPACE fonctionne sous Computer

SPACE sépare les décisions de contrôle de l’exécution des commandes, offrant aux agents un environnement persistant sans traiter chaque commande comme une nouvelle machine.

Un déploiement SPACE commence par des modèles. Un modèle définit l’environnement initial à partir duquel une instance de sandbox est créée.

Chaque sandbox reçoit sa propre machine virtuelle et son système de fichiers accessible en écriture. Plusieurs commandes peuvent ensuite s’exécuter dans ce même environnement, en conservant les fichiers et les dépendances installées entre les étapes.

Cette persistance permet un comportement réaliste des agents. Un agent peut générer un projet, installer ses dépendances, exécuter des tests, examiner l’échec, modifier les fichiers et relancer les tests.

L’application demande d’abord un sandbox à l’API de contrôle. Les changements de cycle de vie étant asynchrones, l’API renvoie un identifiant d’opération que le client vérifie jusqu’à ce que l’action soit terminée.

Ce modèle évite qu’un long travail d’infrastructure bloque une requête unique. Il donne également aux clients un moyen plus clair de réessayer ou d’examiner des opérations incomplètes.

L’exécution des commandes utilise un modèle de session. L’application crée une session de commande, s’y attache, démarre le processus et reçoit la sortie ainsi que le résultat final de sortie.

La sortie circule par une connexion distincte du plan de données utilisant un jeton d’attachement propre à la session. Cette séparation limite les identifiants accessibles à un client de sortie de processus.

SPACE expose plusieurs états au-delà de la simple création et suppression. Un sandbox peut rester actif, être mis en pause, suspendu, repris ou arrêté, selon le compromis requis entre disponibilité et utilisation des ressources.

Ces états comptent sur le plan économique même lorsqu’aucun prix n’est évoqué. Maintenir chaque environnement entièrement actif réduit la latence, mais consomme davantage de capacité durant les périodes d’inactivité.

Tout arrêter économise des ressources, mais oblige les utilisateurs à attendre la restauration. Une plateforme de production a besoin de politiques permettant de choisir entre ces résultats pour de nombreuses charges de travail.

Les pools chauds répondent à une partie de ce problème. Ils maintiennent des environnements démarrés prêts à l’emploi afin qu’une nouvelle requête évite un démarrage à froid complet.

Un pool chaud améliore la réactivité, mais introduit des questions de capacité. Les opérateurs doivent décider combien d’environnements réserver, comment remplacer les instances défaillantes et comment éviter le gaspillage.

SPACE documente également les snapshots de base. Un snapshot peut restaurer un état de système de fichiers préparé au lieu de le reconstruire pour chaque tâche.

Les snapshots sont utiles lorsque les agents ont régulièrement besoin des mêmes langages, bibliothèques ou configurations de projet. Ils créent également des responsabilités de gestion des versions et du stockage qui doivent être traitées avec soin.

Au niveau de l’isolation, SPACE utilise Firecracker par défaut. Amazon Web Services a créé Firecracker pour les charges de travail virtualisées légères, notamment les fonctions serverless et les conteneurs.

L’architecture Firecracker publiée utilise la technologie de machine virtuelle basée sur le noyau Linux afin de fournir une isolation assistée par matériel. Son modèle de périphériques réduit vise à limiter la surcharge de démarrage et la surface d’attaque disponible.

L’utilisation de Firecracker ne sécurise pas automatiquement l’ensemble d’un service. L’authentification, la configuration de l’hôte, la provenance des images, la politique réseau, les mises à jour du noyau, les limites de ressources et la séparation des locataires exigent toujours une mise en œuvre correcte.

SPACE prend également en charge les contrôles de réseau sortant via des profils d’egress. L’egress désigne le trafic qui quitte le sandbox, par exemple lorsqu’une commande télécharge un package ou contacte une API externe.

Il s’agit d’une surface de politique critique pour les agents. Un sandbox disposant d’un accès sortant illimité peut transmettre des données sensibles, même s’il ne peut pas s’échapper directement de sa machine virtuelle.

Les opérateurs ont besoin de règles qui distinguent l’activité réseau nécessaire des accès dangereux. Un agent de programmation peut avoir besoin d’un registre de packages sans avoir de raison de contacter des services administratifs internes.

Le dépôt public inclut des instructions de déploiement local utilisant Kind, qui exécute des clusters Kubernetes via des conteneurs locaux. Il contient également une infrastructure de référence pour le service Kubernetes managé d’Amazon.

La documentation indique que SPACE peut fonctionner sans Kubernetes. Cette flexibilité élargit son audience potentielle, mais signifie aussi que les opérateurs doivent comprendre quelles garanties proviennent de SPACE et lesquelles dépendent de leur ordonnanceur environnant.

Le sandbox SPACE de Perplexity représente donc un ensemble de décisions d’infrastructure coordonnées. La microVM n’en est qu’un composant.

Le contrat d’API, la machine à états du cycle de vie, la capacité préchauffée, les snapshots, l’authentification, le streaming des commandes et le comportement de récupération déterminent si le système reste utilisable sous de vraies charges de travail.

Ce mécanisme explique pourquoi Srinivas peut qualifier cette primitive de commodité tout en défendant le travail opérationnel. Créer une VM isolée est simple comparé au maintien d’un comportement prévisible malgré des défaillances répétées et une demande variable.

Perplexity SPACE vs E2B : l’auto-hébergement face aux opérations managées

La compétition principale ne porte pas sur la capacité d’un projet à démarrer une microVM, mais sur qui assume la charge opérationnelle lorsqu’un agent commence à l’utiliser.

E2B est devenu une interface familière pour fournir aux agents des environnements distants. Les développeurs utilisent son SDK pour créer des sandboxes, exécuter des commandes, manipuler des fichiers et conserver l’état entre les appels d’outils.

SPACE reconnaît cette base installée grâce à sa couche de compatibilité E2B documentée. Le wrapper permet de diriger le comportement pris en charge des clients E2B vers un déploiement SPACE.

C’est une démarche concurrentielle pragmatique. Une équipe peut évaluer SPACE sans réécrire immédiatement chaque appel de son application d’agent.

La compatibilité ne signifie pas un comportement identique. Chaque fournisseur peut différer en matière de sémantique du cycle de vie, de limites, de réseau, de persistance, de gestion des erreurs, d’observabilité et de fonctionnalités SDK prises en charge.

Les développeurs doivent tester les opérations exactes utilisées par leurs agents. Un exemple élémentaire de commande ne peut pas révéler le comportement en cas d’annulation, d’interruption réseau, de sessions simultanées ou de défaillance de l’hôte.

Le choix entre Perplexity SPACE et E2B commence par la question de la responsabilité. Une plateforme managée laisse au fournisseur l’exploitation de la capacité, des mises à jour, de la disponibilité et d’une grande partie de la frontière de sécurité.

L’auto-hébergement de SPACE donne à l’adoptant davantage de contrôle sur le déploiement, les modifications, la localisation des données et l’intégration réseau. Il lui transfère également une responsabilité opérationnelle plus importante.

Pour une petite équipe de développement, une infrastructure managée peut réduire le travail nécessaire avant le lancement d’un agent. L’équipe intègre une API et se concentre sur l’application.

Une entreprise réglementée pourrait préférer une infrastructure au sein d’un compte cloud approuvé. Elle peut appliquer ses contrôles existants d’identité, de journalisation, de réseau et de conformité autour du service de sandbox.

Aucun de ces choix ne l’emporte universellement. La voie appropriée dépend de la sensibilité de la charge de travail, de l’échelle, des effectifs, des exigences de latence et de la tolérance à une dépendance vis-à-vis d’un service externe.

L’open source modifie le pouvoir de négociation, même pour les équipes qui ne le déploient jamais. Les acheteurs peuvent évaluer une architecture alternative et réduire le risque de concevoir leur système autour d’un unique service d’exécution propriétaire.

La licence Apache permet également aux fournisseurs de bâtir des offres commerciales autour de SPACE. Cela pourrait donner lieu à des déploiements managés, à du support d’entreprise ou à des distributions spécialisées.

Un tel écosystème renforcerait la position de Perplexity si les services compatibles préservent ses interfaces. Il affaiblirait le projet si les implémentations se fragmentent ou prennent du retard sur les correctifs de sécurité.

Les fournisseurs spécialisés conservent plusieurs atouts défensifs. Un service hébergé peut rivaliser par sa fiabilité, sa capacité géographique, son support, son intégration, sa supervision et un accès plus rapide aux nouvelles fonctionnalités d’exécution.

Les fournisseurs managés peuvent aussi masquer une complexité opérationnelle que l’open source rend visible. Un dépôt rempli de composants est précieux pour une équipe d’infrastructure, mais intimidant pour une équipe applicative.

L’avantage de Perplexity réside dans la preuve de sa pertinence interne. L’entreprise affirme que la plateforme prend en charge les capacités de sandbox derrière Computer, ce qui fournit au design une charge de travail de référence exigeante.

Cependant, le dépôt ne permet pas à lui seul aux observateurs externes de reproduire cette affirmation. Il ne révèle ni la taille de la flotte de Perplexity, ni ses résultats de niveau de service, sa topologie régionale, son historique d’incidents ou ses dépenses d’infrastructure.

L’expression « millions de sandboxes » exige également une interprétation prudente. Elle peut décrire des créations cumulées, un pic de concurrence, des environnements actifs ou une autre mesure interne.

Ces métriques sont sensiblement différentes. Des millions de créations de sandboxes éphémères au fil du temps n’impliquent pas des millions de machines virtuelles simultanées.

Ce déficit de vérification n’invalide pas le projet. Il limite les conclusions que les lecteurs devraient tirer de l’annonce.

Les développeurs peuvent vérifier l’API publique, le code, les instructions de déploiement et les tests. Ils ne peuvent pas vérifier le volume de production interne à partir de ces seuls artefacts.

La comparaison la plus crédible émergera donc de déploiements indépendants. Les équipes doivent mesurer la latence de création, la récupération après défaillance, le streaming des commandes, l’utilisation des hôtes et le comportement face à des charges de travail hostiles.

Elles devraient également suivre le coût humain de l’exploitation de la plateforme. Un système techniquement capable peut malgré tout être peu rentable s’il exige l’intervention constante d’une équipe d’infrastructure spécialisée.

La publication open source a déjà modifié le paysage concurrentiel, car elle crée une option supplémentaire pouvant être inspectée. Elle n’a pas établi que SPACE offre un meilleur résultat opérationnel qu’un service managé.

Le code ouvert ne prouve pas la sécurité en production

SPACE fournit des détails d’implémentation significatifs, mais ses preuves publiques ne valident pas encore les implications les plus ambitieuses de Perplexity en matière d’échelle et de sécurité.

Les sandboxes d’agents traitent des charges de travail particulièrement risquées. Leur objectif central est d’exécuter des commandes générées par un modèle, fournies par un utilisateur ou assemblées à partir de contenu externe.

Cela signifie que les opérateurs doivent supposer que certaines commandes seront malformées. Ils doivent également supposer que des attaquants testeront délibérément les frontières d’isolation.

Une microVM réduit l’exposition par rapport à l’exécution de commandes non fiables directement sur un hôte applicatif partagé. Elle n’élimine pas le besoin de défenses en profondeur.

Les noyaux hôtes, les composants de virtualisation, les chemins de stockage, le réseau, les API de contrôle et les pipelines d’images peuvent tous contenir des vulnérabilités. Une mauvaise configuration peut affaiblir une architecture par ailleurs saine.

Le dépôt comprend un processus privé de signalement des vulnérabilités et indique que seule la dernière version mineure reçoit des correctifs de sécurité. Sa politique de sécurité publique ne liste aucun avis publié au moment de l’examen.

L’absence d’avis ne prouve pas l’absence de vulnérabilités. Les nouveaux projets ont souvent besoin de temps, d’adoption et de tests adverses avant que leurs faiblesses ne deviennent visibles.

La politique de dernière version mineure crée également du travail pour les adoptants. Les équipes qui auto-hébergent SPACE doivent suivre les versions et effectuer rapidement les mises à jour pour rester dans la fenêtre de sécurité prise en charge.

L’aptitude à la production implique davantage que la prévention de l’évasion de VM. Les opérateurs ont besoin d’authentification des locataires, d’autorisation, de quotas, de gestion des secrets, de journaux d’audit et d’un nettoyage fiable.

Les échecs de nettoyage peuvent devenir coûteux ou dangereux. Un sandbox abandonné peut continuer à consommer des ressources, conserver des fichiers sensibles ou préserver des identifiants réseau plus longtemps que prévu.

L’accès sortant mérite une attention égale. Une charge de travail isolée peut toujours causer des dommages en sondant des systèmes externes, en téléchargeant du code malveillant ou en envoyant des données à un attaquant.

SPACE offre des mécanismes de politique, mais l’adoptant doit les configurer. L’existence d’un profil d’egress ne garantit pas que chaque déploiement applique des paramètres par défaut restrictifs.

Les modèles et les snapshots créent une autre surface de chaîne d’approvisionnement. Une image de base compromise peut affecter chaque sandbox créé à partir d’elle.

Les opérateurs ont besoin de builds reproductibles, de revue des dépendances, de signature d’images, d’analyse des vulnérabilités et d’un processus de promotion contrôlé. Ces pratiques ne sont pas fournies automatiquement par une licence open source.

L’observabilité peut révéler un risque concurrent. Les journaux et les traces aident à diagnostiquer les défaillances, mais une télémétrie imprudente peut capturer le contenu des commandes, des chemins de fichiers, des jetons ou des données utilisateur.

Les équipes doivent décider quoi enregistrer et combien de temps le conserver. Les déploiements d’entreprise nécessiteront également des contrôles régissant qui peut examiner l’activité des agents.

La fiabilité reste une incertitude distincte. Les sandboxes peuvent échouer lors du démarrage, de l’exécution, de la suspension, de la restauration ou du streaming de sortie.

Une application doit distinguer une opération retardée d’une opération échouée. Elle a également besoin de nouvelles tentatives idempotentes, qui évitent de créer des ressources dupliquées lorsqu’une réponse est perdue.

La documentation de Perplexity aborde les comportements de récupération et de quarantaine, ce qui suggère que le projet traite ces catégories de défaillances. Des benchmarks publics rendraient ces capacités plus faciles à évaluer.

La version actuelle ne fournit pas de chiffres de débit ou de disponibilité audités de manière indépendante. Elle n’établit pas non plus à quel point la configuration publique correspond à l’environnement de production interne de Perplexity.

Les entreprises exécutent souvent des systèmes supplémentaires autour d’un cœur open source. Des ordonnanceurs internes, des prévisions de capacité, des services de sécurité, l’automatisation des déploiements et des outils de gestion des incidents peuvent expliquer une grande partie du résultat opérationnel.

L’affirmation de Perplexity doit donc être lue de manière restreinte. L’entreprise a publié un code substantiel associé à son architecture de sandbox.

Elle n’a pas transféré tous les processus nécessaires pour reproduire le service derrière Perplexity Computer. Elle n’a pas non plus publié suffisamment de données pour permettre aux observateurs externes de valider l’échelle de production revendiquée.

C’est le compromis central de cette publication. Le code ouvert améliore l’inspectabilité et le contrôle, tandis que l’auto-hébergement confère davantage de responsabilités à l’adoptant.

Une équipe évaluant SPACE devrait commencer par un modèle de menace, et non par une liste de fonctionnalités. Elle devrait identifier les entrées non fiables, les actifs protégés, les destinations autorisées et les temps de récupération acceptables.

L’équipe devrait ensuite tester les cas de défaillance que les démonstrations ordinaires évitent. Il s’agit notamment des démarrages bloqués, des flux de sortie interrompus, de l’épuisement de la capacité hôte, des snapshots invalides, des identifiants révoqués et des arrêts forcés.

Elle devrait également tester la résistance aux évasions au moyen d’un examen de sécurité indépendant. Une plateforme conçue pour exécuter du code hostile mérite un examen plus approfondi qu’un service interne conventionnel.

SPACE semble suffisamment sérieux pour justifier ce travail. Les éléments disponibles ne justifient pas de l’omettre.

Trois signaux montreront si SPACE devient une infrastructure partagée

La prochaine étape sera déterminée par l’exploitation externe, la réponse en matière de sécurité et la compatibilité réelle, plutôt que par l’attention accordée au seul dépôt.

Le premier signal sera un déploiement indépendant en production. Les développeurs devraient surveiller les organisations exécutant le sandbox Perplexity SPACE en dehors de l’environnement propre à Perplexity.

Une étude de cas significative devrait décrire la forme de la charge de travail, la concurrence, la latence de création, les taux de défaillance et les effectifs. Un logo ou une annonce d’installation en révélera bien moins.

Un fonctionnement indépendant renforcerait l’argument de Perplexity selon lequel le code transmet un savoir-faire de production exploitable. Des rapports répétés sur la complexité des déploiements l’affaibliraient.

Les contributions de la communauté comptent également dans ce premier signal. Des modifications substantielles de la planification, des environnements d’exécution, des cibles de déploiement ou des diagnostics indiqueraient que des contributeurs externes comprennent et prolongent l’architecture.

Le deuxième signal concerne l’historique du projet en matière de sécurité et de publications. Les chercheurs testeront SPACE, car la plateforme accepte par conception du code non fiable.

La gestion des prompts n’est pas le problème central à ce niveau. La question essentielle est de savoir si un processus malveillant peut franchir les limites d’isolation, détourner des identifiants ou accéder à des réseaux interdits.

Un processus transparent de publication d’avis, des correctifs rapides et des consignes de mise à niveau claires renforceraient la confiance. Des correctifs silencieux ou des mises à jour de sécurité incompatibles compliqueraient l’adoption par les entreprises.

Les utilisateurs devraient également observer avec quelle régularité Perplexity maintient le dépôt public. Une plateforme open source perd de sa valeur lorsque le développement interne progresse tandis que les versions publiques prennent du retard.

Le troisième signal est la compatibilité dans des charges de travail d’agents réelles. Le wrapper E2B offre un test direct permettant de vérifier si les applications peuvent changer d’infrastructure sans modifier leur comportement.

Les développeurs devraient examiner les commandes de longue durée, les transferts de fichiers, les annulations, les reconnexions, la persistance et les sessions simultanées. Ces cas limites en révèlent davantage qu’une commande « hello world » réussie.

Une compatibilité fiable accentuerait la pression sur les fournisseurs de sandboxes gérées. Elle permettrait aux équipes de considérer le backend d’exécution comme un composant remplaçable.

Une compatibilité incomplète préserverait les coûts de changement. Les fournisseurs pourraient continuer à se différencier par des comportements dont les applications dépendent discrètement.

Perplexity Computer offre un autre point d’observation. À mesure que Computer prend en charge des livrables plus complexes, les utilisateurs rencontreront les limites pratiques de son environnement d’exécution.

Les échecs liés à l’installation de packages, aux tâches longues, à l’état conservé ou aux fichiers générés peuvent révéler où l’infrastructure de sandbox contraint encore le produit. Les améliorations peuvent montrer à quelle vitesse la plateforme sous-jacente progresse.

Les développeurs qui construisent des agents intensifs en connaissances devraient également réfléchir à la manière dont l’exécution se connecte au contexte. Une sandbox peut exécuter du code, mais elle a toujours besoin de fichiers et d’instructions soigneusement sélectionnés.

La récupération d’informations et la conception des autorisations deviennent donc aussi importantes que l’isolation des ressources de calcul. Une base de connaissances IA consultable peut organiser les sources avant qu’un agent n’y reçoive accès.

La publication de la sandbox Perplexity SPACE permet aujourd’hui de tirer une conclusion raisonnable. L’exécution d’agents devient une couche d’infrastructure indépendante, avec ses propres interfaces, enjeux de compatibilité et choix de déploiement.

Elle n’établit pas encore que l’auto-hébergement soit la meilleure solution pour chaque équipe. Les opérations gérées restent précieuses lorsque la fiabilité importe davantage que le contrôle de l’infrastructure.

La question pratique est donc précise : votre organisation doit-elle posséder la frontière d’exécution, et peut-elle l’exploiter en toute sécurité ?

Si la réponse est oui, testez SPACE face à des charges de travail hostiles et à des conditions de défaillance réalistes. Si la réponse est non, utilisez sa conception publique pour poser des questions plus pertinentes aux fournisseurs de services gérés.

Surveillez les déploiements indépendants, les divulgations de sécurité et les résultats de compatibilité au cours des trois prochains mois. Ces signaux montreront si SPACE devient une infrastructure partagée pour les agents ou reste avant tout l’implémentation de référence publiée par Perplexity.