De JSON brut à quatre formats d’export

Dans les deux premiers articles, nous avons suivi le chemin jusqu’aux données.

Nous avons vu pourquoi Stalker Chat Export V4 a été construit.

Puis nous avons regardé comment l’extension récupère directement la conversation au lieu de reconstruire la page affichée dans Firefox.

Mais recevoir le JSON n’est que la moitié du travail.

Il faut maintenant en faire quelque chose d’utilisable.

Le JSON brut n’est pas encore un export.

La réponse reçue par V4 contient les données de la conversation, sa structure, ses relations entre les différents nœuds et les messages eux-mêmes.

C’est une excellente source de données.

Mais ce n’est pas forcément le format dans lequel quelqu’un souhaite relire son ancienne conversation.

On pourrait simplement enregistrer le JSON tel quel.

Et c’est justement ce que V4 permet de faire.

Mais nous voulions aller plus loin.

Une seule extraction, plusieurs sorties.

Le principe retenu est simple :

une conversation récupérée → une structure interne → plusieurs formats d’export.

Il n’est donc pas nécessaire de refaire l’extraction pour chaque format.

Le JSON reçu sert de matière première.

Après reconstruction de la conversation, V4 peut produire quatre fichiers différents :

• Markdown — pour une lecture simple et une réutilisation dans un éditeur.
• HTML — pour conserver une présentation structurée et directement consultable dans un navigateur.
• TXT — pour obtenir la version la plus simple et la plus universelle.
• JSON — pour conserver les données structurées.

Quatre formats.

Une seule extraction.

Pourquoi ne pas convertir directement le JSON ?

Parce que le JSON reçu n’est pas simplement une longue liste de messages.

La conversation possède une structure.

Un message peut avoir un parent.

Un nœud peut avoir plusieurs enfants.

Il peut donc exister plusieurs chemins possibles dans les données.

V4 doit d’abord déterminer le chemin actif avant de transformer les messages en document linéaire.

RAW JSON
   │
   ├── mapping
   ├── current_node
   └── message nodes
         │
         ▼
   ACTIVE CONVERSATION PATH
         │
         ▼
   RECONSTRUCTED MESSAGES
         │
         ├──────────────┬──────────────┬──────────────┐
         ▼              ▼              ▼              ▼
       .MD            .HTML          .TXT           .JSON

C’est cette étape intermédiaire qui permet de garder une logique commune aux quatre exports.

Le Markdown >

Le Markdown est probablement le format le plus naturel pour notre propre usage.

Il reste lisible dans un simple éditeur de texte et peut facilement être réutilisé dans d’autres outils.

Chaque intervention est reconstruite avec son rôle et son contenu.

## User

Question or message from the conversation.

## ChatGPT

Response from ChatGPT.

## User

Another message.

## ChatGPT

Another response.

Pas de mise en page complexe.

Pas de dépendance à une application particulière.

Le fichier reste un document texte.

L’HTML >

L’HTML répond à un besoin différent.

On veut pouvoir ouvrir le fichier dans Firefox et retrouver immédiatement une présentation structurée.

V4 génère donc un document autonome à partir des mêmes données reconstruites.

<article class="chat-export">

  <section class="message user">
    ...
  </section>

  <section class="message assistant">
    ...
  </section>

</article>

L’intérêt est de pouvoir conserver une copie directement consultable, sans devoir revenir dans ChatGPT pour relire l’ancienne conversation.

Le TXT >

Le TXT est volontairement beaucoup moins ambitieux.

C’est précisément son intérêt.

Un fichier texte brut peut être ouvert pratiquement partout.

Il n’a pas besoin d’un navigateur particulier, d’un éditeur Markdown ou d’un traitement supplémentaire.

Pour une archive, c’est parfois exactement ce que l’on veut.

Le JSON >

Et puis il y a le JSON.

Contrairement aux trois autres formats, il conserve la structure des données.

C’est le format destiné à ceux qui veulent continuer à travailler avec les données plutôt qu’avec leur présentation.

Il peut notamment servir de base à une analyse ultérieure, à un traitement automatisé ou simplement à une conservation fidèle des données structurées reçues par l’extension.

Le Markdown est fait pour lire.
L’HTML est fait pour consulter.
Le TXT est fait pour rester universel.
Le JSON est fait pour travailler avec les données.

Une seule reconstruction pour quatre formats.

Le point important n’est donc pas d’avoir ajouté quatre boutons.

Le véritable choix d’architecture est ailleurs.

V4 ne traite pas quatre fois la conversation.

Elle extrait les données une fois, reconstruit la conversation une fois, puis utilise cette structure pour produire les différents formats.

API RESPONSE
     │
     ▼
CONVERSATION DATA
     │
     ▼
ACTIVE PATH
     │
     ▼
MESSAGE STRUCTURE
     │
     ├──────► Markdown
     ├──────► HTML
     ├──────► TXT
     └──────► JSON

Cette séparation rend également les tests beaucoup plus simples.

Si la reconstruction est correcte, les quatre formats doivent partir de la même représentation de la conversation.

Le contrôle avant téléchargement.

Nous ne voulions pas simplement afficher une barre verte et considérer que tout allait bien.

Avant de proposer le téléchargement, V4 vérifie plusieurs éléments de la reconstruction.

API response received
        ↓
mapping present ?          ✓
current_node detected ?    ✓
root found ?               ✓
active path valid ?        ✓
messages reconstructed ?   ✓
        ↓
     EXPORT READY

Ce contrôle est particulièrement important pour les longues conversations et pour les conversations qui contiennent des branches.

Un fichier peut parfaitement être créé alors que la reconstruction est incorrecte.

Le simple fait d’obtenir un fichier ne prouve donc pas que l’export est complet.

Le principe de V4.

Au départ, le problème semblait être un problème d’export.

En réalité, il fallait d’abord comprendre la structure de la conversation.

Une fois cette structure comprise, les formats deviennent presque une conséquence logique.

Le même contenu peut être présenté différemment sans être extrait plusieurs fois.

Une conversation.
Une extraction.
Une structure.
Quatre façons de la conserver.

Et maintenant, les longues conversations.

Jusqu’ici, les essais nous ont permis de vérifier que V4 pouvait récupérer une conversation, reconstruire son chemin actif et produire plusieurs formats.

Mais une petite conversation ne permet pas vraiment de mettre l’architecture à l’épreuve.

Que se passe-t-il avec une conversation contenant plusieurs centaines de messages ?

Que se passe-t-il lorsque le JSON devient beaucoup plus volumineux ?

Et surtout : est-ce que V4 reste capable de terminer l’extraction sans que l’utilisateur ait besoin d’attendre une éternité devant sa fenêtre Firefox ?

À suivre…

(4) – Le test des conversations volumineuses.

Dans le prochain article, nous allons pousser Stalker Chat Export V4 sur les conversations qui commencent réellement à devenir intéressantes en taille.

Parce qu’un export qui fonctionne sur vingt messages, c’est bien.

Un export qui tient encore debout quand le chat devient énorme, c’est autre chose.

AxehGo & DebIA
Independent Research & Experiments in Linux, AI and Statistical Computing