Import

L'import fait entrer une base de connaissances existante dans un espace en un seul téléversement : exports de claude.ai et de ChatGPT, serveur de mémoire MCP, projets et mémoire Claude, mais aussi de simples fichiers Markdown et texte. Le format est détecté d'après le contenu, et non d'après le nom du fichier : vous n'avez donc rien à préparer à la main — le moteur analyse l'archive de lui-même et la range en dossiers.

L'import est le miroir de l'export : l'export lit sur le disque les fichiers qui sont la source de vérité, tandis que l'import analyse la source et écrit les notes par le chemin d'écriture habituel. Chaque note arrive dans l'espace exactement comme si un humain l'avait créée dans l'éditeur — avec versionnement, provenance et indexation.

Les formats reconnus

Une même archive Claude ou ChatGPT contient généralement plusieurs types de données à la fois ; l'import détecte et reprend tout ce qu'il sait traiter :

Source	Fichier dans l'export	Ce qui devient une note
Conversations Claude	`conversations.json`	Une note par conversation, messages sous forme de `### Human/Assistant`
Conversations ChatGPT	`conversations.json` (y compris fragmenté en `conversations-000.json…`)	Une note par conversation, transcription dans l'ordre chronologique
Mémoire MCP	`memory.json` (JSONL)	Une note par entité ; les relations → `[[wikilinks]]`
Projets Claude	`projects.json` ou `projects/<uuid>.json`	Un dossier de projet : documents + instructions
Mémoire Claude	`memories.json`	Une note par bloc de mémoire du compte
Chats de design Claude	`design_chats/<uuid>.json`	Une note par chat
Markdown / texte	`.md`, `.txt`	Une note, le corps du fichier = le corps de la note

Le format est déterminé en analysant le contenu (chaque service livre un fichier nommé conversations.json, le nom n'est donc pas fiable). Les messages vides et les conversations dépourvues du moindre fragment utile ne créent pas de notes « orphelines » — le nombre d'éléments ignorés apparaît dans le récapitulatif de l'import. Si l'archive contient du JSON non reconnu, il y figure lui aussi, marqué unsupported : une perte de données est toujours visible dans le récapitulatif, jamais silencieuse.

Comment importer

L'import se trouve dans l'onglet Import des paramètres de l'espace (/s/<space>/management/import). Chaque option forme sa propre section :

File — choisissez le fichier d'export (conversations.json, l'export ZIP en entier ou memory.json). Un fichier .md/.txt isolé s'importe par glisser-déposer (voir plus bas), et non par cette boîte de dialogue.
Skip existing notes — que faire lors d'un import répété (voir plus bas).
Memory entries — où placer les entités de mémoire (voir plus bas).

Un import long s'exécute comme une tâche durable : une barre de progression avec un compteur en direct des notes écrites, la phase en cours et un bouton Cancel. Vous pouvez quitter l'onglet et y revenir — l'import continue de tourner en arrière-plan, et à votre retour vous retrouvez la progression, ou le récapitulatif final.

Déposez un fichier dans la fenêtre

La boîte de dialogue de téléversement dédiée n'a rien d'obligatoire : déposez un fichier .md ou .txt directement dans la fenêtre de l'application et il devient une note. Un dépôt sur un dossier de l'arborescence y classe la note ; un dépôt dans la zone de contenu la classe dans le dossier de la note ouverte, ou à la racine. C'est le même pipeline d'import, avec simplement une seconde porte d'entrée.

L'option « Skip existing notes »

Le nom de fichier d'une note est déterministe et lié à l'identité de la source. De ce fait, réimporter le même export écrase les mêmes fichiers au lieu de multiplier les doublons — et cinquante conversations « Untitled » n'entrent pas en collision les unes avec les autres.

Désactivée (valeur par défaut pour un téléversement répété — upsert) — les notes existantes sont écrasées par chemin, de façon idempotente.
Activée — les notes dont le chemin existe déjà sont ignorées. C'est le cas « j'ai réimporté un historique mis à jour : n'écrase pas ce que j'ai déjà corrigé à la main ».

L'option « Memory entries »

Les entités issues de memory.json peuvent être dirigées vers trois destinations au choix :

folder — des notes visibles, côté utilisateur, sous le dossier racine de l'import.
space — dans le point de montage caché de la mémoire d'agent de l'espace (.notarium/memory) : ces entrées n'apparaissent ni dans l'arborescence, ni dans le Fil, ni dans la recherche, mais l'agent y accède via recall.
skip — ne pas importer la mémoire du tout.

