Le lecteur Markdown/HTML pour mobile que j’ai teasé plus tôt est terminé, et il s’appelle Jilan.
Il résout un problème petit mais de plus en plus agaçant :
Quand quelqu’un vous envoie un rapport IA, un PPT web ou un document Markdown via WeChat, l’app Fichiers ou un groupe de discussion, l’ouvrir sur votre téléphone donne généralement un écran blanc, du code source brut, des styles cassés ou une totale confusion quant à l’application à utiliser.
Les fichiers comme .md, .markdown, .html, .htm, .txt et même les ZIP web empaquetés peuvent désormais être ouverts directement sur iPhone et iPad avec Jilan.
Rendu local, stockage local — pas d’envoi, pas besoin de créer un compte.
Il y a un lien TestFlight à la fin ; vous pouvez postuler directement si vous voulez l’essayer. J’ai ouvert 8 000 places.

Mais je n’ai pas fait Jilan juste parce qu’il nous manquait un lecteur.
La raison plus directe, c’est que je ressens de plus en plus nettement ces derniers temps qu’avec la participation de l’IA à la production de contenu, les formats que nous utilisons pour échanger du contenu changent.
Beaucoup de contenu textuel commence à atterrir en Markdown, et beaucoup de contenu de présentation en HTML.
Jilan n’est qu’un petit outil tombé de ce changement quand il a atteint le côté mobile.
Markdown n’est pas qu’un format texte ; il devient la couche de données de l’IA
Il y a quelques jours, j’ai vu une citation de l’auteur d’Obsidian que je trouve très juste : .md devient un point de Schelling dans l’interaction entre fichiers et IA.
Un point de Schelling, c’est un choix vers lequel les gens convergent naturellement sans aucune régulation imposée.
Markdown ressemble un peu à ça maintenant.
Personne n’a imposé que l’IA utilise Markdown, et aucun comité de normalisation n’est venu annoncer quoi que ce soit.
Mais dans l’usage réel, que ce soit des humains qui écrivent à l’IA ou l’IA qui écrit pour les humains, cela finit souvent en fichier .md.

La raison est simple.
C’est du texte brut, donc léger pour que les modèles lisent et écrivent.
Il a suffisamment de structure pour exprimer titres, listes, tableaux, blocs de code et liens.
Et il n’est pas enfermé dans un format complexe comme .docx.
Les humains peuvent l’ouvrir directement, l’IA peut le traiter directement, et la gestion de versions et les diffs sont propres.
Mais je pense que plus important, Markdown ne peut plus être compris seulement comme « du texte dans un éditeur ».
C’est plutôt comme les données sous-jacentes d’un workflow IA.

C’est comme ça que je l’utilise dans CodePilot.
Il n’a pas de mécanisme de mémoire particulièrement complexe ; beaucoup de mémoires ne sont en fait qu’un ensemble de fichiers Markdown.
L’IA y écrit, l’IA y lit, et je peux les ouvrir et les modifier moi-même.

En outre, les widgets dans CodePilot peuvent utiliser ces fichiers Markdown locaux et ces mémoires comme sources de données.
Quand le fichier change, l’affichage du composant change avec lui.
À ce stade, Markdown n’est plus seulement « un article à lire ».
Il devient une couche de données locale très légère : les humains peuvent le voir, l’IA peut le lire, et les outils peuvent générer de nouvelles interfaces et interactions basées sur lui.

C’est aussi pourquoi je trouve que la direction que beaucoup prennent en continuant à peaufiner des éditeurs Markdown est peut-être un peu étroite.
Ce qui est vraiment intéressant, ce n’est pas de faire une boîte d’édition plus jolie, mais de traiter Markdown comme des données pour construire de nouvelles façons de lire, gérer et interagir homme-machine.
HTML devient la couche d’affichage du contenu IA
À l’autre bout, il y a HTML. Cette tendance est aussi devenue de plus en plus évidente ces derniers temps.
Le mois dernier, j’ai open-sourcé une compétence PPT qui génère des présentations au format web.
Elle a atteint 10 000 étoiles en 25 jours, et plus tard, lors de défenses en présentiel, d’expositions et de sessions de partage, j’ai vu à plusieurs reprises des gens utiliser des PPT réalisés avec elle.
Cela m’a confirmé une chose :
Dans de nombreux scénarios, ce que les gens veulent, ce n’est pas un fichier .pptx standard, mais une présentation qui peut être présentée, comprise et partagée rapidement.

