WeChat Local Viewer : rechercher et analyser localement les conversations WeChat

Lorsque les conversations WeChat atteignent plusieurs centaines de milliers, voire plusieurs millions de messages, les outils de consultation intégrés au système répondent souvent difficilement aux besoins de recherche, d’archivage et d’analyse. ops120/wechat-local-viewer propose une solution locale : après avoir préparé leur propre base de données de conversations, les utilisateurs peuvent consulter les discussions dans un navigateur, parcourir les messages, effectuer des recherches plein texte, exporter les données et, s’ils le souhaitent, connecter un LLM pour générer des résumés ou répondre à des questions.

Une limite importante du projet est la suivante : ce n’est pas un outil de déchiffrement. Le dépôt ne contient aucun code permettant d’extraire des clés, de déchiffrer une base de données ou de contourner des mécanismes de sécurité. Les données de conversation doivent être préparées par l’utilisateur et placées dans le répertoire prévu par le projet ; la visionneuse se contente d’analyser et d’afficher des données déjà lisibles.

Pourquoi ce projet mérite l’attention

La valeur principale du projet ne réside pas simplement dans l’affichage des conversations, mais dans l’organisation d’une chaîne complète de traitement des données locales :

Lire les bases de données de contacts, de sessions et de messages fournies par l’utilisateur.
Organiser les données dans une base SQLite intermédiaire au moyen d’un processus ETL.
Créer un index plein texte FTS5 pour les messages.
Fournir des interfaces de pagination, de recherche, de statistiques et de LLM via FastAPI.
Utiliser une interface Vue pour parcourir les conversations, consulter le contexte des messages et effectuer des exportations.

Cette architecture évite au frontend de lire directement de grandes bases de données brutes et facilite également les actualisations incrémentielles, la reconstruction des index et l’optimisation des requêtes. Le projet a été testé avec l’importation de 640 000 messages ; la navigation reste fluide. La recherche plein texte repose sur SQLite FTS5 et vise un retour en quelques secondes, généralement en moins d’une seconde.

Fonctionnalités principales

Liste des conversations : affiche les discussions individuelles, de groupe et les comptes officiels, classés par heure du dernier message décroissante.
Consultation des messages : affiche les messages dans l’ordre chronologique et prend en charge la pagination ainsi que le contexte des messages.
Recherche plein texte : recherche dans le contenu des messages avec SQLite FTS5 et fournit des suggestions de recherche.
Exportation dans plusieurs formats : organise les conversations locales dans des données faciles à conserver et à traiter ultérieurement.
Résumés et questions-réponses avec un LLM : se connecte à DeepSeek, OpenAI, SiliconFlow, Ollama et autres services via le protocole compatible avec OpenAI.
Priorité au local : ne dépend d’aucun service HTTP externe, à l’exception du service LLM configuré volontairement par l’utilisateur.
Traitement incrémentiel : l’ETL utilise l’empreinte des données pour déterminer s’il faut effectuer un traitement complet, une mise à jour incrémentielle ou ignorer l’opération.

Configuration requise

Le projet cible Windows 10/11 et nécessite :

Python 3.10 ou version ultérieure
Node.js ^22.19.0 ou >=24.0.0
Windows 10/11

Par défaut, le backend écoute sur le port 18787 et le serveur de développement frontend sur le port 15713. Le projet évite volontairement le port 8765, qui peut poser problème sous Windows, ainsi que le port Vite par défaut 5173, souvent sujet aux conflits.

Préparer le répertoire de données

Placez les données de conversation déjà préparées à la racine du projet. Le projet détecte automatiquement decrypted/ ou .decrypted/ ; un seul des deux suffit :

wechat-local-viewer/
├── decrypted/
│   ├── contact/      # données des contacts
│   ├── session/      # données des sessions
│   ├── message/      # bases de messages, par exemple message_*.db
│   └── hardlink/     # index des images, facultatif
└── start.bat

Le répertoire hardlink/ est facultatif et sert généralement à l’indexation des images. Même en l’absence de fichiers multimédias complets, les messages texte et certaines images déjà restaurées peuvent être consultés normalement.

Démarrage en un clic

Sous Windows, la méthode la plus simple consiste à double-cliquer sur start.bat à la racine du projet. Le script vérifie si le port est déjà utilisé puis ouvre automatiquement :

http://127.0.0.1:18787/

Le backend héberge directement les fichiers frontend déjà compilés ; aucun serveur de développement frontend supplémentaire n’est donc nécessaire pour une utilisation en production.

Pour modifier les ports, définissez les variables d’environnement avant le démarrage :

