Le portail francophone de la géomatique

Merci pour votre réponse rapide et pour info la fusion concerne deux intercommunalités

Bonjour
je me permet d'intervenir car j'ai fait la même erreur de vouloir organiser les données en fonction des thématiques et c'est là qu'on construit une usine à gaz parce qu'on n'a pas fait le pont entre des données qui sont exploités dans plusieurs services et des mises à jour qui ne se font pas.
Donc effectivement :
- commencer par identifier le besoin. C'est probablement le travail qui à la fois normalement le plus facile parce que normalement chaque service est sensé savoir de quoi il a besoin pour travailler et pourtant ce n'est pas une démarche que les gens font facilement. du coup ils reviennent plus tard en disant mais il y a ça aussi et ça et on pourrait faire tel truc et ca serait cool si on pouvait rajouter ca et ca aussi ...
Donc il faut passer du temps pour définir le besoin. J'estime cette étape à 80 % de la réussite d'un projet de ce type.
- ensuite par l'analyse des besoins on pourra constater que des données sont réutilisé pour plusieurs services, c'est juste une question de vocabulaire ou de présentation.
L'analyse du besoin prendre 15% du temps.
Et la construction de la base en elle même si le besoin a bien été réalisé, c'est juste 5% ...

Le plus gros souci que j'ai rencontré est une problème de communication.
Je travaille pour les services techniques des collectivités, qui ont des besoins.
Je fais l'intermédiaire avec les développeurs. Et il y a certains mots qui ne veulent absolument pas dire la même chose.
Donc pour identifier le besoin, il ne faut pas aborder le contenu technique/Base de données.

Le métier/Client/commune effectivement vous donnera des informations par thématique ...
Ensuite : identification des besoins.
Votre travail réalisé les ponts entre les services regroupés les données et simplifier ...

il y des documents techniques de développeur je crois qu'il appelle les uses  je ne sais pas plus ... ensuite de quelle données on a besoin et on remonte. J'avais construit un "dictionnaire des données".
vous prenez votre service il a besoin de quoi ? et on fait ca première liste. Ensuite votre deuxième service service il abesoin de quoi et il y aura déjà des données dans votre dictionnaire ... A ce stade on n'a pas encore construit la base de données. on a juste lister ce qu'on doit avoir dedans.
Ensuite on recommence en construisant une première base. Et on passe en revue les besoins est ce que avec le modèle de base que je viens de construire je peux répondre à tous les besoins ...

Difficile d'expliquer

Bon courage
Aurélie

Dernière modification par evaporite (Fri 28 October 2016 12:17)

voila exactement
le besoin métier ... la clé est là

Bonjour,

Apparemment, on ne raisonne pas de la même manière. Vous présentez les choses du point de vue de l'informaticien pur jus - ce n'est pas une critique - ce qui n'est pas mon cas dans la réponse que j'ai faite.
D'après votre commentaire, le SIG et les SI sont des outils. C'est votre acception, et, par métonymie, on peut en avoir d'autres. A mon sens, ne les considérer que comme des outils est réducteur. Les SI participent également au background qui permet à une institution de fonctionner correctement, comme la commande publique, par exemple. En collectivité, le SI est surtout orienté à destination des agents et pas des administrés. L'exception notoire serait le site internet de la collectivité mais le contenu (donc ce qui est visible pour les administrés) est du ressort de la communication et pas de la DSI. En ce sens, je considère les SI comme supports.
Sans prétendre connaître toutes les compétences d'une collectivité, on peut connaître très facilement ses grands domaines d'intervention et, par le dialogue avec les chefs de service, connaître leurs besoins et tacher d'y répondre.
Enfin, à ma connaissance, un schéma UML intègre le diagramme de classe, sans qu'il ne s'y réduise. En revanche, sans diagramme de classe, pas de schéma UML complet. Or l'idée d'Olivier69 est bien, au final, d'arriver à un schéma complet.
UML est un mode de représentation de systèmes parmi d'autres.
Ce que je souhaite proposer n'est pas le schéma final - à mon sens impossible à délivrer sans les données qu'il contient - mais une représentation heuristique (non normalisée) des liens entre services utilisateurs et données et entre les données elles-mêmes. J'entends ici "données" comme les grandes thématiques et les actions qui en déclinent que les collectivités sont amenées à traiter.
Mon ambition n'est donc pas de donner un schéma clé en main mais un schéma qui aide à la compréhension des besoins et qui facilite la création du système finalement mis en œuvre.