L’utilisation du SIG comme centre de connaissances dans un contexte pétrolier

Une etude statistique sur l’utilisation du SIG dans le contexte de la Compagnie pétrolière moyenne montre que, comme on devrait s’attendre, cet outil n’est généralement pas utilisé pour répondre aux questions de base du métier, c’est à dire, où doit-on forer pour trouver du pétrole ou du gas. En fait, les éléments de réponse essentiels à cette question sont fournis par des outils et solutions logicielles spécialisés, qui comportent, certes, une interface dite SIG ou cartographique, mais qui dans la plupart des cas considèrent la fonctionnalité purement SIG comme étant d’une importance secondaire.
 
Le SIG est généralement utilisé dans le cadre soit d’un inventaire des données patrimoniales et /ou historiques, ou bien pour la planification de nouveaux centres d’intérêt pour l’exploration et/ou la production. Et, c’est justement dans ces domaines d’activité, impliquant des données réelles et concrètes, que les fonctionnalités du SIG prennent toute leur valeur.
 
Des éléments supplémentaires fournis par les utilisateurs actuels du SIG, ainsi que par des utilisateurs potentiels, permetent de déduire que dans la plupart des cas, le travail effectué sur le SIG doit être complété par des informations et données de natures diverses ; le plus souvent, ces dernières proviennent de sources qui ne font pas partie de l’environnement SIG, et dont l’intégration à celui-ci pose de sérieux problèmes de compatibilité et/ou de performance.   
 
En tenant compte de ces observations, un projet pilote a été élaboré cette année pour une Compagnie pétrolière moyenne sous le nom de code « Archimedes ». L’objectif du cahier de charges était de définir une solution dans laquelle le SIG   jouerait en principe un rôle compatible avec la problématique exposée ci-dessus, tout en tenant compte des contraintes et limitations imposées par le contexte spécifique, et en restant suffisamment ouvert pour une implementation à plus grande échelle si nécessaire.

Les éléments principaux du cahier de charges étaient les suivants :
 
-          Le SIG se trouverait au centre de la solution, et joue le rôle d’un fédérateur de données, à composante spatiale ou pas.
-          La solution devait permettre la consultation de données de plusieurs types, en association avec des objets représentés spatialement. Les types suivants de données ont été sélectionnés dans le cadre du projet-pilote
 
            o   Fichiers en format standard Microsoft
            o   Fichiers-métier en formats divers (p.ex. des fichers de diagraphies en format LAS, ou des fichiers de données sismiques en format SegY)
            o   Documents et matériaux imprimés, référencés dans une ou plusieures bases de données
            o   Références à des pages Web contenant des informations relatives à un ou plusieurs objets définis spatialement.
            o   Flux RSS libres ou sous abonnement
            o   Notes personnelles.
 
-          Une organisation du travail suivant une logique ‘projet’ a été souhaitée par le client.
-          Les différents fichiers associés aux objets spatiaux devraient pouvoir être visualisés, dans la limite de la faisabilité technique, par des applications-métier standard, en utilisant des méthodes de l’environnement Windows.
-          La solution devrait permettre d’une part la consultation, et d’autre part la gestion (organisation) des données. L’édition des données ne faisait pas partie des spécifications du cahier de charges.
-          La gestion des données, et plus particulièrement, la sélection et l’association à des objets présents dans l’environnement spatial devrait être effectuée suivant une procédure automatisée ou semi-automatisée.
-          La consultation des données devait être possible aussi bien en installation locale, qu’à travers le navigateur.
-          La technologie SIG souhaitée par le client était ArcGIS/ArcView
-          Le budget était relativement limité

Afin de satisfaire les exigences de ce cahier de charges, une solution .NET a été dévéloppée autour d’un noyeau ArcGIS/ArcView. Dans le but d’éviter une surcharge du système et le ralentissement inévitable de ce dernier, il a été décidé d’appliquer une architecture modulaire, permettant d’effectuer les opérations lourdes à l’extérieur de l’environnement ArcGIS. Ainsi, les requêtes et consultations de la ou des Bases de données sont effectuées par l’intermédiaire de connexions OleDB indépendentes opérant depuis des processus externes.
 
