L’introduction des logiciels libres à l’ENST : une histoire vécue

Je suis, depuis 1999, enseignant-chercheur en informatique à l’École nationale supérieure des télécommunications (ENST). Auparavant, de 1991 à 1994, j’étais moi-même à la place de ceux qui sont aujourd’hui mes élèves.

Ce faisant, j’ai suivi et souvent participé à la mise en place des logiciels libres dans l’école. En 1991, en utilisant Perl sur les machines utilisant le système propriétaire SunOS, je me prenais comme un cowboy des temps modernes, un rebelle contre l’autorité. Cette sensation s’est accentuée en 1992 lorsque j’ai installé 386BSD puis Linux sur mon 486 flambant neuf équipé de ses 4 Mo de RAM. Le terme de logiciel libre n’apparaissait dans aucun journal, aucune télévision. Je n’ai réalisé que beaucoup plus tard que ce mouvement n’était pas né le jour où j’en avais entendu parler mais une trentaine d’années plus tôt.

Il n’en reste pas moins que nous n’étions que deux étudiants sur une promotion de plus de 200 à utiliser consciemment des logiciels libres. Nous n’étions pas des fanatiques, seulement des aventuriers. L’indiscrétion de Google me permet aujourd’hui de me retourner, souvent avec quelque gêne, vers ma folle jeunesse, lorsque je posais des questions portant aussi bien sur des logiciels libres que sur des logiciels propriétaires, le plus souvent dans un anglais plus qu’approximatif.

Mais revenons à l’école. À l’époque, chaque annonce d’une mise à jour du système d’exploitation provoquait une mini crise d’épilepsie chez les administrateurs système. En effet, il fallait systématiquement s’assurer de la compatibilité de l’ensemble des logiciels utilisés par les enseignants-chercheurs ; en cas de problème, les solutions n’étaient pas nombreuses : soit on réinstallait l’ancien système, soit on se procurait, contre espèces sonnantes et trébuchantes, une nouvelle version du logiciel problématique. Bref, soyons clairs, c’était loin d’être l’extase.

Avançons maintenant d’une quinzaine d’années pour nous retrouver en 2007. Comment se présente la situation aujourd’hui ?

Commençons par les systèmes d’exploitation. SunOS est devenu Solaris qui est maintenant libre. GNU/Linux et FreeBSD sont omniprésents. Quelques rares salles de travaux pratiques arborent encore des ordinateurs tournant sous Microsoft Windows. Mais, me direz-vous, pourquoi, en 2007 et dans une école publique, utiliser un système d’exploitation propriétaire alors que des alternatives libres existent ?

À cause tout simplement… d’autres logiciels propriétaires. Certains éditeurs, pour des raisons qu’ils sont les seuls à connaître, n’offrent toujours pas de version de leurs programmes pour GNU/Linux ou FreeBSD. C’est leur droit le plus strict ; mais lorsque ces logiciels sont indispensables pour l’enseignement, ils provoquent un effet domino qui impose l’utilisation d’une version spécifique d’un système lui-même propriétaire.

Heureusement, dans le cas de la plupart des enseignements dispensés, une alternative libre existe, souvent de qualité équivalente ou supérieure à ce qui existe en logiciel propriétaire. Dès lors, la vie devient plus simple. L’apparition d’une nouvelle plate-forme matérielle ou d’une nouvelle version du système d’exploitation nécessite, la plupart du temps, une recompilation du logiciel. Si un problème survient, il sera bien souvent déjà résolu par la communauté ; dans le cas contraire, des personnes de chez nous se chargeront de l’atomiser et partageront la correction avec les autres utilisateurs.

La versatilité des logiciels libres leur permettent, du moins pour ceux utilisés pour l’enseignement et la recherche, d’être installés sur un grand nombre de plates-formes. C’est ainsi qu’un étudiant disposant d’une machine personnelle pourra généralement reproduire chez lui l’environnement de travail qu’il utilise à l’école, que ce soit sous Microsoft Windows, GNU/Linux, MacOS X ou que sais-je encore. Et ce, en tout légalité.

L’étudiant souhaite partager ces logiciels avec un ami ou un camarade de promotion ? Qu’il le fasse, bien au contraire, les logiciels libres raffolent de la copie sauvage. Il veut installer ces mêmes logiciels sur l’ordinateur de ses parents pour travailler lorsqu’il rentre en week-end (vous remarquerez à l’occasion que les années n’ont en rien entamé ma candeur et ma naïveté) ? Grand bien lui fasse, y compris si ses géniteurs ont choisi un autre environnement informatique.

Un enseignant-chercheur souhaite reproduire ce que fait un de ses collègues ? Rien de plus simple avec les logiciels libres. Travailler chez lui ? Mais allez y mon bon monsieur, copiez, c’est toujours un plaisir.

