[cllfst] Logiciels libres et qualité : quelques mythes et réalités

["Baroudi Malek" <baroudi.malek@xxxxxxxxx>]

Il est une croyance communément répandue que les logiciels libres sont de meilleure qualité que leurs homologues propriétaires. Nous avons déjà eu l'occasion de nous exprimer sur la question, en soulignant notamment les différences flagrantes d'un logiciel à un autre. Il est un élément souvent oublié : l'utilisation d'outils de vérification automatique du code source.

 

Qu'est-ce que la qualité logicielle ?

A dire vrai, la notion de qualité porte elle-même à confusion. Qu'entend-t-on par qualité ? Une meilleure adéquation aux besoins de l'utilisateur final ? Un nombre plus faible de bogues ? Une plus grande facilité de maintenance ? Un nombre de failles de sécurité plus faible ? Une meilleur réactivité aux vulnérabilités et aux défauts détectés ? A dire vrai, dans la culture informatique au sens large, la qualité logicielle, c'est un peu tout cela... Le logiciel libre peut être tantôt avantagé, tantôt défavorisé. Ainsi, un logiciel de visualisation d'images développé par des techniciens chevronnés ne conviendra pas forcément aux besoins d'une secrétaire travaillant dans une imprimerie. A l'inverse, un serveur Internet développé par des spécialistes de la gestion d'infrastructure Internet conviendra très bien à la population qui l'aura enfantée.

Nous ne reviendrons pas sur la sécurité, objet de longues discussions entre, notamment, les éditeurs Linux et Microsoft, chaque partie vantant les mérites de son produit respectif. Reconnaissons simplement que les études neutres et complètes font encore défaut pour se faire une idée objective et trancher la question.

La question des erreurs de programmation

Venons en plutôt à la question des erreurs de programmation. La croyance veut que le logiciel libre soit favorisé du fait de la révision du code source par les pairs : ''Étant donnés suffisamment d'observateurs, tous les bogues sautent aux yeux''. Cette loi (dites ''loi de Linus'') est vrai tant que le nombre d'utilisateurs qui contribuent est élevé. Ce n'est pas toujours le cas. Par exemple, un logiciel libre développé par un seul mainteneur ou en petit groupe ne bénéficiera souvent pas de cette activité de révision. Les créateurs de logiciels libres le savent d'ailleurs bien : il ne suffit pas de mettre un logiciel sur Internet pour que les contributions affluent. Autre exemple : si le gestionnaire de projet est fermé à toute forme de réelle coopération, l'activité de contribution sera fortement contrariée.

Admettons maintenant que ces conditions (ouverture du leader à la coopération, vaste communauté d'utilisateurs, etc) soient vérifiées et que les contributions affluent. Cela suffirait-il à faire d'un logiciel libre un logiciel moins bogué ? Oui et non. En effet, si l'on prend un projet comme celui du noyau Linux, on constate que plusieurs techniques sont utilisées pour éliminer les erreurs. D'une part, le nombre de contributeurs est élevé (une centaine aux dires de Microsoft, plus de mille selon d'autres). D'autre part, des outils automatiques sont utilisés. En l'occurrence, les développeurs du noyau Linux disposent d'une application d'analyse de code : SPARSE.

Des outils libres pour le déverminage

Une large palette d'outils libres pour le déverminage de logiciels est par ailleurs disponible. Le plus connu est probablement Bugzilla, une application de suivi de bogues. En matière de sécurité, Flawfinder et RATS sont deux outils d'analyse statique -famille de techniques permettant de dériver des résultats sur l'exécutions de programmes sans les exécuter- permettant la détection d'erreurs de programmation pouvant être la cause de vulnérabilités. Les outils de tests unitaires -les tests unitaires permettent de tester un seul module logiciel, indépendamment du reste du programme, afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances- sont nombreux : CppUnit (C++), JUnit (Java), DUnit (Delphi), DejaGNU,... La couverture de code (vérification que le test passe dans la totalité -ou une fraction de la totalité- des branchements possibles) peut l'être avec Gcov (fourni avec GCC). Gprof est un outil de profiling (le profiling permet de connaître où votre programme passe le plus de temps et quelles fonctions sont appelées durant l'exécution). Les fuites mémoires peuvent être détectées avec Valgrind.

Certes, mis dans les mains d'un mauvais développeur, ces outils ne feront pas de miracles. Ils aident par contre à la détection des défauts de programmation. Un outil d'analyse statique comme Flawfinder ou RATS facilitera ainsi la détection de vulnérabilités classiques telles que les dépassements de tampon (typiquement, en C) ou la faille include / require (sites écrits en PHP). Pour exemple, le ver PhpInclude.Worm s'attaquaient aux sites dont les webmestres n'avaient pas sécurisé le mécanisme d'inclusion de fichiers. PhpInclude.Worm et Santy (qui s'attaquait aux forums PHPbb en exploitant une faille de type dépassement de tampon) partagent une caractéristique commune : la recherche de victimes était automatisée. Elle était en effet réalisée en recourant aux moteurs de recherche de type Google. Dans ce dernier, la commande inurl permet de procéder à des recherches de sites dont l'URL des pages respecte une forme particulière. Il est dès lors facile de détecter un site PhpBB (par le 'viewtopic'), un site tournant sous NPDS (par le 'op=newtopic') ou un simple site PHP (par l'extension '.php' de ses pages). Peut-être est-il temps d'automatiser la recherche d'erreurs, dès lors que les pirates utilisent l'automatisation pour trouver des victimes !?

La force des grandes communautés libres

Pour autant, les tests unitaires ou l'analyse statique ne sont pas la panacée. En effet, ils ne remplacent pas les tests permis par une réelle mise en situation du logiciel. En la matière, les grandes communautés de logiciels libres disposent d'un avantage certain.

Prenons le projet Apache. Cette communauté dispose d'une très large base d'utilisateurs (près de 70% des sites Internet tournent sur Apache), favorisant la remontée d'informations. De plus, les contributeurs sont structurés en fonction de leurs mérites respectifs. La Fondation Apache s'est en outre intéressée aux outils d'analyse automatique. On notera ainsi l'existence de projets comme Apache JMeter (tests de performances) ou Maven. Ce dernier est un logiciel de gestion de projets, qui inclut des outils de gestion de la qualité du logiciel pour la génération de métriques sur le code source, les tests unitaires, etc.

Conclusion

Certes, la révision par les pairs est un facteur de succès du logiciel libre et un élément important en vue de la production de logiciels de qualité. Cependant, il s'agit d'un élément parmi d'autres. Les techniques automatiques de tests logiciels sont en effet utilisées dans les projets libres d'envergure et contribuent elles-aussi à améliorer la qualité du code publié. Si certains projets ne recourent pas encore à ces méthodes, ce n'est pas faute d'outils libres, ces derniers étant nombreux et reconnus par les développeurs.

Sources :
[1] LinuxFr : Démarche qualité et Logiciel Libre
[2] OSDL : Kernel Testing at OSDL
[3] LinuxFr : 985 bugs dans le noyau Linux

-- 
"Qui allume sa bougie à la mienne reçoit de la lumière sans me plonger dans l'obscurité…"
                                                 ' Thomas Jefferson'