set WCVIEWER_PORT=28888
set WCVIEWER_FRONT_PORT=25813
start.bat

La détection des ports est très pratique : au lieu de ne signaler une erreur de liaison qu’après le démarrage du service, le script fournit un message clair à l’avance, ce qui est particulièrement utile lorsque plusieurs services de développement locaux fonctionnent simultanément sous Windows.

Démarrage manuel et mode développement

Le backend utilise FastAPI et Uvicorn :

cd backend
pip install -r requirements.txt
python -m uvicorn app.main:app --host 127.0.0.1 --port 18787

Le frontend utilise Vue et Vite :

cd frontend
npm install
npm run dev

Pour compiler la version de production :

npm run build

Une fois la compilation terminée, le backend héberge automatiquement frontend/dist. Lorsque le réseau est limité ou que l’on souhaite améliorer la fiabilité de l’installation npm, la documentation recommande d’utiliser un miroir et de limiter le nombre de connexions simultanées :

npm config set registry https://registry.npmmirror.com
npm config set maxsockets 4
npm config set audit false
npm install

ETL et base de données de cache

Le projet n’analyse pas directement les bases WeChat brutes à chaque requête de page. Il convertit les données sources en base d’exécution via backend/app/etl.py :

.cache/app.db
├── sessions
├── contacts
├── messages
└── index FTS5

Le processus ETL comprend notamment :

parse_sessions : analyse les sessions et les écrit dans la table sessions.
parse_contacts : analyse les contacts et les écrit dans la table contacts.
parse_messages : lit les fichiers tels que message_*.db, écrit les données dans la table messages et crée l’index plein texte.
_update_session_stats : agrège les statistiques des sessions.

L’empreinte des données sert à déterminer s’il faut relancer le traitement. En l’absence de changement, l’opération peut être ignorée ; en cas d’ajout ou de modification, une actualisation incrémentielle est effectuée ; si nécessaire, l’ETL peut également être lancé de force via l’interface d’administration. Cette conception est particulièrement importante pour plusieurs centaines de milliers de messages, car effectuer un import complet à chaque ouverture ralentirait considérablement le démarrage.

Les répertoires suivants sont également générés à l’exécution et ne font pas partie du dépôt source :

.cache/   # base intermédiaire app.db
.export/  # fichiers exportés
.tmp/     # journaux et fichiers temporaires

Ils sont exclus par .gitignore et ne doivent pas être ajoutés au dépôt.

Conception de l’API

Le backend fournit une API REST relativement claire, pratique pour le débogage ou l’extension à d’autres clients :

Endpoint	Méthode	Utilisation
`/api/sessions`	GET	Récupérer les sessions classées par `last_time` décroissant
`/api/sessions/{username}`	GET	Récupérer les détails d’une session
`/api/messages?session=X`	GET	Récupérer les messages par pages
`/api/messages/{id}`	GET	Récupérer un message
`/api/messages/{id}/context`	GET	Récupérer le contexte d’un message
`/api/search?q=X`	GET	Effectuer une recherche plein texte avec FTS5
`/api/search/suggest?q=X`	GET	Obtenir des suggestions de recherche
`/api/admin/etl`	POST	Déclencher l’ETL, avec possibilité de transmettre `{"force": true}`
`/api/admin/status`	GET	Consulter l’état de l’ETL
`/api/admin/logs`	GET	Consulter la fin des journaux
`/api/admin/rebuild-fts`	POST	Reconstruire l’index plein texte
`/api/admin/stats/daily`	GET	Obtenir les statistiques quotidiennes
`/api/llm/config`	GET / POST	Lire ou enregistrer la configuration du LLM
`/api/llm/chat`	POST	Retourner les réponses en continu via SSE
`/media/...`	GET	Fournir les fichiers multimédias restaurés

L’endpoint /api/llm/chat utilise une sortie SSE en continu. L’interface peut ainsi afficher progressivement le contenu pendant la génération du modèle, sans attendre la réponse complète.

Intégration facultative d’un LLM

Le LLM n’est pas une dépendance nécessaire à la visionneuse. Dans la section « Paramètres » située en haut à droite de la page, l’utilisateur peut renseigner un service compatible avec OpenAI :

DeepSeek :    https://api.deepseek.com/v1
OpenAI :      https://api.openai.com/v1
Ollama :      http://localhost:11434/v1
SiliconFlow : https://api.siliconflow.cn/v1

Exemples de modèles courants :

deepseek-chat
gpt-4o-mini
qwen2.5:7b

Les paramètres comprennent Base URL, API Key et Model. La clé API est uniquement stockée dans le localStorage du navigateur et envoyée au backend avec chaque requête de question-réponse. Des valeurs par défaut de secours peuvent également être fournies via des variables d’environnement :

set LLM_BASE_URL=https://api.deepseek.com/v1
set LLM_API_KEY=your-api-key
set LLM_MODEL=deepseek-chat

Même sans LLM configuré, la consultation des conversations, la recherche et l’exportation restent disponibles. Lorsque l’utilisateur clique sur la fonction de résumé, l’interface indique clairement qu’aucun LLM n’est configuré au lieu d’échouer silencieusement.

Il faut noter que « exécuter localement » ne signifie pas que les requêtes LLM sont entièrement locales. Si DeepSeek, OpenAI ou un autre service distant compatible est utilisé, le contenu envoyé à ce service quitte la machine locale. Pour conserver une séparation des données plus stricte, il est possible d’utiliser Ollama en local et de définir Base URL sur http://localhost:11434/v1.

Limites en matière de confidentialité et de sécurité

Le projet met l’accent sur une utilisation locale :

En dehors du base_url LLM configuré par l’utilisateur, aucune requête HTTP externe n’est effectuée.
La route statique /media/ n’énumère pas le contenu du répertoire.
La clé API du LLM est uniquement conservée dans le localStorage du navigateur.
Les données brutes, la base de cache, les fichiers exportés et les journaux temporaires restent sur la machine locale.

Cependant, les conversations contiennent généralement des informations personnelles sensibles. Lors de l’utilisation d’un LLM distant, il faut vérifier les politiques du fournisseur concernant la conservation et l’entraînement des données, et envisager de n’envoyer que les extraits nécessaires. Pour des données hautement sensibles, un modèle local est généralement plus approprié qu’une API distante.

Performances et validation

Les estimations de performance fournies par le projet comprennent :

Démarrage jusqu’au premier affichage : quelques secondes avec une base de 640 000 messages, mais la documentation ne donne pas de durée mesurée précise.
Ouverture d’une conversation : chargement initial de 30 messages, s’appuyant sur des requêtes indexées et offrant de bonnes performances.
Recherche plein texte : utilise FTS5 et vise un retour en quelques secondes.
Premier token en streaming LLM : dépend principalement du service de modèle et de la latence réseau ; aucune valeur mesurée fixe n’est fournie.

Lors du déploiement ou du diagnostic, commencez par vérifier la structure des répertoires frontend :

cd <racine-du-dépôt>
tree /F frontend

Si les dépendances frontend ne sont pas encore installées, accédez au répertoire frontend et lancez l’installation. Si les résultats de recherche sont anormaux, appelez /api/admin/rebuild-fts pour reconstruire l’index. Si l’état de l’ETL n’est pas clair, consultez /api/admin/status et /api/admin/logs.

Cas d’utilisation

WeChat Local Viewer convient aux développeurs et aux utilisateurs avancés qui souhaitent conserver, rechercher ou étudier durablement leurs conversations personnelles, par exemple pour :

Rechercher un mot-clé ou une décision dans un grand volume de messages historiques.
Parcourir les discussions au long cours d’un projet.
Exporter les conversations à des fins d’archivage personnel.
Utiliser un modèle local ou compatible avec OpenAI pour résumer de longues conversations.
Construire un outil de recherche local sans téléverser la base de données complète.

Le projet est distribué sous licence MIT. Son code est principalement écrit en Python, Vue et TypeScript, avec une répartition approximative de 64,8 % pour Python, 24,2 % pour Vue, 7,7 % pour TypeScript, 2,4 % pour Batchfile, 0,5 % pour JavaScript et 0,2 % chacun pour HTML et CSS. Selon les informations affichées sur la page, le dépôt compte 143 stars et 94 forks, et n’a pas encore publié de Release officielle.

En résumé, ce projet transforme la lecture d’une base locale de conversations en une application locale extensible : SQLite FTS5 répond aux besoins de recherche, l’ETL et le cache gèrent le volume, FastAPI et Vue définissent une séparation claire entre les composants, tandis que l’intégration facultative d’un LLM ajoute des fonctions de résumé et de questions-réponses. Surtout, l’utilisateur peut effectuer les opérations essentielles de consultation et de recherche sans dépendre d’un service cloud, puis décider d’activer ou non les fonctions de modèle en fonction de ses exigences de confidentialité.

Source

ops120/wechat-local-viewer : visionneuse locale de conversations WeChat — navigation dans les sessions, recherche plein texte, exportation dans plusieurs formats et résumé intelligent facultatif par LLM, le tout exécuté localement sans dépendances externes.