Les logiciels libres ont réussi leur percée. Le phénomène, annoncé depuis longtemps par certains, minimisé ou redouté par d’autres, a fini par se faire une place dans les systèmes d’information et les esprits. Je ne reviendrai pas sur les succès médiatiques de la suite bureautique OpenOffice.org, récemment adoptée par la Gendarmerie Nationale, ou du navigateur web Firefox, qui ose (enfin !) remettre en question le monopole d’Internet Explorer. Inutile également de s’appesantir sur la progression fulgurante des serveurs d’application Open Source (PHP, Tomcat, JBoss, etc.) ou de vanter les mérites d’Apache, qui détient près de 70 % de parts de marché parmi les serveurs web.
Tout le monde aujourd’hui « sait » que les logiciels libres sont moins chers, plus fiables et plus flexibles que leurs équivalents propriétaires et qu’ils redonnent une indépendance aux équipes informatiques. Bref, l’Open Source, c’est « in », et tant pis pour ceux qui n’ont pas pris le train, ils le paieront tôt ou tard.
Et pourtant… Nombre de sociétés, de toutes tailles, n’ont pas franchi le cap et persistent dans l’utilisation de produits éditeurs. Il y en a même (nous en croisons tous les jours) qui choisissent encore de démarrer des projets sur des technologies propriétaires et fermées. C’est que, malgré tout, l’Open Source continue de susciter des inquiétudes et des interrogations.
Pourquoi il ne faut pas avoir peur du libre
Généralement, les raisons invoquées à l’encontre de l’Open Source sont de trois ordres :
-# absence de support de la part d’un éditeur ;
-# inquiétudes liées à la pérennité du produit ;
-# incertitudes autour de la licence.
Reprenons point par point ces arguments et voyons s’ils sont fondés.
Le support
La question du support est essentielle lors de l’acquisition d’un programme informatique. Tout le monde rêve de logiciels simples à installer, à configurer, à utiliser et se mettant à jour tout seuls, mais malheureusement la réalité est toute autre : il y a toujours des bogues ou des failles de sécurité à corriger, sans parler des « killer features » apparaissant dans les versions ultérieures. Aussi, l’entreprise qui dispose d’un logiciel doit avoir un interlocuteur prêt à le faire évoluer.
Or, dans le cas d’une solution éditeur, la réponse est simple : soit celui-ci assure lui-même le support, soit il faut passer par un partenaire ; mais dans tous les cas, on est sûr de ne pas se retrouver dans une impasse.
Lorsqu’on choisit de partir avec une application Open Source, deux cas de figure se présentent :
– soit le projet Open Source est soutenu par un éditeur (comme c’est le cas pour les distributions Linux RedHat ou Mandriva, la base de données MySQL, le serveur d’applications JBoss et d’un nombre toujours plus grand d’applications) qui assure des prestations de service et de support (c’est même précisément ce qui le fait vivre), et on est alors dans la même logique que pour un produit propriétaire ;
– soit le projet n’est soutenu par aucun éditeur (cas de tous les projets de la fondation Apache notamment, mais aussi d’une multitude d’initiatives isolées), et dans ce cas il faut avoir recours à un prestataire de service qui fera office de support, sauf si le service informatique interne est en mesure d’assumer ce rôle. A noter que cette dernière éventualité n’est pas à écarter d’office : la plupart des projets libres « vivants » se caractérisent par une communauté active d’utilisateurs et de développeurs, ainsi qu’une documentation abondante, facilitant leur appropriation.
Dans tous les cas, la logique est différente entre un produit éditeur et un produit Open Source : si l’éditeur s’engage généralement à corriger les anomalies bloquantes détectées (le plus souvent moyennant finances et dans des délais prédéfinis), le support Open Source n’impose que rarement des obligations de résultat, le prestataire s’engageant seulement à répercuter les corrections apportées par la communauté. Ce qui ne veut pas dire que le support sera de moins bonne qualité : on constate en général que les communautés Open Source sont beaucoup plus réactives que les éditeurs…
La pérennité
Deuxième argument souvent dressé à l’encontre des logiciels libres : la pérennité des produits. C’est à mon sens le moins fondé des trois : on ne compte plus les exemples d’éditeurs ayant abandonné une solution, soit qu’ils aient décidé de recentrer leur activité, soit qu’ils se soient fait racheter, ou bien encore qu’ils aient tout simplement mis la clé sous la porte. L’exemple le plus parlant est sans conteste Netscape, qui n’a vu sa survie que grâce à la mise en Open Source de son navigateur, devenu depuis Firefox et rencontrant le succès que l’on sait.
Alors, cela ne veut pas dire que les logiciels libres sont plus pérennes que les logiciels propriétaires, loin de là : on ne compte pas non plus les innombrables projets libres qui sont laissés à l’abandon. Il y a toujours une grosse part d’incertitude quant à la pérennité d’une solution sur deux, trois, cinq ou dix ans. Mais il est plus facile d’évaluer le risque avec un produit libre qu’avec un produit éditeur :
– la pérennité d’une solution éditeur dépend souvent de la survie de cet éditeur, ainsi que de contraintes économiques ou politiques qui peuvent être totalement extérieures au produit (l’opinion courante qui consiste à croire qu’il est plus pérenne de partir sur une solution portée par un gros éditeur est infondée : les gros éditeurs abandonnent aussi des produits, ainsi Visual Source Safe de Microsoft, délaissé au profit de Team Foundation) ; au contraire, la survie d’une solution Open Source est beaucoup plus liée aux qualités intrinsèques du produit ;
– la taille et la vivacité de la communauté d’utilisateurs et de contributeurs sur un projet Open Source donne une bonne indication quant à sa pérennité, chose que l’on peut plus difficilement mesurer avec une solution éditeur ;
– enfin, la viabilité d’une solution est fortement liée à sa solidité technique, que ce soit pour un logiciel libre ou éditeur ; or cette solidité n’est appréciable que lorsqu’on a accès aux sources (même s’il faut reconnaître que très peu d’intégrateurs le font réellement, ce qui est regrettable).
La question de la pérennité se pose donc dans les mêmes termes pour une solution propriétaire et pour une solution Open Source. Mais elle est généralement plus facile à apprécier dans ce deuxième cas.
La licence
Précisons d’emblée qu’il n’y a pas une licence Open Source, mais plusieurs centaines ! Les seuls points communs entre toutes ces licences sont :
– la mise à disposition gratuite du produit[[En théorie, rien n’interdit de vendre un logiciel libre, mais étant donné que n’importe qui a le droit de le mettre à disposition gratuitement, un modèle économique basé sur la vente de logiciels libres n’est pas viable. Les sociétés spécialisées dans le libre vendent généralement des services autour de logiciels libres.]] ;
– la possibilité de modifier le code source.
La plus connue (et la plus répandue) est la licence GNU GPL (General Public License). Elle contient une clause obligeant l’utilisateur à redistribuer aux utilisateurs toutes les modifications qu’il apporte au logiciel, et c’est généralement ce qui fait peur aux entreprises, qui ne souhaitent pas étaler sur la place publique des informations pouvant se révéler précieuses pour leurs concurrents. D’autant plus qu’à partir du moment où seulement une partie d’un programme utilise du code placé sous GPL, automatiquement tout le reste du programme se trouve « contaminé ».
En réalité, ce qui apparaît lorsqu’on lit soigneusement la GPL, c’est que cette contrainte n’est valable qu’à partir du moment où l’application est diffusée à des tiers. Or il est rare qu’une entreprise distribue son programme à d’autres entités. L’utilisation au sein d’une application web, par exemple, n’est pas assimilée à de la « diffusion » [Voir à ce sujet la [FAQ de la licence GPL.]].
Le seul cas où la GPL peut être trop contraignante, c’est lorsque justement l’utilisateur souhaite distribuer son programme (le vendre par exemple). Dans ce cas, il est dans l’obligation de mettre à disposition les sources également.
Mais si la GPL couvre aujourd’hui une majorité de logiciel libres (dont tout le système d’exploitation Linux, notamment), il faut préciser que nombre de projets utilisent d’autres licences (les licences Apache, Mozilla, FreeBSD, etc.) qui n’ont pas cette vertu « contaminante » et qui n’obligent pas à rendre publiques les modifications, quel que soit l’usage qui est fait du programme.
Quoi qu’il en soit, il est primordial de bien se renseigner sur l’adéquation de la licence à ses propres besoins avant de se lancer dans les développements.
Pourquoi il ne faut pas faire le choix du libre
Je sens parmi mes lecteurs comme un soupçon d’étonnement : après toute cette démonstration visant à prouver qu’il ne fallait plus avoir peur des logiciels libres, il va maintenant nous convaincre qu’il ne faut pas les utiliser ? Ca sent l’arnaque de consultant, la manipulation n’est pas loin… Rassurez-vous, le but de mon propos n’est pas de vous prouver tout et son contraire : si je pense qu’il ne faut pas craindre les logiciels libres, c’est qu’à mon sens ils peuvent réellement apporter un plus aux entreprises.
En réalité, ce titre volontairement provocateur doit être compris ainsi : aujourd’hui, il ne faut pas « faire le choix » du libre, c’est à dire décider de passer au libre parce que le libre c’est bien, c’est dans l’air du temps et ceux qui n’ont pas compris ça ne sont plus dans le coup. Non, le libre ne doit pas être vu d’un point de vue idéologique, dans le contexte d’une entreprise en tout cas (si ensuite vous choisissez de privilégier les logiciels libres à titre personnel parce que vous voulez promouvoir l’esprit de partage et de liberté transfrontaliers, cela ne regarde que vous – personnellement je n’utilise que des logiciels libres depuis des années !). Bref, aujourd’hui, on ne doit pas décider de « passer au libre », mais plutôt choisir pour chaque besoin la solution la plus appropriée, qu’elle soit libre ou propriétaire.
Le risque idéologique
C’est qu’un choix trop précoce, que je qualifie donc d’idéologique, par opposition à un choix argumenté et pragmatique, peut se révéler catastrophique.
Prenons un exemple : dans le domaine de la gestion de contenu web, deux technologies prédominent aujourd’hui : Java et PHP. Le choix de l’une ou l’autre de ces technos est impactant sur le système d’information dans sa globalité : infrastructure, compétences, intégration d’applications, etc. Il intervient donc souvent en amont, devenant du coup un pré-requis pour le choix de la solution de gestion de contenu. Or, ceux qui connaissent un peu ce secteur savent que si, dans le monde PHP, il existe de très bon outils Open Source (SPIP, Typo3, eZ publish, etc.), en revanche, en Java, les meilleurs produits sont propriétaires (Noheto, Vignette, Jahia, etc.). Il existe bien des projets libres (Lenya, eXo Platform, Graffito, etc.), mais ceux-ci n’ont pas encore atteint le niveau de leurs concurrents éditeurs. Décider par avance de partir sur une solution Open Source en Java risque d’engager des coûts de développement bien plus importants que les coûts de licence des outils propriétaires.
Bien sûr, il arrive que ce choix de « passer à l’Open Source » émane d’une directive groupe ou ministérielle. Mais les directives bien écrites sont celles qui préconisent le choix de solutions Open Source, sans pour autant fermer la porte aux éditeurs. Et, dans le cahier des charges, il est préférable d’écrire que les solutions à base de logiciels libres seront privilégiées plutôt que d’imposer ce choix à l’avance. Seule une analyse précise des besoins et des réponses apportées par les solutions, tant sur le plan fonctionnel, technique, qu’économique, pourra en définitive permettre de trancher.
Comparer libre et propriétaire
Tout cela est bien joli, mais beaucoup doutent de la simple possibilité de comparer un produit libre avec un produit éditeur. Autant, sur le plan fonctionnel et technique, cela ne pose aucun problème, autant, sur les aspects économiques, les choses ne sont effectivement pas si simples.
C’est que généralement, les grilles de critères élaborées par les consultants sont adaptées aux solutions éditeurs. Comment évaluer le vendeur d’un logiciel, quand celui-ci n’existe pas ? Ou la réactivité du support lorsque celui-ci est (indirectement) assuré par une communauté ?
Par ailleurs, ces fameuses grilles de critères font souvent la part belle à tout un tas de « nice-to-have features », autrement dit des fonctionnalités un peu « gadget » qui ne sont absolument pas requises, mais qui pourraient éventuellement apporter un petit plus. Elles ne devraient intervenir dans le choix que dans un second temps, une fois que les fonctionnalités vraiment nécessaires ont été évaluées. Le problème, avec les solutions éditeurs, c’est qu’une part importante du budget est consacrée à ces touches plus marketing que vraiment utiles, et les décideurs se laissent parfois séduire par des équipes commerciales habiles. Alors que c’est un aspect totalement absent des logiciels libres, pour lesquels on peut être sûr que chaque fonctionnalité implémentée répond a un besoin réel. Mais lorsqu’on regarde de haut la liste des fonctionnalités, c’est sûr, la solution éditeur semble plus attractive !
Bien souvent, une telle analyse fait ressortir la solution Open Source comme étant a priori moins coûteuse que la solution propriétaire, mais plus risquée. L’évolution va dans le sens d’une diminution des coûts des solutions propriétaires (ce, notamment grâce à la concurrence des logiciels libres), et d’une plus grande maîtrise des risques associés aux solutions Open Source (grâce à la multiplication des retours d’expérience).
Attention toutefois à ne pas tomber dans le piège qui consiste à croire que le libre est forcément moins cher que le propriétaire. L’analyse économique ne se limite pas aux seuls coûts de licence : il faut prendre en compte les coûts de développement, d’intégration, de support, mais aussi la pérennité, les évolutions, etc. Une telle analyse est généralement complexe à mener.
D’où la nécessité de se faire accompagner par des équipes connaissant parfaitement les deux mondes, capables d’évaluer la réactivité d’une communauté, de faire la part des choses entre les fonctionnalités vraiment utiles et les autres, etc. J’ai eu l’occasion de travailler récemment avec une équipe indienne, sur une mission de conseil devant aboutir au choix d’une solution. Les produits étudiés étaient tous propriétaires, sauf un logiciel libre (qui justifiait en fait ma présence au sein de l’équipe). La partie la plus difficile a été de convaincre les Indiens que l’on pouvait comparer des produits propriétaires avec des produits Open Source. Il a fallu se battre pour adapter la grille de critères, en la faisant davantage coller aux besoins réels du client (pour l’anecdote, ce dernier a finalement décidé de partir sur la solution libre, après un prototypage concluant).
{{L'{Open Source rentre dans le rang}}}
Finalement, tout ce discours tend à montrer qu’il ne faut plus pointer du doigt les logiciels libres en les présentant comme un phénomène en marge du reste du monde : ils ont atteint suffisamment de maturité pour « rentrer dans le rang ». D’ailleurs, pour les logiciels libres soutenus par des éditeurs, la distinction entre produit Open Source ou éditeur est subtile ; et de plus en plus d’éditeurs vont dans le sens de l’ouverture d’une partie de leurs sources, généralement les couches les plus basses (framework, formats d’échange, etc.), répondant ainsi à une demande croissante des utilisateurs.
Lorsqu’un projet s’annonce, il ne faut pas commencer par se poser des questions existentielles sur le choix d’une solution Open Source ou pas. Il faut simplement inclure dans l’étude préalable les solutions qui paraissent les plus intéressantes, qu’elles soient libres ou propriétaires. C’est l’analyse économique qui déterminera si « faire le choix du libre » est pertinent ou pas.