Par coïncidence, l’équipe Claude Code parle de la même chose récemment.
Ils ont un article spécifiquement sur pourquoi de plus en plus de sorties commencent à utiliser HTML au lieu de Markdown.
La raison est directe : HTML a une densité d’information plus élevée, est plus facile pour la hiérarchie visuelle, est meilleur pour afficher des graphiques, des mises en page et des interactions, et est plus facile à ouvrir et lire par d’autres.
Cela correspond très à mon expérience personnelle.
Markdown est bon pour consolider le contenu, mais il devient difficile à lire quand il est long. Un rapport de milliers ou dizaines de milliers de mots entassé dans un fichier .md est difficile à digérer pour un humain, même si la structure est correcte.
HTML, c’est le contraire. Il peut utiliser la mise en page, l’espace, la couleur, les graphiques et l’interaction pour organiser l’information en quelque chose qui ressemble plus à « quelque chose à consommer ». Ce n’est pas mieux pour stocker des faits, mais c’est mieux pour aider les gens à comprendre les faits.

Donc je suis de plus en plus enclin à voir ces deux choses séparément :
Markdown est la couche de données, HTML est la couche d’affichage.
Gardez le contenu sous-jacent en Markdown — propre, lisible, versionnable.
Quand il doit être montré aux gens, présenté ou partagé à l’extérieur, rendez-le en HTML.
Ce n’est pas un nouveau standard grandiose ; c’est plutôt une division du travail qui a naturellement émergé des workflows IA.
Mais cette chaîne est cassée sur mobile
Le contenu est là, les fichiers sont envoyés, mais le problème survient à la dernière étape : les gens les ouvrent souvent sur leur téléphone.
Sur ordinateur, ça va. Vous avez des navigateurs, des éditeurs, et en dernier recours, VS Code.

Mais sur mobile, c’est différent.
Surtout quand vous recevez un rapport généré par IA, un PPT web ou un document Markdown dans WeChat, l’expérience courante est qu’il ne s’ouvre pas, affiche du code source, a des styles cassés, ou nécessite de sauter entre plusieurs apps. C’est une petite chose, mais très agaçante.
Une messagerie comme WeChat n’est essentiellement pas un lecteur de fichiers.
Sa priorité est la discussion, l’aperçu et le transfert, pas d’ouvrir sérieusement un fichier Markdown ou HTML.
Les navigateurs ne sont pas conçus pour ce scénario non plus.
Par défaut, les navigateurs gèrent « tu me donnes un lien, j’ouvre la page web pour toi ».
Mais ce que les autres vous envoient est souvent un fichier local, pas un lien. Vous pouvez certainement faire des contorsions pour jeter le HTML dans un navigateur, mais toute la chaîne est longue et maladroite.
De nombreux outils Markdown sont aussi orientés vers l’édition et la prise de notes, et ne sont pas nécessairement adaptés pour ouvrir temporairement un fichier envoyé par quelqu’un d’autre.
Sans parler que certains outils nécessitent d’importer, de synchroniser, de construire une bibliothèque ou de créer un compte.
HTML a une couche supplémentaire de problèmes de sécurité : un fichier étrange peut contenir des scripts, et vous ne voulez pas nécessairement qu’ils s’exécutent par défaut.

Donc j’ai toujours senti qu’il manquait une chose très simple :
Un moyen d’ouvrir ces fichiers courants des workflows IA sur un téléphone, de manière sûre et pratique.
C’est Jilan.
Jilan est très concentré : Ouvrir, Lire, Conserver
Je n’ai pas fait de Jilan un éditeur, ni ne l’ai connecté à l’IA. Au fait, je dois féliciter CodeX pour l’icône de l’app, elle est trop mignonne.

J’étais très clair dès le départ : il ne fait que trois choses : Ouvrir, Lire, Conserver.
Quand vous recevez un fichier, sélectionnez Jilan depuis WeChat, l’app Fichiers ou la feuille de partage système pour l’ouvrir. Il supporte .md, .markdown, .html, .htm, .txt et les fichiers .zip empaquetés à partir de ressources web.

Tous les fichiers sont traités localement — pas d’envoi, pas de création de compte.
En lecture Markdown, je me suis surtout concentré sur la lecture de longs textes.
La taille de la police, l’interligne et le fond peuvent être modifiés ; les longs tableaux peuvent défiler horizontalement ; les documents avec une structure de titres peuvent utiliser une table des matières pour naviguer.
La syntaxe Obsidian courante, comme les listes de tâches, les Callouts, les notes de bas de page, les Frontmatter et les tags, est également compatible autant que possible.

Il supporte aussi le passage en mode sombre et les thèmes de couleur.

