❌

Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Grist : quand un tableur devient une application métier

8 septembre 2026 à 15:56

Un tableur pour stocker des données, jusque-là rien de très surprenant.

Mais un tableur capable d’authentifier des utilisateurs, d’afficher des documents, de proposer une interface de notation sur mesure, de croiser automatiquement plusieurs évaluations et d’alimenter un site web ? C’est déjà un peu moins commun et c’est pour ça que ça nous intéresse !

De prime abord, Grist ressemble à un tableur collaboratif. Mais derrière cette interface familière se trouve un outil open source particulièrement flexible, qui a l’avantage de pouvoir être déployé et maîtrisé dans un environnement souverain. Son modèle relationnel, son système de permissions, la gestion des pièces jointes, ses formules Python et surtout ses modules personnalisés, permettent de dépasser largement les usages classiques d’un tableur pour en faire le socle d’une véritable application métier.

Grist et La Suite numérique

Grist fait partie des outils développés et soutenus dans le cadre de La Suite numérique, l’écosystème de services numériques collaboratifs porté par l’État, notamment par la DINUM et l’ANCT. L’objectif est de proposer aux agents publics et à leurs partenaires des outils ouverts, interopérables et maîtrisés, constituant des alternatives crédibles aux grandes plateformes propriétaires.

Notre usage de Grist s’inscrit donc également dans une logique de souveraineté numérique : privilégier des briques open source,dont les conditions d’hébergement, les données et les évolutions peuvent rester maîtrisées.

Cette combinaison entre ouverture, maîtrise des données et capacité de personnalisation, en fait une alternative particulièrement intéressante aux solutions SaaS propriétaires. Grist permet de construire rapidement des outils adaptés à des besoins spécifiques, tout en conservant la maîtrise de leur hébergement, de leur évolution et des données qu’ils contiennent.

C’est précisément l’usage que nous en faisons dans plusieurs de nos projets. Partir d’un besoin métier, structurer les données dans Grist, puis construire autour d’elles les interfaces et les automatisations nécessaires. Nous pouvons ainsi concentrer nos efforts de développement sur ce qui apporte réellement de la valeur aux utilisateurs, tout en nous appuyant sur une infrastructure relativement légère, sécurisée et maîtrisable.

Revenons ensemble sur le potentiel offert pas Grist à travers deux cas d’usage !

Le point de départ : faire travailler plusieurs personnes autour des mêmes données

Premier cas d’usage : un dispositif de notation de formations pour la Délégation interministérielle à la stratégie nationale pour les troubles du neurodéveloppement (DITND). Dans le cadre de la construction de la plateforme nationale dédiée à l’autisme et aux troubles associés, une commission était chargée d’évaluer la qualité des contenus de formations déposés par différents organismes au regard des Repères nationaux.

Dans l’idée, le processus est simple : plusieurs experts examinent de façon asynchrone les formations, consultent les documents associés, et les évaluent sur la base d’une trentaine de critères. Chacun de ces experts doit pouvoir donner son avis (critère atteint, partiellement atteint, non atteint…) et apporter des commentaires. L’ensemble des ces interactions doit pouvoir être tracé. Il faut ensuite croiser les différentes évaluations, repérer les désaccords pour permettre à la commission d’aboutir à une décision.

En pratique, cela représente beaucoup de données à croiser, beaucoup d’interactions et une multiplication des fichiers et des ressaisies. Il fallait aussi garantir la sincérité de l’évaluation en s’assurant que chaque expert ne voit que ses notes et éviter tout biais de jugement.

💡Plus qu’un tableur en ligne, un tableur souverain ?

Pour comprendre notre choix, revenons sur ce qu’est Grist. Au premier regard, il ressemble à un tableur collaboratif. Mais cette interface familière cache un fonctionnement plus proche de celui d’une base de données.

Les colonnes sont typées, les tables peuvent être liées entre elles par des références et les formules sont écrites en Python. Grist permet aussi de gérer les pièces jointes ainsi que les droits d’accès des utilisateurs pour chaque table et selon des groupes personnalisables.

À ce stade, Grist joue déjà le rôle d’une petite base de données relationnelle. Mais stocker correctement l’information ne réglait qu’une partie du problème. Hors de question pour les utilisateurs de travailler directement dans les tables : il faut leur proposer une interface adaptée. C’est là que les modules personnalisés entrent en jeu.

Bien plus joli qu’un tableur, une interface user friendly

Grâce aux modules personnalisés – ou custom widgets – de Grist, nous avons développé une interface dédiée aux validateurs, directement connectée aux données de la base.

💡Qu’est-ce qu’un widget ?

Un widget est une petite application web connectée directement au document. Elle peut lire ses tables, afficher les données autrement que sous la forme de lignes et de colonnes et, si nécessaire, écrire de nouvelles informations dans Grist.

Chaque membre de la commission est authentifié via son compte Grist. Dès lors, il retrouve les formations qui lui sont attribuées, et peut consulter les documents associés, parcourir les différents critères, sélectionner son avis et ajouter ses commentaires. Les réponses sont enregistrées directement dans les tables, sans étape intermédiaire ni ressaisie.

L’évaluateur n’a donc pas besoin de manipuler directement les tables situées derrière l’application. Il utilise une interface conçue spécifiquement pour son besoin, tandis que Grist continue d’assurer le stockage et la structuration des données en arrière-plan.

Le même principe est utilisé quand la commission se réunit grâce à une seconde interface. Elle agrège les évaluations, affiche les avis côte à côte et permet de repérer immédiatement les critères faisant consensus ou, au contraire, ceux sur lesquels les évaluateurs divergent.

Le résultat ne ressemble donc plus vraiment à un tableur. Pour les utilisateurs , il s’agit d’une application métier dédiée à l’évaluation d’une formation de bout en bout. En arrière-plan, Grist reste le moteur qui stocke les données, gère les accès et assure leur cohérence.

💡Un workflow complet dans un seul environnement

La formation et ses documents sont d’abord déposés grâce à un formulaire. Les validateurs l’évaluent ensuite depuis leur interface. Les résultats alimentent directement les tables Grist. Les réponses sont consolidées par l’interface de commission, puis un export au format JSON est généré pour alimenter le site public.

On obtient donc une chaîne complète : dépôt → évaluation → consolidation → décision → export → publication. Avec un avantage important : les différentes étapes travaillent toujours à partir des mêmes données. Ce qui nous intéresse ici n’est pas seulement l’automatisation de quelques tâches. C’est la capacité à faire circuler les données dans tout le workflow sans avoir à construire et maintenir une succession de bases, d’exports et d’interfaces intermédiaires.

Grist fournit le socle, tandis que le développement sur mesure porte sur l’expérience et les règles métier. Le principe est simple : le module s’annonce d’abord auprès de Grist et précise les droits dont il a besoin. Les modules personnalisés communiquent directement avec Grist via sa son API dédiée (grist-plugin-api). Ils peuvent ensuite lire les données d’une table puis créer ou modifier des enregistrements lorsque l’utilisateur agit dans l’interface.

Grist, un socle flexible pour prototyper

Grist permet de prototyper très rapidement une interface ou un workflow, mais tous les besoins n’ont pas vocation à rester entièrement dans l’outil.

Pour les applications qui doivent durer, nous pouvons par exemple héberger les modules personnalisés comme des applications web indépendantes, afin de retrouver les pratiques classiques du développement logiciel : versionnement, gestion des dépendances et déploiement maîtrisé.

La même logique vaut pour la structuration des données. Dans notre cas d’usage, stocker chaque critère d’évaluation sur une ligne aurait généré plusieurs milliers d’enregistrements. Nous avons donc choisi de regrouper les réponses d’une évaluation dans une donnée structurée au format JSON, interprétée par le module personnalisé. Nous choisissons la structure la plus adaptée au volume, aux usages et aux contraintes du projet plutôt que de complexifier l’infrastructure par défaut.

