Jean-Marie Gouarné (Logiciel Libre, Licences, Garanties)

Ces thèmes sont passablement rebattus depuis quelques années. Pourtant, les vraies questions ne sont ni les plus souvent posées ni les mieux traitées.

Sans rien avancer de révolutionnaire, essayons d'en explorer quelques unes, sans revenir sur la, ou plutôt les définitions du logiciel libre (LL) car, ou bien vous les connaissez, ou bien vous les trouverez dans d'innombrables documents de référence comme par exemple celui-ci. Je n'insiste pas non plus sur ce qui caractérise formellement le LL par rapport à de nombreuses catégories contractuelles présentées notamment ici. Je me contente pour l'instant de considérer comme "libre" tout logiciel "à code source ouvert" dont tous les utilisateurs disposent au moins des prérogatives suivantes :

il existe des options intermédiaires, consistant à accorder une partie de ces droits à une partie des utilisateurs. Mais cela concerne des situations anecdotiques et transitoires, dont le modèle économique et la mécanique contractuelle ne sont pas ceux du logiciel libre.

Je ne connais pas de terme positif pour qualifier les logiciels "non libres". Le mot "propriétaire", parfois employé, est une mauvaise traduction de l'Anglais proprietary qui veut dire "approprié" ou "spécifique", ce qui ne convient pas vraiment. Et "logiciel-dont-le-code-source-est-fermé" est un peu lourd. J'utilise donc ici l'expression "logiciel fermé", mais l'idée de fermeture concerne uniquement le code source et non pas les caractéristiques du produit. Quant à son contraire, le mot "ouvert", il a été tellement galvaudé qu'il ne veut plus rien dire aujourd'hui en informatique.

le logiciel libre n'est pas une nouvelle technologie

On assimile parfois, à tort, l'expansion du logiciel libre au cours des 10 dernières années à une vague technologique parmi d'autres, mais la réalité est très différente.

D'abord le logiciel libre, tout comme le logiciel non libre d'ailleurs, touche à tout et n'a pas de spécialité technologique particulière (même s'il est plus fortement présent dans certains types d'applications que dans d'autres). Ensuite, loin d'être un phénomène nouveau, le logiciel libre est au moins aussi ancien que la plupart des grands éditeurs de logiciels commerciaux actuels. Il convient d'ajouter à ce propos que le logiciel libre est souvent animé par une culture de la continuité, voire du développement durable, de sorte qu'il reste la plupart du temps en retrait par rapport aux "révolutions technologiques" successives, imposées par les éditeurs pour entretenir les marchés, et qui créent souvent plus de bruit que de valeur. N'oublions pas, par exemple, que le système Linux, qui occupe la place d'honneur au hit-parade des logiciels libres, n'est que le plus célèbre chapitre d'une saga dont le prologue se situe aux alentours de 1970.

Le logiciel libre ne se distingue des offres dites "propriétaires" que par ses modes de production et de distribution du code ainsi que par les régimes de propriété intellectuelle applicables. Ce n’est pas une technologie, c’est un modèle économique. Ce qu'il y a de nouveau, c'est son expansion accélérée, son entrée dans la conscience publique, son hyper-médiatisation (contrastant avec de longues années de quasi-boycott journalistique) et les débats à forte coloration politique dans lesquels il est impliqué.

liberté et gratuité

Le logiciel libre (LL) est généralement considéré comme gratuit, et la gratuité est vue par certains comme son principal intérêt. Or la gratuité n'est pas un élément essentiel de la problématique du logiciel libre. Je ne crois pas me tromper en ajoutant que cette gratuité, lorsqu'elle est invoquée comme le premier facteur de succès du LL, est en réalité un argument contre l'adoption du LL. Ce n'est pas mon penchant immodéré pour le paradoxe et la provocation qui me fait dire cela, mais ce sont les constats suivants :

En pratique, le LL est très souvent gratuit, mais la gratuité ne fait pas réellement partie de sa définition. La confusion entre "libre" et "gratuit" vient de l'utilisation du même mot anglais "free" pour désigner les deux. La Free Software Foundation insiste pourtant sur la nuance :

"Free software" is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech", not as in "free beer".

La traduction française de cette mise en garde est impossible et inutile. Par souci de respect "phrase à phrase" (sinon mot à mot) des textes fondateurs, les correspondants français de la Free Software Foundation ont quand même essayé :

L'expression "Logiciel libre" fait référence à la liberté et non pas au prix. Pour comprendre le concept, vous devez penser à la "liberté d'expression", pas à "l'entrée libre".

Notons au passage que bière gratuite a été remplacé par entrée libre. C'est un choix qui se discute car il semble suggérer que l'idée d'entrée libre est étrangère à la définition du logiciel libre.

Le logiciel libre évoque tout autant pour moi l'entrée libre que la liberté d'expression. L'entrée libre, dans un marché concurrentiel, c'est la possibilité d'examiner un produit, voire de l'essayer, avant de l'acquérir. Tout comme dans un bazar, l'entrée dans le logiciel libre est non seulement libre mais aussi gratuite [1]. C'est sans doute la première différence palpable avec le logiciel fermé : il n'est pas nécessaire de payer pour voir. Mais la gratuité cesse dès lors qu'il s'agit de déployer et d'exploiter, car la mise en oeuvre effective d'un logiciel (installation, configuration, paramétrage, formation, gestion des incidents, etc) représente toujours une charge que quelqu'un doit assumer d'une manière ou d'une autre. Le prix d'une licence n'est qu'une partie du coût global d'utilisation d'un logiciel.

Il convient tout de même de ne pas déduire hâtivement de ce dernier constat l'idée que la gratuité de la licence ne sert à rien et qu'il vaut mieux utiliser du logiciel payant en s'imaginant que ce qui se paye est plus "sérieux" que ce qui est gratuit. Certains éditeurs tentent de nous persuader que, en achetant des licences (et les services associés), on achète de la tranquillité et que, tout bien pesé, le logiciel commercial revient moins cher que le logiciel libre. Cette affirmation se fonde sur un postulat selon lequel, dans le domaine du logiciel comme dans une industrie traditionnelle, seul un acteur commercial de premier plan est capable de s'engager sur la robustesse et la pérennité de son offre. Or, depuis quelques années, ce postulat est si souvent battu en brèche dans certains pans de l'activité informatique qu'on se demande ce qu'il vaut aujourd'hui. La réalité démontre que le seul fait d'avoir payé (ou non) les composants logiciels d'une solution informatique ne préjuge pas de la valeur finale de la solution. Dans ces conditions, le simple bon sens voudrait qu'on se demande "pourquoi payer" avant de se demander "pourquoi ne pas payer".

D'abord, ce qui est gratuit (ou pas) ce n'est pas la propriété du logiciel, car un logiciel, comme un roman, appartient à son auteur. Ce qui est généralement mis dans le commerce, c'est le droit d'utiliser le logiciel. Un contrat de licence de logiciel (libre ou non libre) est en effet un contrat de droit d'usage et non un contrat de transfert de propriété. Quand on est titulaire d'une licence de logiciel, on n'a donc pas pour autant le droit de faire tout ce qu'on veut de ce logiciel. Et ceci, qu'on l'ait payé ou non.

Ensuite, et surtout, l'enjeu économique n'est pas nécessairement significatif. Tout dépend du profil de l'utilisateur.

Prenons l'exemple de la bureautique, qui concerne directement la plus large population. Pour un particulier, qui doit généralement payer le prix fort pour un logiciel bureautique commercial (sauf à se livrer au piratage), l'adoption d'une distribution Linux avec toutes ses applications peut représenter une économie de plusieurs centaines d'euros. Mais pour une grande entreprise, le coût des licences logicielles ne représente qu'une très faible part du coût de possession global de chaque poste (peut-être moins de 5%). Dans ce dernier cas, si la gratuité des licences est le seul argument favorable aux solutions libres, mieux vaut abandonner l'option sans état d'âme : le gain obtenu sur les licences ne compensera guère le coût du changement. À court terme, la gratuité n'est un argument valable que pour ceux qui ne sont pas encore équipés, qui n'ont donc pas à affronter la conduite du changement, qui peuvent se débrouiller tous seuls et qui ne comptent pas leur temps.

En revanche, dans d'autres secteurs de l'informatique d'entreprise, les licences logicielles accaparent des portions beaucoup plus significatives des budgets, allant jusqu'à plusieurs dizaines de pourcents. Les alternatives gratuites méritent alors un examen très sérieux. Malheureusement, le LL n'est pas forcément présent là où il ferait chuter les coûts de licences le plus vite. On trouve de plus en plus facilement des produits libres, gratuits et prêts à l'emploi dans le monde du middleware et des infrastructures (je pense en particulier au marché des serveurs d'application et des bases de données, où PostgreSQL, MySQL, JBoss et Jonas commencent à taquiner IBM, BEA et Oracle). Mais dans le monde luxueux des progiciels de gestion intégrés (PGI) ou de la "gestion de la relation client" (GRC), l'offre est encore presque inexistante.

Dans un calcul à long terme, cependant, la gratuité des licences peut devenir un avantage significatif dans tous les domaines car

Toutefois, la gratuité (combinée avec l'absence de formalité administrative préalable à l'utilisation), peut provoquer des chocs culturels, car elle permet de court-circuiter les procédures classiques d'acquisition de logiciels (appel d'offres, passage obligé par un service des achats, etc) et peut donc faciliter le déploiement sauvage de solutions ou de technologies non homologuées. Or certaines organisations sont aussi attachées au respect des normes informatiques qu'elles édictent qu'aux résultats produits par l'informatique.

Certains grands utilisateurs, se croyant plus rusés que d'autres, ont "étudié" le logiciel libre sans la moindre intention de l'adopter, mais dans le seul but d'utiliser sa "gratuité" comme un levier de négociation tarifaire avec leurs éditeurs de logiciels préférés. Cette petite roublardise ne saurait produire de grands effets. La seule présence du LL sur un segment de marché pousse de toute façon les prix à la baisse (il n'y a qu'à suivre la dégringolade des prix ces dernières années dans les moteurs de bases de données et les systèmes d'exploitation). Mais pour obtenir une baisse de prix individuelle supplémentaire significative par la menace d'une alternative libre, il faut non seulement être un gros donneur d'ordre, mais aussi être capable de franchir effectivement le pas. Par exemple on sait (même s'il n'est pas forcément opportun de les citer), que certaines organisations ont obtenu, dans certains pays, des concessions tarifaires allant jusqu'à la quasi-gratuité auprès d'un grand éditeur de logiciel, mais seulement après avoir démontré par un commencement d'exécution qu'elles étaient prêtes à déployer un logiciel concurrent gratuit. Les éditeurs de logiciels sont eux-mêmes passés maîtres dans l'art du bluff, et il est difficile de les manoeuvrer sur ce terrain. Pour un commercial expérimenté, il est facile de sentir si le client est vraiment dans l'état d'esprit qui accompagne les vrais projets de migration vers le LL. Une entreprise qui fait semblant d'aller vers le LL sans en avoir envie ne fait que dégrader son image et sa capacité de négociation à long terme.

