Lier 2 pages avec remplissage automatique

al1g · Février 25, 2026, 9:25

Bonjour,

Je reprécise ma demande pour qu’elle soit plus claire :

Existe-t-il une méthode que lie 2 tables, mais surtout qui permette de remplir la 2ᵉ table avec toutes les informations de la 1ʳᵉ dès qu’une valeur particulière est saisie dans la 1ʳᵉ ?

merci pour toute aide.

Marc.as · Mai 29, 2026, 10:02

Bonjour,

Votre sujet est un peu ancien et je vois que personne n’y a répondu mais avez-vous trouvé une solution par vous-même .

Je cherche une Solution à ce problème avec une première table qui est alimentée par réponse à un formulaire, et une 2e table qui devrait se remplir automatiquement dès qu’une nouvelle réponse arrive dans la première.

Merci pour votre retour

Cordialement

al1g · Juin 3, 2026, 8:51

Bonjour,

malheureusement, je n’ai aucune solution pratique.
Pour le moment j’utilise des vues avec filtrage

Bon courage

grr · Juin 3, 2026, 10:27

Bonjour,

Pourriez-vous préciser un peu le scénario ? S’agit-il de remplir une ligne dans la seconde table à partir des informations d’une nouvelle ligne dans la première ? Quels types d’information ? etc.

À défaut de précision, je ne peux que vous renvoyer vers la fonction lookupOrAddDerived(.) dont il existe 2 exemples qui me semblent proches de votre besoin, consultables ici et là.

al1g · Juin 10, 2026, 3:42

Bonjour,

merci pour le retour et désolé pour le délai de réponse, je pratique GRIST en plus de tout le reste…
Pour préciser le scénario : j’ai une base élève de l’année 2025-26 avec une série d’informations par élève et j’aimerais que ces infos basculent dans une base 2026-27 dès que la nouvelle classe d’affectation est saisie

J’ai tenté lookupOrAddDerived() mais n’étant pas expert, je ne parviens pas à grand chose.

En espérant avoir été plus clair sur mes intentions cette fois-ci

vincent.blain · Juin 12, 2026, 12:46

Bonjour @al1g,

Quand vous parler de lier plusieurs tables, je crois comprendre que vous voulez consolider un jeu de données à partir de plusieurs tables dans Grist.

Peut être que ces deux solutions vous aiderons.

Le déploiement d’un processus ETL branché sur un webhook Grist.
L’idée est que le webhook de Grist envoi à un serveur intermédiaire un évenement, qui envoi l’ordre à l’ETL de jouer son scénario (pipeline) pour par exemple faire une jointure entre plusieurs tables Grist, faire une union des lignes, filtrer, trier, calculer des indicateurs, des agrégats…

L’avantage de cette solution c’est la méthode par évènement… plus propre que CRON qui tourne à intervalle régulier, et moins contraignant qu’une exécution manuelle. L’inconvénient c’est la complexité de mise en œuvre, et l’ajout d’une dépendance avec un outil tiers à Grist (comme Achache HOP, n8n, Talend, Pentaho)
Un custom widget
Une autre solution, directement intégré dans Grist, serait d’utiliser un custom widget responsable de la consolidation de votre jeux de données depuis plusieurs tables sources via exécution du processus par un simple bouton.

image1619×157 11.8 KB

L’inconvénient majeur, dans cette méthode, c’est que l’utilisateur doit lancer la consolidation du jeux de données à la main. L’avantage ? Tout est intégré dans Grist, et réside dans du code JavaScript.

++

Enro · Juin 13, 2026, 5:01

Bonjour, il existe une variante de la deuxième solution :

2.5. Un widget bouton d’action

Le bouton d’action est un widget personnalisé proposé dans l’instance DINUM de Grist (et sans doute dans d’autres instances) qui permet de copier, après un clic sur ledit bouton, des données d’une table vers l’autre en ajoutant toutes les conditions souhaitées. Je vous renvoie vers cette documentation complète :

