Comme le montrent régulièrement Bertrand Lemaire ou Louis Naugès, les décideurs choisissent trop souvent leurs logiciels en fonction de deux critères principaux : couverture fonctionnelle et notoriété de l'éditeur. (Voir par exemple les billets Diatribe à la Paresse ou To Vista or not to Vista, that is the question !.) Ce deuxième critère disparaissant, dans le cas des logiciels libres, on comprend mieux pourquoi, leur adoption est si lente en entreprise. Pourtant toute solution logicielle devrait être évaluée selon une grille de critères indépendants de sa caractéristique libre ou propriétaire. Voici quelques pistes.

Bien qu'il soit assez facile d'établir une liste de critères subjectifs (simple, ergonomique, etc), ceux-ci ne permettent généralement pas d'évaluer objectivement (autant que possible) les solutions disponibles. Pourtant, seule une évaluation objective s'appuyant sur des paramètres mesurables peut minimiser notre subjectivité. Pour dresser une telle liste de paramètres, nous partons des critères subjectifs que nous traduirons ensuite en une métrique. Par exemple, la liste suivante :

• Simplicité d'apprentissage et de mise en oeuvre
• Simplicité d'adaption à ses besoins : simple à étendre sans modification.
• Fonctionnalités requises et souhaitées pour le projet
• Interopérabilité
• Stabilité
• Pérennité
• Qualité du support
• Licence adaptée au projet

La satisfaction de ces critères peut être évaluée en mesurant des grandeurs plus objectives :
Sur le plan technique :

• Simplicité de la conception : nombre de classes, de fichier, de lignes de code, etc.
• Degré de modularité : nombre de modules (ou plugins), indépendance entre eux.
• Utilisation de normes : Design Patterns, charte de codage, etc.
• Respect des standards et des formats ouverts : formats d'entrée/sortie, protocoles de communications, etc.
• Légèreté de la solution : emprunte mémoire, rapidité d'exécution.
• Fiabilité et stabilité : nombre d'erreurs en stress test, nombre de bugs présents/corrigés sur le tracker.
• Importance de la documentation : API (via un générateur de documentation), manuels, guide, tutoriel.

Sur le plan humain :

• Taille de la communauté : développeurs, utilisateurs, organismes et sociétés de soutien.
• Efficacité du support : forum, mailing list, etc.
• Ancienneté de la solution, maturité.
• Visibilité : nombre de citation google par exemple.
• Références : acteurs et projets utilisant la solution.

Toute étude menée pour choisir une solution devrait dresser la liste des critères subjectifs puis objectifs guidant le choix. L'étude doit ensuite concevoir la métrique à partir de ces critères plutôt que de se servir d'une grille standard qui sert à tous les projets. Et malgré cela, des facteurs subjectifs non mesurables auront toujours un grand rôle dans le choix...