N'y allons pas par quatre chemins : l'Open Source est partout. Trouver un seul fournisseur informatique qui ne surfe pas sur la vague de l'Open Source relève du défi, que ce soit Linux, MySQL, Perl, ou l'outil réseau Snort. Où que l'on se tourne, les éditeurs majeurs tels IBM, Oracle et Sun annoncent des investissements massifs dans des projets Open Source et le développement en communauté. Sans oublier Novell qui change carrément de modèle. Même Microsoft s'y met.
Cependant, cet adoubement des fournisseurs par l'odeur des profits potentiels alléchés ne se traduit pas par une promenade de santé du côté d'utilisateurs, tout aussi intéressés par l'aspect pécuniaire e l'enjeu.
Reste que les modèles économiques autour de l'Open Source s'affirment, et ce qui a au départ sollicité quelques pionniers est en train de devenir une vraie révolution dans la façon d'envisager le secteur logiciel. S'il est naturel, et même conseillé, de nourrir un sain scepticisme face à l'Open Source aujourd'hui, le modèle Open Source pourrait d'ici quelques années devenir la norme, plutôt que l'exception.
D'où le dilemme pour les Responsables Informatiques : tandis que les vieux modèles et certitudes du monde logiciel commencent à céder, les fournisseurs informatiques doivent aussi revoir les moyens d'évaluer et de livrer les logiciels d'entreprise. De plus en plus, ces décisions vont faire appel à un nouveau savoir faire lié à l'écosystème du développement logiciel lui-même, bien au-delà du simple problème budgétaires.
Les bons comptes font les bons amis
La première question à laquelle il faut répondre est de savoir comment des entreprises comme IBM ou Oracle peuvent se permettre de livrer leurs logiciels gratuitement, méthode la plus couramment vendue pour expliquer le concept open-source. La réponse est simple : en fait, ce n'est pas exactement ce qu'elles font !
Petit retour en arrière. Pour de multiples raisons, le modèle de distribution des logiciels à l'unité s'adapte mal à l'informatique d'entreprise. Alors que les infrastructures deviennent toujours plus larges et complexes, les schémas de licences par utilisateur ou par UCT deviennent un vrai casse-tête. Les méthodes tarifaires alambiquées donnent des structures de prix qui ne reflètent pas fidèlement l'utilité réelle du logiciel, quand elles n'inspirent pas aux Directeurs de Services Financiers abasourdis une palanquée de méthodes comptables créatives.
Pour toutes ces raisons, des entreprises telles Sun ont résolument pris la décision d'abandonner le format de distribution à l'unité, en faveur d'un tarif à l'enregistrement seul. Le logiciel en lui même est gratuit. Les clients paient pour le support, la maintenance, et l'assistance pour l'intégration courants.
Les sceptiques diront que ce n'est qu'une autre forme de poudre aux yeux comptable. D'ailleurs, c'est vrai : à long terme, l'annulation d'un prix spécifique pour la licence ne signifie pas nécessairement que les clients économiseront de l'argent. Il importe cependant de noter que l'entreprise qui a franchi le pas vers la structure de l'enregistrement payant n'est qu'à un doigt de la prochaine étape de son évolution.
Le modèle logiciel d'enregistrement pour le support n'est finalement pas autre chose que le modèle du logiciel Open Source, tel qu'il tend à se développer aujourd'hui en entreprise. Il ne reste plus qu'à ouvrir le code - ce que Sun, entre autres, est exactement en train de faire (voir l'article Sun ouvre une ère nouvelle pour l'Open Source).
Les pionniers spécialisés, dont MySQL AB et Red Hat, ont élaboré des activités fructueuses en faisant payer le support aux entreprises pour des logiciels libres. Alors que des initiatives similaires se poursuivent et fleurissent, les éditeurs de solutions propriétaires sont donc tenus de se demander si l'intérêt commercial de garder leur code source verrouillé surpasse vraiment les autres avantages offerts par ce nouveau paradigme logiciel...
Compter les bons points des communautés
Pour les éditeurs de logiciels comme pour les clients, l'avantage clé de ce nouveau style de développement logiciel réside dans la communauté. La communauté impliquée dans un projet Open Source constitue son souffle vital (voir l'article Au MIT, des systèmes informatiques hétérogènes fonctionnent de concert grâce à l'Open Source). Un code logiciel, le meilleur soit-il, dépérira et stagnera sans le support d'un écosystème de développeurs actif, prospère et engagé. L'évaluation de ces communautés peut représenter pour la clientèle un défi de taille dans le processus d'achat des logiciels. La décision d'acheter tel ou tel logiciel professionnel propriétaire se résume souvent à la réputation de l'éditeur en question. L'évaluation d'un projet Open Source peut par contre impliquer des facteurs bien plus complexes encore.
Avant qu'une entreprise ne prenne la décision d'implémenter un projet Open Source, il est essentiel que son équipe informatique expérimentée étudie le projet de façon exhaustive. Comment s'organise la communauté de développeurs ? Selon quel modèle est-elle orchestrée ? Qui sont les contributeurs les plus actifs? Qui a le pouvoir de conférer les modifications, et à quelle fréquence cela a-t-il lieu ? Comment les conflits internes sont-ils résolus? Comment le code est-il mis sous licence ?
Le soutien d'un éditeur de logiciels majeur peut apporter du crédit supplémentaire à un projet Open Source aux yeux des utilisateurs professionnels, mais il peut aussi soulever de nouvelles questions. Par exemple, les équipes commerciales de l'éditeur peuvent appréhender la mise en place de la communauté de différentes façons. Certaines vont considérer qu'il faut laisser faire alors que d'autres peuvent forger l'espoir d'utiliser leurs communautés comme des réseaux de vente pour leurs services. En tant que client, il est préférable de rechercher les entreprises qui mettent en avant l'Open Source, tout en mettant une limite claire entre leur initiative Open Source et leurs efforts commerciaux.
Au final toute décision en informatique naît d'un problème métier. Résoudre ce problème reste la mission première pour tout éditeur informatique; en ce sens, les logiciels Open Source doivent être évalués en fonction de leurs fonctionnalités, de leur stabilité, de leur évolutivité, de leur sécurité, et de tout autre standard qui donne leur valeur aux logiciels propriétaires.
Ceci étant dit, la prolifération de l'Open Source résulte néanmoins d'un choix plus large. Les personnes les plus impliquées sur les projets sont les plus à même de faire ce choix, fortes d'une connaissance fine de la communauté et d'un ressenti de l'aboutissement d'un projet. C'est pourquoi un personnel informatique qualifié ayant une connaissance détaillée de la technologie reste plus que jamais un atout crucial pour la réussite de l'entreprise qui se lance dans l'open source. En cela, au-delà de l'apport en ingénierie, la communauté apparaît également comme un vivier, une véritable bourse aux compétences. Si tant est que l'aspect contributif ne soit pas remisé au second plan, l'un des risques majeurs auquel est aujourd'hui confronté le modèle. (voir l'article SSLL : l'approche contributive mise à mal par le principe de réalité de l'intégration)
Placées au plus près du client, ce sont en premier les intégrateurs, les Sociétés de Services en Logiciels Libres (SSLL), qui aujourd'hui soulèvent quelques questions. En ligne de mire : leurs contributions jugées trop réduites par les éditeurs."Il est vrai que les SSLL ne sont pas de gros contributeurs. Leurs métiers consistent davantage à fournir du service, de l'intégration et des développements autour de l'open source. Et en cela, l'apport des SSLL est intéressant", confie Benoit Sibaud, président de l'April (Association pour la Promotion et la Recherche en Informatique Libre).
Soutenues par l'association ASSLL, les SSLL sont plus de 70 en France. Un nombre croissant qui s'explique notamment par la maturité de l'offre. Mais également, par une sur-enchère sur le modèle open source notamment exercée par Oracle et Sun, qui se sont auto-proclamés meneurs du mouvement.
Une popularité à double tranchant toutefois : les SSLL doivent désormais composer avec les grosses SSII, qui s'ouvrent à leur tour à l'open source. "Les SSII viennent directement concurrencer les SSLL. Leur force de frappe, en terme de développement, recherche et effectifs est nettement supérieure. Dans ce cadre, les SSLL sont souvent reléguées au stade de sous-traitants d'une SSII, plus à même de gérer les gros contrats", explique Benoit Sibaud. Et de conclure : "les SSLL, plus limitées en ressources, ne font pas de la contribution leur priorité".
Les SSLL s'inscrivent dans une méthode tournée vers le client
Reste que le premier métier des sociétés de services est l'intégration. Et en cela, elles ne s'inscrivent pas dans une logique de conception logicielle. Pour Olivier Guilbert, PDG d'Idealx, SSLL et éditeur en solutions de sécurité open source, les SSLL ne travaillent pas sur un pied d'égalité avec les éditeurs. "Pour contribuer, on doit s'inscrire dans une roadmap", raconte Oliver Guilbert. Et d'enfoncer le clou, remettant en cause l'idée de la participation systématique : "On ne peut pas se décréter contributeur. Les SSLL s'inscrivent davantage dans une méthode tournée vers le client. Un éditeur vers le logiciel. Les SSLL arrivent avec des développements beaucoup trop spécifiques pour être reversés et inclus dans une roadmap".
Il est vrai que leur métier d'intégrateur pousse vers les développements très orientés métiers. Et c'est justement là que pourrait être leur force, nuance un responsable de chez Audaxis, SSLL Belge, spécialisée dans l'intégration de Compiere (PGI) fraîchement débarquée en France. "C'est la diversité des expériences d'utilisation [...] qui permettra de tester et de stabiliser au mieux l'outil." Soulignant ainsi que la contribution ne résiderait pas uniquement sur l'apport en ligne de code. "Dans le cadre d'un projet ERP open source, le développement de code n'est pas critique, il ne représente que 10% des efforts de développement." Dès lors, la contribution s'oriente davantage dans l'analyse, les tests et les corrections. "La contribution des SSLL aux tests et aux spécifications fonctionnelles est indispensable et bien plus importante que le développement de code. Car c'est la diversité des expériences d'utilisation de l'ERP (diversité des processus métiers, des tailles d'organisations, des volumes...) qui permettra de tester et stabiliser au mieux l'outil", avance Audaxis.
Un écosystème en pleine mutation
Le développement communautaire n'aurait cependant pas dit son dernier mot. Mais s'orienterait davantage vers des cercles d'éditeurs, que vers une communauté éparpillée. Plaçant entre leurs mains conception, maintenance et développement.
"Nous sommes en train d'assister à la naissance de communauté d'intérêts qui seront gérées par des éditeurs", raconte Olivier Guilbert. Et ne laissant au SSLL que l'intégration. Et dans ce cadre, en frontal des SSII, elles enregistreront un taux élevé de turn-over, et auront peut-être du mal à s'imposer comme autre chose que sous-traitant de sous-traitants...
InfoWorld : Que signifie l'accent mis dernièrement par Sun sur l'Open Source ?
Tim Bray : On peut illustrer ce que l'on croit chez Sun en disant que les avantages du concept font boule de neige. L'idée selon laquelle les logiciels constituent une grosse boîte noire onéreuse et hermétique, qui demande un gros cheque pour être livrée, installée et utilisée avant même de savoir si elle sert à quelque chose, devient de plus en plus rédhibitoire. Nous sommes persuadés que nous travaillerons mieux si nous levons les obstacles à l'utilisation des logiciels.
Mais il semble qu'il y ait d'autres moyens de lever ces obstacles que de donner le code source ; par exemple les versions de test des grandes bases de données professionnelles.
Et bien oui, mais cela ne résout le problème qu'à moitié. Il est possible de les télécharger et de les essayer. La plupart du temps, on ne voit pas le code source, si bien que l'on ne sait pas vraiment où l'on met les pieds. Il n'existe aucune communauté de personnes alentours qui ne connaisse vraiment le code source et comment il fonctionne. Et puis il y a ce budget des dépenses qui continue de gonfler au-dessus de votre tête. Vous décidez d'appuyer sur la gâchette et de le faire partir. Aïe! Il faut vous préparer à batailler pour gravir 8 échelons de hiérarchie avant de le faire valider !
Alors quelle est l'approche de Sun pour gérer une communauté? J'imagine que les clients sont sur la défensive et se disent que l'énergie qu'ils y mettent profite en fin de compte à Sun?
C'est difficile. Je pense qu'un élément clé consiste à ne pas essayer de la gérer. Si c'est une communauté qui en quelque sorte vous appartient et que vous orchestrez en toute transparence pour votre propre avantage, il est vrai qu'il va y avoir une résistance substantielle de la part des développeurs indépendants. Mais d'un autre côté, la communauté des développeurs a soif des possibilités d'influencer, modifier et orienter l'évolution du logiciel qu'ils utilisent. Autour de cette dynamique, il est possible de guider, d'influencer et de construire une activité. Mais si vous essayez de contrôler le tout, alors ça ne fonctionnera pas, tout simplement.
En tant que client, que dois-je prendre en compte pour évaluer les projets Open Source et leurs communautés?
Et bien, en fin de compte, vous avez un problème métier à régler, et vous devez avoir la garantie que le produit envisagé va le résoudre. Donc, une fois que vous avez vérifié l'aspect de base des fonctionnalités et des performances - crucial et essential - l'élément suivant à prendre en considération est de savoir si la solution est un bon pari sur le long terme. Je suis d'avis que l'un des facteurs les plus déterminants dans cette décision est la bonne santé, le dynamisme et la taille de la communauté de développeurs impliquée dans son développement.
Il semble donc que Sun a intérêt à soutenir les communautés les plus importantes, saines et impliquées qu'il soit?
Tout à fait, sans aucun doute.
L'équipe informatique de l'Institut de Technologie du Massachssets (MIT) doit être prête à travailler à partir d'à peu près tout. Elle est en charge d'un équilibre délicat, devant à la fois promouvoir les normes informatiques pour la sécurité et le travail en réseau, et laisser à chaque département la liberté de choisir ses plateformes et ses applications technologiques.
Bien souvent, les départements optent pour des technologies Open Source. Selon Patrick Jaillet, qui est à la tête du département Génie Civil et Environnemental du MIT, la principale raison se trouve dans la souplesse obtenue quand les équipes informatiques, les chercheurs compétents et les étudiants qui maîtrisent les connaissances peuvent modifier le logiciel en fonction de leurs desiderata. "Nous ne voulons pas que les gens sacrifient leur ingéniosité. L'Open Source est un avantage considérable" ajoute-t-il.
La technologie Open Source a aidé le groupe en charge des ressources informatiques distribuées du MIT à gérer les technologies des différents départements situés loin du service, tout en maintenant un ordre et un service de base sur le campus. "On peut facilement fournir de nouvelles fonctionnalités, selon les besoins nouveaux des utilisateurs" souligne l'analyste réseau Tom Coveney. Il explique que l'accès au code et à la structure des données brutes dans les logiciels Open Source facilite l'intégration des applications, comme la création de nouvelles applications. Par exemple le MIT est en train de développer un système commun de gestion d'identité qui intègre les différents portails et serveurs utilisés sur le campus. Ceci est possible grâce aux outils de développement Open Source, ainsi qu'à l'accès au code source. De même, le MIT utilise le système de téléphonie Asterisk connecté à une base de données et un portail Web pour donner les horaires des navettes sur le campus via Internet et via des messages vocaux interactifs.
Tom Coveney consacre la plupart de son temps au support des intranets et serveurs Web des départements ; il en assure le bon fonctionnement et la sécurité. Il aide également les départements à tirer le meilleur profit de leurs portails et serveurs. Il remarque que la plupart d'entre eux choisissent des outils de portail Open Source ; quatre d'entre eux utilisent la plateforme de développement et de gestion de portail Metadot.
D'autres départements utilisent Metadot sous Linux, d'autres sous Windows, d'autres enfin sous MacOS X. Cette diversité ne gêne en rien Tom Coveney pour tous les gérer. "Je peux changer de plateforme et utiliser le même logiciel" explique-t-il. Il lui est également possible de combiner des technologies de plateformes différentes dans Metadot, par exemple en utilisant le système de base de données FileMaker comme moteur de base de données du portail intranet d'un département dédié aux emplois du temps. Par conséquent, il peut prendre en charge les prés requis individuels des utilisateurs tout en travaillant depuis une base commune.
La souplesse pour les options de support constitue un autre avantage. "Nous ne dépendons d'aucun éditeur pour la maintenance" souligne Tom Coveney. Il évoque ce cas où l'éditeur d'un portail propriétaire dans un département avait fait faillite ; il avait fallu un an pour refaire le système. Il n'y aurait eu aucun problème de la sorte avec un portail Open Source parce que l'équipe informatique aurait pu compter sur la communauté pour un support en intérim, précise-t-il. De plus, il est plus facile de migrer d'un portail Open Source à un autre car en général ils utilisent tous la même plateforme LAMP, si bien que l'accès au code sous-jacent rend le déploiement plus facile qu'avec un système commercialisé en boîte noire.
Enfin, l'Open Source permet au MIT de gérer différentes boîtes à outils informatiques en toute transparence et en toute maîtrise. Si les entreprises en général serrent plus la bride sur le contenu de leur boîte à outils technologique que le monde universitaire, Tom Coveney remarque que l'hétérogénéité est un état de fait à peu près partout. Il mise sur l'Open Source pour faciliter la gestion de cette diversité.
Par Galen Gruman
