Développements prioritaires envisagés

* ⇒ v2 : indique une fonctionnalité qui n'est pas indispensable et ne sera pas développé en priorité. Afin de privilégier une déploiement rapide d'une solution fonctionnelle. Nous pourrons reporter ces fonctionnalités dans une version ultérieure.

La rédaction du cahier des charges techniques s’est appuyée sur les ressources documentaires listées ci-dessous.

• Licence fermée SINP : dans le cadre de la diffusion des données sensibles.
• Licence ouverte SINP : licence concernant les données non sensibles.
• Formulaire d’accès aux données d’observation sur les espèces (SINP) : exemple de formulaire.
• La diffusion des données environnementales sensibles appliquéeau Parc national des Ecrins
• Groupe de travail "Données sensibles" du SINP
  • Guide technique sur les données sensibles (v1 d'avril 2014)
• Ginco - Floutage des données
• Diffusion des données par niveaux de restitution dans GINCO

Nous distinguons 4 types d'utilisateursdes futurs sitesdes SINP régionaux (SILENE et PIFH) :

• Grand public (citoyen) : utilisateurs dont l'accès aux données avec une faible précision de localisation est suffisant et recherchant plutôt un ensemble de données complémentaires sur le taxon (description, biologie, médias, etc.) ou sur un lieu particulier (commune) ;
• Professionnel non adhérent (décideurs publics, porteurs de projets, scientifiques, etc.) : utilisateurs recherchant des données précises pour un ensemble de taxons, de zones géographiques et/ou de niveau de sensibilité, le plus généralement dans le cadre d'un projet ou d'une étude précise ;
• Adhérent : Adhérent : membres des organismes adhérents aux chartes des SINP régionaux et souhaitant accéder aux données du SINP ;
• Administrateur permissions : administrateurs gérant les inscriptions, les demandes d'accès aux données géo-confidentielles des SINP régionaux ;
• Administrateur données : administrateurs qui assurent la gestion des données d’observation, avec les étapes successives de réception, standardisation, validation et centralisation ;
• Administrateur système : administrateurs qui assurent la gestion des serveurs hébergeant GeoNature par l'installation, la configuration et la mise à jour du système et des logiciels installés, la surveillance du fonctionnement et la gestion de la sécurité.

Pour satisfaire le besoin de l'ensemble des utilisateurs concernant les informations générales sur SILENE et PIFH, nous mettrons en place un système de gestion de contenu (CMS). Le CMS Wordpress permettra de diffuser des informations relatives à SILENE et au PIFH et à leur réseau. Il servira d'aiguillage vers les différents outils disponibles répondant aux besoins des différents types d'utilisateurs. Il offrira aussi la possibilité de diffuser des actualités ou d’accéder à différentes ressources en téléchargement. Par défaut, la charte graphique de ce CMS sera basée sur celle du site actuel silene.eu.

Les utilisateurs de type « grand public » accéderont aux observations restituées dans des mailles 5x5 km, et à la commune, à l'aide de GeoNature-Atlas. Il contiendra au départ peu d'informations complémentaires (photos, audios, descriptions, articles, etc.) mais pourra être enrichi progressivement au cours du temps. Cela sera l'occasion de publier des actualités qui permettront de dynamiser la communauté d'utilisateurs de SILENE.

Pour les utilisateurs « adhérent » ou « pro », c'est GeoNature et son module Synthèse qui fourniront l'accès aux données précises. Mais cet accès passera pour l'utilisateur par une démarche d'inscription, de demande de permissions et de validation par les « administrateurs ».

⇒ v2 : à moyen terme, il lui sera offert la possibilité d'accéder en consultation et modification aux données d'observation qu'il aura pu saisir via GeoNature - module OccTax. Les données saisies par cet outil seront par défaut non publiées tant qu'elles n'ont pas été validées. De même, toute modification d'une observation nécessitera de la valider à nouveau si un des champs principaux a été modifié (qui ? quoi ? quand ? où ?). Afin de simplifier la gestion des données ainsi collectées, il sera proposé de tester un processus de validation à l'aide de GeoNature - module Validation.

Dans GeoNature - module Synthèse l'utilisateur identifié pourra effectuer des recherches à l'aide de nombreux filtres permettant d'afficher, par défaut, au maximum les 50 000 observations les plus récentes correspondant aux critères sélectionnés. Ces observations pourront à tout moment être exportées dans 3 formats universels : GeoJson, CSV et Shapefile. En cas de besoin, le seuil du nombre de données affichables pourra être réévalué, après une série de tests d’ergonomie de l’affichage, afin de fournir aux utilisateurs l’information la plus pertinente possible.

Les « administrateurs » pourront gérer la validation des inscriptions dans UsersHub et les demandes de permissions d'accès dans GeoNature - module Admin. Le référentiel TaxRef sera administrable dans l'outil TaxHub.

Enfin, GeoNature - module Export leur permettra de prédéfinir des fichiers exportables publiquement ou non. Nous passerons par cet intermédiaire pour faire remonter les données au niveau national.

⇒ v2 : à terme ce module permettra l'accès aux données collectées via GeoNature - module OccTax.

Détail des processus et rôles du schéma d’organisation des outils :

⓵. Portail principal de présentation et d’orientation des utilisateurs vers les différents outils ;

• Publication d’actualités ;
• Téléchargement de ressources documentaires ;
• Liens vers des sites externes (portail documentaires des CBN, INPN, SINP national, etc.).

⓶. Visualisation des données à la maille et à la commune ;

• Consultation des monographies d’espèces.

⓷. Accès via identifiant et mot de passe ;

• Requêtage des données ;
• Visualisation des données (données validées uniquement) :
  • maille / commune / données précises selon les accès,
  • filtres géographiques selon les accès,
  • zonages et limites administratives,
  • données sensibles selon les accès (PIFH : signataires de la Charte et structures ayant une mission de police de l’environnement ; SILENE : droits à définir) ;
• Export des données (données validées uniquement) :
  • Données précises sur un territoire géographique et périmètre taxonomique défini,
  • Données sensibles selon les accès (PIFH : signataires de la Charte et structures ayant une mission de police de l’environnement ; SILENE : droits à définir).

⓸. Gestion de l’affichage des données ;

• Gestion des options de requêtage et d’export des données ;
• Gestion des accès aux données : floutage ou précision, filtres géographique, taxonomique,
• temporel et attributaire (organisme, etc.).

⓹. Administration : gestion des inscriptions, groupes, utilisateurs et organismes (création / modification / suppression).

⓺. Intégration du référentiel TaxRef et des taxons ;

• Ajout manuel de taxons.

⓻. Validation des données ;

• Mise au format SINP ;
• Standardisation : intégration et mise à jour des référentiels.

⓼. Contrôles de cohérence et de conformité ;

• Validation des données ;
• Accompagnement du réseau des acteurs.

⓽. Saisie de données des données sources - outil de saisie spécifique du PIFH.

⓾. Saisie de données sources - outil de saisie des producteurs et/ou fournisseurs de données, indépendant des SINP régionaux.

L'application GeoNature devant gérer une grande quantité d'observations (plus de 12 millions et plus de 7 millions pour le PIFH), il est envisagé de dédier un serveur à la base de données.

Afin de garder une possibilité d'évolution vis à vis de l'infrastructure, nous prendrons 2 serveurs virtuels. Cela nous permettra de bien répartir la charge entre la base de données et les interfaces web. Nous pourrons avoir une machine performante avec un grande mémoire vive pour la base de données et plus légère pour les interfaces web.

L'offre Public Cloud d'OVH permettant de répondre à ces besoins, nous avons prévu de prendre dans le même datacenter les éléments suivants :

• une instance de serveur dédiée aux interfaces (type B2-7): 2 vCores, 7 Go de mémoire vive.
• une instance de serveur dédiée à la base de données (type B2-15) : 4 vCores, 15 Go de mémoire vive.
• un réseau privé virtuel (vRack) : reliant les 2 instances
• un volume de stockage (Bloc Storage) haute performance de 100Go extensible et pouvant être connecté à l'instance de notre choix. Dans notre cas, ce volume hébergera les données de la base de données.

Au niveau du système d'exploitation, nous installerons la distribution conseillée pour GeoNature : Debian 10 (Buster).
Concernant la base de données, Postgresql sera installé en version 11 avec la dernière version de Postgis correspondante.

Concernant le PIFH, l’infrastructure des serveurs se basera sur celui réalisé pour le SINP PACA. En effet, il a été discuté un temps la possibilité de maintenir l'hébergement par l’Université Clermont Auvergne. Mais dans un souci de mutualisation des efforts, il a été décidé de réutiliser la même infra-structure pour les 2 SINP.

Les données présentes dans la base de données PostgreSQL seront stockées sur un volume de type Block Storage. Ce type de stockage voit les données qu’il contient distribuées dans trois réplicas sur des disques physiques distincts. De plus, les informations sont réparties dans des serveurs différents.

Après chaque mise à jour majeure, nous lancerons une sauvegarde de la base à l’aide de l’outil pg_dump. Le fichier de sauvegarde ainsi obtenu sera stocké hors serveur OVH sur un ou plusieurs espaces de stockage physiquement distants.

Par ailleurs, nous pourrons effectuer des snapshots du volume contenant les données. Cela nous permettra de restaurer intégralement l’état de la base de données tel qu’il était avant la mise à jour(en cas de problèmes). Ceci pourra être réalisé à tout instant à l’aide des interfaces web d’administration du Public Cloud mis à notre disposition.

Il nous sera aussi possible de réaliser des sauvegardes automatisées des instances (serveurs virtuels WEB et BDD). Une rotation de ces sauvegardes sur plusieurs jours avec suppression automatique de la plus ancienne pourra éventuellement être mise en place.

Les snapshots de volume et les sauvegardes d’instances sont aussi réalisées dans 3 réplicas.

Étant donnée qu'une partie des utilisateurs n'est pas connue par avance, GeoNature devra fournir un formulaire d'inscription accessible directement par tout nouveau utilisateur depuis la page d'accueil.

Lors de la première consultation de GeoNature par un utilisateur l'accès à ce formulaire sera proposé via un lien présent sur la page de demande d'identification. Cela ouvrira une fenêtre modale incluant le formulaire d'inscription décrit ci-dessous.

Cette inscription préalable permettra à l'utilisateur d'accéder aux différents modules de GeoNature en fonction permissions qui lui ont été affectées par défaut (accès aux données publiques et à ses propres données à leur précision maximale).

Au niveau du module Synthèse, cela permettra l'accès aux données publiques. Les données géo-confidentielles resteront floutées en fonction des paramètres du jeu de données et des permissions de l'utilisateur.

Si l'utilisateur souhaite accéder à des observations avec une géolocalisation précise auxquelles il n’a pas accès par défaut (jeux de données privées «floutés» et/ou des observations sensibles), il pourra effectuer une demande de permissions d'accès spécifique.

Lors de la navigation dans GeoNature – module synthèse, l’utilisateur sera informé (par des figurés spécifiques ou un message d’alerte) de l’existence dans Silene de données sensibles non consultables précisément du fait des restrictions d'accès liées aux permissions utilisateurs. Lors des développements liés à l’inscription de l’utilisateur, nous ferons en sorte de respecter les règles du Règlement Général sur la Protection des Données (RGPD).

Le formulaire comprendra les sections et champs suivant :

• Section : « Profil »
  • Prénom [obligatoire] : le prénom de l'utilisateur
  • Nom [obligatoire] : le nom de famille de l'utilisateur.
  • Email [obligatoire] : le courriel principal de l'utilisateur qui servira pour le contacter.
    • Règle : doit respecter une expression régulière.
• Section : « Paramètres de connection »
  • Identifiant (login) [obligatoire] : sera utilisé en complément du mot de passe pour accéder au système.
    • Règle : si l'identifiant existe dans la base une nouvelle valeur sera demandée.
    • Info-bulle : « Cet identifiant vous sera demandé pour vous authentifier dans GeoNature.»
  • Mot de passe [obligatoire] : le mot de passe sélectionné par l'utilisateur.
  • Confirmation du mot de passe [obligatoire] : confirmation du mot de passe précédemment fourni.
    • Règle : les 2 valeurs des champs mots de passe doivent être identique.
• Section : « Organisme »
  • Nom [obligatoire] : une liste déroulante devra permettre de sélectionner un nom d'un organisme existant dans la base (UsersHub). Les membres d'un organisme adhérent à Silene pourront ainsi sélectionner leur structure. Si l'organisme n'est pas disponible dans la liste, l'utilisateur doit pouvoir saisir l'intitulé de celui-ci.
    • Info-bulle : « Commencer à saisir les 3 premières lettres du nom et sélectionner votre organisme dans la liste s'il est déjà présent. Dans le cas contraire, indiquer le nom de votre organisme (association, entreprise, …). Si vous êtes un particulier, sélectionner "Aucun".»
    • Note technique : voir pour utiliser un élément HTML de type datalist. Si le champ est rempli avec un nom abscent de la base, les champs optionnels suivant devrait être apparaitre.
      • Adresse
      • Code postal
      • Ville
      • Téléphone
      • Fax
      • Email
      • Site web
• Section : « Conditions d'utilisation »
  • Condition d'utilisation [obligatoire] : une case à cocher suivi du texte « J'accepte les conditions d'utilisation et la charte Silene » avec un lien vers le fichier PDF de la charte permettra d'indiquer que l'utilisateur s'engage à la respecter.
  • Texte : le texte suivant devra suivre le champ d'acceptation :

        Merci pour votre demande d’inscription. Après validation de l’administrateur, vous pourrez accéder aux observations publiques [=>v2: ainsi qu’à vos propres observations] avec leur précision de géolocalisation maximale. La  géolocalisation des autres observations peut être dégradée suite à l’application des règles de géo-confidentialité du SINP.
        L'accès à ces données avec leur précision maximale nécessite, dans Silene, de compléter un « formulaire de demande d’accès aux données précises » (en savoir plus <insérer lien vers aide formulaire>). L'accord sera formalisé par l’acceptation d'une convention « droit d'accès aux données précises » et donnera lieu à l'attribution d'un accès direct à ces données. La convention  engage le titulaire à un bon usage des données et à une alimentation de Silene en retour <insérer lien plateforme de versement données>.
        Les autorisations d'accès sont gérées par les administrateurs de données s'appuyant sur le Comité d’administrateurs de Silene.
        Les données et informations qui vous sont fournies dans le cadre de Silene ne sont pas exhaustives et peuvent donc s’avérer insuffisantes pour les besoins spécifiques de votre étude. Une réactualisation de ces données dans le cadre d’inventaires complémentaires est nécessaire.

• Bouton : "Valider". Un clic sur ce bouton déclenchera l'affichage d'un message indiquant "Votre inscription a bien été prise en compte. Elle va être évaluée par un administrateur.". Cela enverra la demande d'inscription par email aux administrateurs pour confirmation de la demande et association au bon groupe, organisme…

En cas d'oubli d'identifiant ou mot de passe, l'utilisateur pourra en refaire la demande à l'aide de son email utilisé lors de l'inscription.

Un lien "Identifiant ou mot de passe oublié ?" sera présent la page d'authentification de GeoNature. Un clic dessus ouvrira une fenêtre modale. Celle-ci contiendra :

• le texte "Veuillez renseigner votre adresse email utilisée lors de votre inscription. Un message y sera envoyé avec votre identifiant et la possibilité de renouveler votre votre mot de passe.".
• une zone de saisie pour l'email
• un bouton "Envoyer"

Une fois le formulaire rempli et lors du clic sur le bouton "Envoyer", une message sur fond bleu s'affichera à l'écran pour indiquer la prise en compte de sa demande. Le message sera "Un email vient de vous être envoyé pour récupérer votre identifiant et/ou renouveler votre mot de passe.".
En cas d'erreur (impossibilité d'envoyer l'email, erreur de saisie, …) le message sera affiché sur fond rouge.

Dans l'email reçu par l'utilisateur, un lien sera présent et permettra à l'utilisateur de retourner sur GeoNature pour y recréer un nouveau mot de passe.
L'interface en question consistera en un formulaire composé de :

• un champ "Nouveau mot de passe"
• un champ "Confirmation"
• un bouton "Modifier"

Si le formulaire est rempli avec succès le message "Mot de passe modifié avec succès." s'affichera sur fond bleu et l'utilisateur sera redirigé automatiquement sur le formulaire d'authentification.

L'email de demande d'inscription à destination de l'administrateur aura la forme suivante :

Bonjour,

Un utilisateur vient d'effectuer une demande de création de compte sur GeoNature "Silene - Expert".
Voici les informations de l'utilisateur :

    Nom : <NOM>
    Prénom : <Prénom>
    Identifiant : <identifiant>
    Email : <email>

Informations complémentaires :

    remarque: <remarque>
    validate_charte: ['true']

Souhaitez vous :
 - Accepter cette inscription : <lien-accepter>
 - Accéder à l'interface de gestion : <lien-vers-interface>

Cordialement,

Une fois, l'inscription acceptée par l'administrateur, l'email à destination de l'utilisateur aura la forme suivante :

*** Ceci est un message généré automatiquement ***

Bonjour <prénom> <NOM>,

Votre inscription à "Silene - Expert" a été acceptée.
Vous pouvez dès à présent vous connecter sur http://expert.silene.eu
Pour rappel, votre identifiant de connexion est : <identifiant>

Nous vous rappelons que cette inscription vous donne accès à la consultation des données publiques versées dans Silene [=>v2: mais également de vos propres données]. L’accès aux autres données nécessite de compléter un « formulaire de demande d‘accès aux données précises » (en savoir plus <insérer lien vers aide formulaire>). L'accord sera formalisé par l’acceptation d'une convention « droit d'accès aux données précises » et donnera lieu à l'attribution d'un accès direct à ces données. La convention engage le titulaire à un bon usage des données et à une alimentation de Silene en retour <insérer lien plateforme de versement données>.

Bien cordialement,
L'administrateur.

L'email envoyé suite à la demande de réinitialisation de mot de passe aura la forme suivante :

Vous avez oublié votre identifiant / mot de passe.

Voici vos informations pour vous connecter :

Identifiant : <identifiant> 

Pour réinitialiser votre mot de passe : <lien-vers-interface-GeoNature>

L'utilisateur doit pouvoir indiquer le type d'observations pour lesquelles il souhaite accéder aux informations de localisation précises. Pour cela, un formulaire sera mis à disposition.

Lorsqu'un utilisateur se connecte à GeoNature, un message de présentation s'affiche. Nous utiliserons cet espace pour indiquer à l'utilisateur comment accéder aux données géo-confidentielles.

Le message pourra avoir la forme suivante : « Si vous souhaitez accéder aux observations géo-confidentielles (jeux de données privées avec niveaux de diffusion, observations sensibles). Vous devez accepter électroniquement une convention ponctuelle à l'aide du formulaire de demande de permissions d'accès aux observations géo-confidentielles . ». Un lien vers le formulaire sera présent sur la dernière phrase.

Il sera aussi possible d'accéder à ce formulaire via une entrée dans le menu "Mon compte/Profil" présent dans l'entête de l'interface de GeoNature.

L'activation/affichage du formulaire de demande de permissions sera lié à un paramètre de configuration qu'il faudra activer. Par défaut, GeoNature sera installé sans cette option.

Le formulaire comprendra les sections et champs suivant :

• Section : « Vos demandes » : cette section n'apparaitra que si l'utilisateur a déjà réalisé des demandes.
  • Tableau : un tableau avec les colonnes suivantes :
    • État : contiendra l'état de la demande
      • "Active" : pour les demandes dont la date de clôture n'est pas dépassée.
      • "Inactive" : pour les demandes dont la date de clôture est dépassée.
      • "En attente" : pour les demandes en attente d'acceptation par un administrateur.
    • Fin le : date de fin de l'accès.
    • Zones géographiques : liste des zones demandées.
    • Groupes taxonomiques : liste des groupes.
    • Obs. sensibles : contient "oui" si la demande concernée aussi les observations sensibles.
    • Action : contiendra un bouton "Renouveler" pour les demandes clôturée. Il permettra de recharger automatiquement dans le formulaire ci-dessous les données de la demande. Une bulle d'aide indiquera qu'il faut valider le formulaire pour rendre effective la demande.
• Section : « Demande de permissions d'accès »
  • Texte :

    Veuillez indiquer ci-dessous les zones géographiques pour lesquelles vous souhaitez accéder aux données à leur précision maximale. Merci de préciser également les groupes taxonomiques concernés et le calendrier de votre étude. 

    • Pour le PIFH, une mention concernant les règles d’accès aux données sensibles sera ajoutée. Par exemple :

       Si vous possédez les permissions d’accès aux observations sensibles avec la plus grande précision possible, veuillez cocher la case. Merci de consulter au préalable les règles d’accès à ces données et que vous en possédez <lien vers règles d’accès  aux données sensibles>. 

    • : une fois les règles de diffusion des données sensibles définies en région Sud – Provence-Alpes-Côte d’Azur, cette mention pourra être intégrée à Silene.
  • Zones géographiques [obligatoire] : ce champ sera en réalité composé de 2 zones distinctes situé côte à côte :
    • une zone de saisie fonctionnant sur le même principe que la zone de saisie des emails lors de la rédaction d'un message dans Gmail. Elle doit aussi permettre de saisir une zone n'existant pas dans la base.
      • Info-bulle :

        Saisir les premières lettre d'une commune, département ou région, sélectionner l'élément qui vous convient dans la liste proposée avec les touches fléchés et valider votre sélection avec la touche Entrée. Si votre entité géographique n'existe pas, vous pouvez indiquer son nom et valider sa prise en compte avec la touche entrée ou le caractère virgule. 

    • une carte dynamique permettant de dessiner un polygone, une ligne ou de charger un fichier géographique (gpx, geojson, kml) afin d'indiquer la zone de la demande. Dans ce cas, nous stockerons les nouvelles géométries ainsi créées dans la table ref_geo.l_areas. Elles seront associées à un type de zonage spécifique.
  • Groupes taxonomiques [optionnel] : une zone de saisie fonctionnement sur le même principe que la zone de saisie des emails lors de la rédaction d'un message dans Gmail. Elle doit aussi permettre de saisir un groupe n'existant pas dans la base. Si cette dernière possibilité est trop complexe à mettre en place, un champ « Remarques » sera peut-être ajouté pour gérer ce type de demande. Nous prévoyons d’utiliser les groupes INPN ou un fonctionnement basé sur les colonnes supérieures au genre de la table taxonomie.taxref.
    • Info-bulle :

      Saisir les premières lettre d'un groupe taxonomique, sélectionner l'élément qui vous convient dans la liste proposée avec les touches fléchés et valider votre sélection avec la touche Entrée. Vous pouvez sélectionner plusieurs groupes en poursuivant votre saisie dans ce champ. Si votre groupe n'existe pas, vous pouvez indiquer son nom et valider sa prise en compte avec la touche entrée ou le caractère virgule. 

  • Observations sensibles [optionnel] : une case à cocher suivi du texte « Je souhaite accéder aux observations sensibles (Merci de consulter au préalable les règles d’accès aux données sensibles <lien vers règles d’accès aux données sensibles>) ».
    • L’affichage de cette mention sera paramétrable selon le SINP régional concerné.
  • Accès jusqu'au [optionnel] : un zone de texte permettant de saisir une date suivi d'un widget de calendrier accessible via un icône représentant un calendrier. Le widget indiquera par défaut une date située 3 mois dans le futur.
    • Règles : la date doit être valide et respecter le format jj/mm/aaaa.
    • Info-bulle :

      Veuillez indiquer jusqu'à quelle date vous souhaitez accéder aux données précises. Le format est jj/mm/aaaa. Vous pouvez cliquer sur l'icône de calendrier pour ouvrir l'utilitaire de sélection de date. Pour demander un accès permanent laisser ce champ vide. 

• Section : « Motivations de la demande ». Cette section fonctionne sur le principe des champs supplémentaires paramétrables par l'administrateur.
  • Texte :

     Veuillez décrire ci-dessous les motivations à l'origine de votre demande. 

  • Type d'étude ou de projet [obligatoire] : une liste déroulante où chaque entré est précédé d'une case à cocher et proposant les choix multiples suivant : "Plan de gestion", "DOCOB Natura 2000", Inventaire scientifique", "Expertise écologique réglementaire", Étude trame verte et bleue", "PLU / SCOT", "Autre (à préciser dans description)"
    • Cette liste est issue du formulaire actuellement utilisé dans l’outil Silene. Une liste commune Silene et PIFH pourra être envisagée par la suite.
  • Commanditaire [obligatoire] : zone de texte permettant d’indiquer le nom du commanditaire de l’étude ou l’organisme à l’origine du projet.
    • Info-bulle :

      Veuillez indiquer le nom du commanditaire de l’étude ou l’organisme à l’origine du projet.

    • Ce champ pourra être rendu optionnel pour le PIFH
  • Description [optionnel] : zone de texte permettant de décrire les motivations à l'origine de la demande d'accès.
    • Ce champ pourra être rendu optionnel pour le PIFH
  • Texte :

    Préciser dans le champ description le calendrier, la finalité, l'objet de l’étude scientifique et le cadre réglementaire dans lequel s’inscrit la demande (Étude d'impact, étude d'incidence Natura 2000, étude d'incidence Eau, demande d'autorisation au titre de la loi sur l'eau, demande d'autorisation au titre des ICPE, demande d'autorisation de destruction d'espèces protégées). 

• Bouton : "Envoyer". Un clic sur ce bouton permettra d'afficher une fenêtre avec un texte contenant la confirmation de la demande d'accès ou la convention correspondante à la demande. Ce texte sera basé sur un modèle modifiable par l'administrateur. L'affichage ou pas de cette fenêtre de confirmation/convention sera paramétrable (fichier de config). Le texte du bouton de validation sera aussi modifiable par l'administrateur et pourra contenir le texte "J'accepte les termes de la convention « droit d'accès » Silene." Lorsque la fenêtre de confirmation est "Valider" un message indiquera "Votre demande a bien été prise en compte. Elle va être évaluée par un administrateur.".

<h2>Convention « Droit d'accès ponctuel aux données géoconfidentielles / Silene »</h2>
 
<p><organisation> représenté par <prénom> <NOM> désigné sous le terme « l’utilisateur identifié » s’engage à respecter les termes suivants</p>
 
<h3>Préambule</h3>
 
<p>En Provence-Alpes-Côte d’Azur, Silene est le portail public d’accès aux données naturalistes. Silene informe sur la localisation des espèces de faune et de flore et des habitats naturels ou semi-naturels. Silene est ainsi la plateforme régionale d’occurrence taxon du Système d’Information Nature et Paysage (SINP) en Provence-Alpes-Côte d’Azur.<br/>
Le SINP est un programme national, porté par le Ministère chargé de l’Environnement et conçu comme une organisation collaborative pour la production, la gestion, le traitement, la valorisation et la diffusion des données sur la nature et les paysages. Son organisation est décrite dans un protocole national (circulaire du 15 mai 2013 en cours d’actualisation).<br/>
En facilitant l’accès à l’information, Silene a pour objectif la connaissance et la conservation du patrimoine naturel régional. C’est un outil public et collectif au service de la prise en compte de la biodiversité, financé et piloté de façon partenariale. Les partenaires approuvent un document commun de référence : la charte Silene.<br/>
Les données de Silene sont librement consultables à la précision de la commune ou de la maille. L’accès à l’information plus détaillée est autorisé en réponse à des demandes ponctuelles et motivées, selon les principes validés par le comité de pilotage.<br/>
Les données et informations qui sont fournies dans le cadre de Silene ne sont pas exhaustives et nécessitent la consultation d’autres sources, une réactualisation et des inventaires complémentaires dans le cadre de l’expertise.</p>
 
<h3>Article 1. Objet de la Convention</h3>
 
<p>Cette convention établit les droits d’accès aux données précises de Silene pour l’utilisateur identifié signataire de la présente convention, et les engagements liés à cet accord. Elle traite des aspects relatifs à la consultation et l’exportation des données.</p>
 
<h3>Article 2. Droits d’accès</h3>
 
<p>L’accès est accordé à <prenom> <NOM> - <organisation> en tant que sur une demande motivée pour l’objet suivant : <description></p>
 
<p> <NOM> <Prénom> a reçu lors de son inscription un identifiant et un mot de passe personnel lui permettant l’accès au portail Silene et aux données source des occurrences de taxons. Les droits d’accès et les identifiants fournis sont strictement nominatifs et leur utilisation reste sous la responsabilité de « l’utilisateur identifié ». </p>
 
<p>« l’utilisateur identifié » signataire de la présente convention déclare avoir pris connaissance et approuver la charte. Silene met à disposition l'ensemble des données validées contenues dans Silene pour les droits de consultation suivants :</p>
<ul>
    <li>délimitation géographique : <zones-geographiques></li>
    <li>groupes systématiques : <groupe-taxonomique></li>
    <li>durée de mise à disposition : <date></li>
</ul>
 
<h3>Article 3. Utilisation des données Silene</h3>
 
<p>L’ouverture de droits d’accès pour Silene est strictement subordonnée au respect des conditions suivantes :</p>
<ul>
    <li>ne pas utiliser la donnée Silene pour des buts contraires à la conservation de la nature,</li>
    <li>respecter strictement la charte Silene notamment l’article spécifique sur les règles liées à la donnée et à sa citation,</li>
    <li><strong>ne pas céder à un tiers des données dont il ne serait pas propriétaire sans l’accord de Silene</strong>,</li>
    <li>ne pas diffuser les codes d’accès qui sont nominatifs et sous sa responsabilité,</li>
    <li>toujours citer la source des données dans toute valorisation de leur exploitation : « Silene – date de consultation - sources (fournisseurs de données) »,</li>
    <li>apposer systématiquement le logo Silene dans toute production ayant mobilisé des données de Silene</li>
</ul>
 
<p>Puisque ces droits d’accès sont accordés dans le cadre d’une étude faisant l’objet d’une commande spécifique d’un maître d’ouvrage, l’utilisateur identifié certifie sur l’honneur être effectivement missionné par le commanditaire, et s’engage à :</p>
<ul>
    <li>n’utiliser les données de Silene que dans le cadre de la mission ayant donné lieu à l’autorisation d’accès de la présente convention</li>
    <li>fournir les données recueillies dans le cadre de l’étude en s’assurant de l’autorisation du commanditaire de l’étude pour leur mise à disposition dans Silene dans le délai d’un mois suivant l’expiration du droit d’accès, directement aux administrateurs sous forme de tableaux Excel standardisé précisant a minima : nom de l’espèce (latin), nom du découvreur, commune et la géolocalisation précise de l’observation, date de l’observation. Dans la mesure du possible, elles seront complétées sur les champs optionnels proposés. Un formulaire standard de donnée est disponible sur https://silene.eu onglet « Accès aux données »</li>
</ul>
 
<p>L’usage des données par l’utilisateur n’engage pas la responsabilité de Silene.</p>
 
<p><b>Résiliation de la convention</b> : La convention est établie pour la durée de mise à disposition précisée en article 2. Elle pourra être reconduite sur la base d’une nouvelle demande motivée. En cas de non-respect des engagements de la présente convention, elle peut être résiliée de façon unilatérale sans préavis.</p>

Lors de toute nouvelle demande, un email sera envoyé aux administrateur. Son contenu aura la forme suivante :

Bonjour,

L'utilisateur <Prénom> <NOM> (<organisme>) vient d'effectuer une demande de permissions d'accès à GeoNature : <adresse-web>
Voici les permissions demandées :
 - Accès aux observations privées précises : oui
 - Accès aux observations sensibles précises : <oui-ou-non> [champ paramétrable selon le SINP régional]
Accès limités par :
 - Zones géographique : <liste-des-zones / voir fichier en pièce-jointe>
 - Groupes taxonomiques : <liste-des-groupes>
 - Fin le : <date>

Informations complémentaires :
 - Type d'étude ou de projet : <type>
 - Description : <description>

Souhaitez vous :
 - accepter cette demande : <lien-accepter>
 - refuser cette demande : <lien-refuser>
 - accéder à l'interface de gestion : <lien-vers-interface>

Cordialement,

Si la demande est acceptée un email de confirmation sera ensuite envoyé par le compte "admin/ne-pas-repondre@silene.eu" et contiendra un texte de la forme suivante :

*** Ceci est un message généré automatiquement ***

Bonjour <Prénom> <NOM>,

Votre demande de permissions d'accès à <nom-du-sinp> vient d'être acceptée.
Adresse du site : <https://expert.silene.eu>
Votre identifiant de connexion : <identifiant>
Vos permissions sont valables jusqu’au <date>.
Rappel de votre demande :
 - Accès aux observations privés précises : oui
 - Accès aux observations sensibles précises : <oui-ou-non> [champ paramétrable selon le SINP régional]
Accès limités par :
 - Zones géographiques : <liste-des-zones>
 - Groupes taxonomiques : <liste-des-groupes>

Votre demande de données concerne des données sensibles, données visées à l'article L. 124-4 §8 du code de l'environnement, dont la consultation ou la communication peut porter atteinte à la protection de l'environnement. Par conséquent, elles sont floutées géographiquement lors de leur diffusion. [Champ paramétrable selon le SINP régional]

Pour plus d'information n'hésitez pas à nous contacter, <email-ou-lien-vers-formulaire>.

Bien cordialement,
L'administrateur. 

Si la la demande est refusée un email de confirmation sera ensuite envoyé par le compte "admin/ne-pas-repondre@silene.eu" et contiendra un texte de la forme suivante :

*** Ceci est un message généré automatiquement ***

Bonjour <Prénom> <NOM>,

Votre demande de permissions d'accès à <nom-du-sinp> vient d'être refusée.
Raison du refus : <texte-explicatif>

Pour plus d'information n'hésitez pas à nous contacter, <email-ou-lien-vers-formulaire>.

Bien cordialement,
L'administrateur. 

Les 2 formulaires précédents vont fournir des données qui seront ensuite accessibles par les administrateurs dans 2 outils distincts.
Concernant l'inscription, les informations de l'utilisateur seront visible dans UsersHub. Pour les demandes de permissions d'accès, elles seront gérables via le menu "Admin" de GeoNature.

Les demandes d’inscriptions des utilisateurs à GeoNature seront par défaut stockées dans la table utilisateurs.temp_users, cela correspond à un état en attente de validation d'inscription. L’administrateur en validant l’inscription d’un utilisateur devra l’associer à un groupe : “Pro” ou “Adhérent”.

Ces groupes auront des permissions définies en fonction de la charte.

Les administrateurs de GeoNature seront prévenus de la nouvelle inscription par l'envoi d'un email. Ce dernier contiendra un lien pour accéder directement à l'interface permettant d'accepter/refuser l'inscription.
Cette interface de validation des utilisateurs se trouvera dans UsersHub. Un menu "Demandes de compte" proposera d'accéder à la liste des inscriptions en attente/refusées. Par défaut, un premier onglet affichera un tableau avec la liste des inscriptions en attente. Un second onglet permettra d'accéder au tableau des inscriptions refusées.

La possibilité de renseigner une raison au refus sera proposée à l'administrateur. Cette information sera stockée dans le champ "Commentaire" de l'utilisateur. La date d'acceptation/refus devra aussi être stockée.

Lorsque l'inscription est accepté/refusé un email est envoyé à l'utilisateur pour le prévenir.

Notes techniques : les infos seront stockées dans une table ("temp_users" ⇒ à renommer, si possible) du schéma "utilisateurs" de la base de données.

La gestion des demandes de permissions aura lieu dans l'outil GeoNature et va demander une refonte de l'interface du sous-module "Administration des permissions" présent dans le module "Admin". Les administrateurs de GeoNature seront prévenus de la nouvelle demande par l'envoi d'un courriel. Ce dernier contiendra un lien pour accéder directement à l'interface permettant d'accepter/refuser la demande.
L'acceptation/refus de la demande de permissions générera un courriel automatique à destination de l'utilisateur.

Cette interface de validation des demandes de permissions se trouvera dans GeoNature, module « Admin ». Un menu « Administration des permissions » proposera 2 menus principaux :

• Permissions : gestion des permissions par utilisateur et groupe.
• Demandes : gestion des demandes de permissions à l'initiative des utilisateurs. L’affichage de ce menu sera rendu paramétrable via le fichier de configuration de GeoNature.

Au niveau de ces interfaces, nous utiliserons les termes suivant :

• utilisateur : pour désigner les personnes physiques se servant l'application.
• groupe : pour rassembler les utilisateurs afin de leur affecter des permissions plus facilement. Les utilisateurs associés à un groupe hériteront des permissions du groupe. Le nom des groupes correspondra à des rôle concrets tel que « Administrateurs », « Adhérents SINP »… Nous éviterons donc l'utilisateur du terme « rôle » au sens de la base de données Postgresql qui pourrait porter à confusion.
• permission : le terme permission sera préféré à « droit » car il est moins générique.

L'interface de gestion des permissions contiendra un tableau des utilisateurs et groupes intitulé « Permissions des utilisateurs et groupes » avec les champs :

• ID : identifiant de l'utilisateur ou du groupe présent dans la table t_roles.
• Nom : Prénom et Nom de famille de l'utilisateur ou nom du groupe.
• Type : indique si la ligne correspond à un utilisateur ou un groupe.
• Nombre permissions : le nombre de permissions attribuées.
• Actions : contiendra un bouton avec un icône permettant d’accéder à liste des permissions affectées.

Ce tableau pourra être paginé et filtré. Par défaut, le tableau sera trié par Type avec les groupes en premier, puis le trie s'effectuera sur le champ Nom. Les lignes des groupes auront un fond coloré distinct de celui des utilisateurs.

L'interface de consultation des permissions d'un utilisateur ou groupe contiendra une liste paginée de permissions classées par module. La présentation sera semblable à l'interface du module Métadonnées. Elle aura pour titre « <nom> -Permissions relatives aux modules ». Un bouton « Ajouter une permission » sera présent au dessus de la liste. Cette interface étant chargé dans une nouvelle page, un bouton « Retour » en haut à gauche permettra de revenir sur l'interface précédente. Dans la liste, un clic sur un nom de module permettra de dérouler la liste des permissions qui s'affichera avec les champs suivant :

• Droit : nom du droit correspondant à l'association du verbe du CRUVED et de sa ressource.
• Filtres : nom et valeur de chaque filtre associée à ce droit. Vide si aucun défini.
• Date de fin : date à laquelle le droit prend fin. Vide si toujours actif.
• Action :
  • un bouton icône de suppression permettra de supprimer la permission après avoir validé une boite de dialogue de confirmation.
  • un bouton icône de modification permettra d'accéder à l'interface de modification d'une permission.

L'interface de modification/ajout de permissions se basera sur la nouvelle table cor_module_action_object_filter. L'interface contiendra un assistant fournissant progressivement l'accès à des champs en fonction des choix précédents et des options disponibles dans la table cor_module_action_object_filter. Les champs seront :

• Permissions : une liste déroulante contiendra l'association des verbes du CRUVED (table t_actions) et des ressources disponibles pour ce module tel qu'indiqué dans la table cor_module_action_object_filter.
• Filtres : des filtres seront disponibles si le droit sélectionné précédemment en possède. L'administrateur aura la possibilité ou pas de réduire l'impact du droit en sélectionnant un filtre dans une liste déroulante et en y associant une valeur correspondante aussi sélectionné dans une liste. Un bouton icône "Ajouter" permettra de prendre en compte le filtre qui s'affichera alors en dessous avec un bouton icône "Supprimer".
• Date de fin : possibilité de saisir ou de sélectionner une date dans un calendrier pour limiter l'application du droit dans le temps.
• Bouton "Enregistrer" : permet d'ajouter le droit à la table cor_role_action_filter_module_object et de retourner à l'interface précédente ("Permissions relatives aux modules").

L'interface possédera un titre « Demande de permissions d'accès ». Au dessous, 2 onglets contiendront des tableaux paginés des demandes de permissions d'accès aux données géo-confidentielles :

• En attentes : demandes en attente.
• Traitées : demandes acceptées ou refusées.

Les tableaux des 2 onglets contiendront les colonnes communes suivante :

• Utilisateur : Prénom et nom de famille de l'utilisateur réalisant la demande.
• Organisme : nom de l'organisme de l'utilisateur.
• Permissions : liste des permissions demandées avec leurs filtres (zones géographiques, groupes taxonomiques).
• Date de fin : date jusqu'à laquelle les permissions sont demandées.
• Actions : contiendra les boutons icônes suivant :
  • Consulter : permet d'accéder à la fiche détaillée de la demande comprenant les champs personnalisés supplémentaires (« Motivations de la demande »).

Le tableau des demandes « En attente » contiendra en supplément :

• Actions :
  • Accepter : permet d'accepter les permissions demandées.
  • Refuser : un clic ouvrira une modale demandant la saisie d'un commentaire à destination de l'utilisateur et la confirmation du refus.

Le tableau des demandes "Traitées" contiendra en supplément les colonnes suivantes:

• Traitement : indiquera si la demande a été "acceptée" ou "refusée". Les lignes « acceptées » auront un fond vert pastel et lignes « refusées » rouge pastel.
• Raison : ce champ contiendra le commentaire laissé par l'administrateur suite au traitement.

L'interface de consultation détaillée de la demande, intitulée « Détail demande de permissions - <Prénom> <NOM> (<Organisme>) », affichera l'ensemble des informations saisie par l'utilisateur. Une fois traitée par un administrateur des informations complémentaires pourront y être mentionné (raison du refus).

Si la demande n'a pas encore été traitée une bouton "Définir le statut" sera affichée dans l'entête de l'interface de consultation détaillée. Il permettra d’accéder à un menu avec 2 choix « Accepter » et « Refuser ». Ces menus auront le même fonctionnement que les boutons icônes du tableau des demandes « En attentes ». Si la demande a été traitée, le bouton (nommé "Changer le statut") permettra d'inverser la décision ou de "Placer en attente" la demande. La mise en attente d'une demande comme le refus implique une suppression des permissions associés.

Lors du changement de statut d'une demande un email sera automatiquement envoyé à l'utilisateur pour le prévenir du changement de statut de sa demande.

Les permissions permettant d’accéder aux données géo-confidentielles nécessitent des modifications dans la base de données. À priori, les modifications envisagées sont :

• Schéma gn_permissions :
  • Ajout d'une table t_requests permettant de stocker les demandes d'accès, les informations liées à la motivation de cette demande (description du projet, type d'étude, durée…) et leur acceptation/refus (date).
  • Modification de la table cor_role_action_filter_module_object
    • Ajout d'un champ gathering permettant de cumuler des filtres pour un même droit (Ex. : Accès aux observations sensibles pour le taxon X et la commune Y).
    • Ajout d'un champ end_date permettant d'indiquer une date de fin au droit. Si NULL pas de fin prévu au droit.
    • Remplacement du champ id_filter par id_filter_type et ajout du champ complémentaire value_filter. Le champ value_filter sera type text et pourra contenir un id, une chaîne ou autre en fonction du type de filtre. Nous créerons autant d’enregistrements que nécessaire pour éviter de devoir stocker plusieurs valeurs dans ce champs. Les valeurs possibles en fonction du type de filtre sont les suivantes :
      • SCOPE [nombre entier] : 0 (= aucune donnée), 1 (= mes données), 2 (= données de mon organisme) ou 3 (=toutes les données).
      • SENSITIVITY [booléen] PRECISION [chaine de caractère] : "fuzzy" (=flou) ou "exact" (=précis).
      • TAXONOMIC [nombre entier, chaine de caractère] : le nombre entier correspond au cd_nom de la table ref_taxonomy.taxref. La chaine de caractère correspond à une liste de cd_nom séparés par des virgules.
      • GEOGRAPHIC [nombre entier, chaine de caractère, géométrie] : le nombre entier correspond au id_area de la table ref_geo.l_area ; la chaine de caractère à une de id_area séparés par des virgules ; la géométrie correspond à une zone dessiné depuis une carte ou l'import d'un fichier.

• Pour chaque demande de permissions des nouvelles lignes seront à ajouter dans cette table.
• Suppression de la table t_filters dû à la modification de la table cor_role_action_filter_module_object (ajout champ value_filter).
• Nous utiliserons des constantes applicatives pour les valeurs définies par défaut.
• Nous simplifions le fonctionnement en gardant seulement la table cor_role_action_filter_module_object et en supprimant la relation avec la table t_filter.
• Afin de facilité la création de l'interface de gestion des permissions :
• une droit se compose d'un « verbe » et d'un « complément » :
  • Les verbes sont aujourd'hui stockées dans la table t_actions (CRUVED)
  • Pour le "complément" la table t_objects est retenue. Elle permettra de stocker les « ressources » des modules sur lesquelles une action (CRUVED) agit. Les « sous-modules » actuellement stockés dans cette table peuvent être considérés comme des ressources du module « Admin » de GeoNature.
• Afin d'être certain des permissions implémentées dans un module, nous créerons une nouvelle table cor_module_action_object_filter pour indiquer les actions possibles vis à vis d'un objet pour un module donnée et les types de filtres applicables.
  • Cette table sera renseignée par les développeurs pour indiquer les permissions disponibles dans leur module.
  • Cela implique la suppression des tables : cor_object_module, cor_filter_type_module.

La géo-confidentialités des observations liée aux observations sensibles et au niveau de diffusion des données privées se traduira sur les interfaces de consultation et d'export par un floutage de l'information géographique.

Dans un premier temps, afin de respecter les Chartes des SINP régionaux, tous les jeux de données seront considérés comme privés. Les permissions d’accès attribuées aux utilisateurs permettront alors de définir le niveau de précision géographique accessible.

Ce floutage impacte les types d'interfaces suivant :

• les résultats affichés sous forme de listes ou tableaux
• les observations affichées sur la carte
• les fiches d'informations détaillées
• les exports de résultats

Les modules et applications de GeoNature concernés sont :

1. Synthèse
2. GeoNature-Atlas
3. Export
4. OccTax
5. Validation

Dans le cadre de la première version de l'utilisation de GeoNature pour Silene et le PIFH, nous concentrerons nos développements sur le module "Synthèse" qui sera le seul à pouvoir faire apparaitre des informations précises. Nous réaliserons les développements nécessaires sur les modules dans l'ordre de la liste précédente.

: la possibilité d’une représentation différenciée des observations en fonction de leur niveau de précision sera étudiée dans un second temps.

Nous ne tiendrons compte que du cas des observations de type « inventorielles » (voir attribut natureObjetGeo du standard DEE). Nous ne flouterons que les champs contenant des données géographiques. Les champs textuels comme comment_context ou comment_description pouvant contenir des informations complémentaires sur la localisation (ex. lieu-dit) seront diffusés.

Le niveau de sensibilité des observations sera calculé à l’aide des règles de sensibilité définies dans le cadre du SINP régional et intégrées à GeoNature (voir « Calcul automatique sensibilité des données »). Ces règles seront à définir au niveau régional en se basant sur les recommandations du guide technique « Définition et gestion des données sensibles sur la nature dans le cadre du SINP », et devront être validées par le Conseil Scientifique Régional du Patrimoine Naturel.

Les 4 types possibles d'objet géographique correspondant à des niveaux de floutage sont :

• géométrie précise [G] (= aucun floutage)
• commune [C]
• maille 10x10km [M] (Pour Silene, un floutage par maille 5x5km est demandé)
• département [D]

Les champs d'une observation présents dans la table synthese permettent de calculer les géométries correspondantes aux critères de géo-confidentialité.

Le croisement de l'info présente dans le champ the_geom_4326 avec les géométries de la table l_areas en fonction d'un type d'objet géographique déterminé par les valeurs des champs id_nomenclature_diffusion_level pour les jeux de données privés (champ id_nomenclature_data_origin, table gn_meta.t_dataset) et id_nomenclature_sensitivity pour les observations sensibles permettra de déterminer la géométrie à utiliser pour chacun des critères.

Ainsi, les développements consisteront principalement à rajouter 2 champs à la table synthese :

• the_geom_4326_diffusion_level : contiendra l'id d'un objet géographique dont le type est en correspondance avec la valeur du champ id_nomenclature_diffusion_level
• the_geom_4326_sensitivity : contiendra l'id un objet géographique dont le type est en correspondance avec la valeur du champ id_nomenclature_sensitivity

Ces champs seront pré-calculés et un trigger les maintiendra à jour. Ils contiendront un id provenant la table ref_geo.l_areas. Les informations (dont la géométrie) de la table ref_geo.l_areas seront ensuite utilisées pour l'affichage dans les différents types d'interface listés ci-dessus. Il sera peut-être nécessaire de rajouter un champ à la table ref_geo.l_areas qui contiendra la géométrie au format SRID 4326.

Tableau du type d'objet géographique utilisé en fonction des critères de géo-confidentialité (https://github.com/PnX-SI/Nomenclature-api-module/issues/39#issuecomment-773492258):

Exemple issu du document "Diffusion des données par niveaux de restitution dans GINCO" :

Une donnée ayant une sensibilité de 2 (Maille) et un niveau de diffusion de 3 (Département) sera floutée au département pour un utilisateur sans permissions particulières (c'est le caractère privé qui l'emporte parce qu'il impose un floutage plus important).
Par contre si l'utilisateur a le droit de voir les données privées, l'observation sera floutée à la maille. Le critère de sensibilité étant le seul à s'appliquer.
Enfin, si l'utilisateur a également le droit de voir les données sensible, l'observation ne sera pas floutée pour lui.

Par défaut, dans le module Synthèse aucune données n'est visible par un utilisateur à part les siennes (s'il en a saisie via le module OccTax). Dans le cadre des SINP, par défaut, nous appliquerons aux utilisateurs le droit pour le module "GeoNature" (l'application dans son ensemble) de voir toutes les données de tous les organismes (CRUVED ⇒ R=3).
Ainsi, dans le cas du module "Synthèse", cela permettra à l'utilisateur d'accéder à toutes les observations non sensibles des jeux de données publiques. Les règles SINP de géo-confidentialités s'appliqueront aux observations :

• sensibles des jeux de données publiques et privés
• non sensible des jeux de données privés (niveau de diffusion)

1. L'utilisateur se connecte
2. Chargement des permissions de l'utilisateur liées au module Synthèse
   • nous devons aplatir ses permissions afin d'obtenir une liste composée des éléments : "module", "action", "object", "filters".
   • l’aplatissement consiste à distribuer les permissions par module en fonction de l'héritage pour :
     • les groupes
     • la hiérarchie applicative : module GEONATURE > module spécifique (Ex. : SYNTHESE) > objets du module (Ex. : PRIVATE_OBSERVATION,SENSITIVE_OBSERVATION).
3. L'utilisateur accède au module Synthèse.
   • Nous sélectionnons les permissions liées au module Synthèse
4. L'utilisateur fait une recherche dans Synthèse
5. Récupération de toutes les observations correspondant aux filtres de recherche utilisés et respectant le droit de lecture des données dans GeoNature.
6. Pour chaque observation, nous sélectionnerons la bonne géométrie à retourner :
   • droit de lecture des données (CRUVED ⇒ R=3) :
     • si observation de l'utilisateur
       • non sensible ⇒ géométrie précise
       • sensible ⇒ géométrie précise
     • si observation de son organisme :
       • non sensible ⇒ géométrie précise
       • sensible ⇒ géométrie sensible
         • si droit d'accès observation sensible applicable : géométrie précise
     • si observation d'un autre organisme :
       • si observation publique :
         • non sensible ⇒ géométrie précise
         • sensible ⇒ géométrie sensible
           • si droit d'accès observations sensibles applicable : géométrie précise
       • si observation privée :
         • non sensible :
           • avec niveau de diffusion ⇒ géométrie niveau de diffusion
             • si droit d'accès observations privées applicable ⇒ géométrie précise
           • sans niveau de diffusion ⇒ géométrie précise
         • sensible :
           • sans niveau de diffusion ⇒ géométrie sensible
             • si droit d'accès observations sensibles applicable ⇒ géométrie précise
           • avec niveau de diffusion :
             • si niveau de diffusion plus restrictif que niveau de sensibilité ⇒ géométrie niveau de diffusion
               • si droit d'accès observations privées applicable ⇒ géométrie sensible
                 • si droit d'accès observations sensible applicable ⇒ géométrie précise
             • si niveau de diffusion moins restrictif que niveau de sensibilité ⇒ géométrie niveau de sensibilité
               • si droit d'accès observations sensible applicable ⇒ géométrie niveau de diffusion
                 • si droit d'accès observations privés applicable ⇒ géométrie précise
7. Dans le cas d'un envoi pour affichage sur une carte, suppression des géométries en doublon.
8. Envoie des observations pour affichage sur l'interface cliente.