Deta Surf : un notebook local où les fichiers, les pages web et le modèle d'IA restent sous votre contrôle

Le problème visé : penser à travers plusieurs supports, pas dans un seul

La motivation affichée par le projet part d'un constat simple. La plupart des applications traitent une tâche ou un type de média : les notes d'un côté, les sites web de l'autre, les PDF ailleurs. Or un travail de recherche réel oblige à passer de l'un à l'autre, à ouvrir des fenêtres, faire défiler, copier, coller dans un éditeur ou dans une fenêtre de chatbot. Surf se présente comme un cahier qui absorbe ces allers-retours. Le public visé n'est donc pas l'équipe qui documente un produit, mais la personne seule qui enquête : étudiant, chercheur, développeur qui lit de la documentation, analyste qui recoupe des rapports. Le README insiste sur un point qui distingue le projet d'un simple client de chatbot : la bibliothèque est privée, stockée sur l'ordinateur, et l'application fonctionne sur macOS, Windows et Linux. Cette promesse vaut ce que vaut son format de stockage, et c'est là qu'il faut regarder de près.

SFFS : la bibliothèque comme socle, et non comme accessoire

Le mécanisme central décrit dans le README est SFFS, pour Surf Flat File System. C'est le moteur de stockage local sur lequel repose la bibliothèque. Le projet annonce que les données sont conservées dans des formats ouverts et transparents, et que la documentation détaillée se trouve dans docs/LIBRARY.md. C'est le choix d'architecture qui compte le plus ici. Une bibliothèque qui vit dans une base propriétaire transforme l'application en point de passage obligé : le jour où vous voulez migrer, il faut écrire un extracteur. Un stockage en fichiers plats réduit ce risque, à condition que la documentation décrive réellement la disposition des fichiers et pas seulement l'intention. Le README ne donne pas cette disposition, et je ne peux donc pas confirmer ce que contient un dossier de bibliothèque ni comment les ressources web y sont représentées. C'est la première chose à lire dans docs/LIBRARY.md avant de s'engager. La bibliothèque sert aussi de matière première aux fonctions d'IA : les mentions @, la recherche web et les citations s'appuient sur les ressources qu'elle contient.

Notes intelligentes : mentions, recherche web et citations profondes

Les notes de Surf sont conçues comme un espace où l'on déclenche des actions plutôt que comme un éditeur passif. Le README décrit trois mécanismes. D'abord la mention @, qui permet de générer du contenu depuis n'importe quel onglet, site ou ressource de la bibliothèque. Ensuite la recherche web, déclenchée depuis une note, dont les résultats reviennent dans la note elle-même. Enfin les citations, présentées comme des liens profonds vers la source d'origine : une section de page web, un horodatage dans une vidéo, une page dans un PDF. Ce troisième point est le plus intéressant techniquement, parce qu'une citation qui pointe vers un instant de vidéo suppose que la bibliothèque conserve la position, pas seulement le texte extrait. Les détails sont renvoyés à docs/SMART_NOTES.md, avec des ancres dédiées pour la recherche web et les citations. Le README mentionne aussi l'import d'images, de tableaux et de données collées depuis d'autres applications, que Surf doit interpréter et intégrer. Là encore, la documentation est la seule source disponible : aucune capture ni exemple de sortie n'est fourni dans le matériel dont je dispose.

Surflets : générer de petites applications dans le cahier

Les Surflets sont la fonction la plus singulière du projet. Il s'agit d'applications interactives générées sans écrire de code, à partir de l'outil de génération d'applications intégré. Le README donne un exemple d'usage dans sa liste de choses à essayer : utiliser cet outil et demander une application. L'intention est de produire un visualiseur ou un petit outil d'exploration quand une note et un tableau ne suffisent pas. Deux réserves tiennent au matériel disponible. La première est que la qualité du résultat dépend entièrement du modèle branché, puisque les Surflets comme les notes sont alimentés par le modèle choisi. La seconde est que du code généré puis exécuté dans l'application pose une question de surface d'exécution, sur laquelle le README ne dit rien. La documentation dédiée, docs/Surflets.md, est le seul endroit où chercher une réponse. Tant qu'on ne l'a pas lue, considérer les Surflets comme une commodité expérimentale plutôt que comme un composant sur lequel bâtir un flux de travail.

Choix du modèle : clé personnelle, modèle cloud, ou moteur local

Surf ne fournit pas de modèle et ne l'impose pas. Le README énumère trois voies : apporter sa propre clé pour les modèles courants, ajouter un modèle cloud, ou utiliser un modèle de langue local. Les sujets du dépôt citent nommément Claude, DeepSeek, Gemma, Ollama et OpenAI, ce qui donne une idée des intégrations présentes ou prévues. C'est un choix de conception cohérent avec la promesse de données locales : on peut faire tourner l'ensemble sans qu'aucune ressource ne quitte la machine, à condition d'accepter les performances d'un modèle local. Le compromis est réel et le README ne l'atténue pas. Un modèle local sur un portable sera plus lent et moins capable qu'un modèle cloud sur les tâches de synthèse longue ; un modèle cloud règle ce problème mais fait sortir le contenu des notes et les extraits de la bibliothèque vers un tiers. docs/AI_MODELS.md est la référence à consulter pour savoir quels fournisseurs sont réellement pris en charge et comment la configuration se fait. Le matériel ne permet pas d'en dire plus sur la forme exacte de cette configuration.

