OpenClawChineseTranslation : la distribution chinoise d'OpenClaw, et ce qu'elle implique pour un déploiement en production

Le problème réel : une barrière linguistique sur un assistant auto-hébergé

OpenClaw est décrit dans ce dépôt comme une plateforme d'assistant IA personnel open source qui s'exécute sur votre propre machine et se pilote depuis WhatsApp, Telegram ou Discord. Le projet amont vise des tâches du quotidien : courrier, agenda, fichiers. Sa surface d'administration reste en anglais, avec une CLI et un Dashboard web. C'est là que ce fork intervient. Il ne modifie pas le moteur de l'assistant, il remplace les chaînes de caractères visibles par leur équivalent chinois, dans les deux interfaces. Le public visé est donc précis : des utilisateurs sinophones qui veulent administrer l'outil sans naviguer dans une terminologie anglaise, et qui préfèrent une distribution prête à l'emploi à une traduction locale qu'ils devraient maintenir eux-mêmes à chaque mise à jour. Le README annonce une synchronisation horaire avec le dépôt amont, avec une latence revendiquée inférieure à une heure. Cette promesse est le cœur de la proposition de valeur : sans elle, un fork de traduction devient obsolète en quelques semaines.

Ce que le dépôt contient vraiment, au-delà du README

La page d'accueil du dépôt ressemble davantage à un portail produit qu'à une documentation technique. Elle enchaîne une présentation de l'écosystème, deux blocs de parrainage pour des fournisseurs d'API (词元 API et 胜算云), puis les instructions d'installation. Le langage principal déclaré est JavaScript, ce qui est cohérent avec un projet Node.js, et la branche par défaut est main. Deux flux de publication coexistent : des versions stables du type v2026.9.3-zh.1 et des builds nightly générés par un workflow GitHub Actions. Cette séparation est un bon signal de discipline de publication, mais elle ne dit rien sur la méthode de traduction elle-même. Le README renvoie à un fichier docs/TRANSLATION_GUIDE.md qui contiendrait un glossaire, des principes et un guide de style. Sans lire ce fichier, on ne peut pas savoir si la traduction est appliquée par extraction de chaînes, par remplacement de fichiers de locale, ou par réécriture directe du code source. Cette distinction compte : la troisième option rendrait le rebasage sur l'amont nettement plus fragile.

Installation : ce que le README prescrit réellement

Le paquet publié sur npm s'appelle @qingchencloud/openclaw-zh. Le README organise la mise en route en quatre étapes et impose une précondition explicite : Node.js doit être présent sur la machine. Trois canaux d'installation sont documentés dans le corps du README : le paquet npm, des binaires de release pour Windows, macOS et Linux, et un déploiement Docker décrit dans docs/DOCKER_GUIDE.md, avec une section dédiée à la configuration Nginx en reverse proxy et à l'authentification par token pour l'accès distant. Pour le volet modèle, le README donne un exemple concret avec un fournisseur compatible OpenAI : on sélectionne l'option OpenAI Compatible lors de l'initialisation, on renseigne une Base URL de la forme https://ciyapi.79tian.com/v1, puis la clé obtenue sur le site du fournisseur. Le dépôt documente aussi une procédure de redémarrage du gateway, une procédure de désinstallation et une procédure de mise à jour. Ce niveau de détail opérationnel est inhabituel pour un simple fork de traduction, et c'est probablement ce qui explique son audience. À noter que les blocs de commandes exacts ne figurent pas dans l'extrait fourni : je ne peux pas les citer ici sans les inventer.

La synchronisation horaire est une promesse, pas un mécanisme documenté

C'est le point que je vérifierais en premier. Le README affirme une synchronisation automatique toutes les heures avec OpenClaw amont, et un badge renvoie vers un workflow nightly.yml. Un fichier de workflow existe donc, et il produit des releases datées. Mais rien dans le matériel fourni ne décrit comment les traductions survivent à un rebasage : y a-t-il une étape de détection de conflits, un test qui échoue quand une clé de traduction disparaît, une revue humaine avant publication ? Sans réponse, l'utilisateur fait confiance à un pipeline qu'il ne voit pas. Le risque concret n'est pas une interface partiellement anglaise, c'est une chaîne traduite qui se retrouve appliquée au mauvais endroit après un changement de structure côté amont. Pour un outil qui manipule courrier et fichiers, une mauvaise traduction d'un libellé d'action n'est pas cosmétique.

La licence : NOASSERTION n'est pas une réponse