Mais est-il vraiment pertinent de se focaliser sur la gratuité d'un droit d'usage, alors que ce qui intéresse l'utilisateur, c'est le prix de revient de l'usage réel ?

Comme je le répète à la moindre occasion, ce qui compte c'est l'information et pas l'informatique. L'information, c'est le service rendu par l'informatique. C'est cela que paye l'utilisateur, car ce n'est jamais gratuit. Les dérives du marché du logiciel, et l'interminable immaturité de la non-industrie du logiciel, ont focalisé l'attention des utilisateurs sur les produits au détriment des solutions. C'est à un point tel que, dans certains projets, on a l'impression que le choix de tel ou tel composant technique est plus important que le besoin de l'utilisateur. C'est l'importance indue qu'on accorde au composant technique qui tire vers le bas, c'est-à-dire vers la question des coûts de licence, les discussions sur le logiciel libre.

Or la vraie fonction du logiciel libre, c'est de déplacer le centre de gravité économique des projets de l'éditeur de logiciel vers l'intégrateur (ce dernier pouvant être une SSII, un constructeur informatique, un éditeur-distributeur, ou même le service informatique interne de l'utilisateur). C'est l'intégrateur qui fournit la solution, et c'est le prix de la solution qui compte pour l'utilisateur. Pour ce dernier, la gratuité de tel ou tel composant technique de la solution est une question sans grand intérêt.

Nous n'avons malheureusement aucune statistique crédible permettant de dire si, toutes choses égales par ailleurs, le LL permet ou non de réduire le coût global d'un projet. Chaque éditeur de logiciel a l'habitude de "prouver" au monde entier que l'utilisation de ses produit a permis de réduire de tant pour cent le coût d'un projet. Mais comme un projet n'est jamais réalisé deux fois exactement dans les mêmes conditions avec des composants techniques différents, les démonstrations de ce genre ne sont que des exercices rhétoriques.

D'une manière générale, je me méfie terriblement des outils et des techniques dont le principal objectif serait de "réduire les coûts". Je n'oublie pas qu'Unix dans les "systèmes départementaux", puis le tandem Wintel (Windows/Intel) dans la bureautique, ont été initialement lancés sur le marché avec des messages de réduction des dépenses informatiques. En réalité, les conditions pratiques dans lesquelles se sont généralisés ces outils on été telles qu'ils ont finalement été l'un des principaux facteurs de l'explosion des coûts informatiques dans les années 1990. La réduction des coûts est trop souvent l'ultime refuge de décideurs en panne d'imagination, auxquels la comptabilité tient lieu de stratégie. Et je doute qu'on puisse irréfutablement démontrer un jour sur ce terrain la supériorité (ou l'infériorité) du logiciel libre. De plus, quand la mode est à la réduction des coûts, les comportements sont souvent imbibés de conservatisme frileux, et les seules restrictions budgétaires vraiment recherchées sont celles qui ne dérangent pas les habitudes. Les coups de freins sur les budgets informatiques ne sont donc pas, à eux seuls, les déclencheurs du passage au logiciel libre.

Cependant, si on en croit les récentes annonces provenant de grands consommateurs d'informatique (je pense en particulier à d'importantes agences gouvernementales, notamment en Europe) qui se disposent à élargir leur utilisation de LL au détriment de certains produits commerciaux, le coût des licences apparaît généralement comme la première motivation déclarée. Je ne pense pas que ce soit par erreur. Nous vivons dans un monde où tout projet informatique, pour avoir le droit d'exister, doit faire semblant de démontrer qu'il va produire un avantage budgétaire mesurable, et si possible à court terme, même si son véritable objectif est d'une toute autre teneur. Et même si, dans la profession informatique, nous sommes de plus en plus nombreux à douter de la validité de ces évaluations de "retour sur investissement", dont le bien-fondé est d'ailleurs rarement vérifié a posteriori. Le but d'un projet informatique peut être d'apporter ou de faciliter un changement fondamental; il n'est pas forcément de "faire comme avant pour moins cher". Or le LL est justement un élément (parmi d'autres) qui peut s'inscrire dans un scénario de rupture en matière de conduite des systèmes d'information. En effet, le relâchement des liens de dépendance envers les éditeurs commerciaux (et surtout ceux d'entre eux qui occupent une position dominante sur le marché), et le recours accru à des composants techniques entièrement ouverts, non protégés par des "secrets d'usine", mènent à un rééquilibrage des rapports entre fournisseurs et utilisateurs, et à un changement dans le mode de développement des applications. L'enjeu est fondamental. Mais c'est un enjeu à long terme, dont les avantages ne sont pas facilement quantifiables. Les décideurs qui mènent les projets de migration vers le logiciel libre sont donc obligés d'en passer par les exercices traditionnels de justification budgétaire. Dans ces conditions, la réduction des dépenses relatives aux licences logicielles est la cible la plus facile à désigner. Même si les vrais objectifs sont politiques.

politique et logiciel libre

Il serait très naïf de croire que le choix des logiciels relève dans les entreprises de la pure logique de l'homo economicus. Ces choix sont nécessairement des choix politiques. Je dis cela sans intention péjorative, bien que la mode recommande plutôt de dire "stratégie" voire "gouvernance" quand on pense "politique" dans un sens constructif. L'entreprise doit prendre en considération des facteurs typiquement politiques tels que la qualité de ses relations avec chaque fournisseur, ses estimations de pérennité sur tel ou tel produit, le savoir-faire dont elle dispose (dans ses équipes internes ou chez ses prestataires favoris).

L'adoption de logiciel libre, comme son refus, n'échappe pas à cette logique. La décision, quelle qu'elle soit, ne découle jamais de la seule étude comparative des prix et des caractéristiques fonctionnelles des produits. Elle se doit de tenir compte de facteurs socio-techniques essentiels comme

La problématique est en réalité la même que celle du choix entre deux offres commerciales concurrentes. Dans une organisation déjà largement équipée, les fournisseurs en place bénéficient presque toujours d'une "rente de situation" dans la mesure où, jusqu'à preuve du contraire, le changement est associé d'instinct au risque. Sachant que, jusqu'à nouvel ordre, le LL n'est encore entré que marginalement "dans la place", c'est toujours à ceux qui cherchent à introduire le logiciel libre dans leur organisation qu'appartient la charge de la preuve.

Le caractère sociologique du problème transparaît dans l'une des objections émises par de nombreux professionnels de l'informatique à l'encontre du logiciel libre, à savoir la "rareté des compétences". Or quand un vendeur ou un technicien opérant sur un marché fortement concurrentiel, dans n'importe quel domaine, nous dit que la compétence est rare, cela signifie, en clair, qu'il n'a pas, lui, cette compétence. Cette objection reflète davantage la crainte d'une redistribution des cartes ou d'un effort personnel de mise à niveau qu'un point de vue de stratège ou d'analyste de marché.

Par définition, quand quelquechose de nouveau apparaît, il n'y a pas encore de compétence. En réalité, c'est le développement du marché qui tire l'évolution des compétences. Mais surtout, contrairement à ce que laissent croire certains abus de langage, le logiciel libre n'est pas une nouvelle technologie, c'est avant tout un nouveau procédé de diffusion de la technologie. Pour les (vrais) techniciens, l'adaptation au logiciel libre est donc un problème beaucoup moins dramatique que ne l'a été l'adaptation à chacune des technologies commercialisées tout au long des 20 dernières années (SGBD relationnels, client-serveur, Unix, Windows, Java, serveurs d'application, Microsoft.Net, services web, etc). Concrètement, par exemple, un administrateur de système Unix ayant travaillé dans des environnements IBM, HP ou Sun n'a pas vraiment de difficulté à prendre en main un système Linux ou OpenBSD.

Les choix politiques ne sont pernicieux que quand ils cherchent à se cacher derrière des arguments technico-financiers. Or, à l'heure actuelle, l'adoption à grande échelle du logiciel libre ne peut s'inscrire valablement que dans un scénario de rupture qui, certes, doit faire l'objet d'une évaluation économique aussi rigoureuse que possible, mais dont le fondement ultime relève d'un choix stratégique et ne peut en aucun cas être dicté par le calcul (toujours douteux) d'un ROI ou d'un TCO.

Parmi les considérations stratégiques qui entrent en ligne de compte, on trouve notamment

Bien sûr, cette liste n'est pas limitative, mais il est clair que les critères sont essentiellement "politiques" car le décideur, comme un stratège en campagne, est seul responsable des pondérations et des métriques applicables et ne dispose jamais de toutes les données du problème.

Parmi les critères stratégiques, il en existe un qui est aussi puissant qu'inavoué : c'est la visibilité. En effet, un choix informatique qui risque d'être l'objet d'une forte publicité, même si son impact sur le métier de l'entreprise est modéré, est abordé avec autant, sinon plus de circonspection qu'un choix réellement décisif pour l'organisation.

Ce phénomène se vérifie notamment aujourd'hui à propos de la bureautique libre. Des organisations qui ont à peine hésité à affronter les risques et les remises en question inhérents à l'adoption des grands progiciels de gestion intégrés se refusent encore à envisager le recours à des logiciels bureautiques libres sur les postes de travail. Pourquoi cette réticence alors que, dans ce domaine, les risques et les coûts sont parfaitement prévisibles puisque l'organisation de l'entreprise et les processus opérationnels ne sont pas remis en question ?

Certainement pas pour des raisons liées aux qualités pratiques des produits, car tous les logiciels bureautiques actuels (libres ou non) ont à peu près le même comportement et parce que 80% de leurs utilisateurs n'utilisent pas 20% de leurs possibilités. Certainement pas non plus pour des raisons de productivité, car, comme je l'ai déjà dit ailleurs, personne n'a jamais mesuré sérieusement, à l'échelle d'une grande entreprise, la productivité d'un traitement de textes, et le rapport entre le prix d'un logiciel et la qualité du courrier produit. Certainement pas non plus à cause de la minorité d'utilisateurs pointus qui, eux, ont effectivement besoin des caractéristiques propres à un produit (je pense surtout au tableur, le produit commercial leader du marché étant à ce jour supérieur à toutes les offres libres), car il n'est pas nécessaire d'équiper tout le monde d'un outil complexe et luxueux qui n'est mis en valeur que par quelques uns. Alors, pourquoi hésiter ?

Tout simplement parce que la bureautique est l'application qui touche directement le plus grand nombre d'utilisateurs, et que tout projet d'évolution dans ce domaine est immédiatement visible... donc redoutable. La publicité multiplie la portée psychologique du risque. Surtout à une époque comme la nôtre où, à quelques exceptions près, les directions informatiques adoptent un profil bas. Parfois même trop bas pour jouer pleinement leur rôle de conseil auprès des utilisateurs et des directions générales.

On ne soulignera jamais assez, par aileurs, la distance qu'il convient de respecter entre politique et idéologie. Car ici comme ailleurs, le débat manque parfois de pragmatisme et de sérénité. Certains vont jusqu'à considérer la question du logiciel libre comme l'un des éléments d'un débat de politique générale, comme un critère d'adhésion globale à un certain modèle de société. Parmi les dérapages qui s'ensuivent, on peut citer

En réalité, il n'y a pas de profil idéologique type du créateur de logiciel libre, sinon, probablement, un certain individualisme confinant à l'orgueil et éventuellement mêlé d'altruisme. Je dis éventuellement car la publication gratuite de logiciel libre rend personnellement visible son auteur, dont l'ego est d'autant plus gratifié que le travail est bien fait. C'est là le secret de l'étonnante robustesse du LL : s'il y a une faille de sécurité ou un bogue non corrigé, c'est quelqu'un, et non une équipe de programmeurs anonymes, qui est connu et montré du doigt par le public utilisateur. Pour quelqu'un qui, comme moi, connaît de l'intérieur l'état d'esprit du programmeur au travail, il est évident que l'orgueil personnel est un ressort plus puissant de la "qualité totale" et du "zéro défaut" que les primes de fin d'année. L'un des mérites sociaux du LL a été de révéler qu'un bon programmeur se situe quelquepart entre l'artiste et le compagnon (au vieux sens des artisans du "tour de France"); c'est un travailleur de l'ère pré- (ou post- ?) industrielle [4].

licences et garanties

La question de la garantie n'est pas, contrairement à une idée encore assez répandue, un point essentiel d'opposition entre logiciel libre et commercial. Aucun responsable informatique expérimenté ne se fait d'illusion quant à la protection que lui assurent les clauses de garantie contenues dans les licences des plus grands éditeurs. À tel point qu'on pourrait parfois douter de la consistance, sur le marché du logiciel, d'un tel concept emprunté, peut-être un peu hâtivement, au bâtiment et aux industries manufacturières. On touche là à un autre débat, celui de la définition du logiciel en tant que produit industriel (attention, terrain miné !). En tout cas, la seule garantie sur laquelle on puisse réellement compter dans un projet mis en difficulté par une défaillance du logiciel n'est pas contractuelle. Elle est d'ordre commercial, et ne repose que sur la confiance ou, à défaut, sur des rapports de force.

Les contrats de licence de logiciel sont presque toujours, dans la pratique, conçus et rédigés pour restreindre les engagements des éditeurs et les risques de réclamation des utilisateurs. C'est vrai pour tous les contrats de licence, qu'il s'agisse de logiciel fermé ou de logiciel libre. Dans le cas des logiciels libres, ce phénomène est plus évident qu'ailleurs, pour deux raisons. D'abord parce que les textes sont publics et que chacun est libre de les commenter et de les critiquer, ce qui n'est pas le cas des licences privées. Il est très facile de trouver des articles de juristes ou d'informaticiens sur les mérites ou les limites de tel ou tel modèle de licence libre. À l'opposé, les licences commerciales sont propres à chaque produit et sont généralement découvertes par l'utilisateur après l'ouverture des négociations avec l'éditeur. Ensuite et surtout parce que les licences de LL mentionnent explicitement l'absence de garantie (dans les limites permises par la loi) et préviennent expressément l'utilisateur que l'auteur ne souhaite pas engager sa responsabilité quant aux conséquences directes et indirectes de l'utilisation du produit. Mais la protection de l'utilisateur est-elle réellement meilleure sur la base d'un contrat de licence obtenu à titre payant auprès d'un éditeur commercial ? C'est à voir.

Bien sûr, il serait aventureux de se prononcer là-dessus d'une manière générale sans disposer d'une compilation des licences logicielles non libres pratiquées de par le monde. Mais si je m'en tiens aux quelques constatations que j'ai faites par moi-même sur le terrain, tant dans les textes contractuels que dans les conversations avec des éditeurs et des utilisateurs, nous sommes ici dans le règne du flou et de l'incertitude.

Si l'on s'en tient à la lettre des licences commerciales (non démenties à ce jour par la jurisprudence), la notion de garantie n'a pas grand rapport dans le logiciel avec ce qu'elle signifie lorsqu'il s'agit de biens matériels, à tel point qu'on se demande à quoi est tenu le fournisseur et à quoi peut prétendre le client.

D'abord, la responsabilité de l'éditeur ne peut être engagée, au pire, que jusqu'à concurrence du montant payé pour l'achat de la licence, et ce quels que soient les dommages directs et indirects subis par le client du fait d'une défaillance du logiciel (projets retardés ou annulés, pertes d'exploitation ou manques à gagner, etc). D'ailleurs les engagements de garantie sont beaucoup moins précis sur le logiciel lui-même que sur son support physique, comme si les conditions de remplacement d'un cédérom rayé étaient vraiment d'un intérêt essentiel pour la sécurité de l'utilisateur.

Il existe aussi un mécanisme d'esquive assez subtil, très répandu sur le marché, (et même considéré, dans le monde du logiciel, comme la norme), qui équivaut à faire passer à la trappe, sans le dire, les obligations de résultat qui incombent normalement au fabricant. L'éditeur fait en effet souscrire au client deux contrats, l'un portant sur le droit d'usage du logiciel (la licence proprement dite) et l'autre sur une prestation de service (parfois appelée "support" ou, à tort, "maintenance"). Le client est invité à considérer que tout ce qui devrait normalement engager le fabricant au titre de la garantie est pris en charge au titre du contrat de service. Or ce contrat de service (tout comme un contrat d'assistance technique souscrit auprès d'une SSII) ne met qu'une obligation de moyens à la charge de l'éditeur qui s'engage seulement à faire "au mieux" pour mettre le logiciel en état de marche.

Mais que fait la loi, dans tout ça ? La garantie des "défauts cachés de la chose vendue", telle que définie en France par l'article 1641 du Code Civil ne semble pas s'appliquer au logiciel. C'est apparemment le point de vue des éditeurs, le public semble y être résigné, et les tribunaux n'ont pas encore eu l'occasion de dire le contraire.

On pourrait très bien arguer du fait que, comme je l'ai dit précédemment, la licence ne confère qu'un droit d'usage, que le logiciel n'est pas vendu, et donc que la garantie sur la chose vendue n'est pas applicable. On arrive ici à l'extrême limite de la bonne foi. Admettons quand même, mais poussons un peu le raisonnement. Dès lors qu'on parle non plus d'une vente mais d'un droit d'usage payant, on parle de location, de bail. Dans ce cas, c'est la garantie des "vices et défauts de la chose louée" visée, en droit français, par l'article 1721 du Code Civil qui devrait s'appliquer. Or, dans la pratique, ce n'est manifestement pas non plus le cas. Les clauses écartant cette garantie semblent d'ailleurs légales.

Il convient de préciser que, même si ces protections légales étaient appliquées au logiciel, elles ne seraient d'aucun secours pour les grandes entreprises disposant de services informatiques ou assistées par des consultants informaticiens, car elles sont supposées avoir les compétences techniques nécessaires pour se défendre. La jurisprudence, généralement soucieuse de la défense du consommateur "naïf", considère le consommateur "professionnel" comme capable de traiter d'égal à égal avec ses fournisseurs de logiciel. Cette idée ne devrait pas prêter à controverse dans le cas, par exemple, d'une négociation entre une entreprise utilisatrice française et une société d'ingénierie française en vue de la réalisation au forfait d'un logiciel spécifique. Mais face à un éditeur de logiciel international, le client européen, fût-il un grand compte disposant d'un nombreux personnel informatique et de juristes avisés, ne pèse pas lourd; à la table des négociations, il peut obtenir des concessions tarifaires mais ne peut pas espérer le moindre aménagement en sa faveur sur le plan des garanties. L'égalité technique entre acheteur et vendeur est donc purement théorique et joue finalement contre l'utilisateur professionnel, en lui faisant perdre le bénéfice d'une protection juridique efficace. Résultat: l'entreprise utilisatrice n'aura droit à rien de ce qui n'est pas écrit dans le contrat.

Il est vrai que le logiciel, étant une oeuvre de l'esprit (au même titre qu'un roman), ne peut pas être assimilé à une chose, et que la responsabilité de son auteur ne peut donc pas être engagée sur les mêmes bases que s'il s'agissait de biens matériels. On touche ici à l'une des nombreuses contradictions de ce petit monde. Certains éditeurs militent activement en faveur de la reconnaissance, en Europe et en France, des brevets logiciels. Apparemment, la question des brevets n'a pas de rapport direct avec celle des licences et des garanties. Cependant un brevet est censé s'appliquer à une invention susceptible d'être mise en oeuvre dans le cadre d'une application industrielle, et non pas à une oeuvre de l'esprit soumise au droit d'auteur. De ce fait, si le logiciel devenait un jour brevetable dans toute l'Union Européenne, il conviendrait de reconsidérer son statut d'une manière plus générale. En effet, accorder à un éditeur tous les bénéfices du régime de la propriété industrielle (et infliger à la concurrence les risques et les contraintes qui en résultent), tout en lui concédant l'irresponsabilité liée aux oeuvres intellectuelles non industrielles, ce serait lui donner le beurre et l'argent du beurre. Il est regrettable que le débat récurrent sur les brevets logiciels n'englobe pas cet aspect du problème; ce débat ne devrait pas être isolé d'une réflexion plus globale sur le statut juridique du logiciel incluant notamment la responsabilité du vendeur.

