Pourquoi pas un module GeoNature ?
En une phrase
Par choix : une application à part, branchée d'abord sur GeoNature et ouverte à d'autres sources. En faire un module voudrait dire la réécrire dans les technologies de GeoNature et la faire vivre au rythme de ses versions.
Comment ça marche
Un choix, pas un manque. L’observatoire est une application à part. Il se branche d’abord sur GeoNature, et il reste ouvert aux autres sources. Les deux exemples de ce site en sont la preuve : leurs observations ne viennent pas d’une base GeoNature, mais de GBIF.
Ce qu’un module demanderait. Il faudrait réécrire l’observatoire dans les langages et les briques de GeoNature : l’interface, le serveur, les graphiques, la façon de garder les filtres. Il passerait par les comptes et les permissions de GeoNature, qui savent aussi ouvrir un accès public sans compte, et il faudrait transformer ses scripts de base de données en migrations de GeoNature. Il ne serait plus une application autonome : il s’installerait dans chaque GeoNature, et vivrait au rythme de ses versions.
Ce que ce choix permet. L’observatoire lit GeoNature et d’autres sources sous la même forme. Un seul langage sert à l’interface et au serveur. Le compromis est assumé : un serveur à part, livré dans un conteneur.
Ce qui est proposé à l’écosystème. Trois étapes. D’abord, être visible : l’observatoire est présenté à la communauté aux Rencontres GeoNature des 4 et 5 novembre 2026. Ensuite, publier la liste des tables et des colonnes de GeoNature qu’il lit (les observations, les zonages, la taxonomie, les nomenclatures), pour que l’équipe de GeoNature sache de quoi il dépend. GeoNature continuera d’évoluer, et certaines de ses versions demanderont d’adapter l’observatoire : ce suivi revient au projet, tant que d’autres ne contribuent pas à l’observatoire. Enfin, proposer de mettre en commun, entre tous les outils qui lisent la synthèse, les vues sur la synthèse et le calcul de la sensibilité. Cette dernière étape est une proposition à discuter, pas un accord.
Pour votre informaticien
- Un module demanderait de passer l’interface de Next.js et React à Angular, le serveur de Node et TypeScript à Python avec Flask et SQLAlchemy, et les graphiques Nivo à une bibliothèque utilisable en Angular.
- Il demanderait aussi l’état des filtres en services Angular, la connexion par les comptes et les permissions de GeoNature (UsersHub, qui permet aussi un accès public sans compte), et les scripts SQL en migrations Alembic.
- Le choix du langage : un seul pour l’interface et le serveur, et un rendu côté serveur pour les aperçus de liens.
- Les familles de tables lues :
gn_synthese,ref_geo,taxonomie,ref_nomenclatures. - Docs à paraître.
Ce que l’observatoire ne fait pas (encore)
- La liste publiée des tables et des colonnes de GeoNature qu’il lit n’existe pas encore.
- Aucune mise en commun de calcul n’est engagée avec l’écosystème : c’est une proposition.
La question voisine : En quoi est-ce différent de GeoNature-atlas ?
Vérifié le 30 octobre 2026.