GitHub affiche NOASSERTION pour ce dépôt, ce qui signifie que la plateforme n'a pas su classer le fichier LICENSE. Le README, lui, porte un badge annonçant MIT. Ces deux signaux ne concordent pas, et cette divergence est le point bloquant le plus sérieux du projet. Un fichier LICENSE qui contient du texte MIT modifié, ou qui ajoute des conditions sur les traductions, produit un NOASSERTION. La conséquence pratique : si votre organisation exige une validation de licence avant adoption, le badge vert du README ne suffira pas, il faudra ouvrir le fichier. Je ne peux pas trancher à votre place, et je ne donne pas de conseil juridique. Je constate seulement que la redistribution d'un projet amont sous sa propre licence ajoute une couche de conditions qu'un simple coup d'œil au badge ne révèle pas.

Ce qui entoure le fork : ClawPanel et ClawApp

Le dépôt promeut deux outils satellites du même éditeur, qingchencloud. ClawPanel est un panneau d'administration graphique avec un assistant IA intégré, présenté comme capable de détecter l'environnement et d'installer OpenClaw sans passer par le terminal. ClawApp est un client de chat mobile basé sur le navigateur, avec WebSocket, envoi d'images et affichage des appels d'outils, distribuable en PWA ou en APK. Ces deux projets ne sont pas dans ce dépôt et n'ont pas été examinés ici. Leur présence dans le README indique surtout une intention : transformer une distribution linguistique en suite d'outils. Pour un évaluateur, cela crée une dépendance supplémentaire à évaluer séparément, car ces interfaces deviennent un chemin d'accès privilégié vers l'instance OpenClaw. Le README mentionne d'ailleurs une authentification par token et une terminaison Nginx pour l'accès distant, ce qui suggère que l'exposition réseau est un scénario prévu, pas un cas marginal.

L'alternative : rester sur OpenClaw amont et traduire soi-même

L'alternative directe est d'utiliser le dépôt openclaw/openclaw et de gérer la barrière linguistique autrement. La différence n'est pas dans les fonctionnalités, elle est dans la chaîne de responsabilité. Avec l'amont, vous recevez les correctifs de sécurité et les changements d'API au moment où ils sont publiés, et vous n'avez qu'un seul projet à suivre. Vous perdez l'interface chinoise, sauf à maintenir vos propres fichiers de locale, ce qui suppose de comprendre comment OpenClaw structure ses chaînes. Avec ce fork, vous obtenez la traduction immédiatement, mais vous ajoutez un intermédiaire entre vous et les correctifs amont, avec une fenêtre annoncée d'une heure dont la fiabilité n'est pas démontrable depuis le README. Le choix dépend donc de votre tolérance à ce décalage : pour un usage personnel, il est probablement acceptable ; pour une instance qui traite des données sensibles, il mérite d'être mesuré.

Coût de maintenance et angle mort du suivi de version

La numérotation des releases reprend celle de l'amont avec un suffixe zh.1 : v2026.9.3-zh.1 suit v2026.9.3. Ce schéma rend la correspondance lisible, ce qui est une bonne décision. Il implique aussi que chaque version amont génère au moins une version traduite, donc un rythme de publication dicté par un tiers. Si le mainteneur ralentit, vous vous retrouvez sur une version figée sans que rien ne vous en avertisse, puisque le dépôt n'est pas archivé et continue d'afficher ses badges. Le coût de mise à jour, côté utilisateur, est celui d'un paquet npm classique : remplacer @qingchencloud/openclaw-zh par la version suivante et redémarrer le gateway, dont la procédure est documentée dans le README. Ce qui n'est pas documenté, c'est la compatibilité entre une version traduite et les fichiers de configuration produits par une version antérieure. Sur un outil qui stocke l'état de vos agents et de vos intégrations, c'est la question à poser avant de mettre à jour, pas après.

Conclusion éditoriale

À adopter si vous avez besoin d'une interface OpenClaw en chinois et que vous acceptez de dépendre d'un fork de localisation : installez via le paquet @qingchencloud/openclaw-zh et vérifiez d'abord le contenu exact du fichier LICENSE, que GitHub ne parvient pas à classer. À éviter si votre organisation impose une revue de licence formelle ou si vous devez auditer chaque ligne de code exécutée, car la chaîne de synchronisation horaire avec l'amont n'est pas documentée dans le README.

Sources officielles

1. 1186258278/OpenClawChineseTranslation on GitHub
2. Issues
3. Project website
4. README
5. Releases