Developpez.com

Plus de 14 000 cours et tutoriels en informatique professionnelle à consulter, à télécharger ou à visionner en vidéo.

Java : un choix coûteux pour les entreprises ?
Oui, d'après un expert qui recommande de capitaliser sur les briques open-source

Le , par Idelways, Expert éminent sénior
Quinze ans après l’émergence de Java, David Duquenne, Directeur Génétal du groupe Open Wide Technologies (spécialiste de l'intégration et des l'exploitation des logiciels en France) fait un bilan du langage, qu'il trouve plutôt mitigé.
Un avis plutôt polémique.

Selon lui, Java n'aurait pas tenu ses promesses. Les projets réalisés à l'aide de ce langage auraient la réputation d'être « trop subtils pour les développeurs (sic), coûteux à réaliser et complexes à maintenir».

Le point de vue des Directions des Systèmes d'Information (DSI) serait, pour David Duquenne, sans appel : « prise en main longue et compliquée », « des compétences et une expertise coûteuses », des « architectes apprentis sorciers », un « écosystème technologique étourdissant ».

Bref, un constat qui ferait d'après lui regretter aux DSI les « bons vieux langages [...] complètement dépassés dans certains domaines, mais tellement plus productifs » et les pousserait à expérimenter des langages plus récents ou à explorer de nouveaux paradigmes tels que l'approche par modélisation (MDA) ou la programmation fonctionnelle dédiée.

Des solutions cependant pas suffisamment matures, toujours selon l'analyste, pour être industrialisées sur des projets stratégiques.

Sa solution ? Capitaliser sur des briques open-source proposant des réponses aux problématiques les plus courantes dans le développement d'applications.

« À condition toutefois d'éviter certains écueils » met en garde Duquenne, qui propose des conseils pour faire face aux défis de l'intégration Java comme la gestion du foisonnement de l'Open Source, la versatilité des composants, l'exploitation de la richesse ou l'évacuation de la complexité.

Les DSI qui préfèrent miser sur l'existant plutôt que d'investir dans leur propre « framework maison » seront ainsi confrontés à l’embarras du choix entre les milliers frameworks techniques Java et les dizaines de milliers de modules fonctionnels open source.

Leur but serait d'aboutir à un socle applicatif de qualité industrielle.

Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Autre solution, les entreprises peuvent s'essayer aux socles applicatifs fournis clef en main, qui peuvent être adaptés au contexte spécifique des projets de l'entreprise. Ces socles sont des distributions de composants Open Source intégrées dans une architecture applicative couvrant un périmètre plus ou moins important.

Les DSI doivent selon David Duquenne s'assurer de l'existence d'un support professionnel sur la totalité du socle applicatif afin de sécuriser la réalisation, la maintenance et l'exploitation des applications les plus critiques.

Le coût de ce support, mutualisé entre les entreprises utilisatrices du socle « restera plus économique que la maintenance d’un socle applicatif maison », affirme-t-il.

Le deuxième challenge serait de maintenir ce socle pour les 5, 10 ou 15 prochaines années au milieu d'un écosystème Java en constante évolution.

Cette évolution permet aux composants de devenir constamment plus pertinents et plus robustes et motiver l'apparition de nouveaux composants encore plus performants et innovants. Mais mal gérée, cette évolution peut aussi générer une versatilité désastreuses pour les systèmes d'information.

De plus, le rythme de ces évolutions est imprévisible et diffère pour chaque composant du socle applicatif.

Un composant peut aussi être abandonné, mais rester accessible sur Internet, devenant une sorte de bombe à retardement pour les applications. Ces composants doivent être en permanence remplacés ou maintenus par la société elle-même.

Duquenne met également en garde contre les ruptures technologiques introduites par une évolution majeure ou par le changement brutal d'une licence.

Pour se prémunir, le seul moyen serait d'anticiper ces risques par une veille technologique permanente et sensibiliser les directions sur les coûts (souvent mal vécus) de cette activité de veille sans rapport avec les enrichissements fonctionnels et métiers attendus par l’entreprise.

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Ce départ doit donc être anticipé en organisant un transfert de compétences au sein d’un contrat de maintien en condition opérationnel pour éviter la perte de la maîtrise du socle, ou pire encore, le désengagement technique des partenaires qui ne voudront plus travailler sur une plate-forme obsolète ou non supportée

La verbosité qui fait de Java un langage très structurant (garantissant la qualité et la portabilité des applications) rebute souvent les développeurs expérimentés sur d'autres langages et complique le recrutement et les budgets.

