Quand une bibliothèque dispose d’un développeur, la question des logiciels libres est au cœur des développements. Leur utilisation amène pourtant des contraintes et influence l’organisation du travail. Voici un état des lieux sur leur pratique, avantages et inconvénients.
Un développeur seul n’est rien

Commençons par un constat : pour un développeur web, ce n’est pas très productif de programmer un logiciel de A à Z. La plupart des fonctionnalités de base (création de pages web, gestion d’utilisateurs, etc.) sont fournies par la majorité des CMS et il serait vain de vouloir faire mieux ou de les reproduire à l’identique en travaillant seul. Autre écueil, le travail d’une personne, ne peut rivaliser avec celui d’une communauté de développeurs fournissant mises à jour régulières et correctifs contre les failles de sécurité.
Cependant, on peut comprendre l’envie de l’informaticien de créer sa propre application. Concevoir, modéliser, pratiquer de manière avancée la programmation objet et les patrons de conception sont autant d’étapes passionnantes du cycle de développement. A la manière du forgeron, c’est en développant que l’on devient développeur et l’exercice de son cœur de métier lui permet de réfléchir à sa pratique de la programmation, le code devenant plus propre et efficace, et même beau, au passage.
Des logiciels de qualité
Partant de ce constat, l’utilisation des logiciels libres devient un atout considérable pour un service informatique en bibliothèque. Leur licence permet leur réutilisation, leur modification et offre au développeur la possibilité de les enrichir et les adapter en mettant ses compétences en application. La bibliothèque profite également du travail de la communauté de développeurs fournissant les logiciels, d’autant plus lorsque ces derniers sont spécialisés dans le métier. Leur nombre et leur diversité représente une manne considérable, souvent gratuite. A la BCU, nous n’hésitons pas à les tester et les déployer pour répondre à des besoins précis et ponctuels. Nous avons ainsi mis à disposition des chercheurs une galerie d’images numérisées (piwigo), pour qu’ils puissent les décrire en Dublin Core. Cette description sera réutilisable pour une bibliothèque numérique.
Bref, le tableau est presque idyllique mais à l’usage on rencontre quelques contraintes.
Une course à l’évolution
En premier lieu, intéressons-nous aux mises à jour accompagnant tout logiciel libre. Signe de bonne santé d’un projet, elles permettent de bénéficier des correctifs comblant les failles de sécurité inhérentes à tout logiciel complexe. Elles offrent également les toutes dernières innovations techniques et fonctionnelles du web. A priori, c’est donc un bénéfice de les installer et de faire évoluer le logiciel.
Mais ce processus a une contrepartie. Les temps de maintenance augmentent au fur et à mesure du nombre d’applications installées. Pour preuve, wordpress, utilisé pour l’alambic numérique, propose environ une mise à jour par semaine, que ce soit pour le corps du programme ou pour les extensions installées.
De manière générale les logiciels libres, au moins les plus actifs, souffrent d’une instabilité chronique (au sens d’évolution permanente). Prenons l’exemple de Drupal. Nous l’avons sorti en version 6, au moment même où paraissait la version 7. Dans un an et demi ou deux, quand la version 8 sera prête, la version 6 ne sera plus maintenue. Faut-il passer à la version 7 dès que possible ? Faut-il attendre la version 8 et refondre entièrement le site à ce moment là ? Si l’on veut respecter ces changements de version (et continuer à bénéficier du support de mise à jour), le remplacement du site impliquera de recommencer un cycle de développement (cahier des charges, acquisition de connaissances, formation des utilisateurs, etc.) peu de temps après le précédent.
Il faut toutefois pondérer cet inconvénient. Si le logiciel évolue, les services évoluent en parallèle. Dans deux ans, on peut imaginer que de nouveaux besoins seront apparus et que le remplacement de notre site deviendra évident, et pas seulement pour des raisons logicielles. En bibliothèque, l’avenir proche amènera sans doute à s’intéresser au web de données et au format RDF. On peut toutefois se demander si les efforts fournis aux étapes précédentes ont le temps de porter leurs fruits.
S’adapter au cycle de vie des logiciels apporte son lot de questions importantes : Comment gérer au mieux l’ensemble d’un grand nombre de logiciels installés en interne ? Comment ne pas se laisser déborder par les tâches de maintenance? Comment profiter des changements de version sans devoir tout recommencer à chaque fois ?
Nous n’avons pas les réponses dans l’immédiat, mais ces questions seront au cœur de nos travaux à venir…
OpenEdition vous propose de citer ce billet de la manière suivante :
Mathieu Bacault (20 juin 2011). Logiciels libres et développement en bibliothèque. L'Alambic numérique. Consulté le 8 février 2025 à l’adresse https://doi.org/10.58079/axug
Le pourquoi du raccourcissement du cycle de release, je l’explique en anglais sur mon blog, mais je vais traduire ici en français :
En quoi un cycle long constitue-t-il un problème ? Parce qu’il encourage l’équipe de développement à ajouter des nombreuses fonctionnalités au tout dernier moment (parfois même après la RC1) et ensuite à ne rien ajouter après la sortie de la version majeure. Avec un cycle court, il n’y a aucun problème pour dire “ok, je remets ce développement à plus tard, je l’ajouterai pour la prochaine version majeure”. Avec un cycle long, cela devient plutôt “oh non, si je n’ajoute pas cette fonctionnalité tout de suite, il va falloir attendre 10 mois pour que ce soit disponible dans une version stable ! allez j’essaie de le faire maintenant à l’arrache et je mettrai la pression pour qu’on repousse la sortie de la release”. La conséquence : un cycle qui devient de plus en plus long.
Merci pour votre commentaire et vos explications. Pourrais-je vous demander pourquoi vous avez en projet d’accélérer le cycle de développement de piwigo?
Un logiciel libre au cycle de développement court gagne peut-être en notoriété et par conséquent gagne aussi des contributeurs?
Je suis entièrement d’accord sur le fait de limiter les modifications du noyau du programme pour que les mises à jour soient plus faciles. Il est important de respecter la philosophie du logiciel et ne pas vouloir faire des changements à contre-courant pour une bonne utilisation.
Bonjour,
Je suis le fondateur du projet Piwigo (ce qui explique que j’ai trouvé ce billet, grâce au backlink). Ce billet est très intéressant et je prends à la fois le rôle du développeur de logiciels libres et celui d’utilisateur (j’utilise par exemple WordPress, Drupal, FluxBB, Trac ou encore Dokuwiki).
Sur Piwigo, on est en train de raccourcir le cycle de développement, lire (en anglais) mon billet à ce sujet Piwigo release cycle : on va passer à 6 mois entre 2 versions “majeures”.
Les logiciels évolués, comme WordPress, Drupal ou Piwigo, se laissent personnaliser au moyens d’un système d’extension. Ce sont les fameux plugins (ou greffon) et autres thèmes. Le principe c’est de ne jamais modifier les fichiers originaux de l’application que l’on est en train de rendre “spécifique” à son besoin. Si l’utilisateur de Piwigo a pris le soin de limiter ses modifications à des plugins ou des thèmes, alors il n’aura aucune crainte lors des mises à jour de Piwigo. Entre 2 versions mineures (2.2.1 vers 2.2.2 par exemple), la probabilité de casser un thème ou un plugin est très faible. Entre 2 versions majeures (2.1 vers 2.2), il est possible que certains changement du “noyau” cassent les plugins, qui doivent alors s’adapter. Si l’équipe du projet logiciel fait bien son travail, elle publie la liste des changements techniques à appliquer aux plugins pour les rendre compatibles avec la nouvelle version.
J’ai écrit un peu plus tôt que sur Piwigo, nous étions en train de raccourcir le “cycle de release”. Il va passer à 6 mois au lieu de 12. Avec la nuance suivante : pour la 2.3, on va s’obliger à limiter l’impact sur les plugins, de sorte que les plugins compatibles 2.2 soient automatiquement compatibles 2.3 (c’est une tentative, pas encore sûr d’y arriver). Il y a pas mal de choses à faire sans que l’on ait besoin de casser les plugins, on se garde les modifications impactantes pour la 2.4.
Lorsque j’utilise des logiciels comme Drupal ou WordPress, j’essaie de me conformer à ce que je demande aux utilisateurs de Piwigo : ne pas toucher aux fichiers de noyau (sous peine de perdre la possibilité d’appliquer les mises à jour). Ca limite le travail de maintenance de son code spécifique ! Pour FluxBB en revanche, utilisé sur les forums de Piwigo.org, il n’y avait pas de mécanisme d’extension, donc j’ai fait un tas de modifications sur le noyau, avec pour conséquence qu’aujourd’hui je ne fais qu’appliquer les correctifs de failles de sécurité, mais je ne bénéficie pas des nouvelles fonctionnalités :-/