Vous l’aurez compris, depuis que l’on utilise les logiciels libres sans aucune modération, la vie des enseignants-chercheurs, des étudiants et des administrateurs système, qui ressemblait auparavant à un chemin de croix, s’approche maintenant d’un petit sentier parsemé de pétales de roses. Non non, je vous assure, j’exagère à peine.

Cependant, pour être tout à fait honnête, je dois avouer un peu honteusement que les logiciels propriétaires font mon bonheur une ou deux fois par an : lorsque je vois mentionner, sur une listes de diffusion interne, que la licence d’un logiciel propriétaire a expiré et que l’on attend son renouvellement pour pouvoir l’utiliser à nouveau, je jubile et j’exulte.

Moi aussi, à une époque, j’étais prisonnier. Puis je me suis libéré.

(texte écrit pour la lettre de l’École ouverte francophone)


Related posts:

  1. Logiciels libres et DADVSI : il y a urgence
  2. C’est parti

4 comments to L’introduction des logiciels libres à l’ENST : une histoire vécue

  • Les licences c’est chiant, mais les méthodes de développement ont changé aussi :

    bibliothèque ou système propriétaire : je regarde et essaie de comprendre la doc technique. Ca ne marche pas ? J’essaie de relire la doc technique pour voir où je me suis trompé, et j’essaie de trouver des exemples d’utilisation. Je ne trouve pas ? J’utilise l’assistance de l’éditeur, si je l’ai payée. Finalement il s’avère que c’est un bug chez eux… même s’ils le corrigent à terme, je suis obligé de le contourner (si c’est possible) en attendant que leur prochaine version soit publiée et diffusée chez mes utilisateurs… si elle l’est.

    bibliothèque ou système libre : je regarde la doc technique. Ca ne marche pas ? Je peux aller voir le code source de la bibliothèque concernée pour comprendre ce qui est éventuellement mal documenté. Finalement il s’avère que c’est un bug dans la bibliothèque utilisée : j’envoie un patch aux auteurs et je l’installe chez moi pour commencer. Je recommande à mes utilisateurs de mettre à jour leur version de la bibliothèque utilisée ; si aucune correction n’est diffusée par les auteurs je peux le faire moi-même.

  • Mais quels logiciels propriétaires ? ;) Dans les écoles d’ingé, il y a souvent du Matlab qui traîne (la version sous Linux étant assez calamiteuse, Simulink étant plus ou moins catastrophique, même), mais j’ai vu (chez Cossaw) que l’on pouvait faire des choses tout à fait sérieusement en cours avec scilab/scicos (à Centrale, en l’occurrence). Au salon RTS, je suis tombé sur Labview (de National Instrument), typiquement englué dans le proprio, y compris les formats de fichier, l’interfaçage .Net/VB (ouch !), la disponibilité sous windaube uniquement, etc. Alors effectivement, ça fait des trucs assez puissant dans le playmobil-like, mais le jour où la boîte coule, où le produit est simplement abandonné (ce qui finit toujours par arriver, il ne faut pas croire…), la pérennité de la solution frise le zéro absolu… Le pire étant les compilos propriétaires, ou comment couler en deux secondes une boîte s’il s’avérait qu’il disparaissait (Aonix sort la tête de l’eau apparemment, l’industrie militaire peut reprendre son souffle…) ; je connais ainsi de très grandes entreprises qui sont toujours sur Ads de ARM, l’ancêtre non compatible de RVDS, datant du début des années 90, et qui ne peuvent pas vraiment en changer sans engager des coûts énormes (mais ces problématiques ne doivent pas affecter les cursus scolaires, seulement le milieu industriel pur, non ?).

  • palpatine: pour remplacer Matlab il y a aussi Octave, utilisé à l’ENST, notamment sur les machines Solaris Opteron, car il n’existe pas de version de Matlab pour cette architecture. Encore un autre inconvénient des logiciels propriétaires, on est lié aux architectures que l’éditeur daigne supporter.

  • Il y a aussi Yacas, j’ai fait le tour ;) (c’est plutôt du Mapple-like, ceci dit, pas tout à fait le même secteur ; avec gnuplot en sortie graphique ; et quelques plugins pour faire des sorties LaTeX réinterprétées en graphique, ça c’est cool). Quant aux architectures, c’est toujours du x86 de supporté, voire du Sparc quand on veut être royal (et qu’on a beaucoup de vieux clients industriels), mais c’est surtout une question d’OS, et d’API de programmation utilisée (les meilleurs, c’est Matlab : y’a même du java au milieu… Quoi que Scilab n’est pas en reste) ; les gens qui font ce genre de softs sont de piètres programmeurs pour la grande majorité (il n’y a qu’à voir les performances, c’est franchement désolant). À ce propos, scilab va avoir un portage sous java (hum les perf ^^), avec une jolie interface (enfin !), bien portable, d’ici la fin de l’année.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>