Retour à l'interview d'Alan Fustec

Trois exemples de coopération manquée

Difficultés administratives

Il y a quatre ans, nous nous intéressions aux points de fonction. Cet outil de gestion du développement logiciel s'accordait bien avec nos objectifs de travail sérieux et méticuleux, visant à la maîtrise des coûts et délais.

Malheureusement, cette méthode, telle quelle, ne convient pas à la maintenance, qui n'augmente pas forcément le nombre des points de fonction d'un programme (exemple caractéristique : l'adaptation à l'an 2000).

Nous avons donc eu l'idée de développer le concept de "micro points de fonction", plus fin, et qui aurait répondu à nos attente. Nous avons tenté de monter un partenariat avec une école d'ingénieurs normande , mais les difficultés administratives se sont avérées plus forte que la motivation du laboratoire.

Objectifs purement scientifiques

Il y a quelques années, j'ai eu connaissance du projet Epsom (European Platform for Software Maintenance) qui venait de se terminer. J'ai rendu visite à l'équipe toulousaine qui en était le partenaire français. Mon interlocuteur n'a pu me remettre que des publications techniques inutilisables par notre entreprise : ces travaux de recherche, dite pourtant "appliquée", n'étaient pas applicables en l'état, et loin s'en faut.

Difficulté à comprendre les besoins des entreprises

La difficulté des chercheurs à comprendre le monde des affaires est particulièrement évident en France. Mais j'ai fait des expériences analogues avec des chercheurs britanniques, plus proches que les français du monde des affaires. En matière de maintenance logicielle (une des spécialités de Sys-Com), une équipe de l'université de Durham était allée jusqu'à créer une start-up afin de commercialier leur produit.

En l'occurrence, il s'agissait d'un traducteur de programmes d'un langage dans un autre. On pouvait l'utiliser pour sécuriser des programmes en assembleur, en passant par le langage formalisé WSL. Dans ce langage, des transformations conduisaient à un noyau formellement correct. Il n'y avait plus qu'à re-traduire en assembleur pour obtenir un code propre.

Cela nous intéressait car certains de nos gros clients (les AGF, par exemple), avaient à l'époque un parc logiciel considérable en assembleur.

En pratique, le produit que la start-up voulait commercialiser, avec un nom séduisant (Fermat) et une belle plaquette en couleurs, était inutilisable. Il n'offrait que des fonctions de bas niveau et exigeait des utilisateurs un haut niveau de compétence en programmation... et en fait le recours fréquent aux concepteurs mêmes du produit.

La formule "Une idée vaut 1F, sa réalisation 10 F et sa mise en oeuvre praique 100 F" reste toujours valable, et se traduit dans le niveau des investissements que les entreprises commerciales sont prêtes à consentir. Mais cette loi d'airain est difficile à admettre pour les chercheurs.