Pour pallier en partie les lacunes du système de garantie, l'attirail légal français s'est enrichi en 1998 des articles 1386-1 à 1386-18 du Code Civil, transposant tardivement une directive européenne de 1985 relative à la responsabilité du fait des produits défectueux. Cette responsabilité pèse sur tout producteur agissant à titre professionnel (et, par extension, sur le vendeur ou le loueur du produit). Elle est d'ordre public; toute clause contractuelle tendant à la réduire ou à l'écarter est interdite. D'ailleurs, la responsabilité du fait des produits défectueux s'applique même en l'absence de contrat entre le producteur et l'utilisateur. Sachant qu'un auteur de logiciel libre n'agit pas forcément à titre professionnel et que le fruit de son travail, livré à la communauté, n'est pas forcément assimilable à un produit, on peut peut-être trouver là une vraie différence entre logiciel libre et logiciel commercial en matière de protection de l'utilisateur. À condition bien sûr que le logiciel, lorsqu'il est fabriqué ou mis à disposition par un professionnel juridiquement identifié, soit traité de la même manière que tout autre produit industriel. Dans l'état actuel de la pratique commerciale et de la jurisprudence, le débat n'est pas clos sur ce point. De plus, l'article 1386-11 accorde une échappatoire au producteur, qui peut dégager sa responsabilité en prouvant que l'état des connaissances scientifiques et techniques du moment ne lui a pas permis de déceler le défaut du produit. Un joker que les éditeurs ne se priveront sans doute pas d'utiliser le cas échéant, ce qui ne manquera pas alors de provoquer quelques batailles d'experts.

