Qualité des logiciels : propriétaire contre open source

closeCet article a été publié il y a 15 ans 2 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Je réagis suite à un article de Tristan Nitot, fondateur et président de l’association Mozilla Europe, paru sur 01net. Son article est relatif à l’évaluation de la qualité des logiciels.

Trois façons d’évaluer un logiciel :

  1. L’essayer,
  2. Voir comment il est conçu et écrit,
  3. Tester la réactivité de l’éditeur lors de la soumission d’un problème.

Sur ces trois points, les logiciels open source disposent d’arguments face aux logiciels propriétaires.

© senicphoto - Fotolia.comLe 1/ se vérifie très simplement avec le logiciel open source. Pas de coûts de licence, donc le logiciel est disponible simplement sur le site de l’éditeur ou du projet.

Le 2/ fait parti des critères exigibles pour un logiciel open source. Autrement dit un logiciel open source est facilement auditable. Auditer un logiciel propriétaire n’est que rarement envisageable surtout si l’acheteur est plus petit que l’éditeur. « L’auditabilité » d’un logiciel propriétaire est d’ailleurs inversement proportionnel avec sa diffusion. Je n’ai pas trouvé d’exemple d’audit réalisé sur les méthodes de développement de Microsoft.

Le point 3/ est également facilement vérifiable avec les logiciels open source. En effet, la mise à disposition d’un logiciel de déclaration et de suivi des anomalies et ouvert à tous est habituelle. Tout est listé et transparent.

Posons-nous également la question suivante : la décision de lancer le développement d’un logiciel open source n’oblige-t-il à se poser d’emblée le problème de la qualité du code ?

« Tristan Nitot : Bien sûr, évaluer la qualité d’un logiciel en lisant des listes de bogues est moins rassurant que la lecture d’une plaquette en papier glacé.”Pour aller plus loin sur le sujet vous pouvez également de lire un autre article de Tristan Nitot sur le processus qualité chez Mozilla ou comment sont gérés et intégrés les patch proposés par la communauté.

Dans les faits maintenant ?

Tristan Nitot nous décrit l’organisation d’un gros, voir très gros projet open source. Tous les projets en ont-ils les moyens ? N’y a-t-il pas aussi dans le monde de l’open source des logiciels mal écrits, mal conçus ?

J’oserais répondre oui. Il m’est déjà arrivé de télécharger des scripts PHP ou des programmes que je me suis empressé  de désinstaller tant ils étaient mauvais et pourtant open source.

Je me garderais donc bien de généraliser ou d’affirmer de façon trop péremptoire que l’open source est LA solution pour garantir des logiciels de qualité, mais je pense en tout cas que eu égard aux point 1/, 2/, et 3/  cela peut aider.

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

