Floss criteria : Grille d'analyse d'un logiciel libre

Pourquoi : c'est la question de base de tout projet open source — êtes-vous réellement libre d'utiliser, modifier et redistribuer le code ? Sans cette liberté, les autres critères perdent une partie de leur sens.

Comment évaluer : vérifiez la licence du code lui-même, mais aussi celle des dépendances nécessaires à son fonctionnement. Un projet peut afficher une licence libre tout en dépendant de composants propriétaires non substituables.

Comment interpréter : une licence libre sur le cœur du logiciel mais des dépendances propriétaires obligatoires (modèle "open core") n'est pas forcément disqualifiant si l'essentiel reste accessible librement — mais c'est un point de vigilance, pas un détail à ignorer.

Pourquoi : un logiciel qui ne couvre pas vos besoins métier, même excellent sur tous les autres plans, ne vous sera pas utile.

Comment évaluer : listez vos besoins prioritaires, vérifiez la couverture fonctionnelle du logiciel, regardez si les fonctionnalités manquantes sont prévues sur la feuille de route ou peuvent être développées par votre administration ou par la communauté.

Comment interpréter : une couverture partielle n'est pas disqualifiante si le manque concerne des besoins secondaires, ou si le projet est ouvert aux contributions — vous pourriez développer cette fonctionnalité vous-même, via un prestataire ou avec d'autres administrations.

Pourquoi : un logiciel difficile à utiliser génère de la résistance au changement, des coûts de formation, et un risque d'abandon par les agents.

Comment évaluer : testez le logiciel vous-même, regardez si une documentation utilisateur existe, vérifiez les retours d'autres utilisateurs. Cette utilisation s'évalue selon diverses catégories comme la compréhensibilité, l'accessibilité, etc...

Comment interpréter : une prise en main difficile peut être compensée par une formation ou un accompagnement mais c'est un coût à anticiper.

Pourquoi : un code de mauvaise qualité complique la maintenance, multiplie les bugs et les failles de sécurité, et rend l'évolution du logiciel plus coûteuse dans le temps.

Comment évaluer : regardez si le code est à la hauteur des standards et normes du milieu, s'il est testé, documenté, et revu avant d'être intégré.

Comment interpréter : un code peu structuré n'est pas toujours un problème pour un usage ponctuel, mais le devient si vous comptez sur le projet à long terme ou si vous prévoyez d'y contribuer.

Pourquoi : un logiciel libre vit grâce aux personnes qui le développent et le maintiennent. Sans communauté active, le projet s'arrête faute de correctifs, de mises à jour de sécurité, ou d'évolutions.

Comment évaluer : regardez qui contribue, depuis combien de temps, à quelle fréquence, et si la communauté répond aux sollicitations.

Comment interpréter : une communauté restreinte mais active et réactive vaut souvent mieux qu'une communauté large mais silencieuse depuis plusieurs mois.

Pourquoi : le choix d'un logiciel peut engager votre administration au-delà de la technique : dépendance à un éditeur ou un pays, alignement avec une stratégie de souveraineté numérique.

Comment évaluer : identifiez qui pilote le projet, où sont hébergées les données par défaut, et si d'autres administrations ont une position connue sur ce logiciel via le SILL ou le forum.

Comment interpréter : ce critère dépend largement de votre contexte propre — un même projet peut être pertinent pour une administration et problématique pour une autre.

Pourquoi : "gratuit à l'achat" ne veut pas dire "gratuit à l'usage". Intégration, maintenance, formation, support : tout cela a un coût, interne ou sous-traité.

Comment évaluer : estimez le coût total — déploiement, maintenance, support, montée de version — et comparez-le aux gains attendus.

Comment interpréter : un coût de maintenance plus élevé peut rester acceptable s'il s'accompagne d'une autonomie ou d'une souveraineté que les alternatives propriétaires ne permettent pas.

Pourquoi : un projet isolé, sans lien avec d'autres outils ou communautés, est plus fragile et plus difficile à faire évoluer qu'un projet inscrit dans un écosystème actif.

Comment évaluer : regardez les intégrations existantes, les autres organisations qui utilisent ou soutiennent le projet, sa présence dans des catalogues reconnus comme le SILL.

Comment interpréter : un écosystème riche est un signal positif de pérennité, mais son absence ne disqualifie pas un projet récent ou de niche.

Est-on réellement libre d'utiliser le code ?

• Le code lui-même est-il sous licence libre ? Le cas des logiciels open core nous semble tolérable si les fonctionnalités libres permettent un usage utile du logiciel et n'obligent pas à payer une licence propriétaire. Le projet sera néanmoins à observer attentivement.
  
• Les dépendances nécessaires à son fonctionnement le sont-elles aussi ?
  Cette question concerne principalement les logiciels et n'est pas facilement applicable pour les groupes de logiciels comme les systèmes d'exploitation.
  
• Est-ce que les dépendances SaaS obligatoires se basent sur des logiciels libres ?
  
• Les données nécessaires à son fonctionnement sont-elles ouvertes ?

Est-ce que la communauté du projet est active et résiliente ?

• Quelle est la date du dernier commit ? Un projet actif en publie quotidiennement ; un projet stable, mensuellement ou trimestriellement. Au-delà, soyez vigilant.
  
• Quelle est la date de la dernière release ? Un projet actif en publie mensuellement ; un projet stable, trimestriellement ou annuellement.
  
• Combien de personnes assurent 50 % des développements ? En dessous de 3, le projet est fragile, sauf s'il est bien documenté, stable, et ouvert à des contributions extérieures régulières.
  
• La communauté est elle joignable ? Par exemple, est-ce qu'elle répond aux sollicitations sur les canaux indiqués comme les issues ou les mails ?
  
• Le projet est-il bien documenté pour favoriser la réutilisation et les contributions ?

Est-ce que le projet est mature et robuste ?

• Depuis quand le projet existe-t-il ? Quelle est la date de sa première release ?
  
• Est-ce que le projet a montré qu'il était utilisable en conditions opérationnelles ? Notamment, il ne s'agit pas d'une preuve de concept, mais bien d'un projet suffisamment mature et utilisé en production.
  
• Le service tient-il la charge pour un nombre d'utilisateurs cohérent avec un usage réplicable ?
  
• La couverture de tests est-elle suffisante au regard des fonctionnalités du projet ?
  
• Est-ce qu'une personne peut vérifier que les tests ont été lancés sur le code d'une release ou les lancer elle-même ?

Est-ce que le projet suit une trajectoire de commun numérique ?

• Quelle est la gouvernance du projet ? Est-ce que la communauté du projet accepte les contributions extérieures, mais plus encore partage les décisions sur l'avenir du projet ? Ou au contraire, est-ce que tout est centralisé, voir opaque ?
  
• Quel est le modèle économique ? Le projet est-il communautaire, financé par un éditeur, soutenu par une fondation ?
  
• Comment ces deux réalités nous parlent de la trajectoire du projet ? La trajectoire idéale est celle du commun numérique. Il ne s'agit pas d'y être pour investir dans le projet mais de vérifier que tous les signaux de la gouvernance et du modèle économique ne sont pas au rouge.

Est-ce que la gestion de la sécurité par la communauté est adaptée aux standards ? Et est-ce qu'une personne peut avoir une autonomie relative afin de réagir en cas de problème ?

• Existe-t-il un processus identifiable pour signaler discrètement une faille à la communauté, par exemple une politique de divulgation responsable (security policy) ?