L’accompagnement du Cerema est proposé pour répondre à des besoins et demandes spécifiques concernant l'outil, cela peut être la mise à jour d'un diagnostic dans le cadre des missions PAPi, la mise en place d'observatoire de vulnérabilité, l'utilisation des diagnostics pour mettre en place des stratégies d'aménagement ... Le Cerema vous accompagne donc en priorisant avec vous les indicateurs nécessaires à la réalisation de vos objectifs (et on oriente le développement de l'outil suivant ces critères), en construisant des points de vue dédiés à vos attentes (gestion de crise, aménagement, porteurs de PAPi ...) et en produisant également des sorties cartographiques personnalisées.
Le coût varie en fonction du besoin et des tâches à réaliser ainsi que de la durée. Le fait d'être adhérent au Cerema permet également d'avoir des avantages et de réduire le coût.

Il peut y avoir deux raisons principales :

- soit la donnée n’a pas été correctement importée dans le plugin ;

- soit la donnée pour le calcul de l’indicateur souhaitée n’est pas disponible sur le territoire d’étude (ex : la donnée ERP - établissements recevant du public - de la BDTopo est incomplète sur certaines régions / départements)

Pour en savoir plus, se référer au détail des logs enregistrés dans “parametres_locaux/logs” dans le dossier du plugin.

La notion de point de vue a été créée à la suite d’un besoin exprimé des utilisateurs identifiés de personnaliser les regroupements d’indicateurs et leurs libellés en fonction de leurs missions locales.

Actuellement, trois points de vue sont intégrés dans l’outil :

- SNGRI : pour reprendre l’ensemble des indicateurs du guide méthodologique “Référentiel national de vulnérabilité aux inondations” à l’origine du projet AgiRisk ;

- Aménagement : pour aider à la mise en place de stratégies d’aménagement sur des territoires inondables ;

- Crise : pour faciliter l’identification et la localisation des enjeux en gestion de crise.

Cette catégorisation n’est pas exhaustive et d’autres points de vue sont d’ores et déjà en phase de construction pour les porteurs de PAPI notamment.

Deux raisons principales peuvent expliquer l’apparence grise (et non verte) des indicateurs et leur non-sélection :

→ soit les processus de calcul de ces indicateurs n’ont pas encore été programmés et implémentés dans l’outil ;

→ soit les étapes de calculs (variables, indicateurs et représentations cartographiques) n’ont pas été réalisées (auquel cas, il faut lancer les 3 étapes de ces calculs via les boutons en haut à droite de l’onglet “indicateurs”).