La liaison avec des bases de données documentaires est effectuée à travers des tables de « cross-référencement », en se servant de requêtes attributaires SQL.
 
L’association de pages Web aux objets définis spatialement peut être effectués soit au niveau de l’objet ou au niveau du projet, ce dernier étant défini comme un groupement d’objets. La recherche est effectuée en utilisant un moteur de recherche standard et paramétrable (p.ex. Google), et en associant à une ou plusieurs valeurs d’attributs des mots-clés spécifiques par type d’objet. Ainsi, le nom d’un champ pétrolier peut être associé à des mots-clès tels la production, l’infrastructure, les compagnies participantes etc, le tout étant fourni comme agrument au moteur de recherche.
 
Les utilisateurs se voient offrir la possibilité d’introduire des notes personnelles aussi bien au niveau de l’objet, qu’au niveau du projet.
 
L’association des documents imprimés est effectuée manuellement à ce stade ; il a été prévu cependant d’étendre la fonctionnalité pour implementer un système de codes-barres.
 
La notion d’un dossier centralisé sur le réseau, comportant des sous-répertoires et servant de serveur de fichiers, est très fréquemment mise à l’œuvre dans les Compagnies Pétrolières petites à moyennes ; son utilité est de permettre au plus grand nombre d’utilisateurs d’accéder à des fichiers sous le même chemin, l’accès étant géré par le système de droits du serveur spécifique.
 
C’est précisément ce serveur central qui a été utilisé pour la gestion et l’association semi-automatisée de fichiers standard à des objets spatiaux. La sélection des fichiers à associer est effectuée en utilisant le moteur de recherche par texte de Google. Pour les besoins du projet-pilote, le moteur Google Desktop a été utilisé, mais l’utilisation de Google Enterprise est préconisée pour des installations plus étendues. La recherche de texte comporte des valeurs d’attributs des objets spatiaux, ainsi que des listes de mots-clés paramétrables. Quant à l’indexation des fichers, elle est effectuée automatiquement.
 
Une sauvegarde des fichiers documents dans la base de données en mode ‘Full-Text’, initialement envisagée, a été finalement abandonnée, car elle chaqrgerait inutilement la base de données.
 
L’association automatique de fichiers-métier à des objets spatiaux est effectuée suivant le principe qu’un fichier peut être associé à un ou plusieurs objets, ou a un projet regroupant des objets. Pour effectuer physiquement l’association, le fichier à associer est copié dans un dossier comportant un démon de veille de fichiers (« filewatcher »). Un fichier xml de paramètres est également présent dans ce dossier. Chaque fois qu’un nouveau fichier y est copié, le démon lit les paramètres d’association (objets individuels, requête regroupant des objets, identifiant du projet, etc), crèe un enregistrement dans la base de données en identifiant uniquement le fichier, crèe des enregistrements d’association avec les identifiants d’objets ou de projet, et, finalement, déplace le fichier dans un dossier de destination sur le serveur de fichiers.
 
A noter que la recherche de texte est dans la plupart des cas des fichiers-métier, inefficace, étant donné le format binaire parfois incompatible (p.ex. ebcdic) ou le codage de ces fichiers.
 
L’association des fichiers-métier à des applications spécifiques est effectuée en passant par les types de fichiers standard Windows. Pour les fichiers spécifiques, tels les fichers de sections sismiques, des visualiseurs standard sont utilisés.
 
Le benchmarking initial de cette solution a été effectué en utilisant la base de données de la Louisiane, avec une série de 25'000 documents fictifs comportant des identifiants de puits pétroliers.
 
L’utilisateur desktop dispose d’une interface simple, appelée depuis l’intérieur d’ArcMap, lui permettant d’accéder à un inventaire global des documents et matériaux associés à un objet défini spatialement, ou à un projet. Quant à l’utilisateur éloigné , il peut accéder aux mêmes fonctionnalités à travers une installation complémentaire. Pour les besoins du projet-pilote, une interface Web a été développée en utilisant GeoServer/OpenLayers et PhP, mais ArcGIS serveur/java serait l’environnement à utiliser dans le cadre d’une installation plus globale.