ChatGPT-On-CS : un agent d'assistance qui pilote les messageries e-commerce depuis le bureau

Le problème visé : plusieurs messageries, une seule personne

Un vendeur présent sur Qianniu, Pinduoduo et Douyin ne reçoit pas ses messages dans une boîte unique. Chaque place de marché impose son propre client, avec ses fenêtres et ses notifications. Le README annonce une « 聚合聊天 », c'est-à-dire une file de conversations où les demandes Taobao, Pinduoduo, Douyin et JD se retrouvent côte à côte. Le projet vise donc un opérateur unique qui surveille plusieurs comptes marchands, pas une équipe disposant déjà d'un centre de contact outillé.

La cible est étroite : des vendeurs chinois, ou des prestataires qui gèrent des boutiques pour leur compte, sur des plateformes dont l'accès programmatique est fermé ou réservé aux partenaires agréés. Le README mentionne aussi une offre OEM, ce qui indique que le dépôt sert de socle à des revendeurs qui posent leur propre marque.

Un point de vocabulaire utile : le dépôt s'appelle ChatGPT-On-CS mais le README décrit le produit sous le nom 金销数据云智能客服. Le code publié et la vitrine commerciale ne portent pas le même nom, et les deux ne se recouvrent pas forcément.

Ce que révèle la pile technique : de l'automatisation d'interface, pas des webhooks

Les sujets du dépôt incluent autohotkey aux côtés de typescript et llm. Autohotkey est un outil d'automatisation Windows qui simule des frappes et des clics. Sa présence dans un projet écrit en TypeScript indique que l'agent n'appelle pas des API de messagerie : il agit sur les clients installés localement, en lisant les fenêtres de conversation et en y injectant du texte.

Les conséquences de ce choix sont structurelles. L'agent doit tourner sur une machine Windows dotée d'une session graphique, avec les clients de chaque plateforme ouverts. Le README mentionne d'ailleurs le « 浏览器多开支持 », soit la capacité à faire tourner plusieurs sessions de navigateur en parallèle, ce qui confirme que l'architecture repose sur des sessions locales plutôt que sur des connexions serveur à serveur.

Le flux se lit ainsi : un message arrive dans une fenêtre de messagerie, le programme le capte, l'envoie au modèle choisi (GPT-3.5, GPT-4, 通义千问, 文心一言 ou DeepSeek selon le README), récupère la réponse, puis la saisit dans la même fenêtre. Entre les deux, une base de connaissances propre à l'entreprise peut être interrogée, et un système de plugins peut donner accès à des ressources externes. Aucune de ces étapes n'est décrite en détail dans le README, qui renvoie à six vidéos de démonstration hébergées dans docs/videos/.

Fonctions annoncées et fonctions documentées

La liste des fonctionnalités est longue : réponse automatique, modèles de réponses prédéfinies, traitement du texte, de la voix et des images, import et export Excel des réponses, détection de la reprise en main par un humain, export des historiques, réponse différée aléatoire, mention du robot dans les groupes WeChat, et un outil de test de correspondance par mots-clés.

Deux éléments méritent l'attention. La « 人工接管自动检测 » signifie que l'agent doit s'effacer quand un opérateur humain intervient. C'est une contrainte de conception importante, et le README ne dit pas comment la détection fonctionne ni quel est son taux d'erreur. La « 延时随机回复 » indique que le produit cherche à ne pas répondre instantanément, probablement pour imiter un rythme humain. Là encore, aucun paramètre n'est donné.

Le README indique que la base de connaissances n'est pas rédigée à la main mais extraite de conversations réelles, formulation reprise de la légende d'une vidéo. C'est une affirmation produit, pas une description d'algorithme. Le dépôt ne contient, dans les extraits fournis, aucune explication du procédé d'extraction.

Installation : ce que le README ne fournit pas

C'est la faiblesse la plus nette du matériel disponible. Le README ne contient aucune commande d'installation, aucun nom de paquet, aucune clé de configuration, aucun exemple de fichier. Il renvoie à la section « 使用指南 », qui elle-même renvoie vers le site jinxiaoai.com/apps. La documentation d'usage vit donc hors du dépôt.

Pour un lecteur qui évalue l'adoption, c'est un obstacle concret. On ne peut pas vérifier depuis le dépôt quel gestionnaire de paquets est utilisé, s'il existe un fichier .env, comment se déclarent les clés d'API des modèles, ni comment on associe un compte marchand à un profil de réponse. Le README mentionne bien une « 多平台独立配置 », donc une configuration séparée par plateforme, mais sans en montrer la forme.

