doocs/md : un éditeur Markdown qui produit du HTML compatible WeChat
✍ WeChat Markdown Editor | 一款高度简洁的微信 Markdown 编辑器：支持 Markdown 语法、自定义主题样式、内容管理、多图床、AI 助手等特性
En bref
- De quoi s’agit-il ?
- Le projet doocs/md convertit du Markdown en article WeChat au moment de la frappe, avec un choix de thèmes et de multiples backends d'images. Utile si vous publiez sur 公众号, inutile si vous cherchez un éditeur Markdown généraliste.
- À qui s’adresse-t-il ?
- Adoptez doocs/md si votre chaîne de publication passe par un compte 公众号 et que vous voulez écrire en Markdown sans retoucher le HTML à la main. Évitez-le si vous cherchez un éditeur Markdown polyvalent pour un blog, un wiki ou de la documentation technique : le rendu est calibré pour WeChat et le projet n'a pas d'autre cible.
- Puis-je l’utiliser commercialement ?
- Oui. WTFPL est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : rédiger en Markdown et publier dans 公众号
WeChat impose son propre sous-ensemble HTML pour les articles de 公众号. Coller du Markdown brut ne produit rien d'exploitable : il faut du HTML en ligne, avec des styles compatibles avec l'éditeur de WeChat. La plupart des éditeurs Markdown génèrent du HTML standard, que WeChat refuse ou dégrade. doocs/md prend le problème par l'autre bout : il rend le Markdown en HTML déjà stylé pour WeChat, en direct pendant la frappe. Le README résume l'objectif en une phrase : « Markdown 文档自动即时渲染为微信图文 ». Le public visé est donc étroit et clair : les auteurs qui publient sur un compte 公众号 et qui veulent écrire en Markdown plutôt que de mettre en forme à la souris. Les autres lecteurs n'y trouveront pas leur compte, et le projet ne prétend pas les servir.
Ce que le rendu accepte au-delà du Markdown de base
Le README énumère les extensions prises en charge : formules mathématiques via KaTeX, diagrammes Mermaid, PlantUML, blocs d'avertissement GFM, et une extension de notation Ruby avec deux syntaxes possibles, `[文字]{注音}` ou `[文字]^(注音)`. Les blocs de code disposent de plusieurs thèmes de coloration syntaxique. Ce périmètre est plus large que ce que laisse supposer l'étiquette « éditeur WeChat » : KaTeX et Mermaid ne sont pas des besoins typiques d'un article 公众号, mais ils évitent de sortir de l'éditeur quand un billet technique contient une formule ou un schéma. La coloration syntaxique des blocs de code est paramétrable, et le README mentionne la personnalisation de la couleur de thème et du CSS. C'est cohérent avec l'objectif affiché : rester dans l'éditeur du premier caractère jusqu'au copier-coller dans WeChat.
L'architecture visible : Vue 3, Vite, Tailwind, et un CLI npm
Le dépôt est en TypeScript, avec Vue 3, Vite et Tailwind CSS d'après les topics du dépôt. Le README pointe une application web hébergée sur md.doocs.org, un paquet npm `@doocs/md-cli` et une image Docker `doocs/md`. Ces trois canaux correspondent à trois usages : l'éditeur en ligne pour essayer sans rien installer, le CLI pour intégrer la conversion dans une chaîne de build, l'image Docker pour un déploiement auto-hébergé. Le README recommande Chrome pour l'expérience en ligne. Le prérequis Node est explicite : `node >= 22`. Ce détail a son importance, car Node 22 n'est pas la version installée par défaut sur toutes les distributions au moment où ces lignes sont écrites. Le dépôt ne décrit pas en détail le pipeline de rendu interne, seulement le résultat. On sait que le rendu est immédiat, on ne sait pas par quel chemin il passe.
Les treize backends d'images et ce qu'ils impliquent
Le README documente treize options de图床, dont un mode par défaut sans configuration. GitHub, 阿里云 OSS, 腾讯云 COS, 七牛云 Kodo, MinIO, S3, 公众号, Cloudflare R2, 又拍云, Telegram, Cloudinary, et un mode d'upload personnalisé. Chaque backend a ses propres clés, listées dans le tableau du README : `Repo` et `Token` pour GitHub, `AccessKey ID` et `AccessKey Secret` pour 阿里云, `SecretId` et `SecretKey` pour 腾讯云, `Endpoint` et `Port` pour MinIO, `appID` et `appsecret` pour 公众号, `AccountId` pour R2, `Bot Token` et `Chat ID` pour Telegram. Le mode par défaut ne demande aucune configuration, ce qui est le point d'entrée le plus simple. Le mode personnalisé, lui, est documenté dans `docs/custom-upload.md` et suppose d'écrire son propre uploader. Point pratique : ces identifiants sont saisis dans l'éditeur, donc la question de leur stockage se pose dès qu'on quitte l'usage personnel sur sa propre machine. Le README ne tranche pas ce point.
Démarrer : commandes et prérequis
Trois chemins sont documentés. Le plus rapide ne demande rien : ouvrir md.doocs.org dans Chrome. Pour un usage local ou auto-hébergé, le README renvoie au paquet `@doocs/md-cli` sur npm et à l'image `doocs/md` sur Docker Hub. Le prérequis annoncé est `node >= 22`. Le README ne fournit pas de commande d'installation détaillée dans l'extrait disponible, donc je m'en tiens à ce qui est écrit : le paquet npm et l'image Docker existent, leurs noms sont ceux-ci, et le seuil Node est celui-là. Pour les préférences, le README mentionne une synchronisation après connexion au compte, décrite dans `docs/cloud-sync.md`. La gestion des brouillons est locale, avec sauvegarde automatique. Si vous voulez essayer sans engager votre poste, l'éditeur en ligne suffit, mais il ne dit rien de la façon dont vos identifiants图床 y sont traités.
Les limites que le README ne masque pas
Première limite, la cible. Un éditeur calibré pour WeChat produit du HTML calibré pour WeChat. Si vous publiez ailleurs, le rendu ne sera pas neutre, et rien dans le README n'indique qu'un mode « HTML générique » existe. Deuxième limite, la licence WTFPL. Elle est permissive à l'extrême, ce qui facilite la réutilisation, mais elle ne contient aucune clause de brevet ni de garantie. Pour un usage interne, cela n'a probablement pas d'incidence. Pour redistribuer le projet dans un produit commercial, faites lire le texte de la licence par quelqu'un dont c'est le métier : je ne donne pas d'avis juridique ici. Troisième limite, la maintenance. Le dépôt n'est pas archivé et la dernière version listée est v2.1.0 (octobre 2025). Le rythme des versions est irrégulier : v2.0.3 en mai 2025, v2.0.4 en juin, v2.1.0 en octobre. Rien d'alarmant, mais rien qui garantisse non plus une cadence fixe. Quatrième limite, l'absence de spécification du pipeline de rendu : si vous devez garantir un HTML identique entre deux versions, vous n'avez pas de contrat documenté pour le faire.
Face à un convertisseur Markdown générique
L'alternative évidente est un convertisseur Markdown vers HTML standard, du type de ceux qui alimentent les générateurs de sites statiques. La différence d'approche est nette : un convertisseur générique produit du HTML sémantique et laisse le style à une feuille CSS externe, ce que WeChat refuse. doocs/md produit du HTML avec les styles déjà en ligne, au prix d'un rendu spécifique à une plateforme. Autrement dit, vous échangez la portabilité contre la compatibilité WeChat. Si votre besoin est de publier sur un blog, un wiki ou de la documentation technique, un convertisseur générique sera plus simple et vous évitera de dépendre d'un projet dont la raison d'être est une seule plateforme. Si votre besoin est WeChat, l'inverse est vrai : réimplémenter le rendu compatible à la main coûte plus cher que d'adopter doocs/md.
Conclusion éditoriale
Adoptez doocs/md si votre chaîne de publication passe par un compte 公众号 et que vous voulez écrire en Markdown sans retoucher le HTML à la main. Évitez-le si vous cherchez un éditeur Markdown polyvalent pour un blog, un wiki ou de la documentation technique : le rendu est calibré pour WeChat et le projet n'a pas d'autre cible. Avant de vous engager, vérifiez trois choses : que le node >= 22 est disponible sur votre poste ou dans votre image Docker, que votre图床 cible figure bien dans la liste des treize backends documentés, et que vous acceptez les implications de la licence WTFPL sur votre usage.
Notes de la communauté