Preswald : livrer une application de données en un seul fichier HTML

Le problème : un script d'analyse que personne d'autre ne peut exécuter

Un analyste écrit un script Python, produit quelques graphiques, puis doit le transmettre. Le destinataire n'a ni Python, ni les dépendances, ni envie d'ouvrir un terminal. La réponse habituelle consiste à déployer un serveur, ce qui déplace le problème vers l'hébergement, l'authentification et la maintenance. Preswald prend le chemin inverse : il transforme l'application en dossier statique. Le README résume l'objectif ainsi : « Create interactive data apps with a full data stack that runs in the browser (no local dependencies!), runs offline, and is shareable in a single file. » Le public visé est donc celui qui livre un outil à une partie prenante, pas celui qui construit un service. Les cas d'usage listés dans le README vont dans ce sens : tableaux de bord d'analyste, rapports interactifs, outils d'inspection de fichiers ou de journaux, kits hors ligne pour le terrain ou les environnements isolés, panneaux de comparaison d'expériences. Ce sont des artefacts à durée de vie courte, souvent jetables, dont la valeur tient à la facilité de transmission. Un point mérite d'être noté : le README insiste sur le contrôle local des données sensibles, ce qui suppose que le fichier exporté reste sur un support maîtrisé. Cette promesse et la promesse de partage facile ne vont pas de soi ensemble, et nous y revenons plus bas.

Pyodide et DuckDB dans l'onglet, et un graphe de dépendances

Le mécanisme repose sur trois briques empilées. Pyodide apporte un interpréteur CPython compilé en WebAssembly, ce qui permet d'exécuter du Python dans le navigateur. DuckDB fournit le moteur de requêtes, également en WASM d'après la description du dépôt, et le README mentionne Pandas ainsi que Plotly et Matplotlib pour le rendu. Le code de l'utilisateur, les données et les requêtes DuckDB sont regroupés dans le dossier produit par la commande d'export. La partie la plus intéressante est le moteur réactif. Le README parle d'un « DAG of dependencies » et affirme que « Only re-run what's needed ». Autrement dit, lorsqu'un composant d'interface change, Preswald ne relance pas l'intégralité du script : il recalcule les cellules dont les entrées ont changé. C'est la différence de fond avec un notebook classique, où l'ordre d'exécution dépend de l'historique des manipulations de l'utilisateur. Ici, la dépendance est déclarée par le code lui-même. Le README présente aussi les applications comme « fully inspectable and modifiable by agents », ce qui décrit une propriété de fait (le code et la structure sont lisibles) plus qu'une fonctionnalité vérifiable depuis les seules informations dont nous disposons. La documentation ne détaille pas, dans le matériel fourni, comment le graphe est construit ni quel est le coût de recalcul d'un DataFrame volumineux. C'est précisément la question à poser avant de s'engager.

Du squelette my_app au serveur local sur le port 8501

L'installation passe par PyPI, avec pip ou uv, comme l'indique le README. La séquence de démarrage tient en quatre lignes : pip install preswald, preswald init my_app, cd my_app, puis preswald run. La commande init crée une arborescence précise : hello.py pour la logique de l'application, preswald.toml pour la configuration, secrets.toml pour les clés d'API, data/sample.csv pour les données et images/logo.png pour l'image de marque. Le README donne un exemple minimal de hello.py qui importe text, table et get_df, écrit un titre, charge le CSV avec get_df("sample.csv") et l'affiche avec table(df). La commande run lance un serveur de développement, annoncé à l'adresse http://localhost:8501. Le fichier preswald.toml se découpe en sections. [project] porte title, version, port, slug et entrypoint, ce dernier pointant vers hello.py. [branding] accepte name, logo, favicon et primaryColor, avec l'exemple #F89613. [logging] prend level, dont les valeurs possibles sont listées dans le README (DEBUG, INFO, WARNING, ERROR, CRITICAL), et format, avec un motif de journalisation classique. L'export se fait ensuite avec preswald export, qui construit un site statique dans dist/. Le README indique que ce dossier contient tout le nécessaire pour exécuter l'application localement ou la partager, qu'il fonctionne hors ligne dans un navigateur moderne, et qu'il est intégrable dans une plateforme d'hébergement. Le nom du dossier de sortie, dist/, n'est pas configurable d'après les informations fournies.

Le fichier secrets.toml voyage avec le dossier exporté

