Introduction

Dans le domaine des SIG, l'offre en matière de logiciels à source ouvert est à la fois importante, quantitativement, et limitée, en ce qui concerne la visibilité.

D'une certaine manière, l'essor ces dernières années des logiciels dits "libres", essor couplé à la revendication d'une certaine approche sociale qui n'est pas partagée par tous les acteurs des logiciels à source ouvert, a provoqué une erreur de perspective : parce que le principal logiciel de SIG à source ouvert est une version sous GNU Public Licence (GPL) de GRASS, quiconque ne connaît pas l'historique du développement de ce progiciel peut conclure que GRASS est une tentative faite par des bricoleurs à l'esprit "partageux" d'offrir une alternative aux propositions commerciales.

Il n'en est rien : la version GPL ainsi que la majorité des logiciels de SIG commerciaux partagent une même source : la version en domaine public de GRASS, logiciel développé sur fonds de l'armée américaine pendant une dizaine d'années (la dernière mise à jour issue de l'U.S. Army Construction Engineering Research Laboratory — U.S. Army C.E.R.L. — date de 1995, la dernière version majeure datant de 1993).

Parce qu'officiellement l'Armée américaine ne trouvait pas de produit commercial convaincant (et parce que prosaïquement, les crédits affectés à la Défense ne sont pas soumis à la réglementation de l'OMC, ce qui permet alors de subventionner en code les entreprises sans encourir les foudres de ladite organisation), le CERL fut chargé d'embaucher des développeurs et de produire un SIG digne de ce nom. Le résultat — Geographical Resources Analysis Support System, i.e. G.R.A.S.S. — a été salué comme une réalisation majeure, comme le SIG topologique de référence, et a fait l'objet d'un transfert de technologie au profit des sociétés commerciales états-uniennes qui dominent aujourd'hui le marché.

Ce processus d'initiation de progrès technologique, de développement par l'une des composantes de la recherche : la recherche sur fonds publics, et de fécondation de développements privés n'est pas propre aux SIG. Il s'agit d'une politique soutenue aux U.S.A., dont l'un des fruits est par exemple l'implémentation de référence de TCP/IP réalisée sur fonds (toujours) de la Défense américaine (DARPA) par une équipe de l'université de Berkeley dans le but d'encourager une diffusion massive de TCP/IP chez les principaux constructeurs et éditeurs informatiques, et cela afin de permettre aux organismes d'État de diversifier leurs approvisionnements tout en étant certains de pouvoir faire coopérer les éléments d'un parc hétérogène par le support d'un protocole commun.

On peut également noter que les progrès ne sont pas uniquement accomplis dans le sens recherche publique vers recherche privée, mais que l'inverse fonctionne. UNIX® est né des travaux de Ken Thompson et Denis Ritchie au sein des AT&T Bell Laboratories — donc dans une structure privée — et a généré, et continue de générer une foison de recherches supplémentaires et d'extensions en provenance de structures non privées — les extensions Berkeley, issues du Computer Systems Research Group (CSRG) de l'Université de Berkeley en Californie par exemple.

Les faits démontrent suffisamment que l'approche états-unienne est une approche efficace, et de type gagnant/gagnant... pour les universités et les entreprises états-uniennes. Et la primauté des publications de recherche dans tous les domaines essentiels par les auteurs anglo-saxons n'est pas indépendante de la maîtrise des outils fondamentaux, maîtrise qui permet de tester de nouvelles approches et, connaissant les limites, de les dépasser.

Le logiciel à source ouvert ayant formé le coeur de nombreuses applications commerciales n'est donc pas, par essence, de qualité inférieure. Certes les bonnes intentions ne font pas du bon logiciel et peuvent même conduire à l'enfer informatique, et un programme dont la seule qualité revendiquée relèverait d'options "sociétales" devrait être considéré avec circonspection. Mais la disponibilité des sources peut relever aussi d'un intérêt informatique bien compris, augmentant la stabilité du logiciel par la multiplication des environnements d'essai, augmentant sa sûreté par la multiplication des inspections, augmentant sa facilité de maintenance par l'exigence d'une organisation compréhensible par le plus grand nombre de développeurs.

Le logiciel à source ouvert n'est pas incompatible avec des développements ou une qualité dite "professionnelle", et ne l'est pas obligatoirement avec les intérêts d'une entreprise éditrice. Dans le domaine des SIG, l'exemple de KerGIS, autre surgeon du GRASS en domaine public, en est l'illustration : KerGIS, par sa licence de type BSD, autorise à la fois un développement ouvert et un accès au source, et des développements et prestations commerciaux.

L'Université n'a pas à être gardienne du savoir mais productrice de concepts, d'outils théoriques. Pas dispensatrice d'érudition, mais créatrice de connaissances : on sait depuis longtemps qu'il vaut mieux une tête bien faite qu'une tête bien pleine, et que les méthodes sont plus essentielles qui permettent les ruptures épistémologiques et le débordement des cadres que la thésaurisation des errements du passé.

Il serait donc encore plus dramatique de la voir se transformer en un sous-centre de formation aux applications professionnelles, reconnaissant ainsi que les détenteurs du savoir sont les éditeurs marchands et qu'elle doit contraindre ses chercheurs et ses étudiants à de dérisoires cabotages dans les étroites limites de ce que les gardiens de la doxa mercantile ont décrété être son horizon insurpassable. Accepter des licences "gratuites" de logiciels au code source inaccessible serait vendre son droit d'aînesse contre un plat de lentilles. Car rien n'est gratuit, pas plus les cadeaux qui finissent par coûter cher au niveau de la dépendance, que le logiciel dit "libre". La différence est qu'un logiciel à source ouvert ne s'acquiert pas uniquement par l'argent, mais qu'il peut légitimement s'acquérir par le travail et la recherche, par un investissement en ressources humaines qui en fait un investissement tout court, c'est-à-dire une création de valeur nouvelle, quand un achat de logiciel non maîtrisé dans le cadre de l'Université n'est qu'une dépense de fonctionnement dont on peut questionner la légitimité. L'Université possède la ressource humaine qui est la plus à même, de par sa nature et de par sa fonction, d'offrir à elle-même et aux autres les moyens de découverte actuels et à venir.

Pour pouvoir explorer ce que ses membres vont découvrir, il lui faut maîtriser et adapter ses outils. L'Université n'est pas par nature une consommatrice de logiciels, mais une productrice.

Mais si chaque branche de l'Université doit pouvoir féconder le savoir par des théories nouvelles, toutes les branches n'ont pas à considérer l'outil informatique au même niveau.
C'est pourquoi il est de prime abord important de clarifier les attentes et apports des différents acteurs du logiciel.

De l'opérateur au développeur en passant par l'administrateur, le logiciel adéquat est le résultat d'une coopération

Il y a 4 types d'intervenants distincts autour d'un logiciel :

Opérateur

Il s'agit d'un utilisateur de l'application en elle-même. Il doit n'avoir à se soucier que de son application, pouvoir l'utiliser de la manière la plus efficace possible, et n'avoir rien à connaître, ni de sa programmation intime, ni de l'environnement qui lui est nécessaire — machine ou système d'exploitation.

Programmeur

Il s'agit d'un utilisateur avancé qui peut configurer l'application de manière aisée pour automatiser certaines tâches, en modifier l'interface pour éliminer les fonctions non utilisées ou ajouter des liens vers celles que les opérateurs vont devoir, pour le problème considéré, employer le plus fréquemment. Il doit pouvoir réfléchir en terme de problématique de haut-niveau, et utiliser des moyens relativement intuitifs (scripts par exemple) pour adapter l'application à son objet.

Développeur

Il s'agit de l'informaticien qui conçoit le programme en lui-même, en définit l'architecture, le code, le maintient et le fait progresser. Il vaut mieux qu'il ait une notion des usages qui en seront faits s'il ne veut pas perdre de vue l'objectif principal, à savoir de fournir aux opérateurs et aux programmeurs les moyens les plus efficaces de résoudre les problèmes que le logiciel est supposé leur permettre d'attaquer, bref de leur permettre d'approcher aussi près que possible la courbe des besoins, qui n'est jamais linéaire, en la rectifiant par une combinaison de portions de code élémentaires.

Administrateur

Il s'agit de la personne qui assure l'installation, la maintenance, les mises-à-jour des systèmes informatiques. Il n'a pas à connaître ce que fait particulièrement l'application qu'il considère comme un tout : le programme. Son souci principal est que le programme en question puisse s'insérer sans heurts au sein de ses systèmes, de tous ses systèmes en épousant leur évolution : quelle que soit la machine physique, quel que soit le type de système d'exploitation, le programme doit être installable facilement, adaptable, évolutif et doit être administrable de la manière la plus uniforme possible.

Un logiciel à source ouvert permet l'installation sur différents types de machines (par compilation) ; permet l'adaptation, si les normes sont respectées, à de nouvelles versions des différents systèmes d'exploitation ; permet qui plus est d'adapter plus finement le fonctionnement du logiciel à l'évolution des besoins, tout en préservant les acquis (parce qu'à la fois les bases de données — les résultats obtenus — sont réexploitables, et parce que la logique — le logiciel — n'est pas liée statiquement à un système à un moment donné — les logiciels compilés qui ne tournaient que sous DOS imposent de continuer de faire tourner DOS alors qu'il n'est plus maintenu). Le logiciel à source ouvert est un organisme vivant.

Bref, un logiciel à source ouvert est le plus à même de permettre aux quatre types d'intervenants de travailler ensemble et donc d'obtenir un produit conforme aux besoins.

Utilisation d'un logiciel à source ouvert dans un cadre professionnel

Il se trouve que l'auteur de ces lignes — Thierry Laronde — a dû utiliser du logiciel à source ouvert pour répondre à un besoin particulier d'un client pour une étude d'aménagement routier.

Il n'était à l'origine pas prévu d'utiliser la version GPL de GRASS, simplement parce qu'il paraissait plus rentable d'investir dans l'achat d'une licence (valant plus de 6000 euros...) que de passer un temps indéfini à programmer une application particulière. Cela supposait cependant que pour cette dépense initiale (dépense de fonctionnement), la solution était immédiate et entraînait une dépense supplémentaire en formation marginale, et une programmation quasi nulle.

Il n'en était rien.

Consulter un SIG déjà constitué, tout le monde sait le faire. Par contre, devoir construire un SIG à partir de sources hétérogènes, sans informations topologiques (ce qu'on appelle les spaghettis), en automatisant au maximum le processus de récupération (pour des problèmes de coûts, c'est-à-dire de temps), cela n'était pas immédiat.
Non seulement la logique du SIG n'était pas explicitée, mais les outils susceptibles de permettre d'automatiser les tâches imposaient des investissements supplémentaires (outils de développement) et imposaient d'apprendre des langages non normalisés.

Il a été plus rentable et plus simple d'utiliser finalement du logiciel à source ouvert, parce que la présence des sources permettait de bénéficier de la documentation la plus complète, parce que l'organisation et la philosophie de type UNIX® autorisait l'approche de la résolution du problème par étape élémentaire, parce que les outils de programmation (Bourne shell et langage C) sont normalisés et les environnements très communs, très répandus et facilement utilisables.

J'ajoute qu'ayant à l'origine fait des demandes à plusieurs éditeurs commerciaux différents, l'un de ceux-ci n'a jamais répondu alors que, sans doute par coïncidence, il est partenaire d'une structure avec laquelle je me trouvais en concurrence et qui ne souhaitait pas nous voir réussir. Je n'ai pas eu ce problème avec du logiciel librement téléchargeable...

Une synergie à créer

Si l'approche parnassienne (l'informatique pour l'informatique) peut aussi avoir sa valeur (pour l'informaticien, qui se posant un problème totalement théorique va découvrir des méthodes dont il aura l'utilité pratique), il est un moment où l'informatique doit être utile à autre chose qu'elle-même.

Une application ne peut pas être définie en dehors de ses utilisateurs. Dans le cadre des Systèmes d'Information Géographique, ce sont donc prioritairement les acteurs ou chercheurs en sciences humaines qui doivent piloter une telle rencontre, car il s'agit avant tout de répondre à la question : un SIG pour quoi faire ? Le comment le faire ? relèvera de discussions entre développeurs, qui doivent être présents, mais dont le résultat sera le produit des rencontres. Pas son objet.

L'objectif doit donc être, parce que les besoins sont multiples mais que la population intéressée par des problématiques ardues est forcément dispersée, de réunir régulièrement opérateurs, programmeurs et développeurs pour faire le point sur les besoins des utilisateurs (sachant que de faciliter la tâche aux administrateurs incombera aux développeurs).

Et parce qu'il faut un début à tout, le plus important aujourd'hui est de créer un précédent.