Eidos : un fichier SQLite unique qui sert à la fois de tableur relationnel et de base pour un agent

Le problème visé : un tableur qui reste un fichier

La plupart des tableurs relationnels hébergés stockent vos données dans un backend que vous ne pouvez pas ouvrir. Eidos prend le chemin inverse. Le README présente Eidos File comme « an open, single-file format built on standard SQLite », et cette phrase résume la proposition : une table avec des champs typés, des relations et plusieurs vues, le tout dans un seul fichier .eidos que vous déplacez, copiez et sauvegardez comme n'importe quel autre fichier. Le public visé n'est pas l'équipe qui cherche un Notion d'entreprise. C'est plutôt la personne seule, ou le petit groupe, qui veut garder une bibliothèque personnelle, un inventaire ou un jeu de tâches hors du cloud, tout en gardant la possibilité qu'un agent ou un script vienne lire et écrire dedans. Le second public est justement l'agent : la CLI est décrite dans le README comme « agent-first », ce qui indique que l'automatisation n'est pas un ajout tardif mais une cible de conception.

Un fichier, un Runtime, une interface partagée

Le dépôt se lit comme une pile de paquets plutôt que comme une application monolithique, et l'architecture visible dans le README le confirme. packages/eidos-file implémente le format et le Runtime. packages/eidos-file-ui fournit l'interface React d'édition partagée. Autour de ces deux briques, trois hôtes consomment le même noyau : apps/eidos-lite-desktop pour le bureau, apps/eidos-file-web pour l'éditeur navigateur, apps/cli pour la ligne de commande et le serveur local. Ce découpage a une conséquence pratique : le comportement d'édition ne devrait pas diverger entre le bureau et le navigateur, puisque les deux s'appuient sur eidos-file-ui. Un quatrième paquet, packages/markdown, gère un éditeur WYSIWYG basé sur Lexical pour ce que le projet appelle Eidos Flavored Markdown. Le README précise que le Markdown reste la valeur canonique et que le paquet possède l'import, l'édition, la sérialisation et les contrôles de fidélité, tandis que les hôtes gardent la persistance et le stockage des pièces jointes. C'est un choix de séparation net : le format de contenu ne dépend pas de l'endroit où il est rangé. Pour l'historique local et une synchronisation optionnelle, Eidos Lite s'appuie sur Graft, décrit comme un système de contrôle de version orienté état d'application, développé séparément. Autrement dit, la versionnage n'est pas intégré au fichier .eidos lui-même mais confié à un composant externe.

Installation et premières commandes

Trois voies d'accès sont documentées. Le bureau : télécharger Eidos Lite depuis eidos.space/download, sans compte requis pour un usage local. Le navigateur : ouvrir editor.eidos.space pour créer ou éditer un fichier .eidos sans rien installer. La CLI : installer le binaire eidos. Sur macOS ou Linux, le README donne curl -fsSL https://download.eidos.space/cli/install.sh | sh ; sous Windows PowerShell, irm https://download.eidos.space/cli/install.ps1 | iex. La création d'un fichier avec une table typée tient en une commande, avec un champ libellé et un tableau JSON de champs : eidos create example.eidos --table Tasks --label-field Title --fields '[{"name":"Title","type":"text"},{"name":"Status","type":"select"}]'. Puis eidos serve example.eidos --open pour servir le fichier et l'ouvrir. Le README renvoie à apps/cli/README.md pour les flux d'agent et d'automatisation. Côté développement, les prérequis annoncés sont Node.js 22.23.1, Corepack et Rust stable pour le travail sur la CLI. La séquence est corepack enable, puis pnpm install --frozen-lockfile, puis les scripts pnpm dev:eidos-lite, pnpm dev:eidos-file-web, pnpm dev:markdown-editor-playground, pnpm test:eidos-file et pnpm test:markdown-editor. La CLI vit dans son propre espace de travail Rust : cd apps/cli puis cargo test --workspace --locked. La version de Node épinglée à 22.23.1 est un détail à ne pas ignorer : elle suggère que la toolchain est suivie de près, et qu'un environnement plus ancien risque de ne pas passer l'installation.

Licence : deux régimes dans le même dépôt

C'est le point le plus concret du dépôt et celui qui décide le plus souvent de l'adoption. Le README indique que le dépôt est sous AGPL v3, mais que les paquets réutilisables @eidos.space/eidos-file et @eidos.space/eidos-file-ui sont publiés sous MIT. La frontière est donc tracée entre le format et l'interface d'un côté, et les applications hôtes de l'autre. Si vous voulez seulement lire, écrire ou servir des fichiers .eidos depuis votre propre code, les paquets MIT sont la porte d'entrée prévue. Si vous voulez reprendre l'application de bureau ou l'éditeur web, vous entrez dans le périmètre AGPL v3, avec les obligations de publication qui vont avec pour un service exposé sur un réseau. Je ne donne pas d'avis juridique ici : faites relire le fichier LICENSE et la notice du dépôt par qui de droit avant de bâtir un produit fermé sur apps/eidos-lite-desktop ou apps/eidos-file-web. Ce qui est certain, c'est que le dépôt ne place pas tout sous la même licence, et que cette distinction est délibérée.