L’enjeu n’est donc pas de tout faire dans Grist, mais de l’utiliser comme un socle flexible, en adaptant l’architecture et le stockage aux contraintes réelles du projet.

Une même architecture pour des besoins très différents

Cette approche modulaire ne se limite pas aux outils de notation. Nous l’avons également utilisée dans le cadre de l’accompagnement du gouvernement grec dans le cadre de l’Open Data Maturity Assessment.

Cette fois, le point de départ était très différent : un fichier Excel de la Commission européenne particulièrement complexe à manipuler. Il contient les réponses de plusieurs pays européens, dont la Grèce et la France, quant à leur degré de maturité en termes d’Open Data.

Aperçu de l'Excel d'évaluation
Aperçu de l'application Grist pour la Grèce

Nous l’avons transformé en un véritable espace de travail collaboratif permettant de présenter chaque question de manière lisible, de rétablir les correspondances entre les questionnaires 2025 et 2026, et d’afficher les réponses grecques et françaises côte à côte afin de faciliter leur comparaison et leur complétion. Les sources restent tracées et plusieurs personnes peuvent travailler ensemble sur le même support.

Le cas d’usage change, mais le principe reste le même : des données structurées dans Grist, sur lesquelles nous construisons une interface adaptée au travail réel des utilisateurs.

Pourquoi cette approche nous intéresse : automatiser sans nécessairement construire une usine

Ces projets illustrent finalement une autre manière d’aborder l’automatisation. Développer une application métier sur mesure implique habituellement de mettre en place plusieurs briques dès le départ : une base de données, une authentification, une gestion des permissions, du stockage documentaire, une interface d’administration, parfois une API.

Grist prend déjà en charge une bonne partie de ce socle. Nous pouvons alors concentrer le temps de conception et de développement sur ce qui différencie réellement l’outil : les workflows, les règles métier, l’ergonomie ou les interfaces spécialisées. Grist apporte de son côté l’authentification, le stockage, les données structurées et l’accès depuis un simple navigateur. Il permet également de conserver un historique des actions et des sauvegardes automatiques fiables et régulières.

C’est probablement là que réside le principal intérêt de l’outil pour nous. Il permet de tester rapidement un fonctionnement, de l’adapter aux retours des utilisateurs et, lorsque le besoin le justifie, de faire progressivement évoluer le tableur vers une véritable application métier.

Et c’est là que se situe notre savoir-faire : identifier les cas où cette architecture est pertinente, modéliser les données, construire les interfaces métier nécessaires et connecter l’ensemble aux autres composants du système d’information. Autrement dit, ne pas simplement « faire un Grist », mais concevoir une application métier légère autour de Grist, lorsqu’il s’agit du bon outil pour le problème à résoudre.

Rétrospective : les bonnes pratiques d’un produit data partagées auprès de la communauté de Numérique en Commun(s)

18 décembre 2023 à 17:16

Rétrospective de Mathilde Bras, avec les contributions de Cécile Le Guen, Augustin Courtier et Quentin Leroy

Les 19 et 20 octobre 2023, la communauté du numérique d’intérêt général s’est retrouvée à Bordeaux pour sa – désormais traditionnelle – grande réunion : Numérique en Commun(s). Cette année, 5 axes thématiques ont ponctué la programmation : données & territoires, écologie & soutenabilité, éthique & émancipation, communs & souveraineté, médiation & compétences numériques.

L’occasion pour Numéricité, partenaire de l’événement, de proposer plusieurs formats de partage d’expérience et de bonnes pratiques autour de défis qui nous tiennent à coeur : l’acculturation par le produit d’équipes ou d’organisations qui souhaitent se transformer, et la mobilisation du droit, en particulier du RGPD, comme un levier d’accélération des services publics numériques.

Dans cet article rétrospective, Mathilde Bras, Strategy & Innovation Manager chez Numéricité, revient sur les principaux enseignements partagés lors de l’atelier “Meilleures pratiques pour un projet data avec et pour des utilisateurs non tech”, et consolide 5 principes d’action pour des projets et produits data.

 

Entreprendre un projet data, un défi pour des profils techniques et non techniques

J’accompagne et entreprends de multiples projets autour de la donnée, depuis la conception de feuilles de route data jusqu’au développement de services d’exploitation de données métiers. Très souvent, je me retrouve dans une situation où les acteurs du projet ont besoin de parler le même langage, tout en mobilisant leurs propres expertises.

Mon rôle de coach est justement de traduire “le langage” des décideurs, faire remonter les besoins des utilisateurs auprès des équipes produit, être médiatrice des besoins opérationnels, et aussi de faciliter l’identification collective de points de passage. Cela se traduit concrètement par la définition des premières orientations du produit, l’identification des parties prenantes à associer, mais aussi la manière de mobiliser les utilisateurs, le mode de communication sur le produit, les risques potentiels, les compétences à mobiliser, etc.

Pour Numérique en Communs, j’ai donc proposé un exercice ouvert d’introspection à plusieurs porteurs d’initiatives liées à la valorisation des données publiques, qu’elles soient partagées en open data ou entre administrations :

En racontant nos expériences aux participants de l’atelier, nous avons pu partager des défis communs lorsqu’il s’agit de construire des produits qui se fondent sur l’exploitation de données. Leur similitude : à chaque étape, il est important de transformer des idées reçues en opportunités pour faire avancer son projet. Quelques exemples partagés pendant l’échange (nous avons partagé des exemples fictifs, mais inspirés de la réalité) :

  • “J’ai besoin de 5 data-scientists pour réaliser le projet, rien d’autre” : en réalité, un projet data nécessite de s’intéresser à une pluralité de profils, tech et non tech. Une personne spécialisée en droit du numérique peut vous être utile, tout comme des compétences capables de traduire le besoin du métier en parcours (les UX designers)
  • “Je sais déjà ce que je souhaite développer, pas besoin de s’adresser aux futurs utilisateurs” : en réalité, en vous adressant aux utilisateurs, vous allez pouvoir considérer l’usage des données comme un intrant pour sa structuration et sa mise en qualité. Dans le cas d’un produit data, il peut s’agir des producteurs de données, des réutilisateurs (techniques et métiers), et de décideurs (dans le cas d’un tableau de bord par exemple)
  • “Le droit ne nous permet pas d’exploiter ces données, on ne peut les intégrer au prototype, il faut attendre la mise en production et l’homologation” : le fait de se poser des questions juridiques dès le démarrage du projet peut aussi être un levier pour transformer la gouvernance d’un projet, d’une politique publique ou d’une base de données
  • “Commandons un logiciel sur étagère, ce sera plus simple dans la durée” : considérer la force de l’open-source est la clef. Il existe aujourd’hui des librairies très riches en matière d’exploitation et de transformation de données, tout comme d’applications de cartographie ou visualisation
  • “Apprendre à des personnes non spécialisées en données à les réutiliser ne sert à rien” : bien au contraire, cela peut constituer un réel outil d’acculturation sur la manière dont les données sont produites, leur utilité pour prendre des décisions et se représenter le réel, et ainsi créer de l’engagement autour des politiques publiques qu’elles suivent

Photo de l'atelier organisé dans le cadre de NEC2023, à Bordeaux le 19 octobre 2023
Photo de l'atelier organisé dans le cadre de NEC2023, à Bordeaux le 19 octobre 2023

Quelques principes d’action pour développer des produits data avec et pour des utilisateurs non spécialistes de la donnée

Forts de ces témoignages et des questions posées par les participations de l’atelier NEC, nous avons consolidé quelques principes d’action pour guider des personnes travaillant actuellement ou prochainement sur des projets ou produits data, qu’elles aient des compétences “techniques” en données ou non.

Notre livrable pour la communauté Numérique en Communs – 5 principes d’action de projet data en commun(s) :

  • Opérer une médiation constante entre les utilisateurs et les données (et le produit) : avoir accès à une base de données n’est pas l’objectif, c’est seulement un éventuel moyen pour répondre à des besoins “métiers” ou “usagers”. Une ou un responsable de produit data a la mission de garder en tête cette perspective, pour éviter par exemple que le service développé soit uniquement compréhensible – et donc utilisable – par les personnes qui connaissent la donnée par coeur. Concrètement, cela implique de s’intéresser autant à l’utilisation – donc la valeur de la donnée – qu’à sa qualité ;
  • Travailler la gouvernance – technique et organisationnelle – tout au long du projet/produit : lors de la conception, échanger avec les personnes qui produisent, reçoivent, transmettent ou transforment la donnée, non seulement pour les inclure – et mobiliser leur expertise ! – dans les différents temps forts du projet, mais aussi pour identifier les enjeux liés à la qualité de la donnée, qui est la clef de tout projet data. Concrètement, pour le projet PILOTE, cela impliquait de se poser la question du cycle de vie des données : est-ce que je dispose de données ou le projet consiste à aller en chercher ? qui les produit ? qui est responsable des mises à jour, du stockage ? ces données doivent-elles respecter des standards de qualité ? sont-elles sensibles au sens du RGPD ?
  • S’appuyer sur les forces de l’open source – et des communs – pour construire des projets data : les standards publics sont pour cela très inspirants. Tout service public numérique doit rendre son code ouvert (”public money, public code”, vivent les communs !). Au-delà du code produit, aller chercher des briques techniques dans l’état de l’art pour développer de services est souvent gage de qualité. Celles en vogue en ce moment sur les données : VueJS (développement d’applications), Apache Superset (datavisualisation), la suite ELK (import de données, requête, analyse et visualisation), Kubernetess (infrastructure de conteneurisation), Keycloack (identité et gestion des accès). Cela implique bien sûr de réaliser de la veille régulière sur ces briques, leurs mises à jour, et de s’appuyer sur la communauté de contributeurs ! Et on ne peut s’empêcher de citer Onyxia, un environnement de travail à l’état de l’art pour la data, open source et propulsé par les équipes de l’Insee, dont les cas d’usage ne font que se multiplier (voir nos travaux sur le projet DATAFID)
  • Considérer le droit comme une opportunité d’innovation et d’accélération : aujourd’hui de nombreux standards doivent s’appliquer aux services numériques développés par des acteurs publics et des questions de droit (qui vont au-delà des sujets techniques) peuvent se poser tout au long du projet, et même si cela demande du travail, c’est une opportunité ! Lors d’un projet data, on peut se rendre compte que certains textes doivent être harmonisés, ou proposer une nouvelle mouture d’une disposition juridique. Et surtout, on peut aussi imaginer des facilités de prototypage même si notre produit n’a pas été homologué : un exemple concret tout récent, la génération de données “fictives”, qui respecte le schéma des données “réelles”, afin de tester une première version d’application, avant la mise en production (en savoir plus avec le projet CM2D ici)
  • Dépasser les frontières de la documentation (technique) pour en faire une plateforme pour la communauté : si vous avez déjà travaillé dans des équipes produits, vous avez déjà dû entendre râler autour de vous lorsqu’il s’est agi de documenter une application ou un service. En réalité, documenter un produit peut en faciliter son adoption, inspirer des utilisateurs sur des usages possibles et permettre le déploiement à grande échelle. Concrètement, comme nous l’a raconté Quentin pour ChartsGouv, cela implique – bien sûr – de publier le code, les informations d’installation (comme un mode d’emploi) et d’aller plus loin en répertoriant des cas d’usages et en réunissant régulièrement la communauté. Dans le cas de l’Open Data University, c’est plus que de la documentation, c’est un plaidoyer sur la vertu pédagogique de l’open data enseigné au sein de multiples formations : qui engagent les étudiantes et étudiants à s’intéresser non seulement aux données publiques, mais aussi au secteur public en général !

Ces principes ne sont pas exhaustifs, nous espérons qu’ils pourront guider le plus grand nombre ! N’hésitez pas à nous faire part de vos retours d’expérience par mail : communication@numericite.eu !

❌
❌