Tiny Little Office : une suite bureautique minimaliste, codée en trois jours, dans une URL
Sommaire
En bref
- Tiny Little Office propose un ensemble d'outils bureautiques (traitement de texte, feuille de calcul, gestionnaire de tâches, planificateur de voyage) accessibles gratuitement sans inscription, sans dépendance à un serveur : chaque document est encodé dans l'URL elle-même.
- Le projet a été développé en trois jours par les co-fondateurs d'Aboard et conçu selon une philosophie minimaliste, sans modèle commercial payant ni captation d'audience.
- La taille des documents est fortement limitée par cette approche : environ 2 000 caractères maximum pour un texte.
Ce que dit la source
Tiny Little Office repose sur une prémisse simple : les outils bureautiques standards (suite Microsoft, Google Workspace) sont surdimensionnés pour de nombreux usages quotidiens. Les co-fondateurs d'Aboard, qui avaient testé cette idée il y a six ans avant de l'abandonner, la ressortent cette fois complètement dépourvu d'infrastructure serveur centralisée. Chaque document, texte, tableau, note, vit entièrement dans l'URL : pas de base de données, pas d'authentification, pas de stockage persistant côté serveur. Le service ne conserve que du texte chiffré pendant quelques heures maximum, et accepte jusqu'à cent liens générés par jour depuis une adresse IP.
- L'encodage URL permet de partager un document via un simple lien, sans dépendre de la persistance du site : si tinylittleoffice.com disparaît, le document reste consultable tant que l'URL est conservée.
- La suite inclut un traitement de texte, une feuille de calcul, un gestionnaire de tâches, un planificateur de voyage et d'autres outils, tous sans inscription ni écran de connexion.
- Environ 2 000 caractères constituent la limite pratique d'un document texte, faute de place dans l'URL ; il existe une limitation de cent liens générés par jour depuis une même adresse.
- L'intégration avec OpenStreetMap pour les cartes pose problème sur le site public : OSM semble bloquer les requêtes massives, suggérant que la montée en charge nuit à la viabilité du modèle sans serveur.
- Un dépôt GitHub permet d'exécuter l'outil localement ou de l'auto-héberger sur un VPS bon marché, contournant les limitations du service en ligne.
- L'interface web accepte les instructions LLM : en lisant llms.txt du site, Claude ou d'autres modèles peuvent générer des URLs formatées pour créer des documents directement.
Dans les commentaires
Débat mitigé, penché vers le scepticisme mesuré. Le côté « vibecodé en trois jours » plaît aux commentateurs sensibles à l'esthétique no-bullshit, mais les limites techniques (taille, rate-limiting, blocage OSM) et l'absence de plan de pérennité suscitent le doute sur la viabilité à moyen terme.
- Plusieurs commentateurs expriment du doute sur la durabilité : l'auteur reconnaît lui-même que les versions antérieures « sont tombées du web » six ans plus tard, et la présente version porte les mêmes risques structurels.
- Des problèmes fonctionnels signalés sur le fil : curseur erratique lors de l'alternance entre saisie tactile et swiping dans l'éditeur texte, blocage apparent d'OpenStreetMap restreignant l'accès aux cartes.
- L'accessibilité des fichiers externes est limitée : impossible d'ouvrir un .csv, .txt ou .ics existant ; l'outil ne fonctionne que pour créer de nouveaux documents via URL.
- Le site public atteint ses limites de quotas sous la charge HN ; la solution locale (auto-hébergement via GitHub) ne s'adresse qu'aux développeurs, pas aux utilisateurs lambda.
- Un commentateur conteste l'utilité du planificateur de voyage, jugé trop simpliste pour des cas réels (Ottawa à 6 personnes, Cancun à ~20) : le besoin réel dépasse nettement ce qu'un formulaire statique peut résoudre.
Notre lecture
Intéressant comme expérience conceptuelle et preuve que la plupart des besoins bureautiques légers peuvent tenir dans une URL, notamment dans une optique pédagogique ou de prototypage rapide. Mais pas de produit à conseiller en organisation : la limite de 2 000 caractères, l'absence de persistance côté serveur (et donc de sauvegarde automatique fiable), et l'impasse six ans plus tard sur le projet original suggèrent qu'une URL n'est pas un système de stockage viable à long terme, même chiffré. L'auto-hébergement local change la donne pour les équipes techniquement averties (développeurs, infrastructures légères), mais sort le produit de sa cible marché affichée. À regarder comme un artefact philosophique cool, pas comme une alternative sérieuse à une suite bureautique.