Ce que l'on peut affirmer, c'est que le projet est publié sous AGPL-3.0 et que le README précise que l'usage commercial requiert une autorisation obtenue en prenant contact. Le dépôt renvoie également vers un miroir Gitee, présenté comme préférable pour les utilisateurs en Chine. Toute évaluation sérieuse commence donc par retrouver la documentation d'installation sur le site, pas dans le code.

La limite de fond : un agent qui dépend de fenêtres qu'il ne contrôle pas

Automatiser une interface graphique, c'est accepter que tout changement visuel côté plateforme casse l'agent. Un bouton déplacé, un libellé modifié, une fenêtre renommée : le programme peut cesser de trouver la zone de saisie sans qu'aucune erreur explicite ne soit levée. Le README ne décrit aucun mécanisme de détection de rupture ni de test de non-régression sur les interfaces cibles.

Le rythme des versions illustre cette fragilité. Les trois publications listées, v1.4.3, v1.4.4 et v1.4.5, s'échelonnent entre le 28 août et le 7 septembre 2024, soit trois versions en onze jours. Le dépôt a reçu des commits bien plus tard, jusqu'au 27 août 2026, mais la dernière version publiée reste v1.4.5. On ne peut pas en déduire que le projet est abandonné, ni qu'il est activement maintenu au sens d'un cycle de publication : le matériel ne permet pas de trancher.

Second point : le traitement de la voix et des images est annoncé sans explication. Un lecteur qui en dépend pour son flux de service client doit considérer cette capacité comme non vérifiée.

Alternatives : construire sur les API au lieu de piloter l'écran

L'approche opposée consiste à brancher un modèle de langage sur les API officielles des plateformes, là où elles existent, ou sur une messagerie qui expose des webhooks. Dans ce modèle, le message arrive par un appel HTTP, la réponse repart par un appel HTTP, et rien ne dépend d'une fenêtre ouverte sur un bureau Windows. Le déploiement tient dans un conteneur, l'agent peut tourner sans session graphique, et une modification d'interface côté plateforme n'a aucun effet.

La différence n'est pas seulement technique, elle est réglementaire et pratique. Passer par les API suppose d'obtenir des identifiants et de respecter les conditions d'accès de chaque place de marché. Pour Qianniu, Pinduoduo ou Douyin, ces accès ne sont pas ouverts à un développeur individuel, ce qui explique probablement le choix de l'automatisation d'interface. Le compromis est donc assumé : ChatGPT-On-CS échange la robustesse contre la couverture. Il atteint des plateformes qu'une intégration par API ne permet pas d'atteindre, au prix d'une dépendance permanente à l'apparence des clients installés.

Le README cite également Dify parmi les sujets du dépôt, ce qui suggère qu'une orchestration externe est envisageable, mais aucun schéma d'intégration n'est fourni.

Licence, maintenance et coût réel

Le projet est sous AGPL-3.0. Le README en résume les conséquences en quatre points : usage personnel libre, usage commercial soumis à autorisation, toute modification devant être publiée et conserver la mention de copyright sauf autorisation commerciale, et renvoi au texte complet de la licence. Cette lecture est celle du README, pas un avis juridique. Une entreprise qui envisage de modifier le code pour l'intégrer à un service interne doit faire examiner la question par un juriste, car l'AGPL étend ses obligations à l'usage en réseau.

Le coût de maintenance se répartit en trois postes identifiables. Le premier est le suivi des interfaces des plateformes, qui ne dépend pas de l'équipe du projet. Le deuxième est l'appel au modèle : le choix entre GPT-4, DeepSeek, 通义千问 ou 文心一言 se traduit par des tarifs à la consommation, dont le README ne donne aucun ordre de grandeur. Le troisième est l'exploitation d'un poste Windows dédié, avec les sessions navigateur multiples que le README mentionne.

La roadmap indique trois chantiers en cours : réponse automatique sur les directs Douyin, publication de contenu multi-plateformes, et support d'un modèle local. Ce dernier point est le plus significatif pour un acheteur soucieux de ne pas envoyer ses conversations clients à un fournisseur externe. Il est listé comme non terminé, ce qui signifie qu'aujourd'hui le traitement passe par un service distant.

Conclusion éditoriale

À adopter si vous exploitez déjà des boutiques sur Qianniu, Pinduoduo ou Douyin et que vous acceptez de faire tourner un agent sur un poste Windows connecté en permanence. À éviter si vous cherchez une intégration par API officielle ou un déploiement serveur sans interface graphique. Avant tout essai, vérifiez deux points précis : la présence effective d'un fichier de configuration et d'instructions d'installation dans l'arborescence, et le fait que l'URL https://jinxiaoai.com/skills renvoie bien une page, le README indiquant lui-même qu'elle répondait encore 404 au 27 août 2026.

Sources officielles

1. cs-lazy-tools/ChatGPT-On-CS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases