Par Scott Henwood, directeur, programme Logiciels de recherche
Il y a plus de trois ans déjà, je m’adjoignais au programme Logiciels de recherche de CANARIE au terme d’une longue carrière en développement de logiciels commerciaux et industriels. Jusqu’à présent, l’expérience s’est révélée édifiante. Au niveau de la mise en œuvre, créer un logiciel dans le milieu universitaire ressemble passablement au processus qui consiste à mettre au point un logiciel dans une entreprise. Les conditions dans lesquelles œuvrent les développeurs à l’université et dans une société, en revanche, diffèrent de façon notable.
Puisque l’entreprise a pour point de mire la rentabilité, on y cherche constamment des moyens pour développer les logiciels avec une efficacité maximale. Quoi que les objectifs et les situations diffèrent, je n’ai pu m’empêcher d’observer que certaines techniques de développement commerciales s’adapteraient aisément à la création de logiciels dans les établissements d’enseignement supérieur. Ceux qui élaborent des logiciels dans les entreprises pourraient sans nul doute eux aussi tirer des leçons de la manière dont fonctionnent leurs homologues universitaires, cependant je préfère laisser cette tâche à quelqu’un d’autre, dont la carrière a emprunté un chemin opposé au mien. Ce billet portera donc spécifiquement sur les logiciels de recherche, c’est-à-dire les logiciels conçus pour faciliter la recherche scientifique dans le milieu universitaire.
1. Privilégiez l’approche Agile
Recourir à une approche structurée quelconque pour créer un logiciel a du sens et quand il s’agit de développer un logiciel de recherche, la méthode Agile est assurément un excellent choix. Plus qu’un mot dans le vent, Agile est une manière de gérer les projets informatiques qui s’articule sur la diffusion fréquente, périodique, de versions évolutives, doublée d’essais constants tout au long du projet. Pareille approche implique la participation et la rétroaction continues des utilisateurs, ainsi qu’une adaptation rapide aux exigences quand elles changent, sans que le projet, dans son ensemble, s’en ressente, ou très peu.
L’approche Agile est plus un regroupement de méthodes qu’un processus en soi. La plus populaire s’appelle la méthode Scrum et suppose l’élaboration d’un logiciel par brèves itérations d’une durée précise baptisées « sprints ». Chaque sprint comprend l’examen des exigences et leur classement par ordre de priorité, ainsi que le développement et l’essai en parallèle du logiciel, le but étant de diffuser ou, du moins, de présenter quelque chose susceptible d’intéresser les utilisateurs à la fin de chaque sprint.
Qu’a de si fameux l’approche Agile?
Bien suivie, les entreprises spécialisées dans les produits et services retireront plusieurs avantages de cette approche. Ainsi, une commercialisation plus rapide leur conférera l’avantage du précurseur sur la concurrence. Le logiciel sera souvent de meilleure qualité, car les essais s’effectuent durant le développement. Enfin, il se peut que le client, qu’il s’agisse d’un gestionnaire à l’interne ou d’une organisation de l’extérieur, ne saisisse pas sur-le-champ toutes les contraintes liées au projet. L’approche Agile permettra de s’ajuster aux connaissances acquises ou aux constatations réalisées en cours de route.
L’approche Agile peut-elle profiter aux logiciels de recherche?
Absolument! De par sa nature, la recherche est une activité où les inconnues ne manquent pas. Même en terrain connu, le chercheur est rarement un expert en ce qui concerne les spécifications des logiciels ou la configuration d’une interface pour utilisateurs. Par conséquent, ménager des pauses où les chercheurs (donc, les utilisateurs) pourront évaluer le logiciel en vue de rectifier le tir est d’une utilité inestimable.
Les logiciels de recherche devraient-ils tous être élaborés selon l’approche Agile?
Certainement pas! Si vous collaborez à un projet ambitieux auquel concourent de multiples équipes qui n’épousent pas la méthodologie Agile, vous pourriez mettre le projet en péril en recourant à cette approche, dépendamment de l’étroitesse des liens qui nouent le travail effectué par les différentes équipes. Plus important encore, l’approche Agile n’est pas une panacée. En effet, il arrive que des projets reposant sur cette méthode échouent dans l’industrie, souvent pour des raisons culturelles. Si les membres de votre équipe font preuve de réticence, si aucun ne possède de l’expérience en la matière ou si la direction ne croit pas en cette approche, la méthodologie Agile pourrait ne pas convenir au projet. Les risques de catastrophe sont innombrables, comme l’illustrera une simple recherche sur Google avec les mots « échec projet agile ». Pour ceux qui ne sont pas disposés à s’y consacrer corps et âme, les principes généraux de la méthode Agile, à savoir une rétroaction rapide, des diffusions fréquentes et des essais continuels, suffiront amplement.
2. Recourez à des testeurs attitrés
Comme c’est le cas pour n’importe quel type de logiciel, bogues et erreurs pourraient exaspérer l’utilisateur au point où il renoncera à se servir du logiciel de recherche. En recherche, la collaboration signifie souvent que les utilisateurs sont dispersés géographiquement, ce qui ne fait qu’empirer les choses. En effet, discuter d’un problème par-dessus la paroi de son poste de travail ou en allant dans le bureau voisin n’est alors plus une option. Dans le pire des cas, des erreurs subtiles au niveau de la simulation ou des modules qui traitent les données pourraient entraîner le rappel des résultats de la recherche, ce que personne, bien sûr, ne souhaite!
Beaucoup de services informatiques d’entreprise parvenus à maturité possèdent une équipe de testeurs attitrés. Ces derniers participent habituellement aux essais d’intégration, de performance et de convivialité du logiciel ainsi qu’aux tests sur le système complet. Puisque le développeur devra tôt ou tard tester son code pour en vérifier les fonctionnalités et que la qualité du code qu’il crée demeure sa responsabilité ultime, demander à des ingénieurs d’essais de découvrir les bogues qui auraient dû être repérés au départ durant le développement s’avérera très onéreux.
Mais, si les développeurs vérifient le code eux-mêmes, pourquoi recourir à des testeurs attitrés? Il y a plusieurs raisons à cela.
- Tester n’est pas facile. Même si, en théorie, le développeur pourrait réaliser tous les essais, ce qui fait un bon développeur ne fait pas nécessairement un bon testeur.
- Le développeur a une vision interne du logiciel qui pourrait teinter la manière dont il réalise les essais. Certes, il ne le fera pas délibérément, mais si vous avez rédigé ou révisé le code, il se peut que vous formuliez inconsciemment des hypothèses sur son fonctionnement.
- Les testeurs représentent mieux les utilisateurs et certains testeurs, parmi les meilleurs, sont aussi des spécialistes dans leur domaine.
Une préoccupation dont on m’a souvent fait part, aussi bien dans le secteur privé que dans le milieu universitaire, est qu’il est impossible d’ajouter un testeur au projet parce que cela en augmentera le coût. Pas d’accord. Bien sûr, les employés entraîneront des frais administratifs, cependant confier la totalité des essais aux développeurs coûtera à peu près autant que recourir à des testeurs attitrés – le projet durera simplement plus longtemps. Ces frais généraux seront amplement recouvrés si l’on découvre les bogues assez tôt.
3. Songez convivialité
Évidemment, les gens n’adopteront pas votre logiciel de recherche, même dépourvu de bogues, s’il est difficile à utiliser. Tout comme il ne fait pas forcément un bon testeur, un bon développeur ne fait pas nécessairement un bon concepteur sur le plan de la convivialité. Les organisations qui mettent au point des logiciels commerciaux depuis un certain temps intègrent souvent des graphistes et des experts en convivialité à leur processus de développement. Le coût n’est pas énorme. Quelques jours de travail suffiront parfois à un spécialiste pour évaluer la présentation du logiciel, sa structure et son organisation, son accessibilité, sa compatibilité avec les appareils mobiles, sa tolérance aux erreurs et le reste.
Pour rendre le logiciel convivial, il importe aussi de rédiger la documentation d’appoint. Mais devrait-on dépenser des dizaines de milliers de dollars pour écrire un épatant manuel en deux attrayants volumes? Qui les lira? Ceux qui participent au programme Logiciels de recherche de CANARIE ont commencé à remplacer la documentation écrite par de brèves bandes vidéo descriptives avec saisie d’écrans. Ces guides visuels s’avèrent très efficaces et leur réalisation coûte peu.
Qui devrait créer la documentation destinée aux utilisateurs dans ce cas? Arrêtez-moi si je l’ai déjà dit, mais un bon développeur ne fait pas forcément un bon rédacteur. Ajouter un tel spécialiste à l’équipe n’aboutira pas qu’à de la documentation de qualité. Un autre avantage pourrait en ressortir. En effet, pour bien comprendre le logiciel, le rédacteur devra s’en servir abondamment. De ce fait, il deviendra souvent un membre informel des équipes à qui l’on a confié les essais et la convivialité.
Comment amènera-t-on plus de créateurs de logiciels de recherche à adopter pareilles approches?
Cette liste n’est en aucun cas exhaustive. La maintenance à long terme des logiciels de recherche, par exemple, mériterait en soi un article complet.
Les bailleurs de fonds comme CANARIE jouent un rôle capital en favorisant l’adoption de pratiques exemplaires pour le développement des logiciels qui appuient la recherche. Les ateliers de CANARIE destinés aux développeurs de tels logiciels contribuent à l’échange des meilleures pratiques en génie informatique ainsi qu’en gestion Agile des projets dans le milieu de la recherche. Au départ, ces ateliers étaient réservés aux personnes inscrites au programme Logiciels de recherche, toutefois nous prévoyons les élargir aux développeurs qui participent aux recherches subventionnées par d’autres organismes de financement nationaux.
Pour encourager le recours à des équipes de développement multifonctionnelles, nous incitons ceux qui sollicitent des fonds à inclure des testeurs, des gestionnaires de projet, des rédacteurs techniques et des professionnels de la convivialité au plan de leurs projets.
L’objectif est d’amener ceux qui élaborent des logiciels de recherche du Canada entier à collaborer de manière à réduire le plus possible le double emploi et d’optimiser la réutilisation des logiciels pour qu’on se concentre sur les aspects du logiciel se rapportant uniquement à la recherche et pour que les chercheurs fassent ce qu’ils font le mieux : progresser vers de nouvelles découvertes scientifiques.