En lecture HTML, je me soucie plus du « contrôle ».
Il utilise le WebView système pour le rendu local, supporte le zoom, le passage entre portrait et paysage, et le basculement entre modes mobile et bureau.
Les scripts dynamiques sont désactivés par défaut. Vous ne savez généralement pas s’il y a des scripts dans un fichier HTML inconnu.
Donc Jilan ne suppose pas l’exécution de scripts par défaut ; si vous rencontrez une page qui a vraiment besoin de JS pour être visualisée, vous pouvez l’activer manuellement.

Le support ZIP est aussi fait pour des scénarios réels.
De nombreuses pages web exportées par l’IA ne sont pas un seul fichier HTML, mais un index.html plus un dossier assets.
Jilan trouvera automatiquement le point d’entrée après décompression, et les images et CSS locaux pourront se charger normalement, donc les styles ne sont pas perdus et les images ne sont pas cassées.
Les fichiers que vous avez ouverts resteront automatiquement dans votre historique local. Si vous voulez les revoir la prochaine fois, vous pouvez les retrouver dans l’application.
Importer plusieurs fois le même fichier ne crée pas de doublons, et les fichiers importants peuvent être mis en favoris.

C’est sa limite actuelle.
Il ne fait pas de synchronisation cloud, de comptes, d’édition ou d’intégration IA.
Non pas que ces fonctionnalités ne soient pas importantes, mais parce qu’un visualiseur doit d’abord faire le travail d’« ouvrir et finir de lire » proprement.
Jilan suit les deux premières choses
En y repensant, Jilan n’est pas un petit outil isolé.
Le mois dernier, j’ai fait PPT Skill parce que je crois que HTML deviendra une forme très naturelle pour que l’IA génère du contenu de présentation.
Il ne remplacera pas forcément PowerPoint, mais pour « générer rapidement quelque chose de présentable », HTML est assez léger, assez ouvert et assez adapté pour que les modèles le génèrent directement.

J’ai fait CodePilot parce que je crois que Markdown deviendra un support de données et de mémoire très naturel dans la collaboration IA.
Ce n’est pas le format le plus joli, mais c’est le plus facile à utiliser simultanément pour les humains, les modèles et les outils.

Jilan gère la troisième étape :
Ces formats ne peuvent pas s’arrêter à « être générés » ; les gens doivent pouvoir réellement les ouvrir, les lire et les conserver.

Les deux premières concernent la production ; Jilan concerne la consommation.
L’IA peut déjà générer du Markdown et du HTML.
Mais si ces fichiers cassent dès qu’ils arrivent sur un téléphone, alors, aussi fluide que soit l’expérience de génération, elle n’a pas vraiment atteint les mains de la personne.
Jilan comble ce dernier kilomètre.
Mais c’est loin d’être fini
Jilan ne comble actuellement que la couche la plus superficielle : recevoir un fichier et l’ouvrir.
À l’avenir, il reste encore plusieurs problèmes à résoudre.

Par exemple, la gestion.
Beaucoup de gens ont déjà un grand nombre de fichiers Markdown et HTML dispersés sur leur téléphone, leurs clouds, leurs historiques de chat et divers caches d’apps.
Ils n’ont pas de valeur nulle, ils sont juste trop dispersés pour être trouvés ou gérés.
Par exemple, le partage.
Jilan résout « comment je consulte ce que les autres m’envoient ».
Mais inversement, « j’ai fait un fichier HTML, comment je laisse les autres l’ouvrir facilement » reste une galère.
Si vous envoyez le fichier, l’autre personne peut ne pas pouvoir l’ouvrir ; si vous envoyez un lien, vous devez trouver un endroit pour le déployer vous-même.
Par exemple, le multi-appareil.
Lire à moitié sur le téléphone et continuer sur l’ordinateur, ou générer un rapport sur l’ordinateur et le pousser sur le téléphone pour le lire, sont tous très naturels.
Mais dès que vous faites de la sync, vous tombez sur des comptes, le cloud, la vie privée et la complexité.
Jilan est encore très petit — si petit que je n’ai pas vraiment envie de l’emballer comme un gros produit.
Mais il s’insère parfaitement dans le vide que je rencontre tous les jours :
L’IA a généré le contenu, mais je veux juste pouvoir bien le regarder sur mon téléphone.
Si vous êtes aussi souvent embêté par les fichiers Markdown, HTML et les PPT web, essayez-le.
TestFlight :
J’aimerais aussi beaucoup connaître votre avis là-dessus : après l’implication de l’IA, que deviendront vraiment les documents, les présentations et la lecture ?