Duquenne recommande des solutions qui peuvent évacuer la complexité du Java et de son environnement comme le cadrage structurant les méthodes de développement, l’utilisation de Frameworks, l'intégration continue ou encore le recours aux approches agiles de gestion de projet favorisant les échanges d'informations et limitant la dépendance aux personnes clefs du projet.

Pour se faire, des socles applicatifs communautaires peuvent compléter les plates-formes avec une surcouche simplifiant le codage des applications, des générateurs de code et un cadre méthodologique.

Le discours de David Duquenne n'est cependant pas un plaidoyer anti-Java, au contraire :

« 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 », conclue-t-il. « 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 […] 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 ».

Source : Communiqué de presse : Open Wide Technologies

Et vous ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de CAML CAML - Membre averti https://www.developpez.com
le 14/03/2011 à 17:00
C'est pas parce que des personnes n'utilisent pas les "bonnes méthodes" que l'outil est mauvais.
Cet article revient à dire : y a pas de mauvais language, mais des mauvais programmeurs/analyste/etc...
Avatar de Gog077 Gog077 - Membre régulier https://www.developpez.com
le 14/03/2011 à 17:19
De toute manière le langage parfait adapté à toutes les situations n'existe pas. Je ne pense pas que ce soit un problème de Java ou pas. On pourrait faire le même discours sur le C# ou d'autres langages encore.
Avatar de willard willard - Membre à l'essai https://www.developpez.com
le 14/03/2011 à 17:38
Java couteux ? Je ne dirais pas ça .. c'est peut etre un langage trop verbeux mais je trouve que c'est ce qui fait sa force. Investir la dedans est clairement plus rentable que d'investir dans un langage bas niveau ou pire dans un autee paradigme.
Avatar de Rei Ichido Rei Ichido - Membre chevronné https://www.developpez.com
le 14/03/2011 à 17:45
Citation Envoyé par Idelways  Voir le message
Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Il faudrait détailler le "souhaité". L'émergence de beaucoup de frameworks est due aussi à la multiplicité des besoins ; est-ce qu'il propose une solution unique ?

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Honnêtement, quel techno ne subit pas ce problème récurrent du départ de celui-qui-sait ?

La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.
Avatar de BugFactory BugFactory - Membre éprouvé https://www.developpez.com
le 14/03/2011 à 18:07
Je ne vois pas ce que l'article de M. Duquenne apporte de neuf. Les atouts et travers de Java qu'il dénonce sont bien connus.

On va m'accuser de manquer d'impartialité étant donné mon investissement personnel dans Java. Néanmoins, ce même investissement me permet d'affirmer qu'aucune entreprise aujourd'hui ne se lance dans Java sans choisir soigneusement les frameworks à utiliser. Ces frameworks deviennent par la suite le standard de l'entreprise.

Si la majeur partie du texte me semble relever de l'évidence, d'autres me font bondir. Notamment ce qu'il dit sur les socles applicatifs.
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…

Très exagéré. A en croire cet extrait, créer un socle applicatif prendrait de 9 à 180 mois hommes! Le pire des cas reviendrait à 15 ans de travail avant même de commencer à programmer l'application elle-même. Hors on peut avoir un socle applicatif décent en assemblant Struts + Swing + Hibernate en quelques jours.

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).

Manque de clarté. Maintenir les applications réalisées aujourd'hui à l'aide de ce socle applicatif pendant quinze ans : bien sûr. Mais je doute que dans quinze ans, on souhaite commencer de nouvelles applications avec ce même socle.

En revanche, là où je suis entièrement d'accord, c'est sur la nécessité de ne pas devenir trop dépendant de son architecte. Ceci d'une façon très simple : prévoir deux jours pour que l'architecte forme l'équipe, et écrire un dossier d'architecture. Dans la pratique, même dans le cas où l'architecte est encore dans l'entreprise, je constate que l'équipe ne connaît pas l'architecture!

EDIT:
Le paragraphe précédent a été écrit avant même que Rei Ichido n'écrive :
Citation Envoyé par Rei Ichido
La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.

Comme quoi...
Avatar de Traroth2 Traroth2 - Membre chevronné https://www.developpez.com
le 14/03/2011 à 18:46
Bonjour les évidences ! Miser sur les briques open-source ? Il était temps qu'il découvre ça, en 2011, le gars ! IDE le plus populaire : Eclipse. Conteneur de servlet : Tomcat. Conteneur d'EJB : JBoss. Sans parler de Spring, Hibernate, etc. Et juste après, il parle du problème posé par le foisonnement de briques open-source, justement. Un peu contradictoire, non ?

Personnellement, je pense que ce foisonnement est justement une des très grandes forces de Java, ce qui en fait un langage avec lequel on peut (presque) tout faire ! Et c'est ce qui le rend aussi difficile à remplacer, aussi, comme on le voit maintenant avec les problèmes posés par l'arrivée d'Oracle aux manettes...
Avatar de Killing Joke Killing Joke - Membre actif https://www.developpez.com
le 14/03/2011 à 19:22
Je suis plutôt d'accord sur certains constats que ce Monsieur fait, mais pas sur le fond.
Pour les constats, oui, l'écosystème Java est parfois devenu un peu trop riche, trop verbeux, trop redondant (tant de librairies pour un même sujet mais pas une seule bien finie jusqu'au bout, etc.), même si çà dénote une forte implication de beaucoups d'acteurs.

Par contre dire que Java n'est pas productif en entreprise, là je suis scié. Il y a peu, dans ma boîte, on maintenait encore de vieilles applications en C, remplacées aujourd'hui par du J2EE. En terme de maintenance et de déploiement, il n'y a pas photo : les applications en C étaient une plaie niveau compilations, dépendances inter-modules, divergences entre plateformes, links avec les .so système ... tout un tas de sujet sur lesquels on a bien galéré (il y a encore pas si longtemps !), alors qu'on était quand même équipé, et qui ont totalement disparu avec Java (ouf).
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 14/03/2011 à 20:01
En même temps tout ça c'est bien vrai. Mais c'est valable pour toutes les technologies.

Le problème de l'architecture, ce sont les profils. Moi quand je lis une personne qui me dit qu'une architecture technique c'est quelques jours en spring/hibernate/strut, je me dis surtout que si Java à introduit une notion, c'est le dogme architectural.
Spring, c'est une des librairies les plus crades du marché, hibernate c'est probablement le framework le plus mal employé de la planéte et qui pose le plus de problèmes de perfs, et strut je ne commente même pas.
Je ne compte plus le nombre de développeur que j'ai vu se prendre les pieds dans le tapis avec la session hibernate, les select n+1, les mappings, les locks de thread sur les singleton spring, les transactions,les jar hell, les fichiers xml partout, ou la submission multiple en strut, la config de strut....

Oui une archi technique même en Java peut prendre du temps et couter cher.
Et il n'y a ni évidence, ni facilité. La plus grande erreur étant celle de prendre des composants open source (pour ne pas payer les outils) en se disant qu'ils font, sans maitriser le sujet qu'ils traitent (pour ne pas payer la formation)

Si les frameworks open source étaient si faciles à mettre en oeuvre et répondaient tant aux besoins fonctionnels, alors beaucoup de boites, dont spring et dont jboss ne gagneraient pas leur vie.
Avatar de DarkVenoM DarkVenoM - Nouveau membre du Club https://www.developpez.com
le 14/03/2011 à 20:08
Et dire que ce monsieur a une "solide" experience Java...
Ils nous conseille quoi au juste ? De faire les SI en ASP 3 ? En Ruby ? En PHP ? En C++ ? Et pourquoi pas en LISP ?

Je ne vois aujourd'hui quel langage de programmation permet de développer un SI avec plus de productivité que Java. C# rivalise mais c'est au prix d'un tarif salé et d'un choix de frameworks plus restreint. Justement, les choix des frameworks parlons en... Ils trouvent que le nombre de cadriciels en Java est étourdissant, et bien moi je me réjouit d'avoir du choix, je préfère passer du temps a choisir un bon framework plutôt que de me voir imposer une mauvaise solution sous prétexte qu'elle est unique. Ainsi en Java (pour faire la comparaison avec .NET, mais on pourrait le faire avec d'autres plateformes) , j'ai plus de choix en terme de serveurs, d'orm, de framework IHM, de framework d'IOC etc.... Java est peut être un choix coûteux pour les entreprises, mais ses alternatives le sont bien plus encore, et bien souvent elles laissent moins de latitudes aux dévelopeurs pour leurs propres choix techniques. Cette latitude permet aux développeurs d'avoir plus de chance de coller aux attentes du client en terme de coûts, de sécurité et de qualité.
Avatar de bugsan bugsan - Membre confirmé https://www.developpez.com
le 14/03/2011 à 21:07
Citation Envoyé par B.AF  Voir le message
Spring, c'est une des librairies les plus crades du marché

Wow...
Offres d'emploi IT
Consultant fonctionnel junior (H/F)
Atos - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Developpeur Delphi
Calame Software - Ile de France - Chatillon
Développeur .net c# h/f
BeMore - Provence Alpes Côte d'Azur - Sophia-Antipolis

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil