2026 DeepSeek Harness : bac à sable E2B ou environnement persistant ?

Le mot « persistant » décrit ici un environnement dont le système de fichiers, les dépendances, les processus et les réglages restent disponibles entre plusieurs interventions. Il ne signifie pas que tout est automatiquement sauvegardé. De même, un bac à sable E2B n’est pas seulement une machine temporaire : il devient une bonne unité d’exécution lorsque la tâche possède un début, une fin, un périmètre et un paquet d’artefacts vérifiable.

La documentation officielle présente E2B comme un environnement isolé destiné à l’exécution de code, au traitement de données et à l’utilisation d’outils par des agents. Elle décrit le bac à sable comme une machine virtuelle Linux créée à la demande, à partir d’un modèle d’environnement. Voir la définition officielle des sandboxes E2B.

La décision pratique se résume ainsi :

• Tâche courte, non fiable et reconstructible : bac à sable E2B.
• Tâche interactive, macOS ou dépendante d’un état local : environnement persistant.
• Tâche mixte : double voie, avec transfert contrôlé entre les deux.
• Tâche nécessitant des secrets de production : aucun accès direct par défaut ; approbation et identifiants limités.

Le premier piège est de confondre la durée de vie de l’exécution et la durée de vie de la session DeepSeek Harness. Une session peut être enregistrée dans une base externe, un journal ou un stockage d’artefacts alors que le bac à sable qui exécutait les commandes a déjà disparu. À l’inverse, un Mac peut rester disponible sans que l’historique Harness, les validations ou les décisions d’approbation soient correctement sauvegardés.

Pour un essai personnel, nous ne recommandons pas de commencer par une infrastructure persistante complète. Un script de transformation, un test de paquet, une analyse de dépôt public ou une génération de fichier audio intermédiaire peut généralement être relancé à partir d’un dépôt, d’un fichier source et d’une commande documentée.

Le bac à sable E2B est adapté lorsque les éléments suivants sont réunis :

• le dépôt peut être récupéré avec une commande reproductible ;
• les dépendances sont décrites dans un fichier de verrouillage ou une recette d’installation ;
• la sortie attendue peut être regroupée dans une archive ;
• aucun processus ne doit rester actif après la fin de la tâche ;
• l’agent n’a besoin que d’identifiants temporaires ou sans privilège ;
• une perte du répertoire de travail ne détruit pas une décision métier.

Cette approche convient également à des travaux créatifs : extraction de métadonnées audio, conversion vidéo, génération de vignettes, préparation de fichiers pour un outil de design ou contrôle de lots d’images. La condition reste la même : le résultat doit être exporté avant la fermeture du bac à sable.

Nous déconseillons en revanche E2B lorsque l’expérimentation devient une enquête interactive. Si nous devons conserver plusieurs versions d’un projet, observer un processus pendant plusieurs heures, reprendre un débogage après une interruption ou laisser un développeur intervenir fréquemment, un environnement persistant demande moins de reconstruction et expose mieux l’état réel du problème.

Le coût caché d’un bac à sable n’est donc pas uniquement son exécution. Il comprend aussi le temps nécessaire pour réinstaller une dépendance, reconstituer un cache, rechercher un fichier temporaire, reconnecter une session ou comprendre si l’échec provient du code, du transfert ou de la durée de vie de l’environnement.

Pour une équipe de recherche, nous commençons par dresser une liste de reconstruction. Chaque ligne doit répondre à une question simple : « Si l’environnement disparaît maintenant, pouvons-nous repartir sans intervention manuelle ? »

Liste de reconstruction

• Code source : dépôt, branche, révision exacte et sous-modules.
• Dépendances : manifeste, verrouillage, versions système et variables nécessaires.
• Données d’entrée : emplacement, taille attendue, format et règles de rétention.
• Base de données : schéma, jeu de données de test, migrations et droits.
• Caches : éléments accélérant le traitement mais non indispensables à la correction.
• Session Harness : messages, appels d’outils, décisions, erreurs et identifiant de tâche.
• Fichiers de travail : brouillons, index, fichiers temporaires et états intermédiaires.
• Artefacts finaux : archive, rapport, journal, empreinte et statut de validation.

Les caches sont souvent le mauvais critère de décision. Leur absence ralentit la reprise, mais ne la rend pas nécessairement impossible. Une base de données de développement, un dépôt privé ou une session contenant une longue enquête sont différents : leur reconstruction peut changer le résultat ou demander une intervention humaine.

