Le portail francophone de la géomatique

Bonjour.

Je suppose que nombreux seraient ceux qui pourraient vous donner des conseils dans ce forum, mais pour cela, il faudrait préciser quelques points:
- dans quelle structure travaillez-vous?
- de quelle production s'agit-il? Quelles données en entrée? Quelles données en sortie?
- Quel est le contexte de cette production? De ce déploiement?

Merci pour ces précisions qui nous permettrons d'être plus précis dans nos réponses à notre tour.

Bonjour.

Encore une petite question (non fondamentale): Qu'entendez-vous par patrimoine non bâti? S'agit-il du patrimoine agricole, naturel, humain, l'ensemble?

Diagnostiquer veut dire: analyser ce qui n'est pas conforme. Conforme à quoi? Justement, il s'agit d'abord de se poser cette question, avant toute chose. Vous avez été recruté pour répondre à une demande. Quels sont les fondements de cette demande? Quel est le besoin (ou quels sont les besoins), les attentes, par rapport à cette base de données? A quoi doit-elle servir?
Dans un second temps, le diagnostique n'est plus que le constat des différences entre la réalité et ces attentes théoriques.
Une méthode (d'autres pourraient ajouter leur contribution):
- lister tous les utilisateurs de cette base de données (de près ou de loin, fréquents ou occasionnels),
- les identifier clairement (qui sont-ils, quelle est leur fréquence supposée, quels sont leurs usages supposés, quels liens ont-ils entre eux, avec les autres services, avec l'extérieur? quels sont leurs droits d'accès?).
- interroger ceux qui ont des droits en lecture seule (données utilisées, pour faire quoi, quelle fréquence d'utilisation? besoins satisfaits, besoins insatisfaits, pourquoi? Attentes de la future base de données en terme de données, mais aussi en terme de fonctionnalité, d'ergonomie, de métadonnées)
- interroger ceux qui ont des droits en lecture/écriture (mêmes questions que précédemment + quelles sont leurs procédures de production, de mise à jour, leurs attentes, leurs desideratas non satisfaits)
- interroger les administrateurs (mêmes questions que précédémment + quelles sont les procédures d'administration, attentes, insatisfactions...)
- en déduire une analyse et une synthèse.
- à ce moment-là, vous confirmerez sans-doute qu'il faut homogénéiser les couches d'informations, mais surtout, vous saurez pourquoi, et connaîtrez les détails des besoins relatifs à ce regroupement entre couche bâtie et non bâtie. Vous aurez aussi de nombreuses autres informations précieuses sur les données, sur les fonctionnalités, sur l'ergonomie, sur les procédures, sur l'administration...
- Vous pourrez en déduire un plan d'action, avec estimation des charges et des délais.
- Vu que vous êtes en stage, les décisions qui suivront viendront de votre hierarchie. A vous de bien présenter votre synthèse et votre plan d'action pour que les bonnes décisions (selon vous) soient prises (selon ce qui est démontré, il est possible d'influencer votre hierarchie, c'est même ce qu'ils attendent de vous: un avis technique).
- Ensuite, il y a aura le travail technique proprement dit. Il ne viendra qu'à ce moment là, mais si ce qui précède a été bien fait, il sera fortement facilité. Mieux vaut passer du temps en amont pour bien concevoir un projet que se lancer dedans tête baissée et se rendre compte au milieu qu'il faut tout recommencer.

Tout cela doit vous paraître à la fois évident (vous y auriez sans doute pensé de vous-même) et décourageant (sur le papier, ça a l'air de demander beaucoup de temps et de savoir-faire). Voyez-le comme une feuille de route qu'il faut essayer de suivre, qui est plus un guide, une aide, qu'un chemin de croix.

Bon courage. Je laisse la place aux autres pour qu'ils ajoutent leurs propres suggestions.