Validation des modifications / suppressions des ZH

[CGuillaume]

Bonjour à tous,

Au CEN Haute-Savoie nous avons migré l’inventaire ZH du département dans le module GeoNature.

Aujourd’hui après une présentation de l’outil à la DDT qui nous délègue la gestion de cet inventaire la question se pose d’ouvrir l’outil pour d’autres structures, notamment les Gémapiens. Ce sont majoritairement eux qui travaillent localement à la mise à jour de cet inventaire avec l’aide de bureaux d’études. Le CEN de son côté joue un rôle de « validation » avant de présenter l’inventaire à la DDT qui le diffuse.

A l’heure actuelle l’outil ne nous propose pas assez de sécurité (de notre point de vue) pour cette ouverture puisque qui dit : mis à jour de l’inventaire, dit : avoir les droits de modification et de suppression des objets qui ne nous appartiennent pas forcément.

Après une discussion avec Camille voici où en sont nos réflexions pour imaginer des développements qui répondraient au besoin :

L’idée ne serait pas de développer un module de validation supplémentaire mais d’ajouter quelques détails à l’existant.

• Mise en place de l’historisation des modifications pour le module ZH. Ce qui permettrait d’avoir un « filet » et éventuellement de faire des états à différentes périodes de l’inventaire.
• Ajout d’un champs « statut/validation » soit avec les nomenclatures SINP (Certain, Probable, Douteux, etc.) soit un booléen relue/non relue qui permet de dire "ok cette fiche est relue on considère qu’elle a sa place dans l’inventaire". Ce champ peut aussi permettre de stocker la valeur « détruite » lors de la destruction des ZH.
• Adaptation de la gestion des droits : Comme déjà dit pour faire une màj de l’inventaire on doit avoir les droits sur toutes les données. La variation du droit serait la valeur du champs « statut/validation »
• Un petit trigger qui change automatiquement le statut si une modification est faite en attendant la relecture par une personne ayant les droits.
• Un éventuel système de notification pour signaler les changements.

J’espère avoir était clair sur les besoins et par ce message j’aimerais bien recueillir vos avis et remarques avant de rédiger un cahier des charges pour ces développements.

Merci d’avance.

PS : Un grand merci à toute l’équipe pour les dernières mises à jour de ce super outil !

[camillemonchicourt]

Je pense que cette solution de relecture est en effet préférable à une logique plus lourde de validation.

Par contre une fois qu'une fiche a le statut de relue, je ne pense pas qu'il faille la depublier. En effet cela va entraîner des objets diffusés, puis non diffusés, puis diffusés à nouveau, etc... C'est pas très bon pour les outils de diffusion publique qu'un objet apparaisse puis disparaisse puis réapparaisse, etc.. Idem pour les outils d'imports qui vont devoir supprimer l'objet puis le recréer puis le supprimer à nouveau, etc...

Je pencherai plus pour un système de notification quand un objet est modifié ou supprimé pour rapidement aller vérifier à nouveau les modifications.

[camillemonchicourt]

Voici ma compréhension du contexte, du besoin et quelques interrogations et points de vigilance :

Le besoin central que j'ai compris est :

