Bonjour à tous,
Je partage ici un retour d’expérience sans prétention, dans l’idée que ça puisse inspirer d’autres personnes qui cherchent à pousser Grist au-delà de l’usage tableur classique.
Le contexte : dans un service des impôts des entreprises (SIE), une grande partie du travail repose sur le croisement et la consolidation de données métier. Grist fait déjà très bien le job côté stockage structuré et logique de calcul. Mais dès qu’on veut des interfaces sur mesure, des parcours guidés ou de l’automatisation poussée, on atteint vite les limites de ce que les widgets natifs permettent.
L’idée de PILOT est partie d’un constat simple : l’API documents de Grist est suffisamment riche pour servir de socle de données, et il n’y a aucune raison de s’arrêter au tableur.
Concrètement, l’architecture repose sur trois couches :
-
Grist comme base de données et source de vérité. On exploite l’API documents (lecture/écriture des tables via les endpoints REST) plutôt que de tout faire vivre dans des formules. Ça donne énormément de flexibilité : on peut requêter, filtrer, écrire depuis l’extérieur sans toucher à la structure du document.
-
Une couche React par-dessus, habillée avec le DSFR. Plutôt que de bricoler dans les widgets custom, on construit une vraie interface métier en s’appuyant sur le Système de Design de l’État. Ça nous donne d’emblée une interface conforme à la charte graphique de l’État, accessible (le DSFR est pensé RGAA), et immédiatement familière pour les agents comme pour les usagers. On reste dans un cadre officiel sans réinventer des composants maison. React communique avec Grist via l’API.
-
Un serveur Python embarqué. C’est lui qui orchestre la logique métier lourde, les appels vers des API externes (dans notre cas, la récupération automatisée de données pour appuyer le travail des agents), et qui sert d’intermédiaire propre entre React et Grist. Ça évite de surcharger le front et ça centralise les règles métier.
Le résultat, c’est qu’on garde tout l’intérêt de Grist (la souplesse de la donnée, l’autonomie de configuration) tout en offrant aux agents une expérience adaptée à leur métier réel, conforme à l’identité visuelle de l’État, et pas à un tableur générique.
On commence par les SIE parce que c’est là que le besoin est le plus tangible, mais l’approche est transposable à beaucoup de métiers de la fonction publique : dès qu’il y a de la donnée structurée + un besoin d’interface guidée + de l’interconnexion avec des systèmes tiers, le triptyque Grist / React (DSFR) / Python tient la route.
Rien de révolutionnaire dans chaque brique prise isolément, mais l’assemblage me semble pertinent à partager. Je suis curieux de savoir si d’autres ici ont exploré des architectures similaires, et quelles ont été vos limites côté API documents (volumétrie, droits, perf) ou côté intégration du DSFR dans un widget Grist.
Bonne journée à tous.
