search

PnX-SI / gn_module_cmr

Module GeoNature pour les protocoles utilisant la méthode de "capture-marquage-recapture"
0 stars 1 forks source link

CMR = suivi de site + suivi d'individus #3

Closed Amegilla closed 1 month ago

Amegilla commented 4 years ago

La prestation lancée par la SHF et réalisée par Geofit a pour but de développer un module CMR. Le besoin d'un module CMR pour la SHF est lié à la Cistude d'Europe mais le module doit rester générique et utilisable pour d'autres espèce(s). J'ouvre un nouveau ticket pour relancer la discussion sur les choix de développements de ce module, surtout avec la sortie récente du module monitoring qui répond déjà en grande partie au besoin. Il manque évidement la partie suivi des individus.

Je me pose quand même la question de l'utilité de partir sur un module neuf ou bien de développer cette partie suivi des individus dans le module monitoring et la rendre (dés/)activable.

camillemonchicourt commented 4 years ago

Je ne connais pas assez le protocole CMR. Mais si il s'agit uniquement de visiter des sites prédéfinis, de faire des observations lors de ces visites. Et quand on fait une observation de pouvoir l'associer à un individu préalablement créé, alors ça peut coller.

Mais je doute que cela soit si simple. Si on doit aussi avoir des entrées par individu par exemple, alors le module Monitoring risque d'être limité pour cela. A voir selon les besoins.

https://github.com/PnX-SI/gn_module_cmr/issues/1 est-il toujours d'actualité ou à compléter/reprendre ?

Amegilla commented 4 years ago

D'après moi l'entrée par individu se fait hiérarchiquement dans une visite. Chaque site (ici des pièges) doit être relevé et soit il n'y a pas d'individus capturés soit il y a. c'est dans le cas où il y a des individus que l'on arrive sur la partie sur les individus.

Avec les choix suivants :

Et cela implique par ailleurs une interface pour visualiser la liste des individus associée à une campagne, et de pouvoir accéder au listing des captures de chaque individus.

On peut repartir de l'issue #1 oui.

DonovanMaillard commented 4 years ago

Salut,

Pour moi, la CMR est en effet un "cas particulier" de suivi, sur lequel on n'enregistre pas à proprement parler des "observations" d'individus inconnus, mais simplement on observer des individus déjà identifiés à l'avance ou susceptible d'être réobservés.

En y réfléchissant, si on veut garder deux modules avec des interfaces très claires (et des modales d'info sur les individus) avec l'idée "1 protocole = 1 module", il faut quasiment "dupliquer" le module de suivi, conserver les parties site/visite sans changements, et remplacer le niveau "observation" par un niveau "individus".

Les différences seraient que ce module là stockerait une liste d'individus avec des champs communs et non plus des observations totalement indépendantes les unes des autres:

Je pense qu'il est intéressant de prévoir un paramètre "constant" booléen dans la conf individual.json. La biométrie par exemple peut être saisie à chaque fois, mais le sexe doit pouvoir ne pas être demandé à toutes les rencontres (et on peut imaginer tout autre champs qui ne se renseigne qu'à la création de l'individu : place de marquage, type de marquage, numéro de la bague ou autre).

Niveau interface, comme dit Romain :

Ensuite, il faut effectivement prévoir sur l'accueil de chaque sous-module de rechercher directement un individu, et d'en tirer la liste des sites et visites où il a été rencontré. Et si possible, pouvoir télécharger ces infos "individus" avec l'ensemble des constantes, variables, sites et visites. Et selon les budgets, on peut même imaginer que face à cette recherche, une carte affiche les déplacements de l'individu en reliant ses différents sites visités.

DonovanMaillard commented 4 years ago

D'ailleurs je ne repartirais pas vraiment du #1, le module de suivi est trop proche de l'attendu pour repartir de la page blanche qu'on avait abordée il y a 2 ans.

Il y a sans doute des éléments à y reprendre dans les "champs utiles" mais, finalement, ca serait à chacun de les mettre ou non dans ses champs additionnels puisqu'il y a peu d'infos "thématiques" en dur à l'arrivée.

TheoLechemia commented 3 years ago

Salut à tous, Merci Donovan pour tes réflexions. Oui en effet, je pense qu'il faut repartir du module monitoring. Pour la maintenance, il faut essayer de factoriser un maximum de chose. Le backend, le tronc commun de la base, le mécanisme de génération automatique des champs additionnels et faire des ajouts côté base et front. En base, pour les ajouts niveau "individu", est-ce qu'on pourrait pas étendre la table gn_monitoring.t_base_visits dans un schéma dédié gn_cmr sur le modèle de ce qui a déjà été fait sur suivis habitat territoire: https://github.com/PnX-SI/gn_module_suivi_habitat_territoire/blob/master/data/sht.sql ?

joelclems commented 3 years ago

Je verrai bien

la variable tree serait:

module: {
  individus: {
    observation_individu: {}
  },
  site: {
    visit: {
      observation: {}
    }
  }
}
DonovanMaillard commented 3 years ago

Je garderais quand même la possibilité de créer un individu pendant la saisie je pense, c'est plus intuitif que de devoir créer ses individus distinctement. Ca a aussi l'intéret de connaitre le site et la visite sur lesquels l'individu a été marqué (donc créé) la première fois.

FlorentRICHARD44 commented 3 years ago

Bonjour, Je suis Florent RICHARD, développeur chez GEOFIT. Nous travaillons actuellement sur un module CMR Cistude pour la SHF. Suite à une première maquette faite par la SHF, à la présentation du besoin de la CMR Cistude par @RomainBaghi et notre réflexion interne, nous avons préparé un maquettage des principaux écrans nécessaires ainsi qu'un diagramme de classes dans l'objectif de répondre au besoin exprimé par la SHF. Voir PDF joint Conception_module_CMR_v1.pdf

Il apparait que certains éléments se rapprochent du module de suivi, mais il y a aussi pas mal de besoins supplémentaires, voire peut-être différents.

En espérant que cela aidera à avancer les réflexions.

camillemonchicourt commented 3 years ago

OK, merci pour le partage du document qui permet de faire avancer la réflexion et de préciser le besoin. Je pense qu'il faut maintenant élargir cette réflexion et la resituer par rapport à l'existant dans GeoNature et notamment le module Monitoring. Cela passe aussi par une simplification des besoins si l'on veut être plus générique.

Cela me semble confirmer que l'on peut s'appuyer sur le module Monitoring, en remplaçant les observations de taxon par des observations d'individus et en ajoutant une partie de gestion, consultation des individus.

Dans ce contexte, quelques premières remarques :

DonovanMaillard commented 3 years ago

Bonjour @FlorentRICHARD44 ,

Je viens de regarder le document, sur certains points il confirme je pense la nécessité de ne pas partir d'une page blanche et de s'appuyer sur le module monitoring, qui à mon sens apporte déjà 50% des réponses à ce besoin CMR. Sur d'autres points, ce document devrait permettre de recaler les besoins communs à toutes les CMR, et identifier ce qui est propre au protocole cistudes (l'approche pièges etc), il y a des infos qui apparaissent ici comme des constantes de la méthode CMR mais qui en réalité sont variables selon les espèces qu'on va suivre.

En voyant cette proposition, je repars dans l'idée que les notions de site + visites du module monitoring peuvent être reprises "à l'identique" (dans la logique en tous cas, mais en y ajoutant des fonctionnalités comme l'import de gpx par exemple), et qu'il faut essentiellement implémenter une "bibliothéque d'individus" et revoir la saisie au niveau des observations.