15 réponses

  1. Tristan dit :

    Philippe, nous sommes tout à fait d’accord. La transparence du Libre permet d’évaluer la qualité (à condition qu’on prenne le temps de le faire), elle ne signifie pas que le logiciel est de qualité. Mais c’est toujours mieux que de se faire refiler une boite noire par un commercial qui, la main sur le coeur, vous affirme qu’à l’intérieur tout est très bien rangé.

  2. LordPhoenix dit :

    Comme pour beaucoup d’autres choses c’est nécessaires mais pas suffisant.

  3. kim dit :

    je rejoins le point de vue de lordphoenix :

    1/ pas nécessairement, un soft peut être open source, mais non disponible à tous.
    2/ globalement vrai, cela dit cela n’enlève pas le fait qu’il faille de l’expertise dans certains cas (je te laisse auditer le code de OpenOffice.org 🙂 )

    3/ non suffisant. On peut prendre l’exemple de bugs dans OOo, ou autres logiciels open source, qui sont ouverts dans les bugzilla & consors, depuis des mois, voire des années. Le dernier sur lequel je suis tombé a trainé plus de 8 mois avant une simple prise en compte (le patch était proposé, mais non vu). A contrario, des éditeurs de closed source sont hyper réactifs.

  4. Philippe dit :

    @Tous: merci pour vous commentaires 🙂
    @Tristan : Il me semble aussi que nous sommes d’accord ! L’open source n’est pas une démarche qualité, c’est une façon de développer des logiciels et de les diffuser avec tout l’argumentaire marketing et commercial que cela peut impliquer et les avantages que l’utilisateur peut en retirer.
    @kim : Je ne comprend pas ton 1/. Comment un soft peut-être open source mais non disponible à tous ? Sinon Ok avec toi sur 2/. Le 3/ est bien suffisant. Si on reprend ton exemple, tu as pu constater qu’un projet ne traitait pas les patch proposés. Tu peux ainsi passer ton chemin. Choisir l’open source c’est accepter un niveau de transparence élevé et donc assumer le fait de devoir être irréprochable. Pas facile forcément…

  5. kim dit :

    1/ ce n’est pas parce que tu fais un soft open source qu’il doit nécessairement être distribué. Par exemple, un développement réalisé en prestation pourrait être mis sous GPL, le client choisit s’il veut le distribuer ou non. Tu peux le faire aussi d’ailleurs, mais rien ne t’oblige à donner à tous ton code à la base.

    3/ Non, ce n’est pas suffisant. tu donnes de la transparence, mais elle n’est pas un gage de qualité, juste d’honnêteté.

  6. Philippe dit :

    @kim : Ok pour le 1/, je ne l’avais pas vu sous cet angle.

    Pour le 3/ on dit la même chose je crois 🙂 , en ayant la possibilité de visualiser ce que les utilisateurs signalent et la nature et la récurrence des problèmes, on peut jauger un peu (mais pas complètement on est d’accord) de la capacité à l’équipe de développement à réaliser des corrections et des évolutions sans générer des régressions systématiques. Ce qui pourrait être un indicateur de problème dans l’organisation du développement et donc du processus qualité censé l’accompagner.
    Je parle d’évaluation de la qualité (au sens recherche d’indication) pas de preuves (gages) qui nécessiterait un véritable audit « qualité » du fournisseur.

  7. Bonjour,

    Lors d’une rencontre à l’AFNOR dans le cadre de la norme NF Logiciel, il est apparu que l’open source répondait à la plupart des exigences liées à l’édittion et à la certification qualité.

    Deux points restent néanmoins à réfléchir quand on parle de qualité:
    1) La responsabilité

    Qui est responsable de la qualité du logiciel, qui contrôle ?
    Dans le cadre de Mozilla, c’est évident, il y a une fondation qui est le maître d’œuvre.
    Par contre lorsqu’il s’agit d’un logiciel plus communautaire, la responsabilité est diffuse voir inexistante (comme dans la licence GPL où cela est explicitement mentionné).

    C’est ici qu’intervient le risque que tu soulève Philippe dans ton post, celui du mauvais logiciel voir pire le logiciel malin.

    Cela ne paraît rien mais dans le cas des ERP, des logiciels de gestion ou de toute autre solutions à « risques » (administratifs, juridiques, financiers…). La responsabilité est importante pour savoir d’où vient l’erreur ou la fraude (remarque faite par un représentant du responsable logiciel de gestion des impôts).

    C’est un véritable frein à l’intégration de l’open source au sein des entreprises….

    2) La temporalité

    On peut certifier une version d’un logiciel mais pour que le logiciel puisse évoluer dans le temps, il faut analyser 2 angles:
    – Le carnet de route qui engage l’éditeur dans une démarche qualité sur le moyen terme et qui est difficile à mettre en oeuvre dans les communautés,
    – La pérennité qui correspond à la lisibilité du logiciel sur le moyen/ long terme, son évolution, son financement..

    Tout cela génère des incertitudes perçues par les clients d’où une démarche de certaine structure dans une assurance open source ou alors une garantie sur les logiciels.

    L’open source va donc dans le sens d’une démarche qualité, d’une transparence la question à se poser et donc de savoir qui vérifie et qui peut garantir la vérification ?

    Pour comprendre que c’est un enjeu stratégique important de l’open source, je vous met un lien vers un post très M$ qui appuie sur cette faiblesse.

    Merci pour ton blog Phillipe,
    Jonathan

  8. J’ai oublié le lien

    A bientôt,
    jonathan

  9. Philippe dit :

    @Jonathan : Merci pour ton commentaire comme toujours très complet. Oui qui vérifie et peut garantir, c’est effectivement une bonne question…

  10. lolovroom dit :

    Bonjour,

    @Jonathan, Pour ce qui est de la responsabilité, et nottament pour les logiciels du type que tu cite en exemple, est ce que ce ne serait pas la société qui réalise la mise en production qui serait responsable de la qualité globale de la solution ? Car si un integrateur choisi de proposer des solutions open source, il le fait en connaisance de cause et après avoir vérifier certains critères de qualité. (Ici c’est plus une question qu’une affirmation car les connaissances juridique contractuelles sont limitées).

    En fait dans tout ça, c’est déjà un premier pas de savoir que l’on peut auditer logiciel open source, mais la vraie problematique est de savoir si on va se donner les moyens ou non de le faire avant de le revendre. Quand je vois que dans certaines boites, la securisation des applis se fait souvent contraints et forcés par les audits (des fois juste au moment de la validation) clients, j’ai peur…

    Laurent

  11. @Laurent: tu as raison, c’est sans doute à le ou les intégrateurs de travailler sur l’audit qualité car ce sont les seuls à être directement engagé par leurs prestations auprès de leurs clients.

    Comme tu le souligne, et Philippe aussi, l’open source permet d’aller beaucoup plus loin dans cette démarche que n’importe quel logiciel propriétaire !!!!!

    A bientôt,
    Jonathan

  12. Benjamin dit :

    Bonjour,
    lorsque l’on parle de qualité, on parle bien souvent de pérennité, et les logiciels Open Source sont montrés du doigt sur ce point:
    – Quid du modèle économique de l’éditeur et donc de sa longévité ? (lorsqu’il en existe un)

    Je souhaite cependant apporter un contre-argument sur cette idée reçue, particulièrement adaptée au monde des logiciels de gestion.
    Nombre de mes clients me racontent régulièrement la même Histoire: Sage (un géant mondial) a racheté l’un de ses concurrents, il torpille son produit et fin de l’histoire.
    Les utilisateurs de ce logiciel n’ont alors que peu de solution:
    1. Suivre sur le logiciel Sage;
    2. Rester sur un logiciel qui va devenir peu à peu périmé
    3. Aller à la concurrence.
    Et c’est quand on constate que ceci n’est pas un cas isolé que l’on peu affirmer que la licence Open Source EST une garantie de pérennité pour le logiciel de gestion d’entreprise…

  13. Philippe dit :

    @Benjamin : Merci pour ce témoignage d’un éditeur open source, on sent le vécu 😉

    Ayant travailler longtemps pour un éditeur/intégrateur d’une solution « propriétaire », la question de la pérennité de la solution était souvent réglée par la réponse « commerciale » : « pas de soucis, nos sources sont déposés, si nous disparaissons vous pourrez y avoir accès ». Cela suffisait en général à calmer les inquiétudes du prospect.

    Si je me place du point de vue du client, ce qui est mon cas aujourd’hui, c’est une phrase qui n’a rien de rassurante d’autant que rien à ce sujet n’est souvent précisé dans le contrat de licence.

    Les licences open source sont clairs sur ce point là !

  14. Fred dit :

    Bonjour Philippe,

    Je reviens quand même sur un point qui n’a été repris que dans un commentaire mais pas modifié dans ton article.
    La définition du logiciel libre n’oblige pas à une diffusion gratuite des logiciels, et donc du code source.
    C’est capital comme information, puisque ton point n°2 comme celui de Tristan sous-entend encore que open source = téléchargeable gratuitement.
    Je peux faire un logiciel libre qui sera téléchargeable après paiement.
    Voir http://www.gnu.org/licenses/gpl-faq.fr.html#DoesTheGPLAllowDownloadFee

    Maintenant, si on oublie les open source qu’on ne peut auditer sans avoir payer quelque chose, je reste d’accord avec l’ordre des points 1 et 2, tester puis analyser le code source, mais je comprend assez mal la position du point 3 ici autant de ta part que de celle de Tristan.

    Quand je dois choisir une solution open source adaptée à un projet, je passe par les étapes 1 et 2, mais je vais en 3 voir la popularité de la solution, la richesse de sa communauté (en 4), la fréquence de mise à jour de l’application (en 5), et sa capacité à traiter les problèmes rencontrés et signalés (ton point 3 seulement en 6).
    Je ne pense donc pas que 3 points soient suffisants pour déterminer la qualité d’un logiciel.

  15. Philippe dit :

    @ Fred : Nous sommes d’accord. J’ai écrit que les 3 points cités « pouvaient aider » mais comme le montre bien tous ces échanges ils ne sont pas suffisant.

    Concernant le fait qu’un logiciel sous GPL ne puisse être disponible en téléchargement qu’après paiement est exacte, mais je ne connais pas trop d’éditeur open source qui ait mis en oeuvre ce système. Comme indiqué plus loin dans la FAQ:
    http://www.gnu.org/licenses/gpl-faq.fr.html#DoesTheGPLRequireAvailabilityToPublic
    une fois téléchargé, le même programme peut-être mis en téléchargement gratuit. Si tu as des exemples d’éditeur open source pratiquant ce système ça m’intéresse.