IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

49PARTAGES

5  1 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de ManusDei
Expert confirmé https://www.developpez.com
Le 15/03/2011 à 9:42
En gros l'article se résume à : "Y a plein de gens qui codent en Java comme des gros porcs, donc c'est le bordel de maintenir une appli Java."
9  1 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 16/03/2011 à 15:08
ce que je trouve amusant dans l'histoire ce que tu compare la création en access d'une application desktop pour 10 personnes à la création en java d'une application web pour 500 utilisateurs Donc j'aurais tendance à dire, 4 fois plus chere pour 50 fois plus d'utilisateur, donc 12 fois moins cher / poste.

Tu prends Eclipse, le JDK, Hibernate, Spring, et strut et PostGre / MySql / Firebird. totalement inutile et déplacé pour une si petite application.
Tu résouds les dépendances. Tu cherche tes plugins -> plus besoin cf ci-dessus
Si t'es rodé, tu prend 5 minutes pour installer un plugin maven. Voilà, t'es paré à travailler en 20 minutes. Pour la db, si t'as besoin d'un db pour ça, un H2 embedded et ça roule.

Tu achétes un serveur d'application linux. 3000 €; linux est "gratuit". Si t'achète un serveur linux, la comparaison aurait voulue que tu acheter un serveur windows de l'autre coté. Donc pas de serveur, c'est une application desktop, c'est gratuit
Tu payes une license pour virtualiser (serveur de prod; serveur de test). 500 € Pas de serveur, pas de virtualisation, toutjours 0€
Tu achètes un serveur Linux pour mettre un SVN. 1500 €.Quand bien même tu en aurais eu besoin -> c'est un investissement unique pour toute ta SISI pendant des années, ca nécessite peu de matos, et de toutes façons, tu ne l'a pas mis plus haut, donc retiré de la comparaison, 0€
Ca fait 1 semaine pour la commande; 3 jours pour l'installation. Rien à commander, rien de compliqué à installer, on est à 30 minutes de temps de dev pour le moment
Tu installes Tomcat. Avec la sécurité et toukivabien et tu te donnes du temps pour tester la sécurité. 2 jours N'existe pas-> 0 minutes.(Et un tomcat s'installe en 20 minutes, (juste à dézipper et c'est prêt), seule ton application devra éventuellement être sécurisée)
Mais tu veux des tests. .... 2 jours ->T'as pas mis de test automatisé dans ta version access. Si tu peux travailler comme un cochon, moi aussi-> 0 jours.
Tu commences alors à développer des écrans. Tu fais du strut. 4 jours. Tu fais une appli destkop, 4 formulaires. Si le client est pas chipoteur sur la position des champs, un formulaire se dessine en 2 heures avec matisse + 2 heure pour faire les requetes JDBC derrière. -> 2 jours (et pour info, des formulaires JSF sur des EJB3, c'est pas plus long quand tu connais)
Tu te demandes comment faire les rapports ? Je prend jodreport, je prend le template que m'a envoyé le client en .doc, et j'y met les instructions d'insertion. 1 jour par rapport parce que je suis spépieu. Au passage je rend les odt au client, comme ça, si il veux, il peux les changer n'importe quand sans avoir besoin de moi.

Maintenant, si nous reprenons l'exemple access: tu peux facilement me compter 3 à 4 jours par formulaire personnellement. Et le même pour les rapport. Non Obstant l'utilisation de technos inutile dans ton exemple, je suppose que les temps que tu donne sont fonction des tes connaissance en java. Les formulaire et la config hibernate / test / JSF et autres, ca va beaucoup plus vite quand tu l'a déjà fait quelque fois. Et struts / JSF c'est pas comparable, tu va facilement 2 à 4 fois plus vite avec JSF

Bref, si on dois comparer, comparons des choses comparables à compétence équivalentes. T'es surement capable de réaliser ça en 4 à 5 jours sous access, je suis tout à fait capable de tenir les même délais en java
8  0 
Avatar de gagaches
Membre confirmé https://www.developpez.com
Le 15/03/2011 à 10:50
moi, perso, ce qui me fait rire, ce sont vos commentaires ...

vous restez tous dans vos carcans d'archi n-tiers Java/C++/C# (python, ruby,...)

je ne veux pas dire "à l'époque", mais le COBOL ça marchait pas si mal.

Et j'ai sous le coude 3 gros projets conséquents de grands comptes qui ont fortement perdu en productivité/performance en passant de mainframe à J2EE.

Mais c'est sûr, J2EE, c'est tellement

Pb de gestion globale : choisir une nouvelle techno sans proto, sans budget, sans suivi, sans investissement dans la formation, et en prenant des frameworks "qui font le café" mais qui sont pas adaptés et tout ça en 40jours, hophop, c'est forcément

Au niveau transactionnel, des langages comme COBOL sont bien plus rapides & productifs qu'un équivalent en couche métier Java.

=> un langage web pour la présentation (web services), un langage transactionnel pour la couche métier, ... c'est trop demandé ?
ie utiliser chaque langage dans ce pour quoi il est adapté plutôt que de vouloir tout faire en un seul langage inadapté !
7  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 15/12/2011 à 17:49
En dehors de tout ça, pour répondre à la question java, choix coûteux ou non. Je dirai que oui, c'est coûteux voire très coûteux par rapport à d'autres technos.
Principalement je dirai à cause des learning curve de la plupart de ces frameworks, y compris (voir surtout) le standard.

J'ai fait pour la première fois du java orienté web en 2007, et j'ai salement galéré avec mon JSF de l'époque. Déjà parce que quasiment tout sur cette techno était mal pensé, stupide et inutilement complexe (je peux développer avant que vous fassiez pleuvoir les -1), mais aussi parce que j'ai du apprendre ce que c'était qu'un serveur d'application, comment ça se configurait, ce que c'était que des servlets et tout ce XML.

Lorsque je cherchais de la doc, ça ne semblait jamais correspondre à ma situation, ou alors c'était des frameworks différents, des versions différentes.... Bref, faire du java c'est pas seulement savoir coder du java, mais aussi connaître un peu l'écosystème et les stacks applicatives sur lesquels les applications s'appuient. Et là il y a beaucoup à savoir.

Si je prends son concurrent, à savoir .Net, on arrive bien plus facilement à un résultat car ça se disperse moins dans tous les sens, il y a un IDE de référence, un serveur de référence et on trouve plus facilement de l'aide car ce monde est plus homogène. Essayez pour voir de faire un webservice en .Net sous visual studio, ça se fait en 3 clics et demi et on se pose pas la question de savoir si on va utiliser Axis, Jax machin ou autre et on est sûr d'avoir fait juste du premier coup même si on connaît rien à IIS, WSDL et tout ça...

En comparaison, je pense pouvoir dire en toute sincérité et sans troll que c'est beaucoup plus dur de débuter le monde serveur/web en java que sur quasiment tous les autres langages que je connais. Que ce soit Php, python ou .net.
Le monde du serveur en java permet de faire des choses très poussées, mais c'est clairement pas à mon sens le choix idéal pour construire un site traditionnel de contenu ou quoi que ce soit d'assez léger.

En gros, java c'est un certaine complexité qui met quand même du temps à s'apprivoiser. Il faut faire des choix (framework de présentation, conteneur, ORM) qui sont implicites sur d'autres technos et qui demandent du temps et du travail pour être compris et utilisés à leur plein potentiel. La doc a beau être abondante sur le net, on ne peut pas toujours s'en contenter et elle ne correspond pas toujours à la stack qu'on utilise.
Cependant il est vrai qu'une fois qu'on est plus à l'aise, qu'on sépare mieux les choses dans sa tête et qu'on a compris le gros du fonctionnement de la machine, on peut faire des choses très poussées.

Donc je résume, la boîte qui passe à java, ça va lui coûter cher surtout si comme 3/4 des entreprises elle renonce à mettre à disposition des moyens de formation au profit des "ptits tutos sur le web". Elle devrait être sûr que c'est nécessaire et que ça lui apporte quelque chose par rapport à du plus simple.
Quelque chose ça peut être le multiplateforme qui peut être stratégique, les performances qui restent quand même très honorables, la possibilité d'être stateful avec des objets de scope server, caches, indexs en mémoire ou autres (ce qui par exemple pourrait être éliminatoire en PHP), la sécurité du code compilé et la richesse de l'écosystème.
6  0 
Avatar de 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.
5  0 
Avatar de BugFactory
Membre chevronné 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...
4  0 
Avatar de Traroth2
Membre émérite 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...
5  1 
Avatar de B.AF
Membre chevronné https://www.developpez.com
Le 15/03/2011 à 10:07
Je suis très d'accord avec le fait que le problème ne soit pas Java ou un autres langage mais son usage.

C'est un problème de gestion globale : techno open source = gratuit, développeurs juniors = bas prix.

A tout gérer par le coût direct le plus petit, faut pas s'étonner des défauts. Mais ça n'a rien à voir avec l'open source ou le Java. Ca peut arriver avec du C++ et du closed source.

Le problème de fonds, c'est qu'à force d'enseigner n'importe quoi, n'importe qui fait n'importe quoi n'importe où.
4  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 15/03/2011 à 11:05
"Il y a deux sortes de langages de programmation : ceux que tout le monde critique et ceux que personne n'utilise", Bjarne Stroustrup

A méditer...
4  0 
Avatar de 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.
4  1