Que lit et que crée l'observatoire dans ma base ?
En une phrase
Il lit vos observations, vos zonages et la taxonomie pour préparer ses chiffres. Il range ce qu'il prépare dans ses propres tables, à part, ajoute quelques index, et ne modifie aucune observation.
MontrerCe que l'observatoire litLe schémaVotre base en trois couleurs
Comment ça marche
Ce qu’il lit. Quatre familles de tables de GeoNature : les observations de la synthèse et leurs rattachements aux zones, le référentiel géographique, TaxRef avec les statuts (listes rouges, protections), et quelques nomenclatures, comme la sensibilité ou le statut de validation.
Qui lit, et quand. Seule la fabrication lit les observations, quand elle prépare ce qui peut être montré : à chaque mise à jour, au rythme convenu avec vous, la nuit. L’application, celle que consultent vos visiteurs, ne lit que ce qui a été préparé, le référentiel géographique et TaxRef. Aucun de ses fichiers ne nomme la table des observations : un test automatique échoue s’il la nomme.
Ce qu’il crée. Ses propres schémas, à part : ce qui peut être montré de chaque observation, les vues précalculées, les rattachements aux zones qu’il calcule lui-même, et ses tables de réglage. Lui seul y écrit.
Des index, aucun sur la synthèse. Il ajoute des index sur le référentiel géographique et sur les statuts de TaxRef. Ils se créent sans bloquer la base : lectures et écritures continuent pendant la création.
Ce qu’il ne touche jamais. Il n’écrit dans aucune table de GeoNature et ne modifie aucune observation. Seule exception, ses outils d’import, qui remplissent une base neuve pour une source extérieure, jamais la base d’un producteur.
Deux comptes, prévus. Un compte de fabrication lit les observations et prépare. Un compte application ne lit que ce qui est préparé. Aujourd’hui, les observatoires en service tournent encore sur un seul compte. L’application ne lit jamais la synthèse, des tests le garantissent. Le retrait du droit lui-même est prévu avant la première installation par un tiers.
Le mode recommandé reste une copie de votre synthèse, ou une base dédiée : votre base de production n’est alors pas lue du tout.
Pour votre informaticien
- Lu par la fabrication :
gn_synthese,ref_geo,taxonomie,ref_nomenclatures(parcd_nomenclature). Écrit : les schémasweb(oumdv),diffusion,sensi,zonage. - Index par
CREATE INDEX CONCURRENTLY IF NOT EXISTSsurref_geo.l_areasettaxonomie.bdc_statut_taxons, aucun surgn_synthese. Un index interrompu reste en base, invalide, sans que le script échoue : relisez sa sortie. - Compte application : aucun
USAGEsurgn_synthese,sensi,ref_nomenclatures, ni superutilisateur ni droit de création. Contrôle sous ce compte :SELECT has_schema_privilege(current_user, 'gn_synthese', 'USAGE')(falseattendu), et le champbarriere_sourcede/api/health/. - Docs à paraître.
Ce que l’observatoire ne fait pas (encore)
- Le compte application n’est pas encore en service sur les observatoires actuels : le retrait du droit est prévu avant la première installation par un tiers.
- Il ne bloque pas un compte unique qui peut lire les observations : il avertit seulement, sur sa page de santé et dans l’écran Sécurité de l’administration.
- Il ne crée pas le compte application à votre place : il faut un superutilisateur PostgreSQL. Le compte séparé est recommandé, pas imposé.
- Il ne protège pas les autres logiciels qui se connectent à votre base.
- Sur une base alimentée hors GeoNature, la protection des observations par le compte n’existe pas encore.
La suite : Va-t-il ralentir ma base ?
Vérifié le 29 octobre 2026.