Voilà, mon nouveau billet vient juste de paraître chez 01Net. Il s'intitule Les leçons de l'open source en matière de qualité.

Le billet en question a une histoire un peu particulière. En effet, je l'ai soumis ce matin, mais la rédaction de 01Net semblait peu enthousiasmée par sa publication. En effet, Mozilla y jouait le rôle principal, et le risque était significatif qu'on prenne cela pour de la publicité. Je dois dire que ça m'a a peine effleuré au moment de la rédaction, mais j'avais décidé de passer outre. Suite à une discussion avec la rédaction, j'ai décidé de faire une version en retirant tous les liens vers Mozilla sauf un. Cette version est celle qui est publiée sur 01Net. Pourtant, je préfère la version originale, et j'ai donc décidé de la publier ci-dessous.

Processus et qualité : l'Open Source montre l'exemple

J'expliquais dans mon dernier billet comment le logiciel Libre, par sa transparence, offrait de meilleures garanties de qualité, tout simplement parce qu'on pouvait regarder le code plutôt que de se fier au sourire du commercial qui vous vend une boite noire.

Mais il y a aussi la possibilité d'utiliser des méthodes de développement qui mènent à un niveau de qualité supérieur, conjugué à ce qu'apporte la transparence du projet et l'ouverture du code.

Dans le cas des gros projets libres, il y a un problème à résoudre, qui vient du fait que chacun peut suggérer un changement au code pour résoudre un problème, sans nécessairement avoir passé un entretien d’embauche à cet effet. Lors de la soumission d'une rustine logicielle, comment peut-on s'assurer que le code rajouté corrige bien le problème et n'en rajoute pas d'autre ? Les processus et outils mis en place pour répondre à cette question ont permis à certains projets libres d’atteindre de nouveaux niveaux de qualité.

Dans ce billet, je vais partir de l'exemple du projet Mozilla, que je connais bien (forcément), sachant que d'autres projets informatiques (libres ou non) utilisent des méthodes comparables.

Ainsi, dans le cadre du projet Mozilla, chaque "patch" (ou rustine) suit un processus traçable de bout en bout pour permettre un retour en arrière si nécessaire. Ainsi, le code proposé doit tout d'abord correspondre à un rapport de bogue qui décrit le problème à résoudre. Il est relu par un spécialiste du module concerné, puis ensuite relu par un expert (pas nécessairement employé par Mozilla) nommé par ses pairs. Dans le cas où les relectures ne sont pas probantes, le code est retravaillé jusqu'à ce qu'il obtienne l'aval des lecteurs et relecteurs. Il en est de même à chaque étape du processus.

Le code est alors compilé sur plusieurs machines équipées de systèmes d'exploitation différents (Vista, XP, Mac OS X 10.4 et 10.5, et plusieurs versions de GNU/Linux). De façon à s'assurer que la modification n'introduit pas de régression et ne provoque pas de problème complémentaire, la version du logiciel intégrant la modification passe une batterie de plusieurs milliers de tests unitaires. C'est ensuite le tour des tests de performance (consommation CPU et occupation mémoire), dont on peut comparer les variations au fil du temps via un serveur de graphes.

Si les tests sont positifs, alors le logiciel résultant est proposé au téléchargement aux gens de la communauté qui travaillent à l’Assurance Qualité. Plusieurs milliers de personnes dans la communauté vont le télécharger puis exécuter cette nouvelle version, soit en utilisation normale, soit pour suivre une procédure manuelle de test, et donner ainsi du feedback sur le système de gestion des rapports de bogues.

Grace à ce processus et à la traçabilité qu’il permet, on dispose au final d’un produit d’une qualité à la fois prévisible et de haut niveau, ainsi qu’une masse de documentation sur l’évolution du logiciel. Ce dernier aspect est important car on le sait, « ceux qui ignore les leçons de l’histoire sont condamnés à en répéter à les erreurs », y compris en entreprise !

Et toi, cher lecteur, que penses-tu de ces deux versions (si tu n'a pas eu la flemme de te farcir les deux ;-) ) ? Le gros intérêt de celle qui est ci-dessus, à mon sens, c'est qu'elle est nettement plus concrète que celle publiée chez 01Net pour deux raisons :

  1. Elle s'appuie sur un exemple concret d'un produit qui existe, Firefox (et les autres logiciels du projet Mozilla). Je n'y décris pas une vue de l'esprit mais un processus qui fait ses preuves au quotidien
  2. Elle dispose de liens qui permettent à chacun de voir de quoi je parle. Tinderbox, le serveur de graphes ainsi que Litmus existent et sont sous licence Libre.

Ainsi, d'une part, le lecteur voit le fonctionnement des différents composants (et les exemples sont souvent plus parlants que les théories) et d'autre part il peut réutiliser les logiciels dont je parle dans son projet. Voilà pourquoi je préfère la version ci-dessus à celle, édulcorée, que j'ai refaite pour 01Net.

Et si vous aviez lu mon billet initial chez 01Net, vous auriez trouvé qu'il avait un coté publicitaire ?