Installation et construction depuis les sources

Le README ne donne pas de commande d'installation directe. Il renvoie à docs/INSTALL.md pour les instructions détaillées, et à CONTRIBUTING.md pour la construction depuis les sources et le développement local. C'est un point à noter : il n'existe pas, dans le matériel fourni, de ligne du type paquet à installer ou binaire à télécharger. Un lecteur qui veut essayer Surf doit donc commencer par docs/INSTALL.md, puis, s'il veut compiler lui-même, par CONTRIBUTING.md. La pile annoncée est Svelte, TypeScript et Rust, avec Electron parmi les paquets utilisés d'après les remerciements, et Tiptap pour l'édition. Cela implique une chaîne de construction plus lourde qu'une application web : au minimum un environnement Node et une toolchain Rust pour la partie native. Le README mentionne aussi un guide des raccourcis dans docs/SHORTCUTS.md, ce qui suggère une interface dense, organisée autour d'onglets, d'une vue divisée et d'une barre latérale. Pour une prise en main, ces quatre fichiers (INSTALL, CONTRIBUTING, SHORTCUTS, LIBRARY) forment le parcours minimal.

Limites, canaux de publication et coût de maintenance

La limite la plus visible est le stade du projet. La dernière publication listée est 1.4.7-beta.0, précédée de deux versions candidates, toutes datées d'avril 2026. Le numéro lui-même porte le suffixe beta. Un outil dont on dépend pour retrouver ses propres documents doit être évalué avec cette information en tête, d'autant que le projet est une application de bureau qui touche au stockage : une régression sur le format de bibliothèque coûte plus cher qu'une régression d'interface. Le README ne décrit aucune procédure de sauvegarde ni de migration de bibliothèque, et je ne peux pas affirmer qu'il en existe une. Autre point, la licence. Le code est sous Apache-2.0, avec deux exceptions explicitées : le correctif du paquet @ghostery/adblocker-electron est sous MPL-2.0, en cohérence avec le projet amont, et certains fichiers peuvent porter leur propre en-tête de licence qui prime sur la licence par défaut. Le nom et les logos Deta ne sont pas couverts par Apache-2.0, ce qui interdit de reprendre la marque même en rediffusant le code. Apache-2.0 autorise l'usage commercial et la modification, mais impose de conserver les mentions de licence et d'État des modifications ; sur ce point précis, un avis juridique reste nécessaire. Enfin, la maintenance d'un fork est coûteuse ici : trois langages, Electron, une partie Rust, et un moteur de stockage maison à suivre.

Face à Obsidian, la différence n'est pas le nombre de fonctions

L'alternative la plus évidente pour un lecteur francophone est Obsidian, qui partage deux propriétés avec Surf : les fichiers restent sur la machine, et l'application est extensible. La différence d'approche est nette. Obsidian organise des fichiers Markdown dans un dossier que l'utilisateur choisit et peut lire avec n'importe quel éditeur ; l'IA arrive par des modules externes, et l'application ne gère pas nativement une vidéo YouTube ou un PDF comme ressource de bibliothèque avec horodatage. Surf prend le chemin inverse : il assume un moteur de stockage dédié, SFFS, et intègre les médias et les modèles d'IA au cœur du produit. On gagne en cohérence, on perd en banalité du format. Un dossier de Markdown se sauvegarde avec rsync et se lit dans un terminal ; une bibliothèque SFFS dépend de la documentation du projet et des outils que Surf expose. Ce n'est pas un défaut en soi, c'est le prix de la fonctionnalité. Si votre priorité est de pouvoir ouvrir vos notes dans dix ans avec un éditeur de texte, Obsidian est plus prudent. Si votre priorité est d'interroger une vidéo et un PDF sans les recopier à la main, Surf attaque un problème qu'Obsidian ne traite pas nativement.

Conclusion éditoriale

Surf convient à qui accumule déjà des PDF, des vidéos et des pages web et veut les interroger sans téléverser sa bibliothèque chez un fournisseur de modèle : le stockage SFFS et le choix du modèle sont les deux arguments qui tiennent. Il ne convient pas à qui cherche un carnet de notes stable pour un usage quotidien en équipe, ni à qui veut un espace partagé, puisque la bibliothèque est locale et personnelle par construction. Avant d'adopter, vérifiez deux points précis : le contenu de docs/LIBRARY.md pour juger si le format SFFS vous laisse récupérer vos fichiers sans Surf, et la liste de modèles de docs/AI_MODELS.md pour confirmer que votre fournisseur ou votre moteur local y figure.

Sources officielles

1. deta/surf on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases