Page suivante Page précédente Table des matières

3. L'illusion des biens manufacturés

Nous devons pour commencer admettre que les programmes d'ordinateurs, comme tous les outils ou les biens en termes de capitaux, ont deux valeurs économiques distinctes. La valeur d'utilisation, et le prix d'acquisition, ou valeur de vente.

La valeur d'utilisation d'un programme est sa valeur économique en tant qu'outil. Son prix d'acquisition — ou de vente est sa valeur sur le marché (en termes économiques, la première est la valeur en tant que bien final, la deuxième en tant que bien intermédiaire).

La plupart des gens, quand ils tentent de raisonner sur l'économie de la production des logiciels, ont tendance à se placer dans un contexte « d'usine », qui est fondé sur les prémisses suivantes.

  1. Une grosse partie du temps des développeurs est payée par le prix de vente.
  2. Le prix de vente d'un logiciel est proportionnel à son coût de développement (c'est-à-dire le prix des ressources nécessaires pour le dupliquer) et à sa valeur d'utilisation.

En d'autres mots, les gens ont une forte tendance à considérer le logiciel comme n'importe quel autre bien manufacturé. Mais ces deux considérations sont fausses, comme on peut le démontrer.

D'abord, le code écrit pour la vente n'est que la partie émergée de l'iceberg de la programmation. Dans l'ère qui a précédé les micro-ordinateurs, tout le monde savait que 90 % du code était écrit en interne par des banques et des compagnies d'assurances. Ce n'est probablement plus le cas — d'autres industries sont devenues bien plus dépendantes du logiciel depuis, et la part de l'industrie de la finance a sans doute baissé — mais nous verrons sous peu que les faits empiriques montrent que 95 % du code est encore produit en interne par ceux qui en ont besoin.

Ce code inclut la plus grosse partie du système d'information et de gestion, les adaptations financières et de base de données sur mesure dont toute entreprise, grande ou moyenne, a besoin. Cela inclut également du code très technique comme les pilotes de périphériques (presque personne ne gagne de l'argent en écrivant des pilotes de périphériques, un point sur lequel nous reviendrons). Cela inclut également tous les types de codes embarqués, pour des machines de plus en plus bardées de puces depuis les machines-outils, jusqu'au grille-pain, en passant par les voitures, les avions, et les fours à micro-ondes.

La plus grosse partie de ce code développé en interne est à ce point dépendant de l'environnement que sa réutilisation, voire sa copie, sont très difficiles (cela est vrai que « l'environnement » soit un ensemble de procédures dans un bureau ou le système d'injection du fioul dans une turbine). Cela étant, l'environnement évoluant, il y a beaucoup de demande et de travail pour que le logiciel suive.

C'est ce qu'on appelle la « maintenance », et tout ingénieur ou analyste vous dira que c'est ce qui constitue la plus grosse partie (plus de 75 %) de la paye des programmeurs. Nous sommes d'accord pour dire que la plupart des heures des programmeurs sont employées (et d'ailleurs, les programmeurs salariés sont payés pour cela) à écrire ou maintenir du code interne qui n'a aucune valeur en termes de vente ou d'achat — un fait que le lecteur pourra constater facilement dans en consultant la liste des offres d'emplois pour programmeurs dans les petites annonces.

Parcourir les offres d'emplois du journal local est une expérience enrichissante que je presse le lecteur d'effectuer. Examinez les offres contenues dans la section programmation, traitement des données, et ingénierie du logiciel, et trouvez celles qui concernent le développement d'un logiciel. Répartissez-les en catégories suivant que ce logiciel est destiné à la vente ou à l'utilisation en interne.

Il deviendra rapidement clair que, même en donnant la définition la plus inclusive possible de « vente », dix-neuf offres sur vingt au moins concernent des logiciels développés dans le seul but d'être utilisés en interne (c'est-à-dire, en tant que biens intermédiaires). Ceci est la raison pour laquelle nous pensons que seulement 5 % de l'industrie se consacre à la vente. Remarquez, cependant, que la suite de l'analyse n'est pas étroitement liée à cette proportion ; si elle valait 15 % ou même 20 %, les conséquences économiques seraient les mêmes.

(Quand je donne une conférence sur le sujet, je commence mon discours en posant deux questions : combien de personnes dans l'audience sont payées pour écrire du logiciel et pour combien d'entre ces dernières le salaire est lié à la vente de leur logiciel. Généralement, une forêt de mains se dresse à la première question, et très peu ou pas du tout pour la deuxième, ce qui provoque toujours une grande surprise dans l'assistance.)

Ensuite, la théorie selon laquelle la valeur du logiciel est couplée à son développement ou à son coût de remplacement est encore plus facilement démolie si l'on observe le comportement réel des consommateurs. Il y a beaucoup de biens pour lesquels cela est vrai (tant qu'ils ne se déprécient pas) — la nourriture, les voitures, les machines-outils. Il y a même beaucoup de biens immatériels dont la valeur de vente est en rapport avec le coût de développement ou de remplacement — droits de reproduction de la musique, cartes géographiques, bases de données, pour ne citer que quelques exemples. De tels biens peuvent garder leur valeur de marché, et même l'accroître après que le vendeur originel ne soit plus pris en compte.

Au contraire, lorsqu'une entreprise qui vend du logiciel se retire du marché (ou lorsque le produit est presque abandonné), le prix maximum que les consommateurs accepteront de payer se rapproche très rapidement de zéro, indépendamment de son utilité théorique ou du coût de développement des équivalents fonctionnels (pour vérifier cette assertion, examinez les fins de séries chez n'importe quel vendeur de logiciels près de chez vous).

Le comportement des revendeurs lorsque les vendeurs de logiciels cessent la production d'un logiciel est très instructif. Il montre qu'ils savent quelque chose que les fabricants, eux, ignorent. Voici ce qu'ils savent : le prix qu'un consommateur paiera pour un logiciel dépend effectivement de la valeur de retour espérée en terme de service de la part du fabricant (ce retour peut ici être compris au sens large des améliorations, des mises à jour, des projets s'élargissant, etc...)

En d'autres termes, le logiciel est largement une industrie de service sous hypnose, qui croit très fortement mais à tort qu'elle est une industrie de biens manufacturés.

Il est intéressant de se demander pourquoi nous sommes incités à raisonner ainsi. C'est tout simplement parce que la petite portion de l'industrie du logiciel qui est fabriqué pour être vendu est aussi la seule qui promeut ses produits. Ainsi, la plupart des produits dont on parle le plus sont des choses éphémères comme des jeux, dont on peut penser qu'on n'en attend pas de services (ce serait une exception plutôt que la règle) [SH] .

C'est également intéressant de remarquer que cette illusion des biens manufacturés encourage des structures de prix qui sont pathologiquement sans rapport avec les coûts de développement. Si (comme c'est généralement admis) plus de 75 % des coûts du cycle de vie typique d'un logiciel se trouvent dans la maintenance, les corrections d'erreurs, et les extensions, alors la politique qui consiste à fixer un prix élevé à l'achat et presque pas de budget pour l'assistance est destinée à produire des résultats qui desserviront tout le monde.

Les consommateurs y perdent, car bien que le logiciel soit une industrie de service, les motivations de ce modèle de l'usine empêchent le fabricant d'offrir un service compétent. Si le fabricant gagne de l'argent en vendant des octets, ses efforts viseront à produire et à sortir des octets. Le service d'assistance, qui ne fait pas de profit, deviendra un placard réservé aux moins compétents, et n'aura en fait de ressources que le strict nécessaire lui permettant de parer activement à la plus grosse partie des plaintes des clients.

L'autre facette de la médaille est que la plupart des fabricants qui raisonnent dans ce schéma de pensée échoueront à long terme. Produire des services d'assistance à perte, à partir d'un prix de vente fixé, ne peut fonctionner que dans le cas où le marché s'étend assez rapidement pour couvrir les coûts du support et ceux du cycle de vie des logiciels d'hier avec les revenus de demain. Une fois que le marché arrive à maturation et que les ventes ralentissent, la plupart des vendeurs n'ont d'autre choix que de réduire les coûts en cessant toute activité sur le produit.

Que ceci soit fait explicitement (en arrêtant le produit) ou implicitement (en rendant l'assistance difficile d'accès), cela a l'effet de conduire les clients chez le concurrent (parce que cela réduit à néant la valeur future que l'on peut attendre du produit, qui est conditionnée par ce service). À court terme, on peut s'en tirer en faisant passer des éditions avec des corrections d'erreurs pour un nouveau produit, avec un nouveau prix, mais le consommateur se fatigue rapidement. À long terme, la seule façon de s'en sortir est donc de n'avoir aucun concurrent — c'est-à-dire, d'avoir un véritable monopole sur son marché. À la fin, il ne peut en rester qu'un.

Et, bien sûr, nous avons régulièrement constaté que cette façon de ne plus assurer l'assistance pour ses produits a tué jusqu'à des concurrents qui tenaient une bonne seconde place dans une niche de marché (ceci doit sembler particulièrement clair à quiconque a observé l'historique des systèmes d'exploitation propriétaires des PC compatibles IBM, des traitements de texte, des programmes de comptabilité et n'importe quel logiciel financier en général). Les motivations perverses, induites par le modèle de l'usine, conduisent à un modèle où le gagnant gagne tout, et où même ses clients finissent par y perdre.

Alors, à défaut du modèle de l'usine, que prendre ? Pour pouvoir assumer les coûts du cycle de vie d'un logiciel de manière efficace (« efficace » étant à la fois pris dans ses sens informel et économique), nous devons trouver une structure de prix fondée sur des contrats de services, des inscriptions, et un échange continu de valeur entre l'acheteur et le vendeur. Dans les conditions de recherche de l'efficacité du libre marché, nous pouvons alors prévoir que c'est le type de structure de prix que la plupart des sociétés de logiciels matures suivront, à terme.

Ces propos commencent à nous faire pressentir pourquoi le logiciel à source ouvert est un défi de plus en plus important, tant du point de vue technique que du point de vue économique, par rapport à l'ordre établi. L'effet de faire du logiciel « libre et gratuit », semble-t-il, est de nous forcer à nous situer dans un monde ou le service serait tout puissant — et d'exposer la faiblesse du support en lequel nous avons toujours cru — le prix d'acquisition des bits des logiciels à sources fermés.

Le mot « libre » est également trompeur pour une autre raison. Baisser le prix d'un bien tend à augmenter, et non pas à faire baisser, l'investissement total dans l'infrastructure qui le soutient. Quand le prix des voitures baisse, les mécaniciens automobiles sont plus prisés — c'est pourquoi il est peu probable que les 5 % de programmeurs qui sont aujourd'hui financés par le prix d'acquisition ne souffrent dans un monde à sources ouverts. Ceux qui perdront au change ne seront pas les programmeurs, mais les investisseurs qui ont parié sur des stratégies à sources fermés là où elles ne sont pas appropriées.


Page suivante Page précédente Table des matières