WeClone : cloner un style de conversation à partir d'un historique Telegram

Ce que le projet cherche à résoudre, et pour qui

Un historique de conversation contient un style : tournures récurrentes, longueur des réponses, façon de couper une phrase, tics de ponctuation. WeClone part de ce constat et propose une chaîne complète qui va de l'export des messages jusqu'à un bot qui répond à votre place. Le README résume l'ambition en une ligne : une solution en un seul point d'entrée pour créer un avatar numérique à partir de l'historique de chat. Le public visé est donc assez précis. Il faut posséder un historique exploitable, ce qui exclut d'emblée quiconque n'a pas accumulé de conversations sur une plateforme supportée. Il faut aussi une machine avec GPU, puisque l'entraînement se fait en local selon le README, présenté comme un choix de contrôle des données. Ce n'est pas un service hébergé : c'est un dépôt Python à cloner, configurer et lancer soi-même.

Le trajet d'une donnée, de l'export au bot

La chaîne se lit dans l'ordre du README : export des données de chat, prétraitement, entraînement, déploiement. Le prétraitement inclut un filtrage des informations privées, présenté comme une étape de la solution et non comme une option périphérique. Vient ensuite le fine-tuning, qui s'appuie sur LLaMA Factory : le projet ne réimplémente pas la boucle d'entraînement, il l'orchestre. Le modèle par défaut cité est Qwen2.5-VL-7B-Instruct, entraîné en SFT avec la méthode LoRA. Ce choix explique une partie du tableau des ressources : LoRA en précision 16 bits demande environ 16 Go de VRAM pour un modèle 7B, contre 120 Go pour un entraînement complet en bf16. Le README précise que d'autres modèles et méthodes supportés par LLaMA Factory restent utilisables, ce qui déplace la question de la compatibilité vers le projet amont. Le déploiement, enfin, branche le modèle sur une plateforme de messagerie. Telegram est marqué comme supporté à la fois en source et en déploiement. Le support des données image existe aussi côté entraînement, mentionné dans les mises à jour de juin 2025.

Mise en route : les commandes du README

Le README impose CUDA 12.6 ou supérieur avant toute chose. L'installation recommandée passe par uv, avec un environnement Python 3.12 : git clone du dépôt, création du venv, activation, puis installation des dépendances via le groupe main en mode éditable. La configuration se fait ensuite dans un seul fichier. Il faut copier le gabarit examples/tg.template.jsonc vers settings.jsonc, et c'est dans ce fichier que vivent les paramètres d'entraînement et d'inférence, comme le README le précise explicitement. Deux points méritent attention avant de lancer quoi que ce soit. D'abord, le gabarit fourni est celui de Telegram : si votre source est ailleurs, la question de l'export se pose avant la configuration. Ensuite, le README signale que Windows n'a pas été testé rigoureusement et suggère WSL comme environnement d'exécution. Sur un poste Windows, cela ajoute une couche à maîtriser avant même d'atteindre le fine-tuning.

Le tableau des ressources dit l'essentiel sur le matériel

Le README fournit un tableau de VRAM estimée par méthode et par taille de modèle. Il faut le lire comme un filtre, pas comme une fiche technique. Un entraînement complet en 7B en bf16 demande environ 120 Go, ce qui sort du champ d'un poste de travail. En QLoRA 4 bits, la même taille tombe à environ 6 Go, et 4 Go en 2 bits. Entre les deux, LoRA en 16 bits à 16 Go reste la configuration la plus citée par le projet, puisqu'elle correspond au modèle par défaut. La progression est à peu près linéaire avec la taille : 32 Go pour du LoRA en 14B, 64 Go en 30B, 160 Go en 70B. Ces chiffres sont des estimations données par le README, pas des mesures. Ils suffisent néanmoins à trancher une question pratique : viser 14B ou plus, comme le recommande le projet pour la qualité, double ou quadruple le besoin matériel par rapport à la configuration 7B.

La limite que le projet annonce lui-même

