ReadAny : un lecteur de livres numériques qui indexe votre bibliothèque en local

Le problème visé : retrouver une idée, pas un mot exact

La recherche par mot-clé suppose que vous vous souvenez du terme employé par l'auteur. ReadAny part du constat inverse : on retient une idée, pas sa formulation. Le README formule la promesse ainsi : trouver des idées par le sens, et poser des questions sur un livre avec des réponses ancrées dans le contexte de lecture. La cible est donc un lecteur qui annote déjà, mais dont les notes restent dispersées, et qui veut interroger sa propre bibliothèque plutôt que le catalogue d'un éditeur. Ce n'est pas un outil de lecture rapide ni un gestionnaire de bibliothèque au sens de Calibre : la comparaison du README positionne ReadAny sur le chat IA, la recherche sémantique et le stockage vectoriel local, là où Calibre et KOReader ne proposent aucune de ces trois fonctions. Le public réel est étroit : quelqu'un prêt à brancher une clé d'API ou à faire tourner Ollama, et à qui l'idée d'un index vectoriel sur son disque ne fait pas peur.

Deux runtimes, un même socle TypeScript

Le dépôt s'organise en packages, avec une application dans packages/app et un logo servi depuis packages/app/public/logo.svg. Les sujets déclarés associent Tauri et React Native via Expo : Tauri pour les trois plateformes de bureau, Expo pour iOS et Android. Le README annonce une version 2.0 qui ouvre les applications mobiles, et la page de téléchargement liste un .dmg, un .msi, un .AppImage, un TestFlight pour iOS et un .apk pour Android. Autrement dit, il n'y a pas un seul binaire multiplateforme mais deux chaînes de build à maintenir, ce qui pèse sur la suite. Côté données, trois briques apparaissent dans les sujets du dépôt : SQLite pour le stockage, un vector store local pour les embeddings, et WebDAV pour la synchronisation entre appareils. Le README mentionne une résolution de conflits par fusion intelligente lors d'éditions concurrentes, sans détailler l'algorithme. C'est exactement le genre de composant où l'écart entre la promesse et le comportement réel se paie en annotations perdues, et la documentation disponible ne permet pas de trancher.

La recherche hybride, et ce qu'elle implique

ReadAny combine deux mécanismes de récupération : une recherche vectorielle et BM25. Le premier retrouve des passages proches par le sens, le second reste sur la correspondance lexicale. La fusion des deux listes est présentée comme un avantage, et c'est cohérent : BM25 rattrape les requêtes où l'utilisateur cite un terme rare, tandis que les vecteurs rattrapent les reformulations. Le corollaire, que le README n'aborde pas, est qu'il faut produire des embeddings pour tout ce que vous importez. Selon le fournisseur retenu, cette étape peut être locale (le README cite Ollama) ou distante (OpenAI, Claude, Gemini, DeepSeek). Le choix n'est pas cosmétique : il détermine si vos livres quittent votre machine au moment de l'indexation, alors même que l'argument central du projet est le stockage vectoriel local. Un lecteur qui configure un fournisseur distant pour les embeddings perd une partie de la promesse de confidentialité, sans que l'interface le lui signale forcément. C'est la tension la plus intéressante du projet, et la documentation disponible ne l'arbitre pas.

Installation : Homebrew, binaires, ou rien

La voie la plus courte sur macOS passe par un tap :

brew tap codedogQBY/readany brew install --cask readany

Sur Windows et Linux, le README renvoie vers les artefacts de la dernière release (.msi, .AppImage). Sur iOS, l'accès se fait par TestFlight, donc avec une durée de validité limitée et un effectif de testeurs plafonné. Le parcours de démarrage tient en trois étapes selon le README : importer des livres par glisser-déposer, ouvrir un livre par double-clic, puis configurer l'IA dans les réglages, cette dernière étape étant explicitement optionnelle. La lecture fonctionne donc sans aucune clé d'API. Ce qui ne fonctionne pas sans configuration, ce sont la recherche sémantique et le chat. La synchronisation WebDAV est également à renseigner manuellement, puisque le projet ne fournit pas de service hébergé. Le README s'arrête au début de la section Settings, sans détailler les clés de configuration attendues : impossible de confirmer depuis cette source les noms exacts des champs à remplir.

Formats : dix annoncés, une conversion qui change tout