Mémoire de l'espace, pas le domaine global

L'option space place les entrées dans la mémoire d'agent de cet espace précis. Il n'existe pas, dans l'interface de l'espace, d'explorateur dédié à cette mémoire — l'agent la voit via recall. C'est la mémoire d'un espace précis, et non le domaine personnel global de mémoire (celui qui s'ouvre par la vue Memory dans l'arborescence de l'explorateur) — cet import n'y écrit pas.

Comment les données sont organisées

L'import crée une arborescence de dossiers prévisible à l'intérieur de la racine choisie :

conversations/claude/     — conversations Claude
conversations/chatgpt/    — conversations ChatGPT
projects/<projet>/        — projets Claude (+ docs/, prompt-template.md)
memory/claude/            — mémoire du compte Claude
memory/<type-entité>/     — entités de memory.json
design-chats/<projet>/    — chats de design Claude

Les dates sont préservées comme des données

Un import naïf daterait tout l'historique d'« aujourd'hui », et le Fil entasserait des centaines de conversations en un seul tas. Notarium, lui, propage la date de création comme une donnée : chaque note reçoit dans son frontmatter un created: fixé au moment où la conversation a réellement eu lieu. Le Fil répartit l'historique importé sur ses vrais jours, et la boucle export → import conserve les dates — rien ne se perd au passage.

Le champ « Created » se modifie aussi à la main depuis l'éditeur (les métadonnées d'une note) — lors d'une migration, par exemple, ou pour corriger la date d'une note. L'heure de dernière modification (modified), elle, reflète toujours le moment où le fichier a réellement été édité et ne peut pas être modifiée.

Sous le capot

L'import est conçu pour encaisser aussi bien des archives de plusieurs gigaoctets qu'une coupure de connexion :

Traitement en flux. Le téléversement est écrit sur le disque au fil de l'eau, le ZIP est décompressé entrée par entrée, et le tableau JSON des conversations est analysé élément par élément — une conversation à la fois. Le pic de mémoire ne dépend pas de la taille de l'archive : un export de 600 Mo ne fait donc pas tomber le serveur.
Tâche durable. Lorsque l'hôte dispose d'une base de métadonnées (la norme en auto-hébergement), l'import est par défaut une tâche durable : le téléversement est enregistré dans la zone de transit, et un worker en arrière-plan écrit les notes en dehors de la requête. Un onglet fermé, une connexion perdue, voire un redémarrage du serveur — rien de tout cela ne vous coûte la moindre progression.
Coopération. Un import en masse ne monopolise pas le serveur : l'écriture cède le pas aux requêtes interactives, et l'indexation en arrière-plan se met en pause le temps du flux, puis rattrape son retard. La recherche et la navigation restent réactives même pendant que des milliers de notes s'écrivent.

flowchart LR
  src([Archive / fichier]) -->|téléversement| stage[Zone de transit sur disque]
  stage -->|tâche d'import| worker[Worker en arrière-plan]
  worker -->|chemin d'écriture| notes[(Notes Markdown)]
  worker -.->|progression| ui([Onglet Import])

Import sans base de métadonnées

Sur un hôte sans base de métadonnées (elle n'est absente qu'en mode AUTH_MODE=none), il n'y a pas de couche de tâches : l'import emprunte la voie synchrone en flux, au sein d'une seule requête, avec le même cœur et le même compteur en direct. La progression et le récapitulatif se présentent de la même façon ; seule différence : l'import ne survit pas à un redémarrage du serveur.

Limites

Annuler, mais pas suspendre. Une tâche s'annule (de façon coopérative), mais ne se met pas en pause pour être reprise ensuite.
L'indicateur est indéterminé. Le nombre de notes d'une archive n'est pas connu à l'avance : la progression affiche donc la phase et un compteur en direct des notes écrites, pas un pourcentage ni un temps restant estimé.
Un téléversement interrompu repart de zéro. La durabilité n'entre en jeu qu'une fois les octets arrivés : si le téléversement d'une grande archive est coupé, il recommence.
Les pièces jointes binaires ne sont pas importées. Le texte des pièces jointes est intégré au corps de la note, mais pas les fichiers binaires eux-mêmes (comme pour l'export).
L'import atterrit à la racine de l'espace. La boîte de dialogue d'import ne permet pas de choisir un dossier cible — les notes vont à la racine ; en glisser-déposer, la racine est déterminée par la zone de dépôt.

Et ensuite

Export — récupérer un espace ou un dossier sous forme d'archive Markdown.
Agents et MCP — comment un agent exploite la mémoire importée via recall.