Du bot QQ à l’espace de travail Discourse : un retour d’expérience authentique sur les limites des outils

Général
1

TL;DR

  • L’objectif central de cette période n’était pas de « faire un bot QQ », mais d’améliorer l’efficacité de la collaboration multi‑tâches et la qualité de la capitalisation du contexte.
  • Le plugin QQ a déjà complété un ensemble complet de capacités exploitables : fiabilité, contrôle des risques, slots de conversation, multimodal, commandes d’administration, etc. Ce n’est pas un simple redirecteur.
  • La valeur du plugin Discourse est de transformer le « chat » en « conteneur de tâches », plus adapté au suivi, au retour d’expérience et à la capitalisation des connaissances.
  • J’ai sérieusement évalué une synchronisation bidirectionnelle QQ↔Discourse : techniquement faisable, mais à ce stade le ROI est faible, avec une complexité et des coûts de maintenance élevés.
  • La stratégie actuelle est donc claire : Discourse en priorité (poste de travail principal), QQ comme point d’entrée (accès à faible friction).
  • Le véritable livrable de ce travail n’est pas seulement des fonctionnalités, mais une méthodologie : séparation du routage et de l’affichage, convergence des responsabilités des plateformes, arbitrages d’ingénierie guidés par la valeur.

Du bot QQ au poste de travail Discourse : un vrai retour d’expérience sur la « frontière des outils »

Cet article est un bilan intermédiaire de ce que j’ai fait récemment dans l’écosystème OpenClaw : plugin QQ, plugin Discourse, réflexion sur la synchronisation cross‑device, puis convergence volontaire de la solution. Ce n’est pas un texte promotionnel, mais un journal de décisions d’ingénierie et de produit.

1. Point de départ : au début, je ne faisais pas « un bot QQ »

Le problème que je voulais réellement résoudre n’a jamais été « sur quelle plateforme discuter », mais :

  • comment traiter plus efficacement plusieurs tâches en parallèle ;
  • comment faire en sorte que le contexte se capitalise, soit recherchable, consultable a posteriori, et collaboratif ;
  • comment permettre à des amis en Chine, sans VPN, de déposer facilement des demandes.

Ces trois objectifs créent naturellement une forte tension dans un même système :

  • l’avantage de QQ, c’est la portée et l’instantanéité ;
  • l’avantage de Discourse, c’est la structuration, le multi‑thread, la capitalisation et la gestion ;
  • l’avantage de OpenClaw, c’est d’unifier plusieurs canaux dans un même Agent et un même système de sessions.

Donc, l’essentiel de cette période a consisté à faire une chose : séparer la « commodité d’entrée » et l’« efficacité de gestion des tâches », puis les équilibrer au mieux par des moyens d’ingénierie, au lieu de forcer l’unification en un seul point d’entrée.

2. Que fait réellement le plugin QQ (ce n’est pas juste « pouvoir discuter »)

Beaucoup sous‑estiment le plugin QQ en pensant qu’il se contente d’envoyer des messages au modèle et de renvoyer du texte. En réalité, ma version du plugin QQ est déjà une couche de capacités de canal relativement complète. Fonctions clés :

2.1 Fiabilité du canal (un socle utilisable en production)

  • Connexion et reconnexion OneBot v11 WebSocket (backoff exponentiel) ;
  • Détection heartbeat/inactivité, identification des « connexions zombies » ;
  • Échec d’envoi : remise automatique en file, puis ré‑envoi après restauration de la connexion ;
  • Éviter que health-monitor interprète à tort la sortie du canal et provoque une boucle de redémarrage (canal résidant jusqu’à abort).

Cette partie détermine en fait si « le bot est vraiment en ligne », plus important que le modèle lui‑même.

2.2 Sécurité et contrôle des risques (indispensable pour déployer sur QQ)

  • requireMention activé par défaut, pour éviter que chaque phrase en groupe déclenche le bot ;
  • Liste blanche de groupes, liste noire d’utilisateurs ;
  • adminOnlyChat (déclenchement admin uniquement) + anti‑rebond de l’avertissement aux non‑admins ;
  • Envoi en segments + intervalle d’envoi (réduction du risque de contrôle) ;
  • antiRiskMode : contournement de certains contenus (ex. URL).

Le contrôle des risques dans l’écosystème QQ est bien plus agressif que sur Telegram ; sans cette couche, on arrive vite à « ça répond dans les logs, mais rien n’arrive dans le groupe ».

2.3 Ingénierie des sessions (le cœur de l’actif de ce travail)

  • Génération de clé de session sous routage standard (déléguée au routing core d’OpenClaw) ;
  • Slots de sessions temporaires en groupe (/临时, /临时重命名, /临时列表, /临时结束, etc.) ;
  • /newsession : réinitialisation précise du slot de session courant ;
  • Nom d’affichage de session (displayName) unifié au nouveau format :
    • qq:<peer>-<YYYYMMDDHHmm>-<title>

Cela signifie : je peux faire avancer plusieurs sous‑tâches en parallèle dans un même groupe, sans mélanger tout le contexte.

2.4 Multimodal et extraction d’informations

  • Parsing de at, chaîne de réponses, images, audio, fichiers, messages transférés ;
  • Traitement des références d’images URL/base64/file avec injection de prompt ;
  • Complétion du contexte d’attachements depuis le message de réponse ;
  • Côté envoi : support texte, image, audio, fichier avec chemin de fallback ;
  • Support des messages des canaux QQ (Guild).

2.5 Opérabilité

  • Commandes d’administration : /status, /help, /mute, /kick ;
  • Commandes de capacité : /models, /model, /newsession, /grok_draw ;
  • Visualisation de l’état occupé : modification temporaire du suffixe de la carte de visite du groupe (ex. « 输入中 ») pendant le traitement ;
  • Message de secours en cas de réponse vide, pour réduire les faux diagnostics « ça a l’air down ».

En une phrase : le plugin QQ n’est plus une démo, mais une couche de canal qui peut tourner durablement.

3. Ce que le plugin Discourse a bien fait : transformer la « conversation » en « tâche »

La valeur de cette voie Discourse est très claire :

  • Entrant piloté par webhook : asynchrone par nature, traçable par nature ;
  • Le topic comme conteneur de tâches : structurellement un modèle favorable à la gestion multi‑tâches ;
  • Chaque réponse, chaque édition, chaque relance conserve un historique consultable ;
  • Collaboratif et propice à la capitalisation, plutôt qu’un flux de chat qui disparaît.

Dans cette itération, j’ai complété plusieurs points clés :

  • Analyse et cache du titre de topic (si nécessaire, récupération de /t/{topicId}.json pour le renseigner) ;
  • Règle unifiée de nom d’affichage de session :
    • discourse:<site>-<YYYYMMDDHHmm>-<title>
  • Écriture simultanée de ConversationLabel et ThreadLabel pour améliorer la lisibilité du panneau de sessions ;
  • Script de renommage en lot des anciennes sessions, pour harmoniser les données historiques.

Cela ressemble à une « optimisation de nommage », mais en réalité, c’est le passage d’une gestion de sessions « utilisable par la machine » à « lisible et administrable par l’humain ».

4. Pourquoi j’ai sérieusement envisagé la synchronisation QQ↔Discourse, puis décidé de ne pas la faire (pour l’instant)

À un moment, j’ai sérieusement évalué un plan :

  • QQ comme entrée : après correspondance de règles, transfert automatique vers Discourse ;
  • Discourse traite, puis repousse vers QQ ;
  • Les deux côtés voient la conversation, comme un « pont ».

Techniquement, c’est totalement faisable, et même pas très difficile. Mais j’ai finalement décidé de ne pas investir pour l’instant, non pour une raison « technique », mais de « densité de valeur ».

4.1 Faisable ne veut pas dire qu’il faut le faire

Pour que la synchronisation bidirectionnelle soit vraiment stable, il faut au minimum résoudre en plus :

  • Boucles (A pousse vers B, B repousse vers A) ;
  • Déduplication (replays webhook / jitter réseau entraînant des livraisons en double) ;
  • Cohérence d’ordre (timestamps et comportements de retry inter‑systèmes) ;
  • Gouvernance du mapping (comment maintenir sur le long terme le mapping session QQ ↔ topic) ;
  • Perte sémantique multimédia cross‑plateforme (fichiers/audio QQ dégradés en représentation forum).

Chaque point n’est pas quelque chose qu’on élimine totalement en « écrivant quelques lignes de glue code ».

4.2 À ce stade, ce qui manque le plus, c’est l’« efficacité des tâches », pas la « cohérence omnicanale »