A terme, le site web d’AgiRisk (https://agirisk.cerema.fr/) contiendra le détail de la construction de chaque indicateur (et des variables associées). Pour le moment, pour toute question relative aux méthodologies, n’hésitez pas à nous contacter via la communauté.

Liste des indicateurs présents dans la v1 :

- Nombre de personnes occupant des bâtiments de plain-pied fortement inondables

- Nombre de personnes occupant un rez-de-chaussée fortement inondable

- Dommages aux logements en fonction de la hauteur d’eau et de la durée de submersion

- Dommages aux cultures en fonction de paramètres hydrauliques

- Surface de zones à urbaniser en zone inondable

- Population en zone inondable

- Surfaces agricoles inondables

- Capacités d’hébergement du territoire situées hors zone inondable

- Population âgée en zone inondable

- Salariés en zone inondable

- Logements en zone inondable

Indicateurs en cours de réflexion et/ou implémentation dans le plugin :

- Nombre de musées et de bâtiments patrimoniaux susceptibles d’être endommagés

- Emprise des bâtiments d’habitation pouvant être inondés

- Nombre de personnes dans les établissements à évacuation complexe / sensibles

- Nombre de personnes dans les établissements de santé vulnérables

- Nombre d’itinéraires routiers interceptés par des zones d’aléa dangereuses pour une personne

- Nombre d’installations susceptibles de déverser des produits polluants

- Dommages aux entreprises en fonction de paramètres hydrauliques et du délai d’intervention

- Dommages aux établissements publics en fonction de paramètres hydrauliques

- Nombre d’enjeux utiles à la gestion de crise susceptibles de dysfonctionnement

- Nombre de personnes dépendantes en zone de fragilité électrique

AgiRisk n’est pas conçu pour créer de la donnée d’aléa - cette dernière doit être produite ou détenue en amont par l’utilisateur.

Toutes les données d’aléas d’inondation peuvent être importées : débordement de cours d’eau, remontées de nappe, submersion marine, ruissellement. Il n’existe aucune restriction. 

Cependant, dans la v1, seule l'intensité d'aléa (faible, moyen, fort, très fort) est prise en compte.

C’est envisagé mais à ce jour les seules contraintes liées à la table d’aléa sont la présence d’un champ “intensite_alea”, comme cela est précisé dans la notice dédiée : https://cerema.app.box.com/file/1327358327728?v=agirisk-v1-notice-import

Pour cela il est recommandé d'importer cette table d'aléa au format Geopackage (.gpkg), pour éviter le troncage (à moins de 10 caractères) des noms de champs par Qgis.

Il faut veiller à bien renseigner chacun des champs présents dans le formulaire d’import dédié ci-dessous en fonction des informations indiquées dans la table attributaire de l’aléa et des connaissances sur l’événement.

Le plugin est mis à disposition sur le github du Cerema, à cette adresse : https://github.com/CEREMA/AgiRisk

Il faut ensuite cliquer sur le bouton vers “Code” puis “Download ZIP”.

Les notices relatives à la configuration et installation du plugin se trouvent à cet endroit : https://agirisk.cerema.fr/mise-en-oeuvre/notices

Les données sont transmises par département en contactant l’équipe projet à cette adresse : agirisk@cerema.fr en ayant au préalable fait une demande d’obtention des données foncières via le site “Datafoncier” : https://datafoncier.cerema.fr/obtention-des-donnees-foncieres

Attention, la livraison des fichiers fonciers ne peut excéder le périmètre de compétence de la structure. Dans le cas d’une livraison à l’échelle d’un département, il faut que cette structure ait fait la demande préalable sur ce périmètre.

Les données foncières sont soumises à des restrictions de diffusion du fait de leur caractère confidentiel.

Les bénéficiaires de ces données (gratuitement) sont les établissements suivants :

- Services de l’Etat,

- Etablissements publics de l’Etat,

- Collectivités territoriales,

- Agences d’urbanisme,

- EPF, SAFER, ADIL, OLAP, SCoT,

- Organismes de recherche,

- Infrastructures de données géographiques,

- Autres structures bénéficiaires de MAJIC.

La demande d'obtention des données foncières se fait via le site "Datafoncier" : https://datafoncier.cerema.fr/obtention-des-donnees-foncieres

La version actuellement supportée est la version 15 de PostgreSQL, téléchargeable ici : https://www.postgresql.org/download/
Les versions antérieures ou ultérieures peuvent entraîner des erreurs à l’installation du plugin et des incohérences dans le diagnostic.

La version actuelle du plugin ne permet pas de travailler sur une emprise intersectant plusieurs départements. Cependant, cette évolution est bien prévue dans une prochaine version.

La base de données peut être reconstituée sur un serveur distant, dans ce cas, à l'exécution du fichier _creation_base.bat (ou _creation_base.sh pour les postes sous Linux) il faut utiliser un compte ayant des droits de superuser sur la base de données présente sur le serveur (au cas où aucune base postgresql / extension postgis ne serait déjà présente sur ce serveur, il faudra bien sûr qu'un administrateur du serveur procède à l'installation de PostGreSQL/PostGis, en version 15 car nos premiers tests ont montré que le script de restauration n'était fonctionnel que sur postgresql15).
En fonction de la politique de gestion des droits de la base de données de ce serveur, il est bien sûr possible d'opérer la restauration "manuellement" (il faut simplement bien tout réintégrer).

• “Droit refusé pour le schéma “r_fichiers_fonciers”, “authentification par mot de passe échouée pour l’utilisateur "admin_agirisk”

Il s’agit nécessairement d’un problème à l’installation de la base de données et la solution la plus efficace est la ré-installation de la base de données à partir de l’étape 5 de la notice du plugin.

Au préalable, vous pouvez vérifier que la ligne 42 du fichier _creation_base.bat comprend bien l’information suivante : SET PGPASSWORD=AdminRisk*

• '“ERREUR:  la relation « r_ban_plus.adresse_2023_d0** » n'existe pas”, “erreur : _dep/d**/r_ban_plus.adresse_2023_d0**.sql : No such file or directory r_ban_plus.lien_adresse_bati_2023_d0**.sql”, que se passe t-il ?

Il s’agit d’une erreur d’accès au package de données de votre département. Il faut vérifier que le dossier _dep contient bien votre dossier d** dézippé.

Il est parfois possible que la première exécution du fichier _creation_base.bat renvoie des erreurs de types "commande invalide", il s'agit d'un bug qui sera résolu dans les prochaines versions de l'outil. Dans ce cas, il ne faut pas hésiter à relancer l'exécution du fichier .bat et l'installation doit normalement se dérouler correctement. Dans le cas contraire, contactez-vous par mail ou via la communauté.

Il s’agit dans la majorité des cas d’un problème dans l’installation de la base (absence du dossier _dep ou du dossier _commun en particulier lors de l'exécution du fichier _creation_base.bat) ou d’un souci dans le paramétrage du fichier _credentials_bdd.json qui doit contenir les informations rentrées lors de l'installation de PostGreSQL et notamment les identifiants de connexion à la base de données, choisis à votre convenance.

Par exemple :

"hostname": "127.0.0.1",

"port": "5432", (en fonction de votre installation de PostgreSQL)

"bdd": "agirisk_v1",

"login": "admin_agirisk",

"mdp": "AdminRisk*"

Il est tout à fait possible, et souvent préféré par habitude, de proposer postgres/postgres comme login/mdp pour la connexion à la base.

En tout cas, actuellement le plugin ne s'ouvre pas si la base n’est pas correctement reconstituée. Une évolution pour pallier ce problème est prévue en 2024.

Il s’agit d’une mauvaise installation de la base de données en amont de l’utilisation du plugin. Attention à bien utiliser la version 15 de PostGreSQL pour éviter toute surprise !

Quatre options possibles :

Option 1, la plus rapide mais peu optimale :
- si ce n'est déjà fait, ajouter dans QGIS une nouvelle connexion PostgreSQL à la base "agirisk_v1" locale créée au moment de l'installation de l'outil AgiRisk ;
- ouvrir et rendre éditables successivement dans QGIS, les tables "zx" et "zq" présentes dans le schéma "c_phenomenes" de la base "agirisk_v1" ;
- supprimer manuellement les enregistrements "en double" dans chacune de ces deux tables, puis réenregistrer celles-ci ;
- rouvrir ensuite le plugin AgiRisk, réimporter le périmètre du territoire sous un nouveau nom encore non utilisé, puis importer, en une seule fois, la couche d'aléa pour ce nouveau nom de territoire ;
- relancer les calculs des variables, indicateurs et représentations cartographiques.
Il est en effet nécessaire de saisir un nouveau nom de territoire, et non forcément utile de supprimer les entités de la table "territoires" du schéma "c_general", pour pouvoir relancer tous les calculs. Dans le cas contraire (utilisation ou reprise d'un nom déjà saisi auparavant dans la base), les indicateurs resteront au vert dans le plugin, sans possibilité d'un recalcul correct.

Option 2, si vous êtes à l'aise en SQL : à partir d'une fenêtre de requête SQL dans QGIS ou d'un logiciel de gestion de base de données tel que pgAdmin ou DBeaver, se positionner dans la base "agirisk_v1" locale, puis lancer les commandes SQL suivantes, en les répétant autant de fois que ce territoire a pu être saisi sous un nom différent dans le plugin :

DELETE FROM c_phenomenes.zx WHERE territoire = '[remplacer ici par le nom1 du territoire saisi dans le plugin]';
DELETE FROM c_phenomenes.zx WHERE territoire = '[remplacer ici par le nom2 du territoire saisi dans le plugin]';
...
DELETE FROM c_phenomenes.zq WHERE territoire = '[remplacer ici par le nom1 du territoire saisi dans le plugin]';
DELETE FROM c_phenomenes.zq WHERE territoire = '[remplacer ici par le nom2 du territoire saisi dans le plugin]';
...
Rouvrir ensuite le plugin AgiRisk, réimporter le périmètre de ce territoire sous un nouveau nom encore non utilisé, puis importer, en une seule fois, la couche d'aléa pour ce nouveau nom de territoire, et relancer enfin les calculs des variables, indicateurs et représentations cartographiques.

Option 3, la moins dégradée : reconstituer la base de données "agirisk_v1" de nouveau en suivant la notice d'installation comme à l'état initial (la base sera automatiquement effacée et remplacée par la structure originale)

Option 4, la plus complexe : une quatrième option, pour éviter la réinstallation complète de la base de données, pourrait être d'exécuter le même type de commande SQL qu'à l'option 2, mais pour toutes les tables des schémas "c_general", "c_occupation_sol", "c_phenomenes", "p_indicateurs" et "p_rep_carto".
Supprimer complètement une ou plusieurs de ces tables, et non seulement leurs enregistrements, impliquerait de réinitialiser leur structure avec leurs attributs. Une procédure d'initialisation de la base de données existe, son exécution seule permettrait d'effacer et de réinitialiser automatiquement toutes les tables, mais elle ne permet pas à ce jour de réinitialiser les tables d'aléas. Il est donc moins fastidieux de restaurer entièrement la base de données comme expliqué dans l'option 3.
Avec l'option 4, il faudrait également supprimer toutes les vues matérialisées présentes dans ces schémas pour éviter de mauvais affichages dans le plugin. Ces vues sont désignées par le nom de la table ("zx", "zq") suivi du nom du territoire d'étude. La commande SQL à lancer est de type "DROP MATERIALIZED VIEW IF EXISTS nom_du_schema.nom_vue_materialisee CASCADE;". Il est également possible de supprimer les vues depuis l'explorateur de couches sous QGIS : clic droit sur la vue > Gérer > Supprimer la couche.

A ce jour les indicateurs sont calculés avec des données nationales (pour faciliter l’accès aux données, les tests de construction et de résultats des indicateurs) mais il est envisagé de prendre en compte l’expertise locale et les données associées crées par les territoires, sous différentes formes :

- par le biais d’une remontée de corrections à appliquer aux référentiels ;

- par le biais d’un partenariat spécifique permettant ainsi l’intégration de vos données et leur prise en compte dans la base et le calcul de l’indicateur associé.

Stack Builder est un gestionnaire de packages nécessaire à l'installation et à l'activation d'extensions telles que PostGis, indispensable à l'utilisation du plugin.

Dans le cas où votre structure bloquerait l'installation de PostGis via cet utilitaire, il est tout à fait possible, après installation de PostGreSQL, de lancer l'installation de PostGis via l'exécutable dédié. Il faut cependant veiller à ce que la version de PostGis soit la même que celle installée pour PostGreSQL.