Gérer l'évolution des applications Open Source en entreprise

De nombreuses entreprises intégrent et adaptent des technologies Open Source en vue de raccourcir la mise en oeuvre de leurs projets, économiser en coûts de licences et standardiser leur infrastructure informatique. Cette politique ne va cependant pas sans soulever des questions quant à l'évolution des coûts de maintenances évolutive et corrective. Certes, la communauté s'en charge en partie ; mais quid en cas de nouvelle version du logiciel intégré et personnalisé ?

Trois spécialistes se sont exprimés sur le sujet sur le journal en ligne ZDNet. Il s'agit de Corinne Brunel (directrice d’Uperto, une filiale du groupe Devoteam), Nicolas Hoizey (directeur technique de la SSLL Clever Age) et Laurent Pierre (directeur technique de la SSLL Linagora) [1].

Bien choisir les briques Open Source

L'importance de choisir des briques populaires est tout d'abord mise en avant. La plus grande popularité du logiciel assure en effet des meilleures caractéristiques en matière de pérennité, de fiabilité et de sécurité.

En effet, soutenue par un grand nombre d'utilisateurs et de développeurs, un logiciel Open Source a plus de chance de survivre à la disparition de l'un d'entre eux. Si Linus Torvalds venait à disparaître, d'autres prendraient le relais, assurant la survie de l'application Linux à son créateur. Il n'en sera pas forcément de même pour une application Open Source maintenue par un seul homme entouré d'une communauté réduite. Les qualité de fiabilité et de sécurité des logiciels libres proviennent pour l'essentiel de la révision par les pairs. Cette dernière n'exclut bien sûr pas l'utilisation de méthologies et d'outils efficaces. Cependant, cette révision, permettant une identification rapide des bogues et des failles, demande un grand nombres d'yeux observant le code. Un logiciel Open Source développé par un seul homme ne sera pas forcément plus sûr ou plus fiable qu'un freeware (graticiel), par exemple. Les premières années du développement de PHP Nuke illustrent cette problématique (développement centralisé et plutôt fermé, architecture de base mal pensée, nombreuses failles de sécurité,...). A l'inverse, il faut penser que l'uniformisation des applications, tendant vers une certaine monoculture informatique, peut également conduire à plus de vulnérabilité, suite à des attaques à très grande échelle. La récente offensive virale (ver Santy [2]) contre les forums libres phpBB est à ce titre illustrative.

L'identification de ces briques efficaces et populaires peut être réalisée par un prestataire externe. Ce dernier peut également assurer le suivi de l'application. Afin de minimiser le risque de voir l'application personnalisée s'écarter progressivement de la version officielle libre, il est recommandable de reverser au maximum les modifications à la communauté. Rien ne garantit cependant que ces modifications par rapport à la version de référence du logiciel soient acceptées par la communauté. Il est donc recommandé de prendre contact au plus tôt avec la communauté, afin de lui communiquer les projets de modification. La cohabitation entre le système de publication Spip original et la version Spip Agora développée par le Service d'information du Gouvernement (SIG) illustre bien cette problématique du co-développement entre la communauté, d'une part, et de gros acteurs institutionnels, d'autre part [3]. La susceptibilité, les divergences d'objectifs, les problèmes de communication, les maladresses,... sont autant de raisons pouvant conduire à un fork, potentiellement dissipateur de ressources.

Par ailleurs, les logiciels libres et Open Source possèdent leur propre philosophie de développement. Les logiciels possèdant une pérennité optimale sont architecturés autour d'un noyau pauvre fonctionnellement, mais robuste et performant. Stable dans le temps, ce noyau est enrichi par des extensions qui évoluent à leur propre rythme et permettent aux entreprises d’enrichir les fonctionnalités du logiciel au gré de leurs besoins sans toucher au coeur [1]. Le logiciel libre Apache illustre bien cette philosophie, à ne pas chercher à contrer sous peine de fork. Qui se souvient, par exemple, que le succès des extensions Frontpage (logiciel aujourd'hui édité par... Microsoft) est dû, pour partie, à la création d'un module propriétaire pour le déjà populaire serveur Web libre Apache ?!