La liste des formats pris en charge couvre EPUB, PDF, MOBI, AZW, AZW3, FB2, FBZ, CBZ, TXT et UMD. Une phrase du README mérite d'être lue deux fois : TXT et UMD sont importés en les convertissant en EPUB, pour la lecture, les notes, la recherche et la synchronisation. La conversion n'est donc pas un détail d'affichage, elle conditionne tout ce qui suit. Si la conversion se passe mal, ce ne sont pas seulement les pages qui s'affichent de travers, c'est l'indexation, donc la recherche et le chat, qui héritent du problème. Le README ne précise pas si les autres formats subissent le même traitement. Le tableau comparatif annonce plus de dix formats contre quinze et plus pour Calibre, ce qui situe ReadAny légèrement en retrait sur ce seul critère. Pour une bibliothèque déjà constituée en AZW3 ou en MOBI, la question de la fidélité de conversion est la première à vérifier avant tout le reste.

TTS, statistiques, Skills : trois ajouts de poids inégal

Le TTS s'appuie sur plusieurs moteurs selon le README : Edge TTS, le TTS du navigateur et DashScope. Il annonce plus de cent voix, un contrôle de vitesse et une lecture en arrière-plan. Edge TTS et DashScope supposent un service en ligne, donc une dépendance réseau que le stockage vectoriel local ne compense pas. Les statistiques proposent une carte de chaleur des habitudes de lecture, des graphiques de temps par jour, semaine et mois, et un suivi des séries de jours consécutifs. C'est une fonction de confort, sans incidence sur la recherche. Les Skills, présentés comme un système avec des compétences intégrées (résumé, explication de concepts, suivi de personnages) et la possibilité d'en créer, sont la partie la moins documentée du README : la nature exacte d'un skill, son format de définition et son mode d'exécution n'y sont pas décrits. Le tableau comparatif les liste comme exclusifs à ReadAny, ce qui est exact au vu des alternatives citées, mais ne dit rien de leur utilité réelle. À traiter comme une fonction à évaluer soi-même, pas comme un argument acquis.

Ce que la licence ne dit pas

Le dépôt est référencé avec le statut NOASSERTION, ce qui signifie que l'outil d'analyse n'a pas su classer le fichier LICENSE, et non qu'il n'existe pas. Le README pointe vers un fichier LICENSE à la racine et affiche un badge de licence, mais le contenu n'est pas fourni ici. Impossible donc de dire s'il s'agit d'une licence permissive, d'une licence copyleft ou d'un texte personnalisé, ni ce que cela implique pour un usage en entreprise ou pour la redistribution d'un binaire modifié. C'est le premier point à lever avant toute adoption en contexte professionnel : ouvrez le fichier LICENSE et lisez-le, plutôt que de vous fier au badge. Sur la maintenance, les trois dernières versions publiées s'étalent sur environ trois mois, avec v1.3.6 en août 2026, v1.3.5 en juillet et v1.3.4 en juin, et le dernier push sur la branche main est daté de septembre 2026. Le projet n'est pas archivé. Le coût réel vient d'ailleurs : deux chaînes de build (Tauri et Expo), un canal TestFlight pour iOS, et une dépendance aux API de fournisseurs de modèles dont les interfaces bougent. Chaque fournisseur ajouté est une surface de maintenance supplémentaire.

Face à un lecteur sans IA, et face à un script maison

L'alternative la plus directe est Calibre, avec ses quinze formats et plus et son écosystème établi. La différence n'est pas une question de qualité mais de nature : Calibre gère une bibliothèque et convertit des fichiers, il ne répond à aucune question sur le contenu. Vous pouvez chercher un mot dans Calibre, pas une idée. KOReader se rapproche davantage sur l'usage, la lecture annotée sur appareil, avec un TTS limité selon le tableau du README, mais sans recherche sémantique ni stockage vectoriel. La troisième option est de ne pas utiliser d'application du tout : indexer ses EPUB avec un script d'extraction de texte, un modèle d'embeddings local et une base vectorielle, puis interroger le tout depuis un terminal. C'est plus de travail, mais cela supprime la question du fournisseur et celle de la synchronisation. ReadAny prend sa valeur précisément là où ce script maison coûte trop cher : interface de lecture, annotations, export vers Obsidian ou Notion, et synchronisation entre un ordinateur et un téléphone. Si vous n'avez pas besoin de ces trois éléments ensemble, l'application est un poids mort.

Conclusion éditoriale

ReadAny convient à celles et ceux qui lisent surtout au format EPUB ou PDF, gardent leurs annotations dans un dépôt WebDAV et acceptent de configurer eux-mêmes un fournisseur de modèles. Il faut l'éviter si votre bibliothèque est majoritairement en AZW3 ou MOBI, ou si vous attendez un lecteur qui fonctionne sans réglage. Avant d'adopter, vérifiez concrètement deux choses : que votre fichier s'importe sans passer par la conversion en EPUB, et que le modèle d'embeddings choisi produit bien des résultats sur une recherche dont vous connaissez la réponse.

Sources officielles

1. codedogQBY/ReadAny on GitHub
2. Issues
3. Project website
4. README
5. Releases