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 pallier les 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 elles-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’est-à-dire 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. 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 clé-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.
Absorber la versatilité des composants
Ces dernières années, les socles applicatifs maison ont été construits en intégrant les composants les plus reconnus, soit en s’appuyant sur une équipe d’architectes interne, soit en déléguant ce chantier à un prestataire. Une fois le socle applicatif terminé et livré, se pose alors la question de sa maintenance pour les 5, 10 ou 15 prochaines années (soit la durée des applications de votre SI).
La particularité de l’écosystème Open Source est qu’il est en constante évolution. C’est d’ailleurs l’un de ses principaux atouts, car en évoluant, les composants deviennent plus pertinents et plus robustes. Cet écosystème est aussi régulièrement enrichi par de nouveaux composants plus performants, voire plus innovants. D’ailleurs, bon nombre des récentes innovations dans le domaine de l’informatique sont issues de projets Open Source.
Mais, mal gérée, les conséquences de cette démographie versatile peuvent aussi être désastreuses pour votre SI, car le rythme de ces évolutions est imprévisible et diffère pour chaque composant de votre socle applicatif. Un composant particulier peut aussi être abandonné par sa communauté mais rester accessible sur Internet. La moindre anomalie critique devient une sorte de bombe à retardement pour vos applications.
Vous êtes alors condamné, soit à remplacer ce composant par un autre plus récent en minimisant l’impact sur votre patrimoine applicatif, soit à assurer vous-même la maintenance de ce composant désormais obsolète. À noter que vous pouvez subir ce même type de désagrément suite à une rupture technologique introduite par une évolution majeure, ou encore par le changement brutal d’une licence Open Source en une licence propriétaire.
Le seul moyen d’anticiper ces risques est d’assurer une veille technologique permanente par un ou plusieurs experts sur les forums, les blogs et autres sites communautaires. Cette capacité d’anticipation ne dispensant pas néanmoins de procéder à des opérations de remplacement, le moment venu. Il est clair que ces activités de veille et de maintenance des socles applicatifs ne sont pas neutres au plan budgétaire.
Ces coûts sont d’autant plus mal vécus par les directions, qu’ils sont mal compris dans leur nature technique et sans rapport avec les enrichissements fonctionnels et métiers attendus par l’entreprise. Ces coûts induits nuisent enfin à l’image de l’Open Source, souvent considérée à tort comme des ressources entièrement gratuites.
Survivre à son architecte
Mais au fond qu’est-ce qu’un socle applicatif ? C’est avant tout un assemblage de composants techniques proposant de cadrer la réalisation des applications tout en tenant compte des spécificités d’environnement propres à chaque entreprise. Afin de répondre au mieux aux exigences et aux contraintes spécifiques de l’infrastructure et du patrimoine applicatif existants, cette construction nécessite le savoir-faire d’un architecte justifiant de plusieurs années d’expérience dans la conception d’applications Java et l’utilisation de composants Open Source.
Toutefois, la phase d’architecture ne représentant qu’une étape nécessaire à la mise en œuvre d’un ou plusieurs projets, l’architecte est souvent un prestataire de haut vol intervenant de façon limitée dans le temps. En effet, une fois le socle applicatif stabilisé, le rôle de l’architecte n’est plus aussi déterminant. C’est sans doute pourquoi, les entreprises qui ont recruté leurs propres architectes ont souvent du mal à les retenir dans la durée.
En effet, les bons architectes puisent leurs motivations dans la résolution de nouveaux challenges techniques, leur permettant d’améliorer leur expertise. Les phases de maintenance induisent rapidement le sentiment de « végéter », d’où sans doute cette réputation de « diva », qui leur est souvent attribuée.
Quoi qu’il en soit, le départ de l’architecte du socle applicatif est bien souvent synonyme de perte de la maîtrise du socle. Cette perte de maîtrise peut rapidement se traduire par des difficultés ou des surcoûts de maintenance, voire même conduire au désengagement technique de vos partenaires qui ne voudront pas travailler sur une plateforme obsolète ou non supportée.
Ces écueils peuvent néanmoins être évités en organisant un transfert de compétences au sein d’un contrat de maintien en condition opérationnel (MCO) de votre socle applicatif dans la durée, ou en optant pour un socle applicatif communautaire supporté dont la maintenance est mutualisée.
Exploiter la richesse, évacuer la complexité
Les subtilités de Java en font un langage difficile d’accès pour un développeur fonctionnel. Ceci est encore plus marqué pour les développeurs expérimentés sur d’autres langages, souvent rebutés par la verbosité de ce langage très structurant. Paradoxalement, c’est cette verbosité qui permet de garantir la qualité et la portabilité des applications développées en Java.
De plus, l’intégration de nombreux composants Open Source pour la réalisation des projets accroît drastiquement les compétences requises pour les développeurs, et avec elles les difficultés de recrutement et les budgets.
Pour de nombreuses entreprises, la situation devient cornélienne lorsqu’elles doivent choisir entre former à Java ses développeurs internes maîtrisant le métier de l’entreprise et des langages plus anciens, ou externaliser la réalisation et la maintenance de ses projets stratégiques auprès d’un prestataire. Pourtant, des solutions existent pour évacuer la complexité du langage et de son environnement.
Les développements spécifiques en Java peuvent être industrialisés par un cadrage structurant les méthodes de développement et l’utilisation de Frameworks. Vous pouvez vous appuyer sur une stratégie d’intégration continue pour un suivi qualitatif de l’avancement de vos projets, ou encore recourir à une approche agile de gestion de projet favorisant les échanges d’informations et limitant votre dépendance aux personnes clés du projet, tout en augmentant votre flexibilité.
Enfin, vous pouvez utiliser, au moins sur une partie du code source, des outils de génération automatique et des tests associés.
Pour vous accompagner dans cette démarche d’industrialisation, certains socles applicatifs communautaires vont bien plus loin qu’une simple distribution de composants Open Source et complètent leur plateforme avec une surcouche simplifiant le codage des applications, des générateurs de code et un cadre méthodologique. Ils offrent les qualités d’un modèle éditeur traditionnel tout en capitalisant sur les bénéfices apportés par la richesse de l’Open Source.
Conclusion
La complexité du monde Java est réelle mais ses qualités, son ouverture et sa standardisation poussent à son adoption malgré les difficultés à bâtir et à maintenir son environnement technologique. Pour bénéficier des avantages de cet environnement, particulièrement bien adapté aux technologies de l’information, il est indispensable de capitaliser sur le savoir-faire et les retours d’expérience des composants Open Source qui le peuplent.
Au delà de l’économie d’échelle induite par l’approche communautaire, celle-ci vous permet de bénéficier d’une constante évolution, gage de fiabilité, d’interopérabilité et de respect des derniers standards.
Un des principaux freins à l’adoption d’une stratégie basée sur l’utilisation de composants Open Source pour une DSI est le foisonnement et la versatilité des solutions proposées. À l’instar de Linux qui s’est déployé sous forme d’offres packagées et supportées pour les entreprises (telles que RedHat et Ubuntu), les socles applicatifs Java intégrant une distribution opérationnelle de composants Open Source commencent à se faire connaître.
Pour les DSI, l’industrialisation et l’homogénéisation de leurs développements Java s’appuiera probablement sur ce type de solutions leur garantissant la pérennité de leurs développements métier et des économies par la mutualisation d’un support et d’une maintenance professionnelle. L’émergence d’éditeurs Open Source dans ce domaine est un signe encourageant de la maturité des socles applicatifs et une réponse adaptée aux DSI qui souhaitent investir sur leur métier, plutôt que sur la technologie qui les sous-tend.
Par David Duquenne, Directeur Général Open Wide Technologies