Mon vrai point de douleur est l’efficacité d’avancement multi‑tâches, pas l’unification des plateformes de chat.

  • Discourse peut déjà porter le flux principal ;
  • QQ n’a besoin que d’être une entrée légère (pas de VPN, les amis peuvent déposer des demandes) ;
  • Faire une synchronisation complexe « pour que ça ait l’air plus complet » a un ROI court terme très faible.

4.3 Renoncer volontairement n’est pas un échec

Je suis de plus en plus d’accord avec un principe :

La maturité en ingénierie n’est pas « être capable de faire plus », mais « savoir ce qu’on ne fait pas maintenant ».

Donc je garde cette synchronisation comme une « idée intéressante », mais je n’y consacre pas d’énergie à ce stade.

5. Les vrais actifs d’ingénierie capitalisés pendant cette période

Même si, ensuite, la maintenance QQ est réduite, ce travail n’a pas été vain. Il a au moins laissé cinq catégories d’actifs à forte valeur :

5.1 Expérience de stabilité côté canal

  • Gestion du cycle de vie des connexions ;
  • Accusé de réception d’envoi et repli en cas d’échec ;
  • Heartbeat et jugement de vivacité ;
  • Approche d’observabilité pour les systèmes à connexion longue.

5.2 Méthodologie du système de sessions

  • Séparation entre « clé de routage » et « nom d’affichage » ;
  • Impact direct de la lisibilité des noms d’affichage sur l’efficacité d’exploitation ;
  • Une fois les règles de nommage unifiées, le coût de diagnostic diminue nettement.

5.3 Compréhension des différences de plateforme

  • QQ n’est pas adapté pour porter du Markdown complexe et une collaboration à longue chaîne ;
  • Un forum (Discourse) est naturellement adapté à la mise en tâches et à la capitalisation de connaissances ;
  • Un même Agent ne signifie pas que tous les canaux doivent porter la même responsabilité.

5.4 Conscience de gouvernance de configuration

  • Anti‑abus, liste blanche, frontières admin doivent être anticipés ;
  • Granularité fine des toggles (fonctionnalités, permissions, stratégie de notifications en couches) ;
  • Compatibilité des différences sémantiques d’entrée de configuration entre WebUI et CLI.

5.5 Capacité de décision produit

  • Passer de « techniquement faisable » à « valeur d’abord » ;
  • Passer de « empiler des fonctionnalités » à « convergence des responsabilités » ;
  • Avec un temps limité, couper activement les branches à faible ROI.

6. Positionnement final : QQ comme entrée, Discourse comme poste de travail

À ce stade, je positionne ces deux canaux ainsi :

  • QQ :

    • Entrée à faible friction ;
    • Les amis déposent des demandes au fil de l’eau ;
    • Notifications rapides, interactions simples ;
    • Entrée de matériaux instantanés comme fichiers/audio.

  • Discourse :

    • Portage multi‑tâches ;
    • Interaction et suivi du flux principal ;
    • Capitalisation des résultats, organisation des connaissances ;
    • Terrain principal pour rétrospectives et collaboration.

Ce n’est pas « lequel est plus avancé », mais remettre chaque plateforme à la place où elle excelle.

7. Trois rappels pour mon futur moi

  1. Ne pas confondre « capacité de canal » avec « valeur produit » elle‑même.
  2. Quand tu commences à empiler de la complexité pour des scénarios périphériques, demande d’abord : est‑ce que je suis en train d’éviter le vrai problème principal ?
  3. Tout plugin peut cesser d’être maintenu, mais la méthodologie et le sens des limites restent — c’est la partie la plus précieuse.

8. Conclusion

Pendant cette période, j’ai fait beaucoup de choses qui ressemblent à du « développement d’outils », mais au final le gain n’est pas un robot plus tape‑à‑l’œil, c’est un jugement plus clair :

  • sur quoi continuer à investir ;
  • sur quoi mettre temporairement en pause ;
  • et quelle est la vraie voie principale du système.

Si je devais résumer ce retour d’expérience en une phrase :

Plutôt que de rechercher « une complétude sur toutes les plateformes », mieux vaut d’abord approfondir et stabiliser « le flux de tâches vraiment important ».

Et pour moi, cette voie principale est actuellement : Discourse en priorité, QQ comme point d’entrée.