Dans le dernier numéro de Code4Lib Journal, deux informaticiens de la bibliothèque nationale de Suède publient un article intitulé « User-Centred Design and Agile Development: Rebuilding the Swedish National Union Catalogue ».

Il s’agit d’un retour d’expérience sur l’adoption d’une méthode de développement dite « agile » pour le catalogue collectif des bibliothèques suédoises, Libris.
Il s’agissait de reconstruire le système de A à Z, en un an seulement, y compris la partie moteur de recherche. Pour favoriser l’innovation, ils ont opté pour mener en parallèle une conception orientée utilisateurs, s’appuyant sur des études d’usages, et un développement itératif de type agile (SCRUM).
Côté étude d’usages, ils ont d’abord fait un questionnaire, puis des focus groups conduits sur la base de scénarios d’utilisation, et enfin des tests d’usabilité sur un prototype et une interface en version beta. Tout ça nous est assez familier, mais ce qui est nouveau, c’est d’adapter la méthode de développement de façon à ce que les retours des utilisateurs puissent être pris en compte dans la réalisation informatique au fil de l’eau.

Dans une méthode agile, l’objectif est de prendre en compte le fait que les conditions et les objectifs peuvent évoluer avec le temps, même pendant que se déroule le projet.
Cela implique de favoriser :
– les individus et leurs interactions plutôt que les processus et les outils
– les logiciels qui fonctionnent plutôt qu’une documentation extensive
– la collaboration avec le client plutôt la négociation contractuelle
– de répondre au changement plutôt que suivre un plan pré-établi.

Comme le dit très justement l’article, ces principes, pour séduisants qu’ils sont surtout vus depuis les utilisateurs du futur système, posent un certain nombre de problèmes. D’abord, ils sont plus inconfortables pour les décideurs, qui perdent en visibilité sur les charges et les dates ce que le projet gagne en souplesse. Il est donc important d’obtenir dès le départ le soutien des décideurs sur la méthodologie, et de bien leur expliquer que même s’ils ne peuvent pas voir les spécifications, le produit final sera bon. D’autre part, le code ainsi construit peut au final s’avérer instable, ce qu’ils ont résolu dans le projet cité en planifiant une session de 3 semaines dédiée à une évaluation fine de la qualité du code.
Tout cela est en grande partie une question de confiance et un des facteurs décisifs du projet a été la mise à disposition d’un espace commun pour les développeurs, où se tenaient également les réunions de travail avec l’équipe projet.

En conclusion, leur retour d’expérience est plutôt bon sur la méthode agile, qui semble avoir évité bien des écueils. Ce qui leur manque c’est plutôt la documentation et le transfert de compétences entre développeurs. Et ils auraient voulu impliquer encore davantage les utilisateurs dans le processus.
Je ne voudrais pas paraphraser la conclusion, qui est classe, donc la voici :

Finally, we would like to conclude that working with user-centred design in combination with iterative development is a better, faster and cheaper way of software development, compared to traditional models. Better – the product being released at the end is a more up-to-date and bug-free version than had we worked with a more traditional approach. Faster – it is our conviction that with traditional methodology we would not have finished on time, or at least not with the same amount of features implemented. Cheaper – if the same number of people are able to do a better job in a shorter amount of time, it is a more cost-effective way of getting the job done.

Il faut reconnaître que le résultat est pas mal du tout : même en suédois, on arrive à s’en servir ce qui prouve que niveau usabilité, c’est plutôt bien fait !!! Enfin pour expérimenter moi aussi la méthode agile en ce moment, je dois dire que cela me paraît effectivement très prometteur pour les projets innovants en bibliothèque.
Merci à Pintini pour la référence.