D’ailleurs @vincent.blain, quel est ce custom widget que tu montres dans ta capture d’écran ? Est-ce que tu peux nous en dire plus ?

al1g · Juin 13, 2026, 7:57

Merci @vincent.blain pour votre retour,
je vais me limiter, vu mes compétences, à quelques choses d’interne à Grist.
Et merci à @Enro, je vais tâcher de trouver du temps pour me pencher sur le bouton d’action

La suite au prochain épisode

vincent.blain · Juin 15, 2026, 2:17

Bien sur !

L’idée de départ, c’était de fusionner plusieurs tables indicateurs (DATA_INDICATEUR_1, DATA_INDICATEUR_2 …) avec la même structure dans une unique table cible DATA_CONSOLIDATION via une application custom widget (simple bouton).

Table « INDICATEURS »

Prenons l’exemple suivant où les tables indicateurs DATA_INDICATEUR_x, sont composées de 5 champs suivants :

Champ	Type de données	Description
`ANNEE`	Numérique	L’année concernée par l’indicateur (ex: `2026`).
`MOIS`	Numérique	Le mois concernée par l’indicateur (ex: `06` pour juin).
`STRUCTURE`	Référence (`STRUCTURES`)	Un lien (clé étrangère) vers une autre table nommée `STRUCTURES`. Cela permet d’associer la ligne de données à une entité spécifique.
`STRUCTURE_CODE`	Formule (Texte)	Exemple de champ calculé automatiquement (jointure). Il va chercher et afficher le code de la structure lié via le champ `STRUCTURE`
`VALEUR`	Numérique	La valeur de l’indicateur

Table cible consolidée

La table cible a la structure suivante :

Nom du champ	Type de données	Description / Rôle
`ANNEE`	Numérique	L’année de la donnée consolidée (ex: `2026`).
`MOIS`	Texte	Le mois de la donnée. Note : Contrairement à la table de saisie initiale où le mois était numérique (`6`), ici il est stocké en Texte, ce qui permet d’écrire le mois en toutes lettres (ex: `"Juin"`) ou sous un format textuel spécifique pour faciliter les tris ou l’affichage.
`INDICATEUR`	Référence (`SYSTEM_INDICATEURS`)	Clé de liaison. Référence la table des indicateurs. Cela permet de savoir précisément de quel indicateur il s’agit (et de récupérer son libellé, son ordre, etc.) sans dupliquer l’information.
`STRUCTURE`	Référence (`STRUCTURES`)	Clé de liaison. Référence la table des structures pour attribuer la valeur à une entité précise (un service, une filiale, une région).
`STRUCTURE_CODE`	Formule (Texte)	Champ calculé automatiquement. Il affiche directement le code technique de la structure (ex: `STR_IDF`) en allant le chercher dans la table `STRUCTURES` liée.
`VALEUR`	Numérique	Le résultat chiffré final (calculé, agrégé ou copié) de l’indicateur pour ce mois, cette année et cette structure.

Conception de l’outil de consolidation

Table référentiel des indicateurs `SYSTEM_INDICATEURS`

Cette table joue le rôle de table de référence (ou référentiel). Son objectif principal est de centraliser la configuration des indicateurs afin de rendre l’application dynamique et évolutive, évitant ainsi de figer (« coder en dur ») la liste des indicateurs dans le code.

Elle permet de piloter le comportement de l’application. En y ajoutant, modifiant ou supprimant une ligne, on met à jour la liste des indicateurs disponibles, leur nom, l’endroit où récupérer leurs données, et leur positionnement dans les rapports ou les menus, le tout sans toucher à la structure technique du système.

Champ	Type	Description / Rôle
`CODE`	Texte	L’identifiant unique et technique de l’indicateur (ex: `IND_001`). Il sert de clé pour l’application.
`LIBELLE`	Texte	Le nom clair et compréhensible de l’indicateur qui sera affiché à l’écran pour les utilisateurs (ex: « Chiffre d’affaires mensuel »).
`TABLE_SOURCE`	Texte	Le pointeur technique. Il indique le nom de la table source dans Grist associé à l’indicateur (comme `DATA_INDICATEUR_1` vue précédemment) où l’application doit aller chercher les valeurs pour cet indicateur.
`ORDRE`	Numérique	Le tri d’affichage. Un nombre (ex: `1`, `2`, `3`) qui permet de contrôler précisément l’ordre dans lequel les indicateurs apparaissent dans les listes, les tableaux de bord ou les exports, indépendamment de leur ordre de création.

Table configuration `SYSTEM_VARIABLES`

La table SYSTEM_VARIABLES fonctionne comme un dictionnaire de type Clé / Valeur (Key-Value store). Elle sert à centraliser toutes les configuration globales. Tout comme la table précédente (SYSTEM_INDICATEURS), il s’agit d’une table de référence et de configuration, mais orientée cette fois-ci vers les paramètres globaux. Plutôt que d’écrire des valeurs fixes dans vos formules de calcul (hard-coding), vous stockez ces valeurs ici. Si un paramètre change, il suffit de le modifier dans cette table pour le mettre à jour.

Dans le processus ici, on utilise

la variable CONFIG::DASHBOARD::YEARS pour définir les années
la variable CONFIG::TOOL::CONSOLIDATION::DEBUG pour activer/désactiver les informations de debug dans l’IHM de l’outil de consolidation.

Custom widget pour la consolidation

Voila le code complet =>

gist.github.com

https://gist.github.com/v20100v/c98dc4bb42940bc68cdaf4e67d8529cd

grist-widget-consolidate-datas.html

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <title>Consolidation Data</title>
    <script src="https://docs.getgrist.com/grist-plugin-api.js"></script>
    <style>
        body {
            font-family: 'Marianne', arial, sans-serif;
            margin: 0;

Ce fichier a été tronqué. afficher l'original

Si besoin, je peux expliquer plus en détail, comment s’organise la consolidation dans le code (si les commentaires ne suffisent pas).

Et pour tester l’outil

++

vincent.blain · Juin 15, 2026, 3:43

En bonus, si vous voulez récupérer l’intégralité du jeu de données au format JSON, vous pouvez ajouter une nouvelle table avec la formule Python suivante :

import json

# Configuration directe des sources (Code: Table)
SOURCES = {
    "IND_001": DATA_INDICATEUR_1,
    "IND_002": DATA_INDICATEUR_2,
    "IND_003": DATA_INDICATEUR_3
}

def main():
    dataset = []

    for code, table in SOURCES.items():
        for r in table.all:
            # Validation stricte en une seule condition
            if r.STRUCTURE and r.STRUCTURE.CODE and r.ANNEE and r.MOIS and r.VALEUR is not None:
                dataset.append({
                    "year": int(r.ANNEE),
                    "month": r.MOIS,
                    "structure": str(r.STRUCTURE.CODE),
                    "indicator": code,
                    "value": r.VALEUR
                })

    return json.dumps(dataset, ensure_ascii=False, indent=2)

return main()

Il est possible d’ajouter des colonnes supplémentaires dans cette table (ex: ANNEE, MOIS, INDICATEUR) pour construire plusieurs JSON filtrés.

L’avantage les données sont rafraichies automatiquement
Le format brut JSON n’est pas lisible, et nécessite d’être consommer pour être afficher
L’inconvénients pas sur que ca fonctionne avec des jeux de données important, du point de vue de la charge/performance.

Lier 2 pages avec remplissage automatique

Table « INDICATEURS »

Table cible consolidée

Conception de l’outil de consolidation

Table référentiel des indicateurs SYSTEM_INDICATEURS

Table configuration SYSTEM_VARIABLES

Custom widget pour la consolidation

Et pour tester l’outil

Table référentiel des indicateurs `SYSTEM_INDICATEURS`

Table configuration `SYSTEM_VARIABLES`