Méthode de Qualification et Sélection de logiciels Open Source (QSOS). Le processus général de QSOS se décompose en plusieurs étapes interdépendantes.

Étape 1 : Définir

Objectif

L’objectif de cette étape est de définir différents éléments de typologie réutilisés par les trois étapes suivantes du processus général.

Les différents référentiels typologiques concernés sont les suivants :

• types de logiciels : classification hiérarchique de types de logiciels et description des couvertures fonctionnelles associées à chaque type sous forme de templates ;

• types de licences : classification des types de licences libres et Open Source utilisées ;

• types de communautés : classification des types d’organisations communautaires existant autour d’un logiciel Open Source pour en assurer le cycle de vie.

Référentiel des types de logiciels

Il s’agit du référentiel qui évolue le plus car, au fur et à mesure que les logiciels évoluent, ils offrent de nouvelles fonctionnalités qu’il est nécessaire d’y ajouter.

Les templates constituant ce référentiel sont composés de critères organisés de manière hiérarchique. Ils sont regroupés selon plusieurs axes d’analyse :

• analyse de la maturité du projet en charge du développement du logiciel ;

• analyse de la couverture fonctionnelle du logiciel.

La méthode QSOS définit et impose les critères d’évaluation de la maturité d’un projet.

Ces critères doivent obligatoirement être utilisés dans toute évaluation QSOS. Ils sont détaillés en annexe du présent document.

Les autres critères d’évaluation sont spécifiques au domaine fonctionnel auquel appartiennent les logiciels évalués.

Consultez le site Web http://www.qsos.org pour le détail des templates disponibles ainsi que pour être guidé dans la construction de nouveaux templates d’évaluation.

Référentiel des types de Licences

Il existe de nombreuses licences libres et open source, ce référentiel a pour objectif de les identifier et de les catégoriser selon les axes suivants :

• propriétarisation : le code dérivé peut-il être rendu propriétaire ou doit-il rester libre ?

• persistance : l’utilisation du code du logiciel à partir d’un autre module se traduit-il ou non par la nécessité que ce module soit placé sous la même licence ?

• héritage : le code dérivé hérite-il obligatoirement de la licence où est-il possible d’y appliquer des restrictions supplémentaires ?

Le tableau suivant liste les licences les plus souvent utilisées en les comparant par rapport aux critères énoncés plus haut.

Licence	Propriétarisation	Persistance	Héritage
GNU Public License	Non	Oui	Oui
CeCILL	Non	Oui	Oui
LGPL	Non	Partielle	Oui
BSD et dérivées	Oui	Non	Non
Artistic	Oui	Non	Non
MIT	Oui	Non	Non
Apache Software License	Oui	Non	Non
Mozilla Public License	Non	Non	Oui
Common Public License	Non	Non	Non
Academic Free License	Oui	Non	Non
PHP License	Oui	Non	Non
Open Software License	Non	Non	Non
Zope Public License	Oui	Non	Non
Python SF License	Oui	Non	Non

Vous pouvez vous reporter au projet SLIC² (Software LIcense Comparator) pour une description plus complète et plus formelle des licences libres et open source ainsi que de leur compatibilités respectives.

Il convient de noter qu’un même logiciel peut être assujetti à plusieurs licences différentes (y compris propriétaires).

Référentiel des types de communautés

Les types de communautés identifiés à ce jour sont :

• développeur isolé : le logiciel est développé et géré par une seule personne ;

• groupe de développeurs : plusieurs personnes travaillant ensemble de manière informelle ou pas fortement industrialisée ;

• organisation de développeurs : il s’agit d’un groupe de développeurs utilisant un mode de gestion du cycle de vie du logiciel formalisé et respecté, généralement basé sur l’attribution de rôles (développeur, validateur, responsable de livraison…) et la méritocratie ;

• entité légale : une entité légale, en général à but non lucratif, chapeaute la communauté pour généralement prendre en charge la détention des droits d’auteur ou gérer le sponsorat et les subventions associées ;

• entité commerciale : une entité commerciale emploie les développeurs principaux du projet et se rémunère sur la vente de services ou de versions commerciales du logiciel.

Étape 2 : Évaluer

Objectif

L’objectif de cette étape est de procéder à l’évaluation des logiciels Open Source. Elle consiste à récupérer des informations depuis la communauté Open Source, de manière à noter le logiciel selon des critères définis lors de l’étape précédente. Cette grille d’analyse ou template est donc un arbre de critères.

Ce travail d’évaluation est insérable dans une démarche plus large de veille technologique qui n’est pas décrite ici dans sa globalité.

Évaluation d’une version de logiciel

Chaque version d’un logiciel est décrite dans une fiche d’évaluation. Cette fiche comporte, outre l’identification du logiciel et de sa version, des informations une description et une analyse détaillées des fonctionnalités offertes.

Templates d’évaluation

Les évaluations QSOS sont réalisées à partir de templates qui décrivent les différents critères d’analyse ainsi que leur structuration. Les critères d’évaluation de la maturité du projet développant un logiciel sont imposés et décrit plus loin. Ils sont complétés par des critères décrivant les fonctionnalités attendues du type de logiciel évalué.

Notation

Les critères sont notés de 0 à 2.

Les templates d’évaluation contiennent les significations des trois notes 0, 1 et 2 des critères à évaluer. Au niveau de la couverture fonctionnelle, la règle de notation est généralement la suivante :

Note	Description
0	Fonctionnalité non couverte.
1	Fonctionnalité partiellement couverte.
2	Fonctionnalité totalement couverte.

Ces notes serviront, lors de l’étape de sélection, à comparer et filtrer les logiciels en fonction des pondérations précisées lors de l’étape de qualification des besoins de l’utilisateur.

Il est possible d’appliquer le processus global de manière itérative. Au niveau de l’évaluation, cela se traduit par la possibilité de noter les critères en plusieurs fois, en calquant le niveau de détail sur celui de l’évaluation réalisée. Cela permet ainsi de ne pas bloquer le déroulement du processus général lorsque l’on ne dispose pas de l’intégralité des notes. Une fois tous les critères évalués, les notes des deux premiers niveaux sont alors recalculées par moyenne pondérée des notes attribuées ou calculées aux niveaux précédents.

Étape 3 : Qualifier

Objectif

L’objectif de cette étape est de définir un ensemble d’éléments traduisant les besoins et les contraintes liés à la démarche de sélection d’un logiciel Open Source. Il s’agit ici de qualifier le contexte dans lequel il est envisagé d’utiliser le logiciel libre, de manière à obtenir un filtre utilisé par la suite dans l’étape « Sélectionner » du processus général.

Filtres

Filtre sur l’identité

Un premier niveau de filtrage peut être posé au niveau des données relatives à l’identité des logiciels. Il peut s’agir, par exemple, de ne considérer que les logiciels d’un type donné du référentiel, ou n’étant distribué que selon les termes d’un licence donnée.

Filtre sur la maturité du projet

Le degré de pertinence de chaque critère de maturité est positionné en fonction du contexte :

• critère non pertinent, à ne pas intégrer au filtre ;

• critère pertinent ;

• critère critique.

Cette pertinence sera traduite par une valeur numérique de pondération à l’étape suivante du processus en fonction du mode de sélection utilisé.

Filtre sur la couverture fonctionnelle

Chaque fonctionnalité décrite dans le template d’évaluation est affectée d’un niveau d’exigence, choisi parmi les suivants :

• fonctionnalité requise ;

• fonctionnalité optionnelle ;

• fonctionnalité non requise.

Ces exigences seront associées à des valeurs de pondération lors de l’étape « Sélectionner », en fonction du mode de sélection retenu.

Étape 4 : Sélectionner

Objectif

L’objectif de cette étape est de sélectionner le ou les logiciels correspondant aux besoins de l’utilisateur, ou plus généralement de comparer des logiciels du même type.

Modes de sélection

Deux modes de sélection sont possibles :

• la sélection stricte ;

• la sélection souple.

Sélection stricte

La sélection stricte se base sur un processus d’élimination directe dès qu’un logiciel ne répond pas aux exigences formulées dans l’étape :

• élimination des logiciels ne correspondant pas au filtre sur la fiche d’identité ;

• élimination des logiciels n’offrant pas les fonctionnalité requises par le filtre sur la couverture fonctionnelle ;

• élimination des logiciels dont les critères de maturité ne satisfont pas aux pertinences définies par ou avec l’utilisateur :

  • la note d’un critère pertinent doit être au moins égale à 1 ;

  • la note d’un critère critique doit être au moins égale à 2.

Cette méthode est très sélective et peut, en fonction du niveau d’exigence de l’utilisateur, ne retourner aucun logiciel éligible.

Les logiciels ayant passé la sélection sont ensuite affectés d’une note globale déterminée par pondération, de la même manière que dans la sélection souple.

Sélection souple

Cette méthode est moins stricte que la précédente car plutôt que d’éliminer les logiciels non éligibles au niveau de la couverture fonctionnelle ou de la maturité, elle se contente de les classer tout en mesurant l’écart constaté par rapport aux filtres définis précédemment.

Elle se base sur des valeurs de pondération dont les règles d’attribution sont détaillées dans les paragraphes suivants.

Pondération fonctionnelle

La valeur de pondération se base sur le niveau d’exigence de chaque fonctionnalité de l’axe de la couverture fonctionnelle.

Niveau d’exigence	Pondération
Fonctionnalité requise	3
Fonctionnalité optionnelle	1
Fonctionnalité non requise	0

Pondération sur la maturité

La valeur de pondération se base sur le degré de pertinence de chaque critère de maturité.

Niveau d’exigence	Pondération
Critère critique	3
Critère pertinent	1
Critère non pertinent	0

Comparaison

Les logiciels d’un même domaine peuvent également être comparés entre eux selon les notes pondérées obtenues lors des étapes précédentes.

Les figures suivantes illustrent ce qu’il est alors possible d’obtenir en synthèse. L’application O3S, présentée plus loin, permet d’exporter les comparaisons dans différent formats (OpenDocument, HTML et SVG).

Le projet QSOS

Un projet libre et communautaire

Outre le fait de proposer un méthode, QSOS constitue un projet libre et communautaire voué à la veille technologique collaborative sur les logiciels open source.

Ainsi, les principaux objectifs du projet sont les suivants :

• gérer les évolutions de la méthode et du format de stockage des fiches d’évaluations ;

• centraliser les référentiels et notamment le stockage des templates, des fiches d’identité et des fiches d’évaluations ;

• fournir des outils pour faciliter l’application de la méthode QSOS ;

• assister les utilisateurs dans l’utilisation de la méthode via des bonnes pratiques et des espaces de communication.

Outils et formats utilisés

Le projet libre QSOS propose également des outils pour dérouler le processus de la méthode et faciliter la collaboration autour des évaluations réalisées, ainsi que des formats de document pour stocker et manipuler les templates et les évaluations.

Le schéma ci-dessous présente et positionne les différents outils et formats existants.