Choisir un logiciel libre

Depuis quelque temps, j’en suis à travailler à la recherche d’un CMS pour le ministère et les différents organismes qui y sont associés. Tout d’abord, je dois dire qu’il est assez difficile de s’y retrouver. CMS Matrix répertorie près de 800 d’entre eux, j’ai même vu une référence qui disait qu’il y en avait plus de 1700! Comment s’y retrouver?

Pour diverses raisons, dont je ne ferai pas l’étalage ici, il a été choisi de se tourner vers des logiciels libres, du moins, dont le code source est partiellement ouvert (certains on des licences très particulières…). Ça diminue le terrain de jeu, mais il n’en demeure pas moins qu’il en reste beaucoup.

Il a fallu que je planche sur une méthode de travail. Oh joie! j’ai trouvé un document du Cirano, «Évaluation et expérimentation de logiciels libres pour la petite et moyenne entreprise» qui présente le travail fait dans le cadre d’une étude pour sélectionner une certaine catégorie de logiciel libre. Je suis donc parti de ça pour élaborer une méthode.

Processus de sélection

L’objectif du processus de sélection n’est pas le processus en lui même, comme il arrive trop souvent au gouvernement, mais plutôt sa finalité, le choix. J’avais au bas mot trois semaines pour y arriver et ce, avec un argumentaire qui soit assez efficace. Le document se résume finalement à dix pages d’analyse, contre un peu plus d’une trentaine en annexes (références, grilles d’évaluation avec résultats, critères…).

Alors, c’est quoi ce processus? en fait, je me suis fortement inspiré de la méthode de David A. Wheeler.

Je tiens à signaler que cette approche n’est pas scientifique et est grandement limitée par le nombre de personnes faisant l’étude (moi même) et le temps qui a pu y être consacrée. C’est loin de ressembler à l’étude de Cirano mentionnée plus tôt, où la rigueur scientifique est marquante. Je tiens à rappeller que l’objectif est d’en arriver à un choix rapidement sans tourner en rond sans fin!

Présentation du processus de sélection d'un logiciel libre selon Gou, inspiré de David A. Wheeler

Dans la suite du billet (en fait, c’est presqu’un roman maintenant), je vous présente brièvement les différentes étapes. Non, je ne présente pas les résultats (ça viendra plus tard, c’est encore en cours d’évaluation!).

Identification

La première phase consiste à diminuer le champ d’étude en sélectionnant des produits les plus susceptibles de satisfaire les besoins de l’organisation. Il faut garder en mémoire que plus de 1700 produits sont référencés sur CMS Matrix.org et qu’il serait absurde de tout vouloir les tester.

Pour procéder à la première sélection, il a été fait une première recherche sur les CMS utilisé dans le contexte gouvernemental (lesquels sont mis en place) et sur divers sites corporatifs. De multiples recherches sur Google et une consultation de sites tels que cmsmatrix.org, cmswatch.com, cms-quebec.com, wikipedia.org, cmsreview.com et contentmanager.net, sans compter de nombreux blogs, listes de discussion et forums.

Suite à cette identification, nous avons gardé plusieurs candidats potentiels. J’étais prêt à passer à la prochaine étape.

L’évaluation

Pour la phase d’évaluation, il est recommandé (Wheeler) de faire de la lecture sur des revue des divers logiciels. Articles, billets, commentaires, comparaisons… Il existe une multitude de sources permettant de discriminer et classer les divers produits entre eux.

Un document particulièrement intéressant est l’évaluation de Frank Bresson «Gestion de contenu Web, 15 cms/portail open source passés au crible». De nombreux autres articles et documents ont été épluchés avant de pouvoir créer une liste de candidats potentiels.

En consultant de façon plus approfondie les références, on a pu écarter les produits non pertinents ou inintéressants dans la dernière liste. Il restait dorénavant moins d’une vingtaine de produits.

La comparaison

Cette étape se fait par la consultation des sites Web des différents projets ou produits et l’analyse des caractéristiques de ceux-ci. Ainsi, une grille d’évaluation sommaire a été montée dans laquelle on retrouve des critères essentiels (ça passe ou ça casse), des critères importants (valant 75% du pointage) et des petits plus (valant 25% du pointage).

Certaines informations ont été difficiles à trouver et ont requis des recherches plus approfondies. La comparaison a pour objectif de réduire à trois les produits à analyser en profondeur. Dans cette étape, ce ne sont pas nécessairement les notes qui sont importantes, mais plutôt l’apprentissage des divers produits qui sera fait tout au long du processus.

Le travail de recommandation d’un logiciel libre est, bien que l’on désire le rendre rationnel, très subjectif. Cette comparaison aura pour effet d’éliminer dans un premier temps les produits qui ne correspondent pas du tout aux besoins et permettront de cibler les candidats à analyser éventuellement.

Ainsi, j’ai pu cibler les trois produits à analyser. Plusieurs ont carrément échoué car ils ne passaient pas les premiers critères essentiels (langue, respect des standards Web…).

L’analyse

Ça, c’est le gros du travail, et la partie la plus amusante (selon moi).

Pour procéder à une analyse détaillée des trois produits restants et pour permettre de sélectionner assez rapidement le plus intéressant, il a été décidé de procéder à une évaluation du niveau de maturité des trois concurrents en se basant sur la méthode OSMM de Bernard Golden. Je ne me considère vraiment pas un spécialiste de la méthode, disons un simple initié. J’ai adapté la grille d’évaluation selon les besoins de notre organisation, ce qui peut être considéré comme un sacrilège ou une erreur, mais j’ai conservé l’essence de la grille.

L’évaluation OSMM

L’évaluation OSMM, ou « Open Source Maturity Model » permet de déterminer le niveau de maturité d’un produit en conformité avec les besoin d’une organisation. La grille employée dans le cadre de l’évaluation actuelle est inspirée de celle présentée par Bernard Golden.

Le niveau de maturité permet de mieux encadrer le choix d’un produit en se référant à son indice de maturité et le type d’organisation qui veut l’utiliser. Ainsi, toujours en se référent aux documents de Golden, on peut, en regardant la note, déterminer si le produit convient à une entreprise qui est précoce ou plutôt à une entreprise dite « pragmatique ».

Précocité versus pragmatisme

Selon Golden, et c’est un fait reconnu aussi en marketing, on retrouve plusieurs types d’entreprise (ou de clientèle) qui adoptera plus ou moins rapidement un produit. Golden subdivise, dans le cas des logiciels libres, la courbe normale en deux groupes, les précoces (« early adopters ») et les pragmatiques (« pragmatists »).

En rapport avec le processus d’adoption d’un logiciel libre, Golden a établi une grille d’évaluation des logiciels qui permet l’attribution d’une note. Cette note permet de déterminer si le produit est acceptable pour une organisation en particulier.

Type d’utilisateur
Type d’usagePrécocesPragmatiques
Expérimentation2540
Pilote4060
Production6070

Golden classe les résultats selon trois types d’usages, soit le test d’un produit, la tenue d’un projet pilote ou l’utilisation dans un univers de production.
Plus la note du projet est élevée, plus il est doté d’une maturée suffisante pour être utilisé dans un univers de production.

Les données présentées par Golden le sont pour une grille standardisée, alors que celle employée pour l’évaluation que j’ai faite est légèrement modifiée pour refléter les caractéristiques d’un CMS et les particularités de l’environnement gouvernemental québecois.

Ce que ça a donné

Le logiciel libre étant, par définition, ouvert, il est nettement plus facile de faire ce genre d’anlayse qu’avec des produits propriétaires fermés. La collecte d’information a permi de connaître de façon beaucoup plus pointue les produits.

La grille permet d’évaluer les fonctionnalités du projet libre, mais aussi de mieux comprendre la vitalité de la communauté et de voir si ce projet est viable dans un contexte précis, comme au gouvernement du Québec. S’il n’y a pas d’implantation du projet dans la région ou la province, il y a fort à parier que le support local sera faible. C’est là un point important à évaluer et ce qui a fait «se planter» deux des produits sur les trois.

Le test de réalité

Pour conclure l’analyse détaillée, il a fallu tester le produit le plus méritant dans un contexte réel (un projet pilote en somme). Cette phase ne fait que confirmer qu’on a bel et bien choisi le bon. Dans notre cas, ça s’est déroulé comme prévu, le bon premier est resté premier. Il n’a pas été nécessaire de regarder les deux autres plus avant.

Des notes sont prises tout au long du processus de la mise en place du produit dans notre environnement et durant la conception d’un site Web exemple. Ces notes servent à documenter et conserver les impressions envers le produit et la facilité d’utilisation. Elles permettent de cibler de façon plus pointue les problèmes qui pourraient survenir lors de l’utilisation du logiciel.

La sélection

Pour la sélection, nous avons (avec mon équipe) regardé les résultats obtenus, discuté sur le support régional, les implémentations du produit dans l’appareil gouvernemental et nous avons formulé notre recommandation finale.

Avec l’analyse qui est faite en respectant le processus que je viens de vous présenter, l’argumentaire est assez éloquent pour ne pas avoir à débattre en long pour cette étape.

6 Comments

  1. Félicitations, du vrai beau travail de pro!

    And the winner is…

    ???

    (oups! pardon, j’imagine que là, j’entre dans de la régie interne… mais après tout, je me sens un peu concerné, non?!)

    😉

Comments are closed.