Symptôme : vos sessions DeepSeek Harness sont bien écrites, mais vous ne savez pas si elles survivront à un arrêt, une migration ou une sauvegarde distante. Solution la plus rapide : pour un essai individuel ou une sauvegarde par session, commencez par valider le JSONL ; pour la recherche structurée, évaluez SQLite uniquement sur un disque local fiable, jamais par simple confiance dans le mode WAL sur un partage réseau.

Cet article s’adresse à trois profils : les développeurs indépendants qui veulent conserver leurs sessions de code ou d’analyse sans administrer une base complexe, les équipes qui gèrent plusieurs sessions sur un Mac cloud et les responsables de plateforme qui doivent formaliser une règle de reprise, d’audit et de livraison des données.

DeepSeek Harness est encore en aperçu développeur et le dépôt officiel prévient que des changements incompatibles peuvent intervenir. Le choix du backend doit donc être réversible et documenté, non présenté comme une garantie de compatibilité entre versions. (github.com)

Commencez par le scénario, pas par l’extension du fichier

La question « DeepSeek Harness JSONL ou SQLite » devient plus simple si vous séparez trois objets qui ne doivent pas être confondus :

  • la persistance de session, qui conserve les événements nécessaires à la reprise ;
  • l’index de requête, qui accélère la recherche dans ces événements ;
  • la sauvegarde, qui livre une copie restaurable sur un autre volume ou un autre Mac.
