Dès le début de ce projet; nous avons adopté 'eXtreme Programming' (XP), une méthode de développement 'Agile' qui commence à être reconnue dans le monde du développement de logiciel. Un aspect essentiel de cette approche est son exigence d'une définition précise et concrète des objectifs à atteindre, exprimée du point de vue de l'utilisateur. Pour éviter par exemple qu'un programmeur ajoute une fonctionnalité parce qu'il la trouve 'cool' (de son point de vue naturellement). De la même façon, en ciblant dès le début une cible concrète (les gestionnaires de réseaux), nous espérons éviter d'alourdir le produit de fonctionnalités trop générales pour être vraiment utiles, en manquant du même coup de ressources pour ce qui est vraiment utile.
L'activité d'un gestionnaire de réseau est fondamentalement organisée autour de la maintenance en condition opérationnelle d'un 'patrimoine réseau'. De plus, les gestionnaire de réseau est de fait dans une situation de monopole sur son territoire. A ce titre, il doit en permanence fournir des informations sur ses opérations à un contrôle de plus en plus exigeant. Il doit donc mettre en place un système d'information performant et évolutif. Ce système doit nécessairement gérer des données spatiales. Ceux qui ont essayé de décrire dans une base de données relationnelle 'classique' des composants enterrés (conduite d'eau ou ligne électrique souterraine) sans passer par une représentation géographique savent de quoi je parle ici.
Ces données spatiales doivent être accessibles à quasiment tous les collaborateurs : on peut notamment citer les études, la maintenance, et même la comptabilité (pour garantir la véracité des immobilisations) ou la gestion de clientèle (pour maintenir un lien valide entre un point de livraison et le réseau qui l'alimente). Ces exemples montrent également que ces données spatiales ne doivent pas être confinées dans un 'silo' isolé (un SIG par exemple), mais doivent être en permanence connectées aux autres données (plus classiques) de l'entreprise : gestion d'interventions et de travaux, gestion de clientèle, comptabilité.
L'orientation 'maintenance' de l'activité a un impact majeur sur le système d'information réseaux. Il doit décrire dans la durée (en général plusieurs dizaines d'années) un relativement grand nombre d'objets (de l'ordre du million), avec un nombre annuel limité de changement (de l'ordre de la dizaine de milliers). Il doit représenter de façon fiable un état stable du réseau (en ignorant les modifications temporaires). Ce dernier point implique que les modifications doivent être organisées en transactions : les changements apportés par un utilisateur ne doivent pas être visibles (par les autres utilisateurs) avant qu'il ait terminé et validé son travail.
Le fait de cibler spécifiquement les gestionnaires de réseaux nous oblige à traiter les problèmes clés qui leur sont posés :
- prendre en charge la dimension spatiale du système d'information réseaux,
- donner à tout collaborateur un accès aux données spatiales, en consultation et en édition,
- supporter le travail en mode déconnecté,
- connecter ces données spatiales aux autres SI de l'entreprise,
- déployer de multiples applications spécialisées et faciles à utiliser.
Nous pensons que ces besoins ne sont pas nécessairement couverts correctement aujourd'hui, même si des réponses partielles existent. La majorité des systèmes de gestion de bases de données relationnelles (Oracle, Db2, Sql*Server, etc) gère maintenant les données spatiales (stockage, indexation, requêtes). Mais il s'agit seulement d'une infrastructure, et les applications restent à développer. Inversement, les systèmes d'informations géographiques (SIG) proposent généralement une offre applicative suffisamment riche, mais sur une plateforme propriétaire difficile à connecter aux autres systèmes d'informations. Dans les deux cas, le déploiement de tels systèmes sur l'ensemble des postes de travail est souvent trop onéreux pour être envisagé, en termes de licences et de formation.