Des documents Grist qui deviennent des applications métier, sur mesure
Un tableur collaboratif porte déjà les données, les droits et l'historique. Ce dépôt ajoute ce qui manque pour en faire un outil de travail : des vues qui lisent ces tables au lieu de les copier — carte, planning, formulaire, plan de charge — et la chaîne qui permet de les fabriquer.
Grist, en deux mots
Grist est un tableur relationnel collaboratif, libre et auto-hébergeable : des tables liées entre elles, des formules en Python, des règles d’accès fines, et une API sur laquelle des vues peuvent se greffer. C’est ce dernier point qui rend ce dépôt possible — un widget personnalisé est une page web à qui le document ouvre ses données.
Pour les administrations françaises, deux instances publiques existent déjà, gérées par des opérateurs de l’État : rien à héberger pour commencer, et les données restent sur le territoire. C’est le cadre dans lequel ces widgets sont pensés — souverain, libre, sans service tiers intercalé.
Les widgets
Artefactory
Un atelier pour écrire ses propres widgets sans quitter Grist : on compose, on prévisualise, on enregistre — l'artefact vit dans le document.
Atlas
La carte n’est pas un export de vos données : c’en est une vue. Les couches, la symbolisation, le relief et le récit vivent dans le document Grist — et quand la table change, la carte a déjà changé.
Form Builder
Des questionnaires branchés sur vos tables : ce qui est répondu atterrit directement dans le document, et le formulaire s'adapte à qui le remplit.
qgis2grist
Un projet QGIS devient un document Grist : les couches, leurs attributs et leur symbologie sont importés, le schéma des tables est déduit de la donnée. La v2 rend en MapLibre et produit un Scene Manifest — ce qu'Atlas sait relire.
TaskFlow
Une suite de gestion de projet qui travaille sur vos propres tables : les mêmes tâches vues en tableau, en planning, en calendrier, en charge par personne. Changez de vue, pas de données.
Ce qui les rend différents
La donnée ne bouge pas
Un widget est une vue, pas un export. Il lit la table avec ses formules et ses liens ; quand elle change, la vue a déjà changé. Rien à réexporter, rien à resynchroniser.
Les droits sont ceux du document
Aucun système d'accès en plus de celui de Grist. On partage un document, les vues suivent : un lecteur consulte, il ne modifie pas.
Chez vous, pas chez un tiers
Ces widgets sont des fichiers statiques servis depuis GitHub Pages, et ils fonctionnent sur n'importe quelle instance Grist, y compris auto-hébergée. Aucun service tiers ne s'intercale entre vous et vos données.
Sans dépendance de build
HTML, CSS et JavaScript autonomes. Pas de chaîne de compilation à maintenir, pas de paquet à mettre à jour pour qu'un widget continue de s'ouvrir dans trois ans.
Le même widget, trois usages
Un widget n'est pas prisonnier de son document. La même adresse sert à concevoir, à diffuser et à relever sur le terrain — ce qui change, c'est ce que l'environnement permet.
| Où | Ce qu'on y fait | Accès |
|---|---|---|
| Dans un document Grist | Le cas courant : le widget est une vue du document, à côté des tables. On construit, on modifie, on écrit dans les mêmes tables. | Lecture et écriture, selon les droits de la personne |
| Dans un navigateur | La même adresse ouverte seule. On charge un fichier, on importe depuis OpenStreetMap, on consulte une scène partagée. Rien à installer pour regarder. | Ce que le document autorise en lecture |
| Sur le terrain | Empaqueté en application Android, le widget ouvre les scènes d'un compte sans passer par un document — parce qu'un navigateur ne peut pas présenter de clé API à l'instance. | Compte complet, hors du moteur web |
Une chaîne, pas des outils épars
Outiller les agents plutôt que les remplacer
Construire une application métier demande d’aller chercher la donnée, de la mettre en forme, d’écrire un widget, de le déployer. Plutôt que d’automatiser ces gestes un par un, on donne à un assistant les outils pour les faire — via le protocole MCP, qui expose un logiciel comme un jeu d’actions qu’un modèle peut appeler. L’assistant travaille alors dans vos outils, avec vos droits, sur vos données.
Construire dans le document
GristCoder
Un serveur MCP qui relie un assistant à un document Grist, accompagné d’un widget d’édition et d’aperçu. Ce qui est produit — HTML, React — est enregistré dans le document lui-même : aucun hébergement externe, et l’artefact suit le document qui le porte. En discuter sur le forum.
Donner l’API, sans interface
mcp-server-grist
L’implémentation MCP de l’API Grist : lire des tables, en écrire, décrire un schéma. C’est la brique qu’on branche quand l’assistant doit manipuler la donnée sans qu’on ait besoin d’un atelier autour. En discuter sur le forum.
Ce qui tient les projets ensemble
Ces widgets ne partagent pas de code — ils partagent des contrats. Un même document peut donc passer d’un outil à l’autre sans conversion, et un projet peut évoluer sans casser les autres.
Scene Manifest
Le contrat de scène cartographique : qgis2grist l’écrit à l’import, Atlas le lit pour dresser la carte — couches, symbolisation déclarative, contrôles. Ni l’un ni l’autre n’a besoin de connaître l’autre, seulement le contrat.
Les tables d’un widget lui appartiennent
Chacun crée les tables dont il a besoin, préfixées à son nom, et seulement s’il en a besoin. Un document où l’on n’ouvre pas le plan de charge n’en porte pas les tables.
Les droits ne sont jamais réinventés
Aucun widget ne tient sa propre liste d’accès. Tous appliquent ceux du document, et vérifient par une écriture réelle plutôt que de croire ce que l’hôte annonce.
Ce dépôt n’est pas seul
Les widgets rassemblés ici couvrent la vue métier — carte, planning, formulaire, plan de charge. D’autres équipes en couvrent d’autres, et leurs widgets s’installent exactement de la même façon : c’est le même écosystème, pas une offre concurrente. Viennent ensuite les briques libres dont ces vues sont faites — sans elles, rien de tout cela ne s’afficherait.