En réalité, on touche ici à un problème de fond. Au-delà des arguments juridiques, les éditeurs de logiciel n'ont ni la culture de la responsabilité, ni l'expérience de la gestion des risques, ni la capacité d'engagement qu'on attend d'un vendeur de biens matériels, notamment dans le monde des industries manufacturières. L'édition commerciale de logiciel s'exerce actuellement selon un modèle économique et dans un cadre organisationnel qui ne supporteraient pas la mise en oeuvre intransigeante des règles classiques de garantie et, plus généralement, de protection de l'utilisateur. Si, à la limite, les utilisateurs (et les juridictions) exprimaient envers les éditeurs de logiciels les mêmes exigences de qualité qu'envers les constructeurs d'automobiles ou d'appareils ménagers, ils provoqueraient un effondrement des marges, voire la disparition pure et simple de certains acteurs majeurs et une restructuration profonde du marché. Je ne m'étends pas sur la question de savoir si ce serait une bonne ou une mauvaise chose. Mais, pour toutes ces raisons, l'édition de logiciel n'est pas (ou n'est pas encore, ou ne sera jamais) une industrie. Le fait qu'un éditeur commercial bénéficie d'une bonne santé financière, tienne un discours stratégique de haut niveau et présente une façade commerciale comparable à celle d'un groupe industriel classique n'est pas un gage de son aptitude à faire face aux conséquences opérationnelles d'une vraie garantie.

Pour la défense des éditeurs, on rappelle parfois qu'il est humainement impossible de garantir l'absence de bogue dans un logiciel comportant plusieurs millions de lignes de programme. L'argument sonne vrai, dès lors qu'on admet effectivement que le logiciel échappe aux règles communes de l'industrie. Qui oserait soutenir qu'un avion long courrier est un produit plus "simple" qu'un progiciel de gestion ? Or, en cas de défaillance du matériel, permettrait-on à Airbus ou à Boeing d'échapper à ses responsabilités en invoquant la complexité du produit ? Le risque et la complexité, ça se mesure et ça se gère partout... sauf dans le logiciel ?

Qu'est-ce qui permet à ce modèle économique et juridique bizarre de perdurer ? C'est sans doute d'abord la tolérance résignée dont les utilisateurs font preuve. Je ne parle même pas des simples particuliers ou des petites entreprises qui, face à un incident informatique, sont complètement perdus et ne savent d'ailleurs même pas toujours de quel composant (matériel ou logiciel) vient la panne. Les grandes entreprises elles-mêmes, qui pourtant disposent de directions informatiques et de services juridiques musclés, renoncent (consciemment ou non) à exiger des garanties réelles sur le logiciel et à les faire respecter.

D'abord, dans les phases de choix de logiciel, il arrive fréquemment que les produits en compétition soient évalués sur des critères exclusivement fonctionnels, techniques et financiers. Les engagements contractuels, et notamment tout ce qui concerne les garanties, ne sont souvent examinés qu'à la fin de la démarche, lorsque les produits sont déjà pratiquement choisis et lorsque acheteur et vendeur savent qu'un retour en arrière serait douloureux. Si on voulait que la garantie soit sérieusement négociée, il faudrait que les juristes travaillent dès le début de concert avec les autres décideurs et que les engagements contractuels soient considérés comme des critères essentiels de choix. À la limite, dans le dépouillement des appels d'offres, l'entreprise utilisatrice ne devrait même pas regarder les propositions ne respectant pas certains standards industriels en matière de garantie. Si elles acceptent les conditions des éditeurs, c'est peut-être parce qu'elles estiment, consciemment ou non, que la garantie du logiciel n'est pas un enjeu très important.

Ensuite, les entreprises répugnent à aller au contentieux contre leurs fournisseurs de logiciels, pour des raisons qui, là aussi, sont sociales et non juridiques. Porter devant les tribunaux un litige avec un éditeur, c'est, de la part du décideur concerné, avouer à sa hiérarchie, à ses collaborateurs, à ses actionnaires et au public qu'il a fait un choix malheureux. Une option politiquement dangereuse en dépit de tout ce que disent les théoriciens du management à propos du "droit à l'erreur".

Enfin, dans les cas les plus graves, quand on finit par comprendre que l'éditeur ne sera pas capable de corriger rapidement un problème, on préfère éviter un recours à outrance qui aboutirait, au mieux, à une compensation financière tardive mais qui provoquerait le naufrage des projets engagés avec le logiciel défectueux. Dans une telle situation, l'éditeur et l'utilisateur (au frais de ce dernier) se mettent implicitement d'accord pour "cacher la poussière sous le tapis" et contourner les bogues à grand renfort de prestations de conseil. Même si c'est au prix d'une explosion des budgets et des délais, on fera tout pour sauver les projets. En évitant d'ébruiter les mauvaises nouvelles qui pourraient faire autant de tort à l'entreprise utilisatrice qu'à l'éditeur [7]. Cette loi du silence comporte à son tour deux inconvénients : d'abord l'éditeur n'est pas commercialement incité à donner entière satisfaction au client (qui ne lui fera probablement pas de contre-publicité tapageuse), et ensuite il ne peut pas y avoir de capitalisation inter-entreprise des connaissances sur les bogues et les solutions de contournement.

Tout ceci m'amène à considérer que, pour un ensemble de raisons qui ne sont pas essentiellement juridiques, le logiciel, quel que soit son modèle économique, libre ou non, n'est pas réellement garanti, que le mot garantie (comme beaucoup d'autres mots empruntés par l'informatique à l'industrie et au bâtiment) a ici un contenu aussi léger qu'imprécis et par conséquent que la garantie n'est pas un critère de choix rationnel entre logiciel libre et logiciel non libre.

Alors comment se protéger ? Par un choix honnêtement politique, c'est-à-dire explicitement fondé sur la confiance qu'on porte à chacune des offres en compétition. Cette confiance, même si elle est nécessairement subjective, peut être justifiée par les relations en cours avec un fournisseur, par la notoriété, par des références précises en matière de service après-vente. Cela peut éventuellement, en cas de projet sensible, nécessiter une démarche d'analyse stratégique.

Si le choix se porte sur un LL, il est toujours possible d'acheter un service global auprès d'un intégrateur qui, lui, assumera l'ensemble des prestations normalement prévues par les licences et les contrats de service des éditeurs. Les contrats d'intégration clés en mains étant, eux, négociables (contrairement aux licences logicielles), il est également possible d'y incorporer une vraie garantie de bon fonctionnement de la solution [8]. Cette approche pemet de chiffrer et de comparer des offres complètes, focalisées sur les solutions et les résultats.

Une analyse purement juridique de la question serait donc insuffisante. Ce qui fait le plus défaut, ce n'est pas tant l'attirail législatif que sa mise en oeuvre effective par les utilisateurs. Mais ce n'est pas une raison, bien au contraire, pour se dispenser de bien étudier le droit applicable [9]...

en conclusion provisoire

Et d'apprécier le logiciel libre non pas comme une offre concurrente exotique, mais plutôt comme l'un des moyens de remettre d'aplomb un marché qui semble encore défier les lois de l'économie, de la gravitation universelle et du simple bon sens.

[1] Je ne cite pas le bazar... par hasard. C'est une métaphore chère aux zélotes inconditionnels du logiciel libre. Voir à ce sujet le texte légendaire d'Eric S. Raymond, La Cathédrale et le Bazar. Cela dit, si le monde du logiciel libre présente quelque ressemblance avec un bazar, le rapprochement entre logiciel propriétaire et cathédrale est un peu forcé. Si nos cathédrales médiévales avaient été construites selon le même "processus qualité" que les grands logiciels commerciaux d'aujourd'hui, aucune ne serait restée debout aussi longtemps. D'autre part, à ma connaissance, l'entrée de ces cathédrales a toujours été largement ouverte au public, les technologies mises en oeuvres dans leur construction n'ont pas fait l'objet de brevets et ont été librement copiées. En outre, la démarche de conception et de conduite de projet qui a produit ces chefs-d'oeuvre n'a jamais été aussi opaque et centralisée (pour ne pas dire "stalinienne") que ne le pense Eric Raymond... Ceci n'enlève rien au talent de l'auteur de Fetchmail dont l'histoire de l'art n'est sans doute pas la principale préoccupation.

[4] Les éditeurs commerciaux gagneraient sans doute à en tenir compte et à donner plus de visibilité personnelle à leurs programmeurs.

[5] Code Civil, art. 1641 : "Le vendeur est tenu de la garantie à raison des défauts cachés de la chose vendue qui la rendent impropre à l'usage auquel on la destine, ou qui diminuent tellement cet usage, que l'acheteur ne l'aurait pas acquise, ou n'en aurait donné qu'un moindre prix, s'il les avait connus."

[6] Code Civil, art. 1721 : "Il est dû garantie au preneur pour tous les vices ou défauts de la chose louée qui en empêchent l'usage, quand bien même le bailleur ne les aurait pas connus lors du bail. S'il résulte de ces vices ou défauts quelque perte pour le preneur, le bailleur est tenu de l'indemniser."

[7] Dans certains cas, la diffusion publque des "mauvaises nouvelles" est même expressément interdite au client. En effet, certains contrats de licence stipulent que l'utilisateur ne peut divulguer aucune information relative aux performances du logiciel sans l'autorisation de l'éditeur. Bien sûr, cela n'empêche pas certaines conversations d'avoir lieu et certaines informations de filtrer. Mais le bouche à oreille est tout de même beaucoup moins efficace que la libre publication.

[8] C'est peut-être même moins compliqué avec un LL qu'avec un logiciel fermé car, souvent, dans ce dernier cas, l'intégrateur et l'éditeur se renvoient la balle en cas de difficulté, et de plus l'intégrateur n'a pas accès au code source du logiciel de l'éditeur.

Logiciel Libre, Licences et Garanties

le logiciel libre n'est pas une nouvelle technologie

liberté et gratuité

politique et logiciel libre

licences et garanties

en conclusion provisoire