Introduction

Il n'existe pas ou si peu, à ce jour, d'offre logicielle libre dédiée aux Sciences de la Terre, à la Géologie. On trouve nombre de logiciels libres dans des domaines voisins ou complémentaires, comme les statistiques, les systèmes d'informations géographiques, les outils de cartographie, de conception assistée par ordinateur, de dessin vectoriel ou raster, les modeleurs 3D. Mais presque rien de spécifique à la Géologie.

Il convient de mentionner quelques exceptions notables: ParaViewGeo. C'est un dérivé du logiciel de visualisation de données scientifiques ParaView, intensément modifié pour la visualisation de données minières et géologiques. Il y a également OpendTect, axé sur l'interprétation de données sismiques, donc plutôt du côté de l'industrie pétrolière.

Les avantages du modèle de développement de logiciels libres sont aujourd'hui largement reconnus, j'en bénéficie au quotidien, comme de plus en plus de personnes, d'entreprises, d'organisations. En désordre, on peut citer:

À l'occasion de 2008, année de la Terre, j'ai décidé de lancer un projet qui me tient à cœur depuis longtemps, que je baptise GéolLLibre, pour GÉOLogie Logiciels LIBREs, une suite logicielle libre dédiée à la géologie.


Constats, argumentaire, fondement du projet

Gaspillages

J'ai été amené, au cours de mon parcours professionnel, à utiliser un grand nombre d'outils informatiques, appliqués à mon métier de géologue. J'ai eu à développer des outils, pour répondre à tel ou tel problème. Outils qui allaient de la simple moulinette à un logiciel plus complet, ou à des outils pour rendre service à des collègues dans l'embarras.


Parmi les nombreux outils que j'ai pu utiliser, bien souvent les mêmes problèmes avaient été adressés différemment par des équipes de développeurs différentes, avec plus ou moins de bonheur et/ou d'efficacité. Il était souvent "râlant" de constater qu'il ne manquait presque rien à tel outil, par rapport à tel autre, pour approcher la perfection, si seulement ces deux équipes de développeurs avaient pu travailler ensemble... Les mêmes fonctionnalités sont redéveloppées moult fois, les roues se réinventent.

Certains vieux outils si pratiques, mais ne tournant que sur telle plate-forme aujourd'hui oubliée, n'existent plus, et c'est grand dommage, leurs remplaçants ne sont que des ersatz, il manque toujours quelque chose.

Nécessité de standards logiciels

Aujourd'hui, les entreprises et organismes travaillant dans le domaine des sciences de la Terre ont chacune ou presque leur système logiciel et données, parfois plusieurs, en fonction de plusieurs paramètres:

Il manque, à l'évidence, un standard, et ce malgré la relative simplicité des modèles de données que manipule traditionnellement le géologue (on est très loin de la complexité des modèles météorologiques ou des contraintes de domaines comme l'avionique, par exemple. Gardons néanmoins en tête que des modèles de données bien plus complexes sont envisageables, comme des modèles vectoriels en quatre dimensions, avec des paramètres multiples stockés dans des voxels par exemple...

Cette absence de standards, combinée au fait que le géologue se 'débrouille' le plus souvent, sur le terrain, avec les moyens du bord et ses compétences, fait qu'on arrive très fréquemment à des situations au mieux complexes, au pire chaotiques voire anarchiques. Lors de la prise de conscience de tels problèmes, par exemple quand il y a nécessité d'une vision synthétique d'un grand aquifère, d'un district minier, d'un champ de production, d'un bassin, etc., l'énergie consacrée à compiler les données est souvent considérable, chronophage, dangereuse et coûteuse. De plus, elle est parfois immédiatement gaspillée, faute de compétences de terrain pour entretenir une base de données trop finement conçue (tendant à l'"usine à gaz" tant redoutée), ou faute de suffisamment de licences du logiciel nécessaire.
Le passage entre deux personnes est, à ce titre, très souvent délicat, laborieux, et très dépendant des bonnes volontés et compétences.

Le temps où les espaces mémoires étaient étriqués, les ordinateurs et leurs opérateurs rares, était, de ce point de vue, nettement plus favorable: j'ai souvenir d'avoir stocké sur une disquette de 1.44Mo des bases de données de sondages d'exploration regroupant les données de milliers de sondages (et je n'ai pas eu le privilège de travailler avec des cartes perforées, seulement des bandes magnétiques). On ne copiait pas à tour de bras, on économisait, on savait ce qu'on faisait, la gestion des fichiers se faisait obligatoirement de manière quasi-permanente et avec rigueur, les fichiers de données étaient conçus pour une grande compacité.

Aujourd'hui, force est de reconnaître qu'anarchie et gabegie de gigas sont plutôt de mise. Au détriment de l'indispensable unicité de LA si précieuse DONNÉE.

Des solutions

Pour tenter de résoudre partie de ces problèmes (qui ne sont pas restreints, loin s'en faut, au domaine de la Géologie!), qui ne feront que s'accroître dans le futur si rien n'est fait, on propose les actions suivantes:

Gageons que ces efforts paieront dans le temps, et que les générations futures de géologues ne refassent pas les erreurs du passé et du présent.

Ce projet a déjà été discuté avec plusieurs personnes, à des stades divers, allant de l'idée utopique de coin de comptoir jusqu'au contrat commercial signé avec un projet doté d'un cahier des charges précis. Comme on le voit, un certain nombres d'actions ont déjà été engagées.

Ce qui a déjà été fait

TecTri

C'est décidé, TecTri, dont je suis l'auteur, devient maintenant un Logiciel Libre. J'ai grand'honte du code source, mais bon, tant pis, je le publie, voilà. Ce fut codé en des temps reculés, avec des pratiques parfois douteuses.

Un bref historique de TecTri:

Au jour d'aujourd'hui, je me suis replongé dans mon vieux code (j'ai réalisé qu'à côté d'horreurs sans nom comme des ribambelles de variables globales, il y a une séparation de bon aloi Modèle-Vue-Contrôleur du code, qui date de bien avant que cela ne soit à la mode), je n'ai commencé qu'à faire des ébauches de classes, rien de vraiment fonctionnel ni convainquant. Si j'attends que je fasse quelque chose de présentable, cela risque de prendre fort longtemps, vu mes emplois du temps professionnels et familiaux. Donc je décide de sauter le pas, de publier le code fonctionnel tel quel, en Visual Basic, avec tous ses défauts (variables globales à tire-larigot, procédures cryptiques, code trop peu commenté, tableaux à dimensions arbitraires, et j'en passe...). Et le binaire compilé avec (pour les "anciens", il n'y a plus besoin du mot de passe qui servait de "protection", le nom du village au cœur de ma zone de mémoire, le fameux "Pedro Andres"), qui tourne, à défaut de mieux, et au moins chez moi, sous quelques Windows, et aussi sous wine.

Développement d'un outil de visualisation de données souterraines

En 2007, au fil de mon parcours professionnel, j'ai eu le besoin d'un outil multi-plateforme me permettant de parcourir des données de sondages sous forme de coupes, plans, et en trois dimensions.

Il existe déjà d'autres logiciels faisant ce travail, aucun multi-plateforme, certains pachydermiques, coûtant très cher, et d'autres efficaces mais si difficiles à maîtriser, mais pas un seul ne répond à mes desiderata. Et aucun n'est libre.
J'avais un besoin, pas ou si peu de temps pour développer, j'ai donc commencé un partenariat entre mon entreprise, Pierre Chevalier Géologue, et une Société de Services en Logiciels Libres.

Nous avons ensemble défini un premier projet correspondant à un de mes besoins immédiats: la visualisation rapide de données de sondages. Nous avons signé un premier contrat de développement de cet outil, les premières phases de développement ont suivi, des premières versions ont été développées, le travail de développement est en cours. L'outil est codé en python, en recourant à des briques logicielles libres, les données sont stockées dans une base de données postgreSQL, une référence incontournable.

Le projet

Développer des partenariats avec des acteurs des logiciels dédiés au Sciences de la Terre. On pense à certains développeurs qui ont déjà codé des outils "dans leur coin", parfois lors de temps héroïques (je pense par exemple à Oyapock), ces codes ayant sombré dans l'oubli. Il faudrait les ressortir de l'oubli, en isoler la substantifique moëlle et l'intégrer dans un ensemble cohérent d'outils logiciels, de bibliothèques communes au projet, respectant des normes/conventions communes de données.

Qu'on ne se méprenne pas: il n'est pas question d'empiéter sur les plate-bandes des logiciels commerciaux: je suis persuadé que les deux modes de développement et de distribution peuvent cohabiter. Alors que le modèle commercial "classique" consiste à vendre un bien (le logiciel), puis sa maintenance, le modèle de développement du logiciel libre, sous son angle commercial, consiste en des prestations de services de développement répondant au besoin d'un client. Le délivrable est un bien logiciel, qu'on peut par exemple choisir de garder à l'exclusivité du client pour un temps donné (quelques mois, la durée est à négocier), après quoi le logiciel serait diffusé librement. Ce mode permet de garantir au client une avance technologique, et permet au logiciel de survivre à long terme, et de profiter du mode de développement libre, plus tard. De tels modes de fonctionnement sont couramment utilisés entre les Sociétés de Services en Logiciels Libres et leurs clients.

Les développeurs savent combien un code s'apparente souvent à une oeuvre d'art. L'exécutable compilé binaire n'en est que l'expression fonctionnelle, dépouillée d'une bonne part de son âme. Et, comme tout artiste, que l'oeuvre lui survive est d'importance. Qu'elle meure avec lui, quelle tristesse.
Le logiciel libre permet, non seulement qu'un logiciel ne meure pas, ne s'oublie pas, mais il permet aussi de conserver la partie littéraire de l'oeuvre, le code. Et les autres développeurs qui le liront pourront l'améliorer, le réutiliser, s'en inspirer, construire sur ces bases, qui ne seront pas perdues. Et coder pour un projet dont on sait que le code sera vu de tous incite à rédiger un code plus propre, dès le début, dans le respect des règles de l'art, ne fût-ce que pour qu'on ne se gausse pas en le lisant.

Le paragraphe précédent peut sonner incongru à qui n'a pas développé. Mais un développeur y sera certainement sensible.

Ce n'est qu'un début...

Tout reste à faire, ou presque. Si vous êtes intéressés, voulez participer d'une manière ou d'une autre, n'hésitez surtout pas à me contacter à pierrechevaliergeol@free.fr.

Librement vôtre.

Pierre Chevalier
29/12/2008

Post-scriptum: mieux encore que de me contacter, j'ai mis en place une liste de discussion, intitulée geolllibre: si le coœur vous en dit, joignez-là en suivant le lien suivant, qui enverra un émail d'inscription au "robot" qui gère la liste: inscription à la liste geolllibre.


28/04/2009