La logique voudrait que lorsque l'on crée quelque chose de nouveau, ce soit dans le but de remplacer une chose plus ancienne afin d'en étendre les fonctionnalités, d'en améliorer la qualité, d'en simplifier la prise en main ou d'en réduire le coût d'utilisation. Dans le cas du langage Java, le bilan est pourtant mitigé après plus de 15 ans d'existence.

En effet, les projets réalisés en Java ont la réputation d'être (trop ?) subtils pour les développeurs, coûteux à réaliser et complexes à maintenir. Ces dernières années, l'utilisation quasi systématique de composants Open Source a permis de réduire la facture par son approche communautaire. Mais attention aux pièges, sous peine d’en payer le prix.

(Mars 2011)

Une "prise en main longue et compliquée", des "compétences et une expertise coûteuses", des "architectes apprentis sorciers", un "écosystème technologique étourdissant". Le constat des DSI sur l'utilisation du langage Java est souvent sans appel, au point qu'elles regrettent parfois leurs bons vieux langages, peut-être complètement dépassés dans certains domaines mais tellement plus productifs. Certaines entreprises expérimentent des langages encore plus récents qui promettent à leur tour de palier aux carences et à la complexité du langage Java. D'autres cherchent à s'affranchir définitivement du code source en explorant de nouveaux paradigmes tels que l'approche par modélisation (MDA) ou la programmation fonctionnelle dédiée (DSL). Mais ces pratiques n'ont pas encore atteint la maturité suffisante pour être industrialisées sur des projets stratégiques. Une autre voie consiste à capitaliser au maximum sur des briques Open Source proposant des réponses aux problématiques les plus courantes dans le développement d’applications de gestion, à condition toutefois d'éviter certains écueils.

Gérer le foisonnement de l'Open Source

Le bon sens nous commande de nous appuyer sur des solutions déjà éprouvées plutôt que de "réinventer la roue". Ainsi, les DSI ayant choisi de réaliser eux-mêmes leur "framework maison" (comme cela a été le cas avec l'arrivée de Java) s’interrogent pour des raisons évidentes de coûts de maintenance et de pérennité de leurs investissements. Cela est d'autant plus naturel qu'Internet regorge désormais de composants (ou frameworks) répondant à quasiment tous les besoins d’une application de gestion. Ils sont eux-mêmes diffusés le plus souvent sous une licence Open Source garantissant ainsi une liberté d'utilisation à moindre frais pour les entreprises.

Mais trouver son bonheur dans ce foisonnement technologique est aussi un véritable casse-tête. En effet, rien que sur les forges Open Source les plus connues, pas moins de 1.500 frameworks techniques Java, plus ou moins matures, rivalisent pour grossir leur communauté respective d'utilisateurs, le buzz étant un des principaux critères de choix d'un composant Open Source. Ce nombre monte à plus de 20.000 composants si vous élargissez votre recherche à des modules fonctionnels.

Au sein d’une DSI, vous serez donc confrontés à l’embarras du choix. Une fois les composants sélectionnés, vous devez ensuite organiser leurs interactions sous la forme d'un assemblage technique en gérant l'hétérogénéité des interfaces de programmation. Avec l'aide d'un ou plusieurs experts techniques, il vous faut donc construire un cadre de développement qui servira de base homogène à la majorité de vos applications afin d'éviter de refaire ce travail de sélection et d'intégration au démarrage de chaque projet.

Pour réaliser un socle applicatif de qualité industrielle (c-à-d complété par des générateurs de code, une approche méthodologique et un processus structurant de développement), il est raisonnable de prévoir une phase d'une durée de 3 à 18 mois de développements techniques avec une équipe de 3 à 10 experts selon vos besoins : niveau d'intégration dans votre système d'information, simplicité de prise en main par vos développeurs, productivité et qualité attendue pour la réalisation de vos projets, criticité des applications pour votre entreprise…

On peut toutefois penser que les besoins identifiés pour votre DSI soient en grande partie identiques à ceux d'autres entreprises (connexion à une base de données, gestion des transactions, sécurisation des accès, suivi des performances...). Ainsi, si vous n'avez ni le temps, ni le budget pour construire votre socle applicatif personnalisé, vous pouvez vous orienter vers un socle applicatif fourni clef-en-main qui pourra ensuite être adapté au contexte spécifique de vos projets. Il existe d'ores et déjà quelques socles applicatifs Open Source garantissant leur prise en main et leur maîtrise par vos équipes techniques. Ces socles se présentent sous la forme d'une distribution de composants Open Source intégrée dans une architecture applicative couvrant un périmètre plus ou moins important selon les applications concernées. Mais attention, si vous ne voulez pas que vos développeurs passent leur temps à suivre les forums de discussion sans garantie de résultats assurez-vous d'un support professionnel sur la totalité du socle applicatif afin de sécuriser la réalisation, la maintenance et l'exploitation de vos applications les plus critiques. Mutualisé entre les entreprises utilisatrices ce socle applicatif communautaire restera plus économique que la maintenance d’un socle applicatif maison.