Les entreprises peuvent également se protéger des modifications d'API en créant leur propre couche d'abstraction. Notons cependant que l'utilisation de logiciels libres populaires assure une certaine stabilité de l'API. En effet, la stabilité des API des grands projets libres est encouragée pour, d'une part, ne pas gêner des projets tiers et, d'autre part, faciliter la distribution du travail et l'intégration ultérieure des multiples contributions. Cela n'empêche cependant pas toujours la fluctuation des API, problème déjà soulevé pour la bibliothèque multi-plateforme Gtk, par exemple.

Bien sélectionner pour mieux mutualiser

L'étape de sélection (et les précautions qui l'accompagnent) se révèle particulièrement importante dans une optique de mutualisation des développements.

Les entreprises viennent souvent vers l'Open Source pour des raisons de coûts (perspectives d'économies). L'ouverture du code est généralement une préoccupation secondaire. Cette ouverture permet cependant la mutualisation des efforts de développement entre plusieurs partenaires. Cette voie est intermédiaire entre le développement sur mesure (conduisant à une solution fonctionnellement adaptée mais souvent ruineuse en terme de coûts de maintenance) et l'achat d'un progiciel (véhiculant l'espoir d'un prix plus faible pour un produit adapté aux besoins du plus grand nombre).

Prometteuse, la mutualisation entraîne généralement une relation complexe entre la communauté qui édite le logiciel libre, le prestataire informatique et les entreprises clientes. Cette complexité n'a pas découragé de nombreuses initiatives, telles qu'IDX-PKI et Samba-LDAP chez IdealX. Utilisés par Gaz de France, les SMBLDAP tools sont maintenant intégrés dans la distribution Samba officielle. La pérennité et la maintenance de Samba-LDAP sont ainsi garantis par la large adoption de l’outil. Notons que le coût de l'intégration des modifications dans la version officielle du logiciel libre ne doit pas être négligé.

Procéder à des tests avant mise à jour

Une fois ces diverses précautions prises pendant le projet, il reste à s'assurer que les mises à jour de l'infrastructure se passeront bien. Les trois spécialistes interrogés par ZDNet [1] suggèrent dès lors de recourir, avant toute mise à jour :

• à des tests de non-régression
• à des tests de montée en charge
• à des tests unitaires

Les tests de non-régression et de compatibilité avec les autres briques utilisées sont facilités par le respect des standards caractérisant la plupart des logiciels Open Source. L'interopérabilité est en effet recherchée, ce qui n'est pas toujours le cas avec des logiciels propriétaires. Une plate-forme de pré-production doit cependant être utilisée pour tester l'ensemble du système. De même, la maîtrise de la totalité de la chaîne logicielle, du code source au déploiement, est un atout. Les tests unitaires permettront pour leur part de valider les fonctionnalités apportées par la nouvelle brique.

En plus des tests fonctionnels, des tests techniques de montée en charge et d'analyse de performances doivent être réalisés. Là aussi, le logiciel libre apporte des outils performants tels que OpenSTA [4] ou IDX-Tsunami [6].

Les multiples outils de communication mis en place par la communauté (listes de diffusion, forums,...) facilitent en outre les retours d'expériences. Cela permet d'anticiper les éléments critiques.

Sources :
[1] Carole Buret, Open source: 8 conseils pour maîtriser la maintenance des applications, ZDNet France, 19 janvier 2005.
[2] Santy.A
[3] Spip en pleine crise de croissance
[4] OpenSTA User Home
[5] Mutualisation des développements: une méthode de conversion à l'open source?
[6] IDX-Tsunami

Posté le 25 janvier 2005.