Précédent Suivant Index

Ateliers de conception participative de logiciels pour les biologistes

Ces derniers mois, des ateliers de conception de logiciels ont eu lieu. Ces ateliers sont dits « participatifs » parce que leur objectif est de faire « participer » des chercheurs à la conception des outils qu'ils utilisent pour l'analyse de séquences -- il s'agit en l'occurrence ici d'un outil pour l'alignement multiple.

Leur objectif est d'intégrer au mieux l'informatique dans l'environnement de travail des biologistes, et non comme c'est malheureusement trop souvent le cas, de forcer les utilisateurs à s'adapter à un système dont le modèle de fonctionnement ne correspond pas au leur, mais à celui de l'informaticien. Cela va bien plus loin que la réalisation d'une « jolie interface » : il s'agit de l'adéquation d'un outil aux besoins réels des utilisateurs, pas d'une piste clignotante avec des couleurs et des boutons partout.

La conception d'un outil informatique peut être considérée essentiellement comme une affaire d'informaticien. Après avoir identifié un besoin et suffisamment analysé le problème, il se lance dans la conception et l'implémentation de l'outil. Un dialogue fréquent avec des utilisateurs potentiels ou avec les demandeurs permet d'affiner l'analyse en cours de route. Enfin, lorsqu'une première version est prête, il est d'usage d'évaluer le logiciel par des tests auprès de quelques utilisateurs.

Remarquons d'abord que cette ligne de production courante dans les domaines commerciaux et industriels, où les contraintes d'utilisabilité et d'ergonomie sont désormais classiques, est en réalité insuffisamment appliquée telle quelle dans le domaine du logiciel scientifique académique. D'une part ce sont souvent des scientifiques eux-mêmes qui produisent le logiciel, et, c'est bien normal, ils ne s'intéressent pas vraiment à ces problèmes : ils écrivent souvent les logiciels d'abord pour eux-mêmes avant de les distribuer à d'autres. Par ailleurs, les exigences que les informaticiens professionnels développant pour ce domaine se donnent portent essentiellement, et on le comprend aussi, sur la validité scientifique du résultat d'un l'algorithme ou sur la qualité des données d'une base de données : l'interface utilisateur est tout juste considérée comme un problème d'implémentation... et les tests, c'est uniquement pour un monde idéal où on aurait du temps à y consacrer...

Le résultat, nous le voyons tous les jours. Même si certains logiciels, souvent sur micro-ordinateur, font très bien un petit ensemble de tâches, nous constatons tous à quel point il est difficile et pénible d'effectuer ce qu'on souhaite sans utiliser une pléthore d'outils différents. Bien souvent, on renonce à résoudre un problème par l'informatique. Enfin les outils ne donnent souvent qu'une vague idée de ce qu'ils permettraient de réaliser. Lorsqu'on n'a pas le temps d'apprendre à maîtriser autant de logiciels différents, on se cantonne à un ensemble stable et cohérent, comme un serveur Web ou un progiciel. Mais cet ensemble est souvent insuffisant.

Les méthodes de conception participative ont ce même but d'améliorer les logiciels du point de vue de leur utilisabilité, mais, pour y parvenir :

  1. elles intègrent les non-informaticiens dans toutes les étapes de la construction du logiciel, et non seulement au début et à la fin ;

  2. elles permettent une participation active et effective.

Exemples de techniques utilisées lors des ateliers

Le brainstorming :

Il permet d'énoncer des idées sur un thème (celui choisi pour l'atelier était : un éditeur d'alignement multiple), sans contrainte d'ordre, de classification ou de cohérence, ni même de réalisme du point de vue de l'implémentation informatique. Cette technique joue sur les associations d'idées entre les participants et permet parfois, en passant par des idées d'apparence incongrue, de trouver des solutions originales. Un modérateur vérifie que chaque personne exprime ses idées, et vérifie qu'il n'y a pas de censure. Une des règles stipule que chaque participant doit émettre au moins une idée qu'il juge stupide - mais sans dire laquelle. À la fin, chaque groupe choisit par un vote les idées qui lui semblent les plus significatives et les expose aux autres groupes (Fig. X).



Figure 1 : Liste d'idées issues du premier atelier

Le prototypage non-informatique :

On utilise des accessoires de bureau pour réaliser une ou plusieurs actions interactives, non pas avec un vrai logiciel, mais avec des simulacres d'interface utilisateur : un postit pour une boîte de dialogue ou un menu déroulant, du papier collant transparent pour une sélection, du scotch double-face non permanent pour accrocher un élément temporaire, des feutres de couleurs différentes, des ciseaux pour fabriquer de nouvelles fenêtres, etc... Le prototypage s'appuie sur des cas concrets : c'est un scénario d'utilisation spécifique et réellement observé qui est rejoué avec les accessoires : réarrangement des gaps dans un alignement d'ADN, recherche d'un motif particulier dans des séquences de protéines pour isoler une zone particulière (Fig. X), ajout d'une note ou d'un lien avec un fichier chromatographie (Fig. X), ....


Figure 2 : Détermination d'une zone de recherche
Le but apparent du prototypage est la conception de l'interface utilisateur, mais en fait, c'est surtout un outil de communication. Parce qu'il aboutit à une situation particulière et concrète, il peut laisser apparaître une incohérence dans la compréhension du problème par l'informaticien ou un problème qui a été oublié ou mal défini. Ainsi, lorsque les biologistes décrivent une analyse ou une problématique particulière, il y a toujours des éléments qui sont considérés comme anodins ou des petits problèmes insolubles (un détail dans un format de fichier...) dont on ne parle pas, tellement ils sont habituels, mais qui en fait finissent par empoisonner la vie et empêcher de travailler efficacement. Ces détails aussi peuvent être découverts et rediscutés lors du prototypage.



Figure 3 : Prototypage des annotations
Ces deux techniques présentent volontairement un caractère informel, concret et non informatique. Elles sont destinées à favoriser la communication et non à la formaliser, comme le font les documents de spécification informatiques ou les images écrans, qu'elles ne remplacent pas mais qu'elles complètent. Elles ont donc l'avantage de la conversation informelle, mais pas son inconvénient, qui est d'être trop abstraite, trop vague.

Enfin, ces ateliers sont aussi l'occasion de :

Éditeur d'alignement

Le thème choisi est la conception d'un éditeur d'alignement. Pourquoi ? Parce que l'alignement (simple ou multiple) est un problème et un outil central dans l'analyse de séquences.

Un certain nombre de raisons peuvent faire de cet outil une aide précieuse :

Certaines de ces fonctions existent de manière éparpillée dans plusieurs logiciels différents, fonctionnant sur différentes plates-formes, et surtout, n'ont de manière générale que très peu fait l'objet d'études auprès des biologistes. C'est la raison de ce projet, dont la suite immédiate va être l'implémentation d'un premier prototype.

Si vous êtes intéressé vous êtes bien sûr bienvenu. Il n'est pas nécessaire d'avoir participé aux premiers ateliers ni d'être un expert en analyse de séquences, bien au contraire.



Catherine Letondal

Édité par :
Service Informatique Scientifique
Institut Pasteur
28 rue du Docteur Roux
75724 Paris CEDEX 15
Tél. : +33 (1) 45 68 85 10
Fax. : +33 (1) 40 61 30 80
Câble : mcb@pasteur.fr
Les contributions et suggestions
sont à adresser à :
Laurent Bloch   bloch@pasteur.fr
Directeur de la publication :
Maxime Schwartz
ISSBN : 1244-524 X

Copyright © Institut Pasteur

Précédent Suivant Index