La notion de campagne évoquée ici n'est pas claire pour moi, elle vient à l'interface entre ce qui pourrait être une visite, un ensemble de visites ou un jeu de données. Nous échangerons sur le sujet mercredi mais je pense que ce niveau là peut être évité. (Si une saison est découpée en "campagne de printemps, campagne d'été, compagne d'automne par exemple, ca peut se renseigner dans un champs additionnel avec liste déroulante).

Pour cette prestation, je pense personnellement qu'il y a un très fort potentiel en "économisant" le temps sur le modèle de données et la partie "sites + visites" (déjà développés pour monitoring), et en reportant tout ce temps pour ce qui est spécifique à la méthode CMR :

Tout ça n'est que mon avis, mais je trouverais dommage de redévelopper un module de A à Z alors que la CMR n'est qu'un cas particulier de suivi, avec un module déjà particulièrement efficace :)

DonovanMaillard commented 3 years ago

Après échanges avec mon collègue, qui applique des CMR sur le terrain, il me fait des retours qui poussent à réfléchir le module un peu différemment en termes d'ergonomie :

FlorentRICHARD44 commented 3 years ago

Merci pour vos commentaires.

J'en déduit que derrière un même terme "CMR", il y a des façons de procéder différentes pour des études et analyses statistiques différentes ensuite:

Il y a évidemment des points communs entre les différentes méthodes, mais je pense que l'expérience utilisateur doit être différente selon les cas. Par exemple éviter de remplir 20 fois la même information pour la visite d'un site si 20 individus y ont été capturés ou filtrer les individus sur un site précis pour faciliter la recherche en CMR orientée "site" versus accéder directement à un individu pour indiquer sa position en CMR orientée "individu". Les requêtes statistiques proposées dans le module doivent également être différentes selon les cas de CMR.

Si vous avez éventuellement d'autres exemples de cas d'application de CMR pour faire avancer la réflexion. Merci

DonovanMaillard commented 3 years ago

Bonjour,

En effet la CMR peut avoir 2 usages principaux à ma connaissance :

En préparation de notre échange de vive voix, je suis en train de préparer une "maquette" pour illustrer un peu ce qu'on peut avoir en tête pour concilier les 2, tout en restant sur des interfaces et un fonctionnement simple.

DonovanMaillard commented 3 years ago

La maquette que j'aurais en tête pour concilier les 2 cas :

maquette module cmr.pdf

Ca fait un "beau module", mais un nombre important de choses peuvent être "recyclés" depuis les autres modules :

DonovanMaillard commented 3 years ago

Re-Bonjour,

Après discussions avec @RomainBaghi ce matin, puis @camillemonchicourt ce midi, voici une maquette mise à jour.

maquette module cmr.pdf

Une question se pose autour des localités qui peuvent ou non selon les cas être récurrentes. A voir comment faire cohabiter les 2 possibilités, une proposition est faite ici mais la notion de localités "récurrentes" ne convainc pas Camille.

camillemonchicourt commented 3 years ago

Merci, ça prend forme. Mes remarques :

DonovanMaillard commented 3 years ago

Sur la première remarque, j'étais en train d'enlever l'entrée action justement, elle est de trop en effet.

Sur le point deux je ne suis pas d'accord, quand je fais une saisie j'ai pas envie de devoir passer à chaque fois par la modale d'info du site/de l'individu, le sélectionner me suffit

Pour les exports oui, garder la logique des autres modules (donc "exporter les sites", "exporter les individus" et dans la modale "exporter l'historique" d'un individu donné

p8 t'embête pas, je suis en train de la compléter /mettre à jour suite à ces changements =D

Je suis également en train d'enlever la notion de sites récurrents ou non pour simplifier les choses, tout en gardant les 2 cas d'usage de la CMR

Amegilla commented 3 years ago

Effectivement cela prend forme. Donc les développements vont partir d'un module "neuf" et reprendre pas mal de choses du module monitoring. A voir si certains choses seront à mettre dans le coeur de geonature, mais pour l'instant je n'en vois pas.

Ok pour les onglets individus et localités sur la page d’accueil. Coté carte je serais d'avis d'afficher tout les géométries d'individu si l'on est sur l'onglet individu et toutes les localités si l'on est sur l'onglet localités avec ensuite les interactions classiques entre la carte et le tableau.

Il manque pour notre besoin l'organisation par Aire d'étude/population étudiée/groupement de sites (peu importe comment on veut l'appeler). Ce niveau est directement lié au jeu de donnée mais pour l'instant je n'ai pas une idée claire de la façon dont il faut l'implémenter. C'est aussi à partir de là que va s'appliquer le cruved. Pour l'utilisation de la SHF, il n'y a pas d’intérêt à ce que sur la page d'accueil, on ait dans les tableaux tout les individus de france ou tout les localités de france... Chaque opérateur a besoin de voir les information liées à une Aire d'étude/un jdd en premier (cela implique de filtrer par jdd avant de peupler les tableaux. La solution d'avoir cette information dans le tableaux et de pouvoir filtrer dessus ne me satisfait pas pour l'instant.

Coté interface, la carte prend 50% de l'écran, dans certains cas j'imagine plus la carte prendre 25% de l'écran et donner plus d'ampleur au tableau, cf maquette de Florent. Et surtout mettre les boutons d'ajout en haut à droite du tableau plutôt qu'en bas car cela force souvent l'utilisateur à scroller car le bouton n'apparait pas ou qu'à moitié.

Pour les exports, nous avons dans la prestation prévu des exports csv et des exports pdf formatés pour les fiches individus notamment (à la façon export des métadonnées dans geonature).

J'ai rebouclé avec Florent qui proposera une nouvelle version de sa maquette dans les jours qui arrivent.

DonovanMaillard commented 3 years ago

Merci Romain pour ces compléments,

Je suis en train de finaliser, et je t'envoie, une version plus aboutie qui intègre toutes nos remarques ce matin, nos échanges avec camille et mon collègue cet après midi. Ca intègre des exports ;)

Concernant les jeux de données, il sera rare dans ton cas qu'un utilisateur ait plusieurs jeux de données dans le module CMR Cistude. La solution vue ce matin, à savoir choisir automatiquement le seul jeu de données disponible, serait transparent pour tes utilisateurs, tout en restant permissif pour ceux qui interviennent dans le cas de plusieurs jeux de données.

Pour le regroupement de sites, tu peux aussi prévoir un menu déroulant dans tes champs additionnels, avec une liste fermée de "groupes de sites". Comme ca c'est applicable sur certaines CMR mais pas forcément une logique imposée à tous les sous-modules.

Pour les cartes dans l'onglet individu je suis d'accord, je préfèrerais aussi voir toutes les localités de cet individu, mais camille trouve que ce n'est pas logique (dans occtax par exemple on charge que les dernières infos saisies, donc la dernière localité lui semblait plus pertinente, à voir).

Pour l'affichage de toutes les données ou que celles de son organisme, ça peut se faire par le CRUVED (portée=mon organisme ou portée=mes données) simplement. Quelqu'un qui est dans un organisme qui intervient avec 2 jdd voit ainsi les données de ses 2jdd et peut filtrer. Les autres ne voient que les données de leur organisme, donc du jdd qui correspond à leur organisme.

Coté interface, pas forcément d'avis sur la taille de la carte, la diminuer une fois que la géométrie est dessinée peut etre très bien, mais je pense qu'il est important de ne pas scinder un même formulaire de saisie. Pour les boutons en revanche, je pense qu'il ne faut pas les mettre en haut, ça ne serait pas homogène avec les autres modules.

En espérant que cette nouvelle maquette complétée puisse vous faire gagner du temps ;) maquette module cmr2.pdf

camillemonchicourt commented 3 years ago

Merci pour ces éléments. Si vous voulez qu'on puisse analyser tout ça au niveau technique, il va nous falloir quelques temps pour digérer tout ça.

Il y a notamment un point important de vigilance. Si il semble possible de réutiliser pas mal d'éléments du module Monitoring, alors il faudrait dupliquer le moins de code possible, voir aucun. Mais à voir comment.

Pour les groupes de site (optionnels selon les protocoles), voir ce qui est prévu au niveau du Monitoring.

Je ne pense pas qu'il faille fixer les JDD au niveau des groupes de sites (aires d'étude) car ça rendrait l'approche et donc le module spécifique. A creuser.

FlorentRICHARD44 commented 3 years ago

Bonjour,

suite à toutes ces discussions, j'ai préparé une nouvelle maquette qui reprend les écrans déjà maquettés par @DonovanMaillard et en détaille également d'autres. SHF_CMR_Cistude.pdf Cette nouvelle version du PDF de maquette inclue des liens dans certains boutons, onglet et hyperlien, qui permet de naviguer entre les écrans.

J'ai refait également un petit document sur la conception pour le vocabulaire et le diagramme de classe qui se trouve plus simple que la version précédente. Conception_module_CMR_v2.pdf

Amegilla commented 3 years ago

Merci Florent pour cette nouvelle maquette. à première vue on commence à avoir une trame qui colle bien au besoins de la CMR en général et de la CMR cistude.

Parmi les points qui restent à éclaircir : Comment gérer les groupements de sites et les jdd? J'ai beau le tourner dans tout les sens, je ne vois pas comment faire sans. D'autant plus qu'après discussion avec mes collègues de la SHF, il y a aura souvent le cas ou le même organisme aura au moins 2 CMR cistude à sa charge.

Voici ce que j'ai en tête (en reprenant la structure de monitoring) :

Le regroupement de site comme imaginé pour le module monitoring a ses limites ici car il faut alors aussi grouper les individus , qui ne sont pas toujours associés à des sites (cas d'une capture opportuniste) et donc lourd à gérer.

camillemonchicourt commented 3 years ago

Dans le module MONITORING, les JDD sont associés à un niveau fin, celui des visites. En effet cela ne semble pas générique de les définir au niveau des groupements de site, qui ne concernent pas tous les protocoles de Monitoring, comme de CMR. A creuser.

DonovanMaillard commented 3 years ago

Pour le cas des jeux de donnees, des lors qu'un utilisateur en a plusieurs possibles je ne vois pas comment faire pour qu'il n'ait pas a le sélectionner. Qu'il selectionne une aire d'étude ou un jeu de donnees en soit ne changera rien.

Ensuite un utilisateur aura accès aux donnees de sa structure (portee 2 du cruved) donc il verrait par defaut les donnees de ses 2 aires d'études par exemple. A lui lors de la saisie de définir pour quel jeu de donnees il fait sa saisie.

Au pire des cas prevoir un paramètre pour faire comle le module d'import, c'est à dire sélectionner le jeu de donnees dans une modale des l'ouverture du sous module. Maos ce n'est pas generique et si cetzit une solution ca devrzit rester un fonctionnement desactivable à mon avis.

FlorentRICHARD44 commented 3 years ago

La sélection d'un jeu de données à l'entrée du sous-module parait une bonne solution, et permet notamment d'éviter de créer trop d'écrans de saisie. Nous allons prévoir que cela soit activé/désactivé selon la configuration du sous-module, pour rester compatible avec les cas qui n'ont pas ce besoin.

DonovanMaillard commented 3 years ago

Ok, donc on serait sur l'idée que :

Du coup par cohérence ca impliquerait que : Dans le premier cas, le contenu du module affiche les données en fonction du CRUVED de l'utilisateur + filtré sur le JDD choisi Dans le second cas, le contenu du module affiche les données uniquement en fonction du CRUVED de l'utilisateur.

Pour @RomainBaghi ça implique aussi qu'avec ce fonctionnement, tes utilisateurs risquent de chercher leurs données plus d'une fois. S'ils ont 2 jeux de données possibles, leur module n'affichera jamais les données de leurs 2 jdd puisqu'il sera sélectionné dès l'ouverture du sous-module. A voir si c'est souhaitable.

Cette solution semble un compromis pour répondre aux besoins génériques et au cas de la SHF mais je reste assez dubitatif à l'usage. A voir.

camillemonchicourt commented 3 years ago

Hum, alors j'ai peut-etre raté quelque chose, mais je comprends pas (du tout du tout) l'idée de demander de selectionner un JDD à l'ouverture d'un sous-module de CMR. Peu ergonomique, peu compréhensible et pourquoi faire ??? Filtrer ensuite les données avec un filtre général demandé au début ??? Jamais croisé un truc du genre. Mauvaise solution à mon avis.

FlorentRICHARD44 commented 3 years ago

Bonjour,

@camillemonchicourt Le besoin est d'avoir un seul sous-module de CMR et qui soit utilisé par plusieurs organismes/utilisateurs. Chacun travaille sur 1 ou plusieurs aires d'études, mais ne doit pas avoir accès à toutes les aires du sous-modules. Par exemple:

Le moyen le plus simple de filtrer ces accès est d'utiliser les JDD. il faut créer un JDD par aire d'étude, lui assigner les utilisateurs correspondants, et ensuite pas besoin de gérer des groupes de sites dans la CMR puisque l'aire d'étude est déjà représentée par le JDD sélectionné. Les exports CSV correspondants des sites et des individus permettent ainsi de n'avoir que les données d'un JDD (donc d'une aire, sans avoir à filtrer ni voir d'autres données). Cela correspond à une navigation: Accueil GeoNature > Module CMR > Sous-Module CMR Cistude > Choix du jeu de donnée > Arrivée sur la page Module/Sites/Individus. Sur cette page, on peut proposer un bouton permettant de changer de jeu de données directement (sans avoir à repasser par l'entrée du sous-module).

Effectivement, cela correspond à un usage pour des CMR sur des aires et individus bien cloisonnés. Comme ce n'est pas le cas de toutes les CMR, ce comportement sera activé via configuration du sous-module.

@RomainBaghi merci de me corriger si j'ai mal compris ou mal interprété le besoin.

@tous N'hésitez pas à faire des propositions si vous avez une meilleure solution pour gérer les droits de chaque aire d'étude et qui conviendrait à tout le monde.

camillemonchicourt commented 3 years ago

Oui mais c'est le CRUVED et les droits de portée 1 (mes données), 2 (les données de mon organisme) ou 3 (toutes les données) qui gèrent ce que l'on voit ou ce que l'on peut créer/modifier/supprimer. C'est pas en sélectionnant un JDD à l'ouverture du module. Pas besoin ni pertinent selon moi. Je pense que c'est pas fonctionnel, ni ergonomique, et difficilement maintenable si paramétrable.

Le sujet central est surtout à quel niveau sont associés les JDD. C'est compliqué si on les met au niveau des groupes de site, car il n'y en a pas pour tous les protocoles, donc peu robuste et générique. A voir comment on peut gérer cet aspect.

DonovanMaillard commented 3 years ago

C'est un besoin que je ne comprends pas bien non plus, les modules au délà du CRUVED appliqué, peuvent dans tous les cas filtrer les données par JDD :

Dans tous les cas, l'endroit où définir le JDD reste "un soucis", puisque selon les pratiques de chacun, on ne rattache pas tous l'information au même endroit. Les JDD de la SHF dans ce cas sont associés à des sites voire un ensemble de sites, chez Flavia on fonctionne avec 1JDD=1prestation : Si on passe 3 prestations avec quelques années d'écart par exemple, on a besoin de voir nos 3JDD qui se dérouleront sur un même réseau de sites (ou hors de sites bien définis) -> dans notre cas il nous faudrait associer le JDD au niveau de l'action... mais j'ai bien conscience que ni nos pratiques ni celles de la SHF sont plus génériques l'une que l'autre.

Coté développements, le JDD est un "widget" qui devrait pouvoir être appelé à n'importe quel niveau pour que la généricité du module soit vraiment au top. Reste que l'id_jdd doit être facile à retrouver coté BDD pour les filtres et requêtes justement, les envois vers la synthèse etc... L'une des idées qu'on pourrait imaginer serait d'avoir une correspondance entre un dataset d'une part, et un "item" d'autre part : un id_site, un id_action, un id_individu... et que le widget dataset puisse renseigner cette correspondance. Avec ce fonctionnement on peut même imaginer de rattacher un site ou un individu à plusieurs JDD...

En complément, si à terme un item "réseau de sites" est créé le JDD pourrait y être rattaché de la même manière du coup...

On peut même imaginer que du coup, l'ensemble des liens entre les différents objets passent par cette table... Un id_dataset, un id_site, un id_individu et un id_action dans cette table de correspondance. Faudrait bien réfléchir aux contraintes de cette table centrale mais sur le papier ca semble une piste :)

camillemonchicourt commented 3 years ago

Je dirai plutôt qu'il faut rattacher les JDD à qu'un seul niveau dans la BDD, les actions à priori, comme dans le module Monitoring où c'est sur les visites. Mais permettre de définir à quel niveau on le saisit dans la conf du module.

DonovanMaillard commented 3 years ago

Et c'est là que ca coince, je réfléchissais mais mon truc ne peut pas marcher.

Tu vas d'abord créer un site ou un individu, qui n'aura donc pas d'action dans un premier temps. Du coup, tu stockeras pas de JDD en base même si tu le saisis dans ce formulaire, aucune ligne ne correspondra dans la table actions...

Ensuite si tu rattaches le JDD à un site comment fait on pour les individus, tu peux les créer mais comment ça se passe niveau cruved, ils seront associés à aucun jdd et inversement. Je pense qu'il faut bien réfléchir à ce point là... il faut qu'on sache comment on rattache les données au JDD, avant de pouvoir les filtrer :) tout en restant souple sur la possibilité d'avoir une entrée site + une entrée individus

FlorentRICHARD44 commented 3 years ago

Bonjour, suite à la réunion du vendredi 02 Octobre, voici une mise à jour du maquettage avec:

SHF_CMR_Cistude_3.pdf

J'en profite pour noter ici les principaux mot-clés utilisés avec la définition (je pense que tout le monde était plutôt d'accord pendant la réunion):

Pour faciliter la compréhension par l'utilisateur, les termes ci-dessus seront configurables dans le sous-module.

camillemonchicourt commented 3 years ago

Merci, voici quelques retours sur la maquette, même si j'ai pas tout suivi en détail, ce n'est qu'un avis :

FlorentRICHARD44 commented 3 years ago

Quelques réponses:

camillemonchicourt commented 11 months ago

Il est plutôt retenu d'ajouter le concept d'individu dans MONITORING. Voir https://github.com/PnX-SI/gn_module_monitoring/issues/213