C'est la limite la plus concrète du modèle, et elle découle de son principal atout. Le squelette généré par preswald init contient un fichier secrets.toml destiné aux clés d'API. Une application statique n'a pas de serveur pour détenir un secret : tout ce que le code lit à l'exécution est présent dans le dossier dist/. Si une clé se trouve dans secrets.toml au moment de l'export, elle se trouve dans le dossier exporté, et donc chez quiconque reçoit ce dossier. Le README ne décrit, dans le matériel dont nous disposons, ni mécanisme de substitution à la compilation, ni liste d'exclusion. Il faut donc traiter secrets.toml comme un fichier de développement local et vérifier le contenu de dist/ avant tout envoi. Cette contrainte entre en tension avec l'argument de contrôle des données sensibles : le contrôle est réel tant que le fichier reste chez vous, et disparaît dès qu'il circule. Une seconde limite tient à l'échelle. Le README affirme que les applications tournent hors ligne « even with large data », sans chiffre. Faire tenir un jeu de données dans un onglet de navigateur reste une contrainte de mémoire, et le coût de chargement initial de Pyodide s'ajoute à celui des données. Enfin, la dépendance à Pyodide restreint les bibliothèques utilisables : un module Python compilé qui n'a pas d'équivalent WASM ne fonctionnera pas dans le navigateur, même s'il s'exécute sans problème sous preswald run. Le README ne fournit pas de liste des paquets pris en charge.

Streamlit exécute côté serveur, Preswald exécute côté navigateur

La comparaison la plus utile est celle avec Streamlit, que le README positionne lui-même en parlant d'« a lightweight alternative to heavier web app platforms ». La différence n'est pas une question de fonctionnalités mais d'endroit où tourne le code. Streamlit démarre un processus Python, garde l'état de session côté serveur et envoie au navigateur une représentation de l'interface. Chaque interaction déclenche un aller-retour réseau et, souvent, une réexécution du script entier. Le déploiement suppose une machine qui reste allumée, et l'accès se gère par l'authentification de la plateforme. Preswald déplace l'exécution dans le navigateur : pas de processus à maintenir, pas de session serveur, et un artefact qui fonctionne sans réseau. En contrepartie, vous perdez tout ce qu'un serveur permet : lecture de fichiers locaux au moment de l'exécution, appels à une base de données interne, secrets côté serveur, accès concurrent pour plusieurs utilisateurs. Le choix se résume donc à une question de cycle de vie. Un outil interne que dix personnes consultent quotidiennement et dont les données changent toutes les heures relève de Streamlit. Un rapport figé sur un instantané, envoyé à un client ou emporté sur un site sans connexion, relève de Preswald. La documentation ne décrit pas, dans le matériel fourni, de mode serveur ni de rafraîchissement automatique des données après export.

Rythme des versions et portée de la licence Apache-2.0

Les versions publiées dans le matériel fourni s'enchaînent rapidement : v0.1.57 le 29 mai 2025, v0.1.58 le même jour en soirée, v0.1.59 le 5 juin 2025. Le numéro reste en 0.1.x, ce qui signale une API encore mouvante. Le dépôt n'est pas archivé et le dernier push indiqué est le 11 juin 2026. Pour une équipe, cela implique de figer la version dans un fichier de dépendances plutôt que de suivre la branche principale, et de prévoir de relire hello.py et preswald.toml à chaque montée de version mineure. Le coût de maintenance se situe moins dans le code de l'application, qui reste court, que dans la chaîne WASM sous-jacente : Pyodide, DuckDB et les bibliothèques de rendu évoluent à leur propre rythme, et une montée de version de Preswald peut modifier l'environnement d'exécution sans que votre code change. La licence est Apache-2.0, mentionnée à la fois dans le README et dans le dépôt. C'est une licence permissive avec clause de brevets, qui autorise l'usage commercial et la redistribution, à condition de conserver les mentions de copyright et le texte de licence, et de signaler les fichiers modifiés. Pour un dossier dist/ que vous diffusez, la question de savoir quelles mentions doivent accompagner l'artefact dépend des composants embarqués, notamment Pyodide et DuckDB, qui ont leurs propres licences. Ce point relève d'une vérification juridique et non de la lecture du README.

Conclusion éditoriale

Preswald convient aux équipes qui doivent transmettre un tableau de bord ou un rapport à une personne qui n'installera rien, et qui acceptent de figer données et code dans un artefact HTML. Il ne convient pas aux applications multi-utilisateurs, aux jeux de données qui ne tiennent pas dans le navigateur, ni aux projets qui dépendent d'une bibliothèque Python sans équivalent WASM. Avant d'adopter, vérifiez trois choses sur votre propre cas : le temps de chargement du dossier dist/ avec vos données réelles, la disponibilité des paquets dont dépend votre hello.py dans Pyodide, et le contenu de secrets.toml, puisque les clés d'API présentes dans le dossier exporté voyagent avec le fichier.

Sources officielles

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