Nous séparons également deux catégories d’état :

1. État de contrôle : identifiant de tâche, règles, approbations, journal, statut, propriétaire et destination du livrable.
2. État d’exécution : fichiers présents, processus, mémoire, sockets, cache local, environnement virtuel et outils installés.

Le premier doit rester dans un plan de contrôle durable. Le second peut être jetable uniquement si nous pouvons le régénérer ou l’exporter. Une session DeepSeek Harness conservée ne restaure pas automatiquement un serveur local, une base non exportée ou une modification restée dans un répertoire temporaire.

E2B expose des mécanismes de création, de connexion, de liste et d’arrêt des sandboxes. Sa documentation de référence indique aussi un délai par défaut de 300 000 millisecondes, soit cinq minutes, pour le paramètre de création, ainsi que des plafonds de durée dépendant du niveau de service : jusqu’à 24 heures pour l’offre Pro et 1 heure pour l’offre Hobby. Ces valeurs sont des paramètres de la documentation consultée, pas une garantie de disponibilité pour chaque intégration DeepSeek Harness. Consulter la référence officielle du cycle de vie E2B.

La conséquence est directe : une tâche dite « longue » doit posséder une stratégie de reprise avant son lancement. Si la tâche ne peut pas exporter son état avant l’échéance ou une erreur réseau, elle ne doit pas être traitée comme une exécution jetable.

E2B ne doit pas être présenté comme un Mac distant. Le bac à sable documenté est un environnement Linux isolé. Il peut exécuter une grande quantité de code, de tests et de prétraitements, mais il ne remplace pas un environnement macOS lorsqu’un outil dépend du système Apple.

Nous plaçons sur un Mac contrôlé les tâches qui nécessitent :

• Xcode et ses SDK ;
• le simulateur iOS, tvOS, watchOS ou visionOS ;
• la signature de code et les profils de provisionnement ;
• le trousseau macOS ;
• Safari ou une automatisation liée à ses capacités système ;
• des outils audio, vidéo ou de design validés uniquement sur macOS ;
• un périphérique Apple connecté ou une opération dépendante d’un identifiant matériel.

La matrice officielle des versions Xcode précise les versions de macOS nécessaires et les SDK pris en charge. Elle indique notamment que le développement pour visionOS requiert un Mac Apple silicon. Ce type de contrainte ne peut pas être déduit d’une simple compatibilité Linux ou d’une image de conteneur. Vérifier les exigences officielles de Xcode et de macOS.

La signature renforce cette séparation. Les profils de provisionnement associent notamment certificats, identifiants d’appareil et identifiant de paquet. Lire la documentation officielle sur les profils de provisionnement. Un bac à sable généraliste ne devient donc pas un environnement iOS parce qu’il reçoit le même dépôt ou la même commande de compilation.

Le trousseau est un autre point de rupture. macOS permet de contrôler quelles applications peuvent accéder aux éléments du trousseau. Voir la documentation officielle des services Keychain. Copier des certificats, des clés privées ou des profils dans une exécution jetable augmente la surface de contrôle à vérifier et ne reproduit pas forcément les autorisations attendues par les outils Apple.

Notre découpage recommandé est le suivant :

• E2B : lecture de dépôt, analyse statique, génération de tests, contrôle de fichiers non fiables, conversion de médias ou prétraitement sans secret.
• Mac persistant : compilation Xcode, signature, tests de simulateur, accès au trousseau, validation Safari et production de l’artefact Apple.
• Passerelle : transfert d’un paquet explicitement identifié, contrôle d’intégrité, journal de décision et approbation avant toute écriture sensible.

Pour comparer les options de Mac disponibles chez MESHLAUNCH, nous vous conseillons de partir de la page environnements Mac pour DeepSeek Harness, puis de vérifier que la version de macOS, les outils requis et le mode de connexion correspondent bien au scénario de livraison. Il ne faut pas promettre une compatibilité Xcode sans la valider sur le nœud réellement utilisé.

Une architecture à deux voies est souvent plus robuste parce qu’elle sépare les responsabilités, non parce qu’elle rend automatiquement l’exécution sûre.

L’environnement persistant conserve le plan de contrôle :

• configuration DeepSeek Harness ;
• registre des tâches ;
• identifiant de corrélation ;
• journal des appels d’outils ;
• statut et propriétaire ;
• règles d’approbation ;
• références vers les entrées et les artefacts ;
• décision de reprise ou d’abandon.

Le bac à sable E2B prend en charge l’exécution qui peut être détruite :

• installation de dépendances ;
• lecture de données à risque ;
• lancement de tests ;
• conversion ou analyse ;
• production d’un rapport ;
• génération d’un paquet de sortie.

La passerelle doit imposer un contrat de livraison. Pour chaque tâche, nous définissons au minimum :

1. un identifiant unique ;
2. une révision de code ;
3. une liste d’entrées autorisées ;
4. une liste de secrets absents ou explicitement accordés ;
5. un chemin de sortie ;
6. une empreinte des artefacts ;
7. un statut de validation ;
8. un propriétaire de la reprise en cas d’échec.

Les fonctions de métadonnées et de gestion du cycle de vie permettent d’identifier une sandbox, mais elles ne remplacent pas votre propre registre de tâches. La documentation décrit par exemple la possibilité d’ajouter des métadonnées personnalisées et de lister les environnements actifs. Consulter la référence de gestion des sandboxes. Nous devons donc conserver l’association entre identifiant Harness, identifiant E2B, dépôt, utilisateur et artefact dans le plan de contrôle.

Le transfert doit être unidirectionnel autant que possible. Un dépôt ou un fichier validé peut entrer dans l’exécution. Un rapport, un diff ou une archive peut en sortir. Une synchronisation bidirectionnelle permanente recrée une partie des risques de l’environnement partagé : écrasement de fichiers, confusion de versions, propagation d’un contenu hostile et absence de propriétaire clair.

Attention : l’isolement d’un bac à sable ne bloque pas automatiquement l’injection indirecte, l’exfiltration par un outil autorisé ou une fuite provoquée par une mauvaise règle de transfert. Les permissions, les sources d’entrée, les domaines accessibles et les secrets doivent rester contrôlés séparément.

Nous ne donnons jamais automatiquement un identifiant de production à une tâche simplement parce qu’elle s’exécute dans E2B. Un code non fiable peut être isolé tout en recevant trop de contexte, en appelant un outil externe autorisé ou en écrivant dans un emplacement qui n’était pas prévu.

La documentation du SDK E2B décrit l’utilisation de variables d’environnement dans la sandbox et l’authentification par clé ou jeton. Cela confirme la capacité technique, pas la pertinence de transmettre un secret sensible à chaque tâche. Examiner les paramètres officiels d’authentification et d’environnement.

Nous appliquons quatre niveaux de garde :

• Aucun secret pour l’analyse de contenu non fiable.
• Jeton temporaire et limité pour une lecture précise.
• Écriture dans une zone de staging pour les artefacts qui doivent être contrôlés.
• Accès de production uniquement après approbation, avec durée, périmètre et journalisation définis.

L’environnement persistant doit subir la même discipline. Sa durée de vie plus longue augmente la valeur de ce qu’il conserve : dépôts privés, sessions, certificats, caches, historiques et processus. Nous séparons donc les espaces de travail par projet ou par niveau de confiance, plutôt que de laisser tous les agents partager un répertoire durable.

Les outils doivent aussi être gardés côté contrôle. Une instruction demandant à l’agent de « ne pas toucher à la production » ne suffit pas si l’outil de déploiement est enregistré sans restriction. Les droits doivent être retirés de l’interface de l’agent lorsqu’ils ne sont pas nécessaires, puis réintroduits dans un flux d’approbation explicite.

Cette comparaison évite une erreur fréquente : choisir l’environnement en fonction du modèle ou de l’interface Harness, au lieu de choisir selon la responsabilité de l’exécution. Le même AI Agent peut produire une tâche adaptée à E2B le matin et une tâche qui exige un Mac persistant l’après-midi.

1. Inventorier les tâches réelles

Exportez une semaine de tâches représentatives. Ne les classez pas selon leur nom. Notez plutôt les fichiers lus, les outils appelés, les secrets utilisés, la durée d’intervention humaine, les processus lancés et les artefacts attendus.

2. Marquer l’état obligatoire

Pour chaque tâche, cochez les éléments qui doivent survivre :

• [ ] dépôt modifié ;
• [ ] session Harness ;
• [ ] dépendance installée localement ;
• [ ] base de données ;
• [ ] cache indispensable ;
• [ ] processus actif ;
• [ ] certificat ou trousseau ;
• [ ] fichier temporaire non reconstructible ;
• [ ] résultat intermédiaire nécessaire à la prochaine étape.

Si au moins un élément critique n’est ni exportable ni reconstructible, placez la tâche dans l’environnement persistant ou concevez une passerelle d’export avant de l’envoyer dans E2B.

3. Retirer les droits par défaut

Commencez avec une exécution sans secret de production, sans écriture externe et avec une liste de domaines minimale. Ajoutez ensuite chaque permission pour une raison documentée. Le test doit vérifier le refus, pas seulement le succès du chemin nominal.

4. Définir le paquet de sortie

Choisissez à l’avance les fichiers qui sortiront du bac à sable : rapport, diff, archive, journal et empreinte. Refusez les sorties « répertoire complet » lorsque le contenu peut inclure des secrets, des caches ou des fichiers injectés.

5. Tester trois reprises

Interrompez volontairement :

• une tâche entièrement reconstructible ;
• une tâche dépendante d’un état ;
• une tâche liée à macOS.

La première doit repartir dans un bac à sable neuf. La deuxième doit retrouver son état dans l’environnement persistant. La troisième doit prouver que le transfert vers le Mac ne contourne ni l’approbation ni la journalisation.

Pour les équipes qui doivent ensuite réserver un Mac de travail, consultez les environnements Mac persistants de MESHLAUNCH uniquement après avoir établi cette classification. Une location est utile lorsqu’elle évite l’achat d’une machine dédiée pour une période de test, une validation ou une livraison contrôlée ; elle ne supprime pas les obligations de gestion des secrets et des artefacts.

Le bac à sable E2B convient-il aux tâches longues ?

Oui, si la tâche est longue mais bornée, si son état est exporté et si la limite de durée est traitée comme une contrainte opérationnelle. Non, si la tâche dépend d’un processus qui doit survivre, d’un cache non recréé ou d’une intervention humaine imprévisible. La durée seule ne suffit donc pas à choisir E2B.

Une tâche nécessitant Xcode peut-elle être placée dans E2B ?

E2B peut recevoir la partie indépendante de la plateforme : lecture, analyse, tests de logique, génération de fichiers ou contrôle de provenance. La compilation et la signature finales doivent rester sur un vrai Mac. Les exigences Xcode et les profils Apple doivent être vérifiés sur la version de macOS réellement utilisée, pas sur une hypothèse de compatibilité.

La session DeepSeek Harness reste-t-elle après l’expiration ?

Uniquement si elle est stockée dans un système séparé. L’expiration de l’exécution ne garantit ni la conservation des fichiers ni la reprise d’un processus. Nous enregistrons l’identifiant Harness, l’identifiant du bac à sable, le statut et les artefacts dans le plan de contrôle avant de considérer la tâche comme récupérable.

Comment séparer le code à risque du travail durable ?

Le code à risque doit recevoir un espace jetable, une entrée limitée et aucun accès implicite aux secrets. Le travail durable conserve la configuration, la session et les décisions. Le passage entre les deux doit se faire par un paquet contrôlé, avec origine, empreinte, analyse et propriétaire de validation. Une simple copie de répertoire ne constitue pas une séparation suffisante.

Si votre environnement actuel est un poste local partagé, ses défauts sont généralement prévisibles : état difficile à auditer, dépendances qui dérivent entre les développeurs et accès aux certificats ou aux fichiers personnels trop large. Si vous utilisez uniquement un bac à sable court, vous perdez en revanche la continuité du débogage, les caches utiles et les outils macOS nécessaires aux livraisons Apple. Une solution unique impose donc soit trop de persistance à du code risqué, soit trop de reconstruction à des projets durables.

Lorsque vos tâches conservent un dépôt, une session, un processus ou une chaîne Xcode, un Mac persistant contrôlé est plus direct. MESHLAUNCH peut alors servir de solution de location pour un environnement de test ou de livraison, sans vous obliger à acheter immédiatement une machine dédiée. Pour un besoin temporaire de calcul, de validation audio ou vidéo, de débogage ou de test d’un flux DeepSeek Harness, vous pouvez commencer par comparer les options Mac disponibles, puis garder E2B pour les tâches jetables et à risque contrôlé.