par ktylerconk
Le logiciel propriétaire est le seul modèle économique où le client n’est pas en plein contrôle de ce qu’il paie. Pour tous les autres produits tangibles, le client peut en faire ce qu’il veut après avoir déboursé pour l’obtenir. Il a acquis le produit.
L’exemple de la maison
Par exemple, lorsqu’on s’achète une maison, il est possible de la modifier soi-même ou de confier les travaux à n’importe quel entrepreneur. On nous fournit même le plan! On pourrait dès la prise de possession, en faire une copie sur le terrain adjacent.
L’exemple de l’automobile
L’automobile est un produit plus technologique et il est produit en série. Son exemple, se rapproche davantage au logiciel propriétaire. Toutefois, le fabricant vend des manuels techniques d’entretien avec des schémas complets de toutes les pièces de l’automobile. Vous pouvez faire l’entretien de la voiture dans un autre garage et même y apporter des modifications sans perdre votre garantie. L’automobile une fois vendue vous appartient.
À qui appartient le logiciel que j’ai acheté?
Lorsque vous achetez un logiciel, vous n’achetez qu’une licence d’utilisation. Le logiciel ne vous appartient pas. Le média sur DVD ou sur CD ne vaut pratiquement rien. Par exemple, Microsoft vend le média seul sans licence à 39,99$ CDN pour la quasi-totalité de ses produits. La licence vous permet d’utiliser le logiciel à perpétuité. Toutefois, rien n’empêche le fabricant de cesser de supporter le logiciel. Comment prévenir ça?
J’ai déjà vu chez un ancien employeur que le client avait exigé que le code source soit transféré dans une fiducie advenant un événement qui empêcherait le support de l’application (faillite, erreur humaine, sinistre, etc.). Le client serait alors en mesure de continuer à maintenir le logiciel sans trop problèmes. Mais, est-ce qu’un client peut exiger ça des grands fabricants de logiciels?
Le modèle d’open source
Lorsque vous installez un logiciel libre, vous avez accès au code source. Vous n’avez plus de lien avec le fabricant. Vous pouvez modifier le logiciel sans demander la permission à quiconque. Ce sont les mêmes droits que vous avez avec votre maison et votre automobile.
Lorsqu’on défend le logiciel propriétaire, on utilise souvent les arguments de support ou d’imputabilité de fournisseur. Lisez vos contrats de licence et ils vous empêchent la plupart du temps de recourir contre eux en cas de préjudice ou discontinuation du produit. L’open source bizarrement peut s’avérer plus sécuritaire pour le client. Quand le logiciel est implanté chez lui, en ayant le code source, il reste maître d’oeuvre de l’évolution du produit.
J’aimerais avoir d’autres opinions à ce sujet. Quel modèle de distribution de logiciel offre une meilleure pérennité pour le client?
Je suis toujours abasourdi de voir encore qu’en présence d’une alternative propriétaire/libre (parce qu’il doit y avoir des cas où il n’y a que des solutions propriétaires, j’imagine), il y ait encore des gens qui cèdent aux arguments des fournisseurs de logiciels propriétaires.
Si on faisait le décompte des catastrophes entraînées par un tel choix, on serait effaré et on y penserait à deux fois avant de faire confiance à qui que ce soit, peu importe sa réputation. C’est maintenant une question de bon sens.
Très bon billet!
Il y a tout un débat à faire là-dessus. J’aurais aimé que tu fasses la comparaison du logiciel propriétaire avec la copropriété.
Il y a surtout un travail d’éducation à faire au niveau des entreprises concernant l’open-source. J’ai eu à proposer un logiciel de «software push» à mon superviseur. J’ai proposé un logiciel open-source et on m’a répondu que «les solutions open-source ne sont pas toujours les plus fiables»… Ici on voit clairement un préjugé. Comment changer cela?
Les entreprises se questionnent souvent sur le service à la clientèle (le support) et restent encore frileuses sur l’open-source, même si ce sont des applications pour Windows.
Le modèle commercial de l’open-source n’est pas encore bien développé à mon avis.
L’autre question que j’ai… Si les modifications au code du logiciel sont permises, qui supporte le logiciel par après? Le client, entièrement? C’est pourtant si facile de rendre non fonctionnel un logiciel
Les décideurs en TI sont souvent réfractaires au changement. Ils ont peur de se retrouver dans des situations d’apprentissage obligées ou ils perdent le contrôle. C’est la raison principale que je vois. La fiabilité des logiciels libres est aussi relativement reconnue par l’industrie. Parlant de résistance au changement, j’avais écrit un billet là-dessus et j’avais un survol sur l’open source :
http://www.ovologic.com/2009/06/01/le-choc-des-generations-dans-les-technologies-de-linformation/
@Hispong Quand vous mentionnez le modèle commercial en open source, vous touchez un des aspects les plus importants de la problématique. MySQL offre par exemple un service de grande qualité si on paie. Évidemment, même avec la Cadillac du service on n’atteint jamais les coûts d’exploitation d’Oracle ou SQL Server. Le support doit toujours être compris dans les offres de service. Il faut comparer des pommes à des pommes.
Aussi, le branding du produit doit être impeccable. Le site d’Open Office est très beau et son interface graphique aide à son adoption. Par contre, il existe plusieurs solutions mal emballées dans le logiciel libre qui ressemble à des expériences universitaires incomplètes.
Autre aspect qui nuit à l’adoption est le cercle fermé de la communauté open source. Je trouve que le milieu de l’open source se parle trop à lui-même. Ça ressemble parfois à une secte. Une secte de donneurs de leçons. On dirait qu’on doit subir un baptême et renier tous nos acquis pour se lancer là-dedans.
Je préconise une transition intelligente. En 2009, tous les systèmes informatiques sont en mesure de s’intégrer, peu importe la plateforme et le langage. En créant des solutions en architecture de services (SOA), on peut habillement passer à l’open source tout en conservant nos applications propriétaires en place jusqu’à leur fin de vie utile.
Le logiciel libre est un bien non-rival, et le logiciel était considéré comme tel avant la marchandisation à grande échelle de ce produit (on peut marquer d’une pierre blanche le moment où Bill Gates a écrit sa lettre au Homebrew Computer Club en 1976). Cependant, la fermeture du code est contre-productive en ce qui concerne l’efficacité du produit, ce qui est tordu! Dans l’univers informatique, la rareté est artificielle. Ce qui est rare, ce qui devrait avoir le plus de valeur, c’est bien l’expertise des artisans du numérique, et non le produit.
Par exemple, j’utilise le logiciel PMB pour la gestion de la collection d’une bibliothèque publique. Alstorm l’utilise aussi et a rémunéré les artisans pour l’amélioration du logiciel. Ça, c’est de l’efficacité parce que tous peuvent en profiter.
Pour moi, acheter un logiciel propriétaire c’est un peu comme acheter un repas sans savoir ce qu’il contient. Je sais qu’il est préparé pour me nourrir, mais je ne sais rien de sa composition. La seule chose qui est écrit sur l’emballage, c’est que je risque la prison si je tente de reproduire le plat ou si je fais goûter ma blonde ^^.
Très bon article/débat!
Moi je crois que c’est toujours en fonction des besoins du client! L’important est que le client soit en mesure de modifier, faire modifier, le code de son application même si elle a été montée sur mesure pour lui. Même si ce n’est pas un logiciel open-source, il doit être en mesure de pouvoir engager un programmeur qui ne connait pas le projet afin d’y apporter des modifications. C’est là que l’on retrouve des problèmes, comment savoir, lorsqu’on ne connait pas la programmation ou peu, qu’un logiciel va être facile à maintenir? Ça prend des test unitaires, un ORM, une bonne séparation des différentes couches… J’ai vu et travailler sur plusieurs projets qui ont mal virré et dans tous les cas, c’était à cause de délais trop serré et de mauvaise compréhension des besoins du client.
Un autre poinnt intéressant est l’exportation des contenus, comme WordPress par exemple, il nous permet de tout exporter dans des XML le contenus de notre site. Il y a aussi le fait de rendre l’API publique, comme facebook qui nous permet de se connecter à notre profil et d’afficher des publications à partir de d’autres sites.
Mais maintenant il y a tellement de solution Open-source qu’il est difficile de ne pas en trouver une qui correspond aux besoins de notre client.
Bon billet. Les choix technologiques sont tributaires des décisions d’achat, elles-mêmes fortement influencées par les contacts d’affaires. Ne pas oublier que bien des directeurs technologiques (CT0) croient encore aux arguments de robustesse/sécurité des vendeurs. Ne sous-estimez pas les efforts de marketing des vendeurs de technologies propriétaires. Leurs meilleurs vendeurs obtiennent avec une facilité déconcertante des entrevues avec les influenceurs et les décideurs. Et encore, je ne parle pas des organismes gouvernementaux (les appels d’offres sont taillés sur mesure pour un statu quo technologique).
Mon expérience personnelle m’a démontré que peu de ces décideurs consultent d’autres sources d’information que celles qu’ils suivent depuis des années. Les décisions de changement sont alors conjoncturelles: Plus assez de budget ? On va essayer WordPress; Un partenaire insiste pour que la plateforme soit Linux, MySQL, PHP plutôt que Microsoft ? On va externaliser le projet (pas de « ça » ici).
Le logiciel libre est probablement la voie de l’avenir pour bien des trucs (logiciels de masse) mais il restera beaucoup de niches où seuls les logiciels payants seront disponible.
Je ne vois pas le jour où des logiciels industriels ou scientifiques seront offerts via un modèle « logiciel libre »…
Pour les logiciels de « base » en particulier pour la maison, presque tout est déjà disponible en logiciel libre, et ce depuis plusieurs années…
@Denis Les logiciels de niche peuvent être développés sur mesure et le client peut exiger la licence GPL ou de quoi de similaire. Le développeur livre son code source au client.
@Josée J’aimerais vous suggérer de lire un billet de Nelson Dumais. Il a reçu une amende du Conseil de la Presse le 1er mai 2009. Un adepte d’open source avait fait une plainte contre lui à cause qu’il se faisait payer des voyages par les fabricants d’ordinateurs et de logiciels lorsqu’ils couvrent des conférences et événements. Il n’en faisait pas mention dans ses articles.
Il disait qu’il lui était impossible pour lui de défrayer tous ces voyages. Il était donc plus rentable pour lui de couvrir un événement commercial avec toutes dépenses payées plutôt qu’un congrès sur les logiciels libres où le vendeur ne peut lui offrir ça. Les moyens financiers des fabricants de logiciels propriétaires leur offrent une meilleure commercialisation et visibilité.
http://blogues.cyberpresse.ca/technaute/dumais/?p=1004767
Ce débat me paraît infertile depuis des lustres déjà. Tout ce dont les logiciels libres manquent, c’est seulement un peu d’exposure et donc d’un peu de temps. Rien à craindre de ce côté : leur adoption se répand, tranquillement mais sûrement.
Ceci dit, les décideurs TI ne sont ni des débiles illettrés ni des inconditionnels réfractaires au changement : nous jouons tous à un jeu dangereux dont les variables sont souvent toutes autres que les seules variables des coûts, réels et financiers, et de la satisfaction des besoins, réels, de production. Nous affrontons plus souvent qu’autrement une opposition politique ancrée dans la culture organisationnelle : 5 ans de « mes voisins d’autres grandes institutions n’ont pas ces problèmes avec du Microsoft (ou autre) » peuvent facilement faire tripler les coûts réels de production seulement en changement de fournisseurs, consultants de services open source et roulement de personnel, de l’usager jusqu’à la direction.
La maladie du logiciel libre en entreprise, c’est 50% celle de la confiance : le moindre bogue réveille le doute et la comparaison, « nous n’aurions pas eu ces troubles avec le logiciel sous licence XXXX 100% proof out of the box », et 50% le mirage de la personnalisation : « c’est du libre, engageons le punk du coin et faisons le lui programmer pour qu’il fasse notre café le matin ».
Le bon décideur TI connaît ces écueils et sait prendre le pouls de son organisation. Il s’engage dans une vision à long terme et fait des choix stratégiques de logiciels sous licences, parfois, et libres, d’autres fois, considérant l’état d’esprit de la culture générale de son organisation au moment présent, et prévoyant ce qu’elle pourrait être dans 3 ans, 5 ans et 10 ans.
Je ne connais pas de décideur TI intelligent qui ne pense pas à l’intangible dans sa gestion d’acquisition, des variables que comprennent bien les décideurs non initiés au TI (les présidents habituellement, décideurs ultime), et encore moins qui prennent des décisions en faveur de devenir un héro visionnaire (sacrifié…) du logiciel libre.
Finalement, je me permets une analogie boîteuse : je ne sais pas ce qu’on retrouve dans une boulette de McDo, et je sais que si je voulais une Cadillac d’hamburger, je choisirais tous mes ingrédients et m’en ferait un maison, mais quand le besoin de « boucher un coin » se fait pressant, c’est un état bien identifié depuis longtemps par McDo qui depuis aussi longtemps présente une bonne solution. Je n’ai pas encore trouvé de bonne copie, et il m’arrive encore « d’acheter la licence » de temps en temps. Je ne suis pas enchaîné au fast food pour autant.
J’aime lire tes Billets Nicolas. Car, il applique le principe suivant !
Si on veut faire changer une idée, il faut la crier a tout vent ! Ou presque !
Le monde des TI est encarcanné dans de vieux concepts. J’ai hate, j’en rêve ! Qu’il change, qu’il évolue intelligemment.
J’ai bien aimé ta comparaison entre le logiciel et la maison. Je serais curieux de voir la réaction d’un futur propriétaire d’une maison si lui mettrait les contraintes de license que nos chers produits logiciels « In-Box » sont régie !
Je suis sur que le marché de l’immobilier tomberait d’un seul coup !
C’est peut-être ce qu’ont peur les vieux montres de l’industrie ..! Que le marché s’effondre au lieu d’évoluer différemment !
Je partage la majorité des points de vue ici. J’ai eu des dizaines d’expériences avec les deux types de logiciels, mais je dois dire qu’il serait hâtif d’affirmer qu’un modèle est clairement meilleur qu’un autre. Les deux ont des lacunes à travailler.
Pas pire le modèle de la Fiducie pour diminuer les désavantages du logiciel propriétaire, mais faut-il vraiment attendre un cataclysme pour accéder à sa propriété ? Le modèle propriétaire pourrait lâcher prise un peu et ouvrir les cas où c’est disponible.
Cela me fait rigoler aussi lorsque j’entends des choses comme « les solutions open-source ne sont pas toujours les plus fiables », la seule différence avec les failles de logiciels propriétaires c’est que 90% elles ne sont pas publiques (à part pour les gros systèmes comme Windows), mais pas moins fréquentes !
Le libre a le défaut de sa qualité : il y a tellement de firmes qui disent pouvoir travailler avec un logiciel libre que ça devient impossible de choisir la bonne, celle qui le maîtrise vraiment. J’ai vu beaucoup de cas où finalement je suis sûr que les programmeurs avaient regardé la « feature lists » et se sont dit « facile! ». Ça donne des projets qui triplent de budget et d’échéancier. La qualité logiciel du propriétaire est inverse : plus rapide, plus en contrôle, moins de dépassments. Mais aussi moins de flexibilité, de liberté et souvent plus de dollars à court terme en tout cas.
Réponse de consultant : c’est du cas par cas. On doit confronter : besoins, budget, échéanciers, risques, durée de vie du projet, intégration à d’autres processus et systèmes avant de prendre une décision. Et selon moi on doit travailler avec des coefficients de risque et de pertinence pour chaque projet pour trouver la voie à suivre.