• Un CEN créé une ZH en 2019 et la valide. Elle est alors diffusée (aux partenaires, dans l'atlas...)
• En 2021 il paie un bureau d'étude pour aller faire un diagnostic et compléter/modifier les infos sur la ZH.
• Le CEN veut que le BE puisse modifier directement sur cette ZH mais que les modifications soient validées avant diffusion

Donc la demande est que si une ZH est modifiée, alors ça modifie le statut de validation de la ZH pour que le CEN relise les modifications du BE et les valide. Comme déjà évoqué, ça me semble un peu bizarre et complexe. Et je trouve dommage qu'une ZH soit publiée, dépubliée, republiée... C'est pour ça que j'ai proposé qu'il y ait plutôt un statut de RELECTURE et des notifications quand une ZH est modifiée, sans publier/dépublier la ZH.

Mais bon, à voir/discuter ce qui est le plus pertinent. C'est assez spécifique il me semble de dévalider une ZH dès que quelqu'un la modifie. Donc là aussi il faut bien réfléchir, car je pense pas que d'autres voudraient qu'à chaque modification d'une ZH ça modifie automatiquement son statut de validation...

---

Ensuite, ayant peur qu'un BE modifie une ZH et fasse des modifications non souhaitables, il est souhaité avoir un système d'historique pour pouvoir revenir au contenu avant modification par le BE, pouvoir consulter les modifications apportées par le BE, etc... Là aussi je pense que ça peut être très complexe pour pas grand chose. Pour faire simple, on pourrait simplement utiliser le mécanisme d'historisation JSON générique et global de GN, comme ça si un BE a trop modifié une ZH, on peut toujours retrouver son contenu avant modification, dans la table d'historisation. Ça sera peu utilisé, mais ça fait un filet.

[B1234j]

Bonjour à tous.

D’avance désolé pour mon message un peu long mais ce sujet de la validation des données est bien complexe et difficile d’apporter ici une réponse (que je n’ai pas 😊). Nous sommes aussi en pleine réflexion sur le sujet avec nos partenaires régionaux (DREAL / AE / OFB / CEN).

Tout d’abord, qu’entend-on ici par validation ? S’agit-il d’une validation de fond (est-ce de la ZH ou pas ?) ou de forme ? (la donnée a-t-elle été correctement saisie ? : topologie des objets, champs descriptifs bien renseignés, etc…).

Sur le « fond » (ZH ou pas ZH ou ZH potentielle), Il y a une grande hétérogénéité d’un territoire à l’autre dans la méthodologie des inventaires. Cela est dû, entre autres, à l’historique de ces inventaires (avant ou après l’arrêté du 24 juin 2008), à l’évolution de la prise en compte des critères du couple « sols – végétation » (d’abord « ET/OU », puis uniquement « ET », puis retour à « ET/OU » …), la méthodologie de saisie (référentiel carto utilisé, échelle numérique de saisie), la prise en compte ou non des cours d’eau et la manière dont ils ont été pris en compte (relevé de terrain ? ou simple saisie carto ?), la prise en compte ou non des ZH < 0.1 ha (seuil d’application loi sur l’eau), …etc. Du coup, sur cette question de la validation de fond, attention de ne pas tomber dans le travers des services de l’Etat qui a tendance à vouloir prendre les inventaires pour ce qu’ils ne sont pas ! en vue d’une application réglementaire. De même, attention à l’implication que cela peut avoir quand il s’agit pour une commune de les intégrer dans son PLU car, à ma connaissance, aucun inventaire n’a été fait à l’échelle du cadastre ! 99% des IZH ont été réalisés à des fins de connaissance et de gestion et n’ont donc pas de portée réglementaire. Ils sont là uniquement pour alerter, entre autres, les communes ou les aménageurs de la présence d’une ZH à l’intérieur d’une enveloppe donnée. Ces IZH sont néanmoins bien à prendre en compte dans le cadre de l’instruction réglementaire des projets soumis à la Loi sur l'eau car elles alertent sur la présence probable d'une zone humide, ce qui conduit dans ce cas à la nécessité d'une étude plus fine de délimitation par le porteur de projet (via le guide national https://professionnels.ofb.fr/fr/node/80). Ce n’est qu’à l’issue de cette « contre-expertise » plus fine que le périmètre de la ZH à un « caractère » réglementaire. De même, une commune peut demander une contre-expertise avant intégration dans le PLU. Aussi, je pense que la base de données zone humide doit rester avant tout à vocation de connaissance et de gestion du fait de la méthodologie et échelles disparates des IZH. Néanmoins, des améliorations peuvent en effet être apportées pour répondre au besoin de distinguer une ZH de « connaissance » d’une ZH « réglementaire » au contour précis. Ça pourrait être pourquoi pas un champ de saisie selon la nomenclature SINP (Certain = pour ZH réglementaire, Probable = pour ZH de connaissance, Douteux = pour ZH potentielle ?). A voir … notamment voir si le référentiel SANDRE donne des pistes de solutions là-dessus. De même, le besoin d’identifier l’échelle de numérisation et référentiel de saisie pourrait être pris en compte par des champs supplémentaires.

Concernant la « validation de forme », il me semble que dans la majorité des cas le besoin pour un GEMAPIEN est de mettre à jour l’IZH « de connaissance » sur un vaste territoire (bassin versant ou EPCI ou commune) et que cela concerne alors plusieurs ZH (à actualiser ou créer). Dans ce cas de figure, nous avons proposé à nos partenaires régionaux une procédure d’import en lot (en cours de validation) qui permet de garantir une saisie « propre » et complète sur certains champs obligatoires de la base de données (une dizaine). Un cahier des charges est transmis au prestataire comprenant un projet QGIS « clé en main » + fichier métadonnée et d’aide à la saisie. Une fois le projet QGIS renseigné, il nous le renvoi et nous procédons à sa vérification puis à son import dans GeoNature ZH. A la suite de cela, nous lui transmettons un droit d’écriture pour compléter les fiches descriptives sous GeoNature. Une saisie / modification est toujours possible « à la ZH » via l’application. Il pourrait y avoir en effet un système de validation finale sur la bonne saisie (complétude) des infos sur des champs considérés comme indispensables pour les gestionnaires (ceux de la hiérarchisation par exemple). Je suis d’accord avec Camille sur le fait qu’il faut éviter de publier / dépublier / republier une donnée à chaque modif en attentant sa validation.

Pour l’historique des modifications, ça serait en effet super de pouvoir mettre en place cela mais ça risque d’être lourd en archivage. Là aussi nécessité de choisir des champs spécifiques ? ou toutes la BD (y compris l’objet géo si modifié) ? Par ailleurs, il serait peut-être utile de mettre en place un système de droit d’écriture rattaché à une zone géographique (bassin versant, Département, EPCI, commune). Ce dispositif existait dans la précédente application du SIT ZH et permettait à un auteur donné de ne pouvoir modifier / créer des ZH que sur une partie de territoire. A dispo pour échanger sur le sujet.

[cen-cgeier]

Bonjour à tous, Et merci pour ces échanges très intéressant.

Il ne me semble pas que le souhait ou le besoin soit dans l'action de publier/dépublier/republier/surpublier/... :) Pour préciser la situation qu'évoque @camillemonchicourt, la situation dans certains CEN (et peut-être d'autres structures) est la suivante:

• le CEN est missionné par la/les DDT(s) pour récupérer, intégrer, diffuser les différents inventaires ZH d'un territoire.
• Ces inventaires ou compléments d'inventaires sont réalisé par diverses structures (BE, CEN, ... ) à la demande des GEMAPIENS.

Pour simplifier la démarche de "récupérer, intégrer", l'idée portée par le CEN74 est d'ouvrir le module gn_ZH aux Gémapiens (ou peut-être à leurs prestataires) afin qu'ils puissent directement réalisé les compléments au sein de l'outil. Ceci allégerais peut-être la démarche et notamment les nombreuses heures récurrentes de restructuration des infos avant intégration des données. Pour répondre donc à la question de @B1234j, je pense que nous sommes +++ sur une validation de forme que sur une validation de fond.

Pour autant, il ne semble pas souhaitable de permettre la modification d'une connaissance au sein l'inventaire d'un territoire sans un process de "Vérification/Validation", sachant que toutes modifications sont irréversibles. Pour répondre donc à la question de @B1234j, je pense que nous sommes ++ sur une validation de forme que sur une validation de fond. Si l'historisation des modifications est quelque chose de très lourd, serait-il plus envisageable d'ajouter une table de proposition de modification ? (le nom de la table est bien sûr à revoir :) ) La table en question identifierait le schéma_cible,la table_cible, l'action_cible, la valeur_cible, la date_soumission, l'auteur. Un opérateur accepte ou non les modifications. Une fois la modification acceptée, celle-ci au sein de la table concernée et devient visible par tous au sein de gn_zh et zh_atlas. Lorsque la modification est acceptée ou refusée, une notification est envoyée à l'auteur de la proposition et celle-ci est supprimée de la table proposition de modification afin de l'allégée.

Je rejoins @B1234j sur la possibilité d'attribuer des droits à un ensemble de personne en fonction d'une zone géographique.

A dispo également pour échanger sur le sujet

[camillemonchicourt]

OK, merci pour ces retours et précisions.

• Mettre en place un système de proposition de modification serait plus complexe, plus coûteux qu'un système d'historisation uniquement niveau BDD, tout en alourdissant et complexifiant l'interface

• Pour l'historisation, nous avons imaginé 2 pistes :

  • s'appuyer sur l'historisation automatique et générique avec trigger dans la table transversale gn_commons.t_history_actions. Cela amène à stocker beaucoup d'infos en double à chaque création et modification d'une ZH, même si cela pourrait être optimisé et allégé en faisant évoluer les formulaires du module ZH en n'envoyant que les champs modifiés et non pas tout le contenu de l'onglet modifié. Et pour aller consulter ou récupérer un état antérieur d'une ZH suite à une modification, il faudrait faire ça directement dans la BDD
  • créer une table dédiée dans le schéma dédié aux ZH pour ne stocker que le champs et son contenu modifié, après avoir fait évoluer les formulaires pour ne poster que les champs modifiés et pas tout les champs de l'onglet modifié. Cela serait plus simple à retrouver et potentiellement plus léger à stocker. Mais on ne pourrait pas forcément retrouver le contenu avant modification
  • l'historisation étant un "filet" si un prestataire a modifié des choses par erreur, il ne nous semble pas souhaitable de mettre en place un système plus complexe où l'historique des modifications est consultable facilement dans le module, encore moins d'ajouter des fonctions en interface permettant de revenir à un état antérieur d'une ZH, avant modification, car cela serait complexe, coûteux et alourdirait l'interface
  • on peut aussi considérer que si c'est un "filet", on a déjà les sauvegardes automatiques et quotidiennes de la BDD et qu'on n'a pas besoin d'un autre système et de dupliquer encore les contenus

• Pour la validation/relecture, à voir si on aurait un champs "Validé (Oui/Non)" ou "Validation (Très probable, Probable, Douteux...)" ou "Validé" (OuiNon)

  • Vérifier la permission V sur le module pour vérifer si un utilisateur a accès à la validation des ZH
  • Dans ce cas ajouter un bouton de validation sur la fiche info des ZH
  • Éventuellement permettre aussi de faire de la validation en masse depuis la liste des ZH (comme on a dans le module Validation ?) pour ne pas avoir à le faire ZH par ZH ?
  • Stocker le statut de validation (ou relecture), ainsi que la date et le validateur
  • Si une ZH validée est modifiée, alors on l'invalide ? Un peu lourd si on modifie un petit truc, d'invalider à chaque fois ?
  • On pourrait seulement indiquer (et pouvoir filtrer facilement) les ZH qui ont été modifiées depuis la dernière validation, et notifier le créateur et le validateur quand une ZH validée a été modifiée