Coût de maintenance et de mise à jour

Le rythme des publications est serré. Trois versions apparaissent sur une même journée dans les données fournies : lite-v0.11.0, lite-v0.10.1 et cli-v1.1.0, toutes datées du 8 septembre 2026. La CLI est déjà en 1.x alors que l'application de bureau reste en 0.x, ce qui indique que l'interface de commande est traitée comme plus stable que l'application. La branche par défaut est dev, pas main : les utilisateurs qui clonent le dépôt pour le compiler récupèrent donc du code en cours de développement, et la version épinglée de Node.js ajoute une contrainte de mise à jour à chaque montée de version. Sur le plan du stockage, le pari du SQLite standard réduit le risque de verrouillage : même si Eidos disparaissait, le fichier resterait ouvrable. Mais ce même pari signifie que toute évolution du schéma ou des conventions de nommage se répercute sur des fichiers que vous possédez déjà. Le README ne décrit pas de mécanisme de migration entre versions de format, et je ne peux pas affirmer qu'il en existe un. Avant de confier des données réelles à un fichier .eidos, testez la montée de version sur une copie.

Quand Eidos n'est pas le bon outil

Le cas le plus net est celui de l'édition collaborative simultanée. Le projet se présente comme local-first et hors ligne, avec une synchronisation optionnelle via Graft. Rien dans le README ne décrit de résolution de conflits en temps réel ni de présence partagée à la manière d'un tableur hébergé. Si votre besoin est que cinq personnes éditent la même table en même temps, dans le même navigateur, avec des curseurs visibles, ce n'est pas la promesse tenue ici. Deuxième cas : les gros volumes. Le format repose sur SQLite, ce qui est un bon choix pour des jeux de données de taille personnelle ou d'équipe restreinte, mais le README ne donne aucune indication sur les performances à l'échelle de millions de lignes, et je ne peux pas en inventer. Troisième cas, plus subtil : si vous voulez seulement un tableur local sans dimension relationnelle ni agent, la CLI et la notion de Runtime ajoutent une surface d'apprentissage qui ne vous servira pas. Le projet vise explicitement le duo utilisateur plus agent, et cette hypothèse irrigue toute la conception.

Face à un fichier SQLite nu ou à un tableur hébergé

L'alternative la plus directe n'est pas un concurrent nommé mais l'usage direct de SQLite. Vous créez une base, vous écrivez vos CREATE TABLE, vous l'ouvrez avec n'importe quel client. La différence est que SQLite ne vous donne ni champs typés avec une sémantique d'interface, ni relations affichées, ni vues multiples, ni éditeur WYSIWYG pour le Markdown. Eidos ajoute précisément cette couche de présentation au-dessus du même moteur, et c'est là que se situe sa valeur : le fichier reste un SQLite standard, mais l'expérience d'édition est celle d'un tableur relationnel. Le prix à payer est un Runtime propriétaire et un format de fichier dont les conventions ne sont pas entièrement documentées dans le README, qui renvoie à docs/specs pour les spécifications normatives. Face à un tableur hébergé, l'arbitrage est inverse : vous gagnez la collaboration et la synchronisation sans effort, vous perdez la propriété du fichier et la possibilité d'ouvrir vos données avec sqlite3. Le choix se ramène donc à une question simple : est-ce que le fait que vos données soient un fichier que vous contrôlez vaut la renonciation à la collaboration intégrée ? Le projet parie que oui, pour un usage personnel ou de petite équipe.

Conclusion éditoriale

Eidos convient à celles et ceux qui veulent un tableur relationnel local dont le fichier reste un SQLite lisible par n'importe quel outil, et à qui la CLI eidos suffit pour les flux d'automatisation. À éviter si votre produit doit embarquer l'interface d'édition sans publier votre code, puisque apps/eidos-lite-desktop et apps/eidos-file-web relèvent de l'AGPL v3 et non des packages MIT. Avant d'adopter, vérifiez deux points précis : la compatibilité de vos fichiers .eidos existants avec lite-v0.11.0 et cli-v1.1.0, et la présence de docs/specs pour les détails du format que vous comptez manipuler directement en SQL.

Sources officielles

1. License: AGPL-3.0
2. mayneyao/eidos on GitHub
3. Project website
4. README
5. Releases