Le numérique est devenu un outil indispensable de la science et l’accès aux programmes informatiques est un enjeu important. Pour la reproductibilité de la recherche bien sûr, mais plus encore pour diffuser des informations, des « détails », que l’on trouve rarement dans les articles scientifiques eux-mêmes.

Les logiciels ont pour particularité d’être exploitables sans en comprendre tous les détails s’ils sont suffisamment bien conçus, à la différence des articles scientifiques. On peut considérer qu’il s’agit de « connaissances exécutables ». Leur diffusion en dehors des laboratoires a donc un potentiel d’impact important sur la société. Une autre particularité des logiciels est qu’ils évoluent, ne serait-ce que pour s’adapter à leur environnement qui évolue sans cesse. Comment permettre l’essaimage de ces outils uniques ?

Les laboratoires de recherche créent des logiciels

La complexité d’un logiciel varie : du script utilitaire (l’équivalent d’un marteau dans un atelier) à un environnement complet (l’atelier complet du forgeron, avec tous ses outils), en passant par des preuves de concept créées à l’occasion de master ou de thèses (les nouveaux outils, qui n’ont pas encore été optimisés et dont l’usage n’est pas encore répandu). Dans bien des cas, un code n’est pas initialement conçu pour perdurer ou être réutilisé… alors qu’il pourrait être utile à d’autres, et que sa diffusion pourrait avoir de la valeur.

Nombre de logiciels créés dans les laboratoires de recherche ne sont pas écrits par des spécialistes du développement logiciel, mais par les chercheurs eux-mêmes, quelle que soit leur spécialité. La priorité est alors d’écrire des programmes qui correspondent aux formules, algorithmes, processus, modèles qu’ils étudient, avant toute considération de génie logiciel. Ce qui caractérise ces logiciels, c’est la complexité du sujet traité : ce qu’ils font est généralement compréhensible des spécialistes uniquement. C’est ce qui rend difficile leur maintenance par une tierce personne.

Enfin, les logiciels développés dans le cadre d’un travail de recherche sont avant tout conçus pour être utilisés dans un environnement contrôlé : celui du laboratoire. De fait, leur utilisation dans un autre environnement peut s’avérer compliqué : matériel, système d’exploitation, compilateurs (qui permettent de passer du code source au code exécutable par la machine), fonctionnement dépendant de matériels ou de logiciels qu’on ne peut pas diffuser, etc.

Les logiciels sont des outils qui évoluent sans cesse

Un logiciel évolue, c’est dans sa nature. Si son périmètre fonctionnel ne change pas, il faudra l’adapter au fur et à mesure de sa diffusion à de nouveaux systèmes d’exploitation, nouvelles architectures, nouveaux compilateurs, etc. Mais aussi et surtout corriger les bugs trouvés lors de l’usage du logiciel dans un environnement différent de celui du laboratoire.

Idéalement, il faut aussi permettre aux utilisateurs de contacter les auteurs du logiciel : de la simple adresse mail à la liste de diffusion, du forum de discussion à un outil spécifique pour gérer les demandes d’évolution ou de correction du logiciel.

Pour mettre à disposition un logiciel, il faut déterminer les conditions d’utilisation, c’est-à-dire choisir une licence. Une des solutions pour partager l’effort de maintenance des logiciels de laboratoire est de choisir une licence libre, pour permettre à l’utilisateur d’adapter lui-même le logiciel a ses besoins.

Les logiciels libres

Les logiciels libres sont des logiciels pour lesquels le ré-utilisateur dispose de quatre droits fondamentaux : les utiliser, les étudier (leur code source), les modifier et les redistribuer. On trouve souvent des logiciels dont le code source est disponible dans le monde académique, mais pour un usage académique uniquement. Ce ne sont pas, par définition, des logiciels libres, qui sont libres pour tous.

Comme l’utilisation est libre pour tous, l’accès au logiciel est gratuit. Ce sont généralement les services autour du logiciel qui sont payants (le support, l’intégration, le développement de fonctionnalités spécifiques, etc.).

Comme un logiciel évolue, l’idéal est de diffuser à l’aide d’un dépôt de code dit « incrémental », qui permet de facilement comparer les différentes versions, et de les maintenir. Il existe actuellement bon nombre de solutions, appelées des « forges » permettant d’intégrer un dépôt incrémental de code, un système de gestion de tickets et des procédures de construction automatique du logiciel à partir de son code source. Ces forges facilitent l’échange de code entre développeurs à l’aide de propositions de modifications sur le dépôt de code. Ces contributions ne sont pas anodines et doivent être prises en compte dans la gestion de la propriété intellectuelle.

En réalité, donner accès au code source d’un logiciel n’est généralement pas suffisant pour permettre son adoption : il faut idéalement disposer de tests automatiques (vérifier automatiquement que pour un certain nombre d’entrées, les sorties attendues sont obtenues) et d’un moyen simple de construire l’application à partir de son code source. C’est ce qui permet de vérifier qu’une modification du code n’entraîne pas de dysfonctionnement évident dans l’application, et, pour un futur utilisateur, de s’assurer qu’il aura la possibilité de maintenir lui-même le logiciel en cas de nécessité.

Sat4j : d’un laboratoire universitaire à une utilisation indirecte massive par des développeurs

Sat4j est une bibliothèque d’outils permettant de résoudre « le plus simple des problèmes difficiles », le problème SAT et ses variantes. Il s’agit d’un problème « pivot », qui permet de résoudre beaucoup d’autres problèmes.

À lire aussi :
Ils ne savaient pas que c’était insoluble, alors ils l’ont résolu

Ces outils ne sont pas destinés au grand public, plutôt aux chercheurs, aux étudiants de master ou à des ingénieurs spécialisés. Contrairement aux autres outils développés dans la communauté scientifique orientés vers la performance pure – la vitesse de résolution des problèmes, Sat4j a été conçue dès le départ comme une brique réutilisable pour les utilisateurs du langage Java.

Sat4j comporte actuellement 45 000 lignes de code et pratiquement 2900 tests automatiques. Sat4j a été développée initialement en 2004 par deux enseignants-chercheurs de l’université d’Artois, une « petite » université de 11 000 étudiants située dans le bassin minier, au sein du Centre de Recherche en Informatique de Lens. Elle a été dès le départ conçue pour être réutilisable hors du monde académique, notamment en la diffusant sous une licence libre permettant son utilisation dans tout type de logiciel. Sat4j a été diffusée dès ses premières versions par le consortium ObjectWeb qui fournissait le dépôt de code, les listes de diffusion et la gestion de tickets nécessaire à son évolution.

En 2007, la plate-forme ouverte Eclipse cherchait une solution pour résoudre le problème de dépendances de ses greffons (ou plugin, en anglais). Eclipse est une plate-forme qui fournit et produit des outils pour réaliser des logiciels – elle est souvent utilisée comme base pour des outils développés par de grandes sociétés, comme IBM, Oracle ou SAP. Chaque module dépend d’autres modules, ou est incompatible avec d’autres. Quand on installe un « greffon », c’est-à-dire un ou plusieurs modules complémentaire, il faut veiller à respecter les dépendances et incompatibilités entre modules.

Il s’agit en fait de résoudre le problème SAT. Si les outils ad hoc développés initialement fonctionnaient correctement quand le nombre de greffons était réduit, le succès de la plate-forme a nécessité une refonte complète de la gestion des dépendances. La bibliothèque Sat4j a été sélectionnée car elle répondait au besoin fonctionnel d’Eclipse, était maintenue et parce que la licence a pu être adaptée pour les besoins d’Eclipse.

En juin 2008, Eclipse 3.4 sortait avec un nouveau système de gestion de ses greffons basé sur Sat4j. Un seul bug dans ce contexte a été trouvé dans la bibliothèque depuis (très rapidement, et corrigé dans la version de septembre 2008). L’intégration a été affinée pendant deux ans, avec notamment la mise en place d’un mécanisme d’explication quand l’installation d’un « greffon » n’est pas possible, dans le cadre d’un contrat avec la société Genuitec. En juin 2010, une « place de marché pour greffons » (un app store spécialisé pour développeurs informatiques) a été ouverte pour Eclipse – basée sur Sat4j.

Toutes les installations de greffons sur ce marché se font à l’aide de Sat4j, soit plus de 40 millions d’installations à ce jour. C’est aussi le cas de toute mise à jour, toute installation manuelle dans Eclipse ou dans les logiciels basés sur Eclipse. Cependant, ce travail est caché. Pratiquement aucun utilisateur d’Eclipse ne connaît l’existence de Sat4j.

Si la dernière version officielle de Sat4j, intégrée dans Eclipse, est sortie il y a sept ans, la bibliothèque continue d’évoluer au fil de nos travaux de recherche.

Sat4j a dès le départ été développé à l’aide du logiciel libre Eclipse : un juste retour des choses, qui souligne le potentiel de co-construction des logiciels libres.

Cet article est republié à partir de The Conversation sous licence Creative Commons. Lire l’article original.