Le dépôt officiel traite bien JSONL et SQLite comme deux modules de persistance distincts, tandis que la couche de requête reste séparée des mécanismes internes de stockage. Activer une recherche ou une projection ne signifie donc pas nécessairement remplacer tous les fichiers de session par une base SQLite. ([github.com](https://github.com/deepseek-ai/deepseek-harness/tree/master/packages/session))

Pour une session unique, un travail de design, de montage audio ou vidéo, ou une courte expérimentation d’agent, le stockage JSONL est souvent le premier candidat à vérifier : vous pouvez copier une session, lire ses lignes avec des outils standards et livrer un dossier sans dépendre d’une procédure SQL. Cette simplicité n’est utile que si la session reste lisible après fermeture et si la reprise fonctionne réellement.

Pour une équipe qui doit retrouver toutes les sessions ayant appelé un outil particulier, filtrer par projet ou établir une chronologie d’événements, SQLite peut offrir une meilleure base de requête. Mais cet avantage ne supprime ni la responsabilité de sauvegarder correctement la base, ni celle de tester les fichiers auxiliaires, ni celle de gérer les changements de schéma.

Utilisez cette grille de choix avant d’activer un backend

La table suivante ne mesure pas une performance officielle. Elle sert à décider quel risque vous acceptez dans votre environnement.

<
Critère de décisionJSONLSQLite
Essai individuel sur un Mac local**5/5** — faible complexité, copie directe par session**3/5** — acceptable, mais plus de dépendance à l’état transactionnel
Inspection manuelle d’une session**5/5** — format texte structuré, diagnostic rapide**2/5** — nécessite un outil SQLite ou une requête
Écriture continue d’un agent**4/5** si l’append et la fin de ligne sont validés**4/5** si le disque local, les transactions et la reprise sont testés
Requêtes sur beaucoup de sessions**2/5** sans index dérivé**5/5** pour les filtres et agrégations structurés
Copie d’une session isolée**5/5****2/5** si des fichiers WAL ou journal doivent être associés
Sauvegarde à chaud**4/5** avec une stratégie de fichiers cohérente**4/5** avec l’API de sauvegarde, VACUUM INTO ou un arrêt contrôlé
Partage réseau ou disque monté**3/5** après test d’écriture et de verrouillage**1/5** par défaut ; validation obligatoire avant usage
Migration entre versions en aperçu**3/5** avec conservation du journal original**2/5** si le schéma ou les migrations ne sont pas stabilisés
Audit d’équipe**3/5** avec index séparé et convention d’événements**5/5** si le modèle de données et la procédure de sauvegarde sont maîtrisés
La règle opérationnelle est donc la suivante : **JSONL pour réduire la responsabilité de sauvegarde et faciliter l’inspection ; SQLite pour augmenter la capacité de requête, mais seulement lorsque le support de stockage est maîtrisé**.

Validez le stockage JSONL sur un cas à faible complexité

Le JSONL ne devient pas fiable parce qu’un fichier portant l’extension .jsonl apparaît dans le répertoire attendu. Vous devez vérifier ce que le processus écrit et ce qu’il sait relire.

  1. Identifiez le répertoire racine réel. Relevez la clé de configuration active, le chemin absolu résolu par le processus et les fichiers voisins créés pendant une session. Ne vous contentez pas d’un chemin trouvé dans un exemple ancien.
  1. Contrôlez l’encodage physique. Ouvrez une copie de la session et vérifiez que chaque enregistrement attendu est décodable, que les retours à la ligne sont cohérents et qu’une écriture interrompue ne laisse pas une queue impossible à parser.
  1. Fermez proprement le processus. Après la fermeture, relisez la dernière session depuis un autre processus. Cette étape élimine les faux positifs où l’interface affiche encore des données conservées uniquement en mémoire.
  1. Provoquez un arrêt anormal. Arrêtez le processus pendant une écriture ou interrompez le Mac de test. Au redémarrage, mesurez ce qui peut être relu : dernière interaction complète, dernier événement d’outil, métadonnées et état de reprise.
  1. Effectuez une restauration minimale. Copiez uniquement le dossier de la session vers un emplacement vide, relancez DeepSeek Harness avec la configuration correspondante et tentez une reprise. Si vous devez recopier tout le répertoire de travail pour que cela fonctionne, votre unité de sauvegarde n’est pas encore définie.
  1. Ajoutez un contrôle d’intégrité. Conservez le nom de la session, la version de Harness, la date de sauvegarde et une empreinte du fichier ou du dossier. Cette preuve ne garantit pas la validité sémantique, mais elle détecte une copie incomplète.
Le point fort du stockage JSONL est ici la lisibilité et la granularité. Son coût caché apparaît lorsque vous devez rechercher des événements dans des centaines de sessions : parcourir tous les fichiers devient une tâche d’indexation. Vous pouvez alors produire un index dérivé sans toucher au journal primaire. Cette séparation vous permet de reconstruire l’index si sa structure évolue.

Évaluez SQLite lorsque les requêtes deviennent une exigence

SQLite répond mieux à un besoin de filtrage structuré : retrouver les sessions d’un projet, regrouper les événements par type, rechercher des appels d’outils ou établir une vue d’audit. Le dépôt officiel expose d’ailleurs un module de persistance SQLite distinct du module JSONL, ce qui confirme qu’il s’agit d’un choix d’implémentation, pas d’une propriété obligatoire de toute session. (github.com)

La contrepartie est opérationnelle. Une base SQLite n’est pas toujours représentée par un seul fichier stable pendant une écriture. En mode WAL, le fichier principal peut être accompagné d’un fichier -wal et d’un fichier de mémoire partagée. SQLite rappelle que ces éléments peuvent être nécessaires à la récupération après une interruption ; copier le seul fichier principal au mauvais moment peut donc produire une sauvegarde incohérente. (sqlite.org)

Pour un agent qui écrit continuellement, vérifiez au minimum :

  • l’état de la transaction après une interruption pendant un événement d’outil ;
  • la réouverture de la base après redémarrage du processus ;
  • la reprise d’une session qui n’a pas atteint son état final ;
  • la possibilité de reconstruire une copie de sauvegarde sans arrêter durablement l’agent ;
  • la cohérence entre la base, le journal et les fichiers auxiliaires.
Pour une sauvegarde active, évitez le simple cp exécuté au hasard pendant une transaction. La documentation SQLite présente l’Online Backup API et VACUUM INTO comme des méthodes adaptées à la production d’une copie cohérente d’une base vivante. ([sqlite.org](https://www.sqlite.org/backup.html?utm_source=openai))

Si votre équipe ne dispose pas encore d’une procédure de sauvegarde SQLite validée, JSONL peut être le choix le plus responsable, même si les requêtes sont moins élégantes. Vous pourrez créer un index secondaire plus tard, alors qu’une restauration mal conçue peut vous faire perdre la confiance dans toute la chaîne de conservation.

Gardez le disque local comme hypothèse de sécurité

Le stockage sur un Mac local, un volume interne ou un disque monté directement n’a pas les mêmes hypothèses qu’un répertoire partagé entre plusieurs machines. Dans un scénario cloud, la tentation est forte de placer le dossier de sessions sur un volume réseau afin de le rendre visible depuis plusieurs environnements. Pour SQLite, cette décision est particulièrement risquée.

SQLite dépend du comportement réel des verrous, de la synchronisation des écritures et de la cohérence du système de fichiers. Sa documentation déconseille de considérer un fichier de base ouvert directement sur un système de fichiers réseau comme une architecture normale ; les problèmes peuvent rester intermittents et ne pas apparaître lors d’un premier essai. (sqlite.org)

Le mode WAL ne transforme pas un partage réseau en disque local. Avant toute utilisation, exécutez un test distinct dans le même type de montage que la production :

  1. ouvrez deux processus qui lisent et écrivent selon le modèle prévu ;
  2. vérifiez que les verrous empêchent réellement les écritures concurrentes incompatibles ;
  3. interrompez l’un des processus pendant une transaction ;
  4. redémarrez depuis le même Mac puis depuis un second client ;
  5. vérifiez la présence et l’association correcte du fichier principal, du WAL et de la mémoire partagée ;
  6. lancez une vérification de l’intégrité et comparez le nombre d’événements attendus.
Si un seul de ces tests dépend d’un comportement non documenté du fournisseur de stockage, ne placez pas la base active sur le partage. Conservez la persistance sur le disque local du Mac cloud et livrez ensuite une copie contrôlée ou un export vers le stockage partagé.

Cette règle est moins spectaculaire qu’un montage centralisé, mais elle réduit une responsabilité souvent oubliée : l’équipe qui administre le partage doit alors garantir les verrous, la latence, les interruptions et la restauration transactionnelle, pas seulement la disponibilité du volume.

Organisez les recherches sans remplacer automatiquement le journal

Les équipes d’audit ont souvent besoin de réponses qui ne correspondent pas directement à la structure de persistance : « quelles sessions ont modifié ce dépôt ? », « quels appels d’outil ont échoué ? », « quels travaux n’ont jamais repris après redémarrage ? ».

La bonne architecture consiste à conserver :

  • un journal de session primaire, en JSONL ou SQLite ;
  • un index de recherche dérivé, reconstructible ;
  • une copie de sauvegarde livrable, testée séparément.
Avec JSONL, l’index peut être régénéré en parcourant les événements. Avec SQLite, certaines requêtes peuvent être plus directes, mais vous devez vérifier que l’index ou les projections ne sont pas devenus le seul endroit contenant une information indispensable à la reprise. Le dépôt distingue justement la persistance durable, les projections et la couche de requête ; cette séparation doit rester visible dans votre procédure d’exploitation. ([github.com](https://github.com/deepseek-ai/deepseek-harness/tree/master/packages/session))

Pour les usages créatifs, cette distinction est utile : les fichiers lourds d’un montage vidéo, d’une bibliothèque audio ou d’un projet de design ne doivent pas être confondus avec les événements de session. Le backend conserve l’historique et les décisions de l’agent ; les médias et les artefacts doivent suivre leur propre stratégie de versionnement et de sauvegarde.

Préparez la migration avec une voie de retour

DeepSeek Harness étant en aperçu développeur, ne planifiez pas une conversion globale comme si les formats étaient figés. Le dépôt officiel mentionne explicitement des changements incompatibles possibles. (github.com)

Utilisez plutôt cette séquence :

  1. Figez l’inventaire. Notez la version exacte de Harness, le commit ou la version de distribution, la clé de configuration, le backend actif, le chemin de stockage et le type de disque.
  1. Conservez l’ancien backend en lecture seule. Ne le déplacez pas immédiatement et ne le supprimez pas après une première ouverture réussie.
  1. Sélectionnez un petit échantillon. Prenez une session courte, une session longue, une session avec appel d’outil et une session interrompue.
  1. Testez le nouveau backend séparément. Vérifiez l’écriture, la fermeture, la reprise, la recherche et la sauvegarde. La réussite de l’import n’est qu’un début.
  1. Comparez le contenu utile. Contrôlez les identifiants, les derniers événements, les sorties d’outils, les métadonnées et la possibilité de poursuivre le travail.
  1. Simulez l’échec. Désactivez le nouveau backend et revenez à l’ancien chemin. Si le retour arrière exige une opération manuelle non documentée, la migration n’est pas prête.
  1. Définissez une date de bascule. Après cette date, les nouvelles sessions utilisent le backend retenu ; l’ancien reste conservé pendant la période de vérification définie par votre équipe.
Ne promettez pas qu’une session ancienne sera réutilisable directement après chaque mise à jour. Conservez la preuve de la version et du résultat de reprise avec la sauvegarde elle-même.

FAQ opérationnelle

Les réponses ci-dessous reprennent les pièges qui apparaissent généralement au moment du déploiement sur un Mac local ou un Mac cloud : emplacement implicite, écriture longue, WAL, migration et livraison des sauvegardes.

Quel backend retenir pour un Mac cloud ?

Choisissez JSONL si vous exploitez peu de sessions, si chaque session doit être copiée séparément et si la restauration doit pouvoir être vérifiée manuellement. Choisissez SQLite si le volume de sessions impose des requêtes régulières et si la base reste sur un disque local dont les verrous et les sauvegardes ont été testés. Le réseau doit servir à livrer une copie, pas à fournir le fichier actif par défaut.

Faites le choix final selon votre responsabilité d’exploitation

Si vous êtes seul, que vous testez DeepSeek Harness ou que vous conservez des sessions de design, d’audio, de vidéo ou de développement par projet, commencez par le JSONL et exigez une preuve de restauration minimale. Vous gagnerez surtout en transparence : un fichier ou un dossier peut être examiné, copié et archivé sans introduire immédiatement une procédure de base de données.

Si vous administrez de nombreuses sessions, que vous devez effectuer des recherches d’audit et que le stockage reste local, SQLite mérite un essai contrôlé. Son intérêt vient des requêtes structurées, pas d’une promesse abstraite de fiabilité supérieure. Le mode WAL, les verrous et la sauvegarde doivent être validés dans votre environnement.

Si votre solution actuelle repose sur un partage réseau, une copie de fichier faite pendant l’écriture ou une migration sans ancien backend conservé, ses défauts sont concrets : reprise non prouvée, sauvegarde potentiellement incomplète, diagnostic difficile et responsabilité dispersée entre l’application et le stockage. Dans ce cas, louer un Mac auprès de MACGPU peut offrir un environnement plus maîtrisable pour isoler la session sur un disque local, exécuter les tests d’arrêt et remettre ensuite une copie vérifiée. Vous pouvez comparer les environnements disponibles sur la page française de MACGPU, puis consulter un Mac M4 à Silicon Valley ou un Mac M4 en Virginie selon vos contraintes de distance et de livraison.

Avant de migrer, remplissez donc votre propre choix : durée de conservation, besoin de recherche, type de disque, méthode de sauvegarde et résultat du test de reprise. Si vous préparez un environnement distant, faites de la restauration et de la remise des données un critère d’acceptation, au même niveau que l’écriture initiale.