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.

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:

• le dynamisme de l'évolution des projets libres,
• la possibilité pour tout un chacun de participer et améliorer tout logiciel libre,
• la transparence du code assure:
• la pérennité des données sous-jacentes, 
• ainsi que la pérennité de l'outil,
• la possibilité de recompiler pour tout système d'exploitation relativement standard,
• l'appui de communautés de développeurs et d'utilisateurs très dynamiques et réactifs,
• la possibilité de distribuer, sans frais de licence ou autre, des nombres illimités de copies logicielles, et donc de standardiser des grands parcs à peu de frais.

À 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:

• l'historique de la société: logiciels maison développés de longue date (Gbis, GDM, Sermine, etc.);
• des logiciels acquis (Systèmes d'Informations Géographiques ou SIG: mapinfo, arcview, arcgis, arc/info, etc.), logiciels dédiés (surpac, integral+, discover, GDM, wellcad, etc.);
• des logiciels non acquis mais utilisés (cas hélas trop fréquent, particulièrement en ce qui concerne les nombres de licences);
• des logiciels utilisés, légalement ou pas, isolément, par des employés car ces derniers sont habitués et productifs avec, ce faute de budget, ou faute de fermeté et/ou de compétence des encadrements;
  
• des développements locaux, scripts ou applications, souvent faits à la sauvette, plus ou moins pérennes, le plus souvent trop peu génériques et difficilement réutilisables;
• une utilisation des Bases de Données (qui sont sensées adresser en partie ces types de problèmes) qui est souvent inadéquate, soit mal employée, soit vécue comme une contrainte plus que comme une aide. Trop peu de bases de données sont simples, pragmatiques et utilisées quotidiennement, de manière distribuée.

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éorologique 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:

• Définition d'un ensemble de normes pour les données géologiques (par exemple par RFC), en s'inspirant des efforts faits en ce sens dans le domaine de l'information géographique. Simplicité et généricité doivent être de mise, avec des schémas externes de données simples, même si les schémas internes peuvent être, forcément, plus complexes et exhaustifs.
  Il s'agira essentiellement de faire quelques choix, il existe déjà des modèles satisfaisants, reste seulement à passer du statut de "standard de fait" à celui de norme.

• Développement d'outils logiciels, basés sur des logiciels libres, en tentant d'abord de fédérer les énergies et connaissances des développeurs en sciences de la Terre (afin de ne pas avoir à réinventer de roue); toutefois, si ceci devait tarder, pour des raisons politiques, commerciales, ou autres lourdeurs administratives/décisionnelles (fréquentes dans les grands groupes), les développements seraient lancés. Un des cas de figure les plus favorables serait qu'un organisme ayant déjà développé dans ce domaine, convaincu par les avantages du logiciel libre, décide de libérer son code, qui servirait de base pour le développement logiciel, en réécrivant/adaptant/migrant ce code. Ceci peut tout à fait rentrer dans le cadre de contrats commerciaux impliquant SSLL (Sociétés de Services en Logiciels Libres) et sociétés ou organismes actifs en géosciences.

• Enseignement, dans écoles et universités de sciences de la Terre: on s'apercoit aujourd'hui que les étudiants arrivant dans le monde de l'entreprise n'ont que très rarement la sensibilisation nécessaire aux bases de données et à leurs multiples avantages. Si l'utilisation de logiciels est généralement bonne, le stockage, l'archivage sous une forme interrogeable et pérenne des données, ne sont souvent même pas conceptualisés. Le Contrôle Qualité de la donnée, une notion pourtant essentielle, est aussi à expliciter et développer.
  Pour ce, un kit de formation pourrait être distribué aux universités et écoles, comprenant des jeux de données (libres ou fabriqués), les logiciels libres en question, et des cours, exercices et tutoriels. Le tout traduit en de multiples langues, comme le veut la coutume des logiciels libres.

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:

• 1986, j'étudie les Sciences de la Terre à l'IGAL, Institut Géologique Albert de Lapparent, et je me prends de passion pour la géologie structurale.
• 1989, je mesure de nombreuses failles (dont de nombreuses fort belles failles synsédimentaires) sur mon terrain de mémoire, dans les Prébétiques, dans le Sud de l'Espagne, et je trace des centaines de stéréogrammes sur des calques.
• Las de ces manipulations fastidieuses, je décide de réduire en esclavage un ordinateur que mon Père venait d'acheter, et de le charger de faire ces manipulations.
• Déçu par ce qu'étaient devenus les ordinateurs par rapport à mes premiers apprentissages de l'informatique sur ZX81 (comment, on ne commence pas par coder une boucle après avoir allumé l'engin? mais qu'est-ce qu'un fichier? pourquoi un système d'exploitation?), j'achète (ça s'achète, un logiciel? Décidément, l'informatique avait considérablent évolué en bien peu d'années) rapidement un langage qui puisse me permettre de commander mon esclave: Microsoft QuickBasic. Parlant déjà couramment le basic à la mode Sinclair et Oric, le choix était naturel. Je parlais aussi l'assembleur, mais bon.
• Je code un programme qui permet de tracer des stéréogrammes, en représentant différents éléments géométriques de failles (traces cyclographiques, stries, polaires de plans de failles, plans de mouvement, etc.) et de trier des populations de failles hétérogènes (c'était là le noeud du problème de mon terrain de mémoire, dans les Cordillères Bétiques)
• 1991: présentation de TecTri lors d'une séance spécialisée intitulée "les failles" à la Société Géologique de France.
• Lors d'un stage chez Elf-Aquitaine, je découvre les joies du C, et je commence à convertir, à grand'peine, mon code basic en C.
• 1991: sortie de Visual Basic: impressionné par la rapidité de développement de l'interface homme-machine (qui prenait largement plus de 80% de mes efforts de programmation) et à son efficacité (interface normalisée SAA/CUA sans efforts; à l'époque, cet éditeur savait parfaitement faire des outils efficaces, stables, et respectant les normes), j'achète l'outil, je repars de mon code en QuickBasic (qui utilise la même syntaxe, à peu de détails près), je jette les trois quarts du code, et j'arrive à un résultat qui est nettement plus manipulable qu'avec une interface purement DOS, construite ex nihilo sans bibliothèque. L'IGAL m'a bien aidé dans ce projet.
• Ensuite, cycles de perfectionnement, débogage, améliorations, déteriorations mystérieuses, patches, redébogages. Utilisation quotidienne dans le cadre estudiantin et professionnel, corrections et développement synchrones de mon utilisation personnelle.
• Commercialisation: un client, l'Université de Bretagne Occidentale,
  Département Sciences de la Terre, que je tiens à remercier, a acquis TecTri, dans sa version sous Windows, et la version DOS, qui "tournait" à l'époque nettement plus vite.
• Depuis 1995, rien à signaler ou presque. Le code vieillit tranquillement. Ce qui ne le bonifie pas: si on installe aujourd'hui TecTri via sa procédure d'installation, on aura quelques écrasements intempestifs de .dlls qui pourront donner à votre machine un look&feel rétro des années 90... Les performances se sont aussi dégradées, mais ceci est imputable à l'évolution pachydermique d'un système d'exploitation trop répandu: les dièdres droits, qui s'initialisaient en une fraction de seconde sous Windows 3.0, 3.1, 3.11, mettent de très longues minutes sous Windows 95 et pire pour les suivants (le truc, pour contourner ce curieux comportement, consiste à changer le diamètre du stéréogramme pour une valeur ridiculement petite, de lancer les dièdres droits, puis de remettre le diamètre à une valeur normale, et enfin relancer les dièdres droits).
• De plus, le code ancien ne daigne plus se compiler correctement avec les dernières versions de Visual Basic, je reste donc plutôt avec l'ancienne version de mon compilateur (acheté honnêtement), qui me donne pleinement satisfaction.
  Bref, le projet rouille, meurt presque. À peine quelques rares corrections de bogues.
• Vers 1999, je découvre avec stupéfaction (lors d'une longue nuit de bidouille dans un camp d'exploration minière dans le désert mauritanien), GNU/Linux en particulier, et les Logiciels Libres en général. Je découvre qu'un ordinateur qui rame sous Windows se transforme à peu de frais en une station de travail performante, simplement en y mettant un système d'exploitation qui marche correctement dès la base. Et avec tous les compilateurs dont on peut rêver.
  Depuis, j'utilise de plus en plus les logiciels libres, j'ai banni les systèmes d'exploitation mal performants de mon foyer et de mon entreprise. Je n'ai plus qu'une seule machine sous Windows, qui ne sert à faire tourner qu'un logiciel, GDM, qui m'est encore irremplaçable et ne veut obstinément toujours pas tourner dans un émulateur.
• Il me paraît alors clair que la survie de TecTri passe par le logiciel libre. Soit. En Visual Basic? Non, faut de goût. Il s'agit alors de choisir un langage, et de ne pas choisir ce qui peut devenir un cul-de-sac. Embarras du choix, il y a tant et tant de langages, tests de moult langages: C, C++, Delphi, java, Rebol, Python, même mapbasic, et j'en passe. Rebol attire vivement mon attention, il est époustouflant de performances, notamment en graphismes. Mais il n'est pas libre, donc potentiellement un cul-de-sac, à plus ou moins long terme. Dommage. Il faudrait convaincre Carl Sassenrath. Tout bien pesé, Python remporte mon choix. Enfin, pour le moment.
  

Au jour d'aujourd'hui, 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 familaux. 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

PS: 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: mailto:geolllibre-request@ml.free.fr?subject=subscribe