C'est rare et cela mérite d'être relevé : le README écrit noir sur blanc que les performances du modèle 7B sont moyennes, et que les modèles de 14B et plus donnent de meilleurs résultats. Il ajoute que l'efficacité du fine-tuning dépend largement de la taille du modèle et de la quantité comme de la qualité des données de chat. Autrement dit, la configuration par défaut, la moins coûteuse en VRAM, est aussi celle dont le projet dit qu'elle ne convainc pas vraiment. L'avertissement complémentaire est que WeClone est en phase d'itération rapide et que les performances actuelles ne représentent pas les résultats finaux. Cela crée une situation inconfortable pour un adoptant : la voie d'entrée accessible est reconnue comme insuffisante, et la voie recommandée suppose un GPU que peu de gens ont. À cela s'ajoute une contrainte de source. Le tableau des plateformes montre Telegram comme seule source réellement supportée pour le texte et les images. WhatsApp, Discord et Slack sont tous marqués en chantier côté source. Si votre historique vit ailleurs, WeClone n'est pas l'outil adapté aujourd'hui, quelle que soit la qualité du reste.

Ce à quoi on le compare : LLaMA Factory seul

Puisque WeClone s'appuie sur LLaMA Factory pour l'entraînement, la comparaison utile est celle-là. LLaMA Factory est un cadre de fine-tuning qui couvre un grand nombre de modèles et de méthodes, avec sa propre interface et ses propres formats de données. Il ne sait rien de Telegram, ne fournit pas d'étape de filtrage des informations privées, et ne déploie pas de bot de messagerie. WeClone apporte précisément ces trois briques autour du cadre : l'export depuis une plateforme, le nettoyage, et le branchement sur un bot. La différence n'est donc pas dans la qualité de l'entraînement, qui reste celle de LLaMA Factory, mais dans le travail d'assemblage. Si vous avez déjà un pipeline de données propre et un script de déploiement, l'apport de WeClone se réduit à la partie export et filtrage. Si vous partez de zéro avec un historique Telegram, c'est l'inverse : la valeur est dans l'assemblage, et la dépendance à LLaMA Factory est un coût accepté.

Licence, maintenance et coût de mise à jour

WeClone est publié sous AGPL-3.0. Cette licence a une conséquence pratique qu'il faut nommer sans faire de droit : si vous modifiez le projet et le mettez à disposition d'utilisateurs sur un réseau, l'AGPL impose de fournir le code source correspondant à ces utilisateurs. Déployer un bot Telegram accessible à d'autres personnes fait entrer dans ce cas de figure. Pour un usage strictement personnel et local, la question ne se pose pas de la même façon. Le rythme de publication est irrégulier : v0.3.01 en juillet 2025, v0.3.02 en août 2025, v0.3.03 en janvier 2026, avec un dernier push sur master en septembre 2026. Le projet se présente lui-même comme en itération rapide, ce qui implique que settings.jsonc et les commandes d'installation peuvent bouger entre deux versions. La dépendance à LLaMA Factory ajoute une seconde source de changement : une mise à jour du cadre amont peut affecter les modèles et méthodes disponibles. Un déploiement stable suppose donc de figer une version du dépôt et une version de LLaMA Factory, plutôt que de suivre master.

Conclusion éditoriale

WeClone s'adresse à des équipes ou des individus qui disposent déjà d'un historique Telegram volumineux, d'un GPU d'au moins 16 Go pour du LoRA en 7B, et qui acceptent de faire tourner LLaMA Factory en amont. Ce n'est pas l'outil à choisir si votre corpus vit sur WhatsApp, Discord ou Slack en tant que source : le tableau du README les marque tous en chantier. Avant d'investir du temps, vérifiez deux choses concrètement : que l'export Telegram couvre bien les messages que vous croyez avoir, et que le filtrage des informations privées tourne sur votre corpus réel, pas sur un échantillon. Le reste, y compris le passage à 14B ou plus, se décide après avoir vu la qualité du jeu de données nettoyé.

Sources officielles

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. xming521/WeClone on GitHub