Discussion :

[batataw]

EJB ? Annotation ? Tests ? Couches ? Multiplication des frameworks ?
Je suis ravi pour toi si tu peux aujourd'hui créer des bus de service sans overhead.

Là je n'ai pas compris mais c'est pas grave, çà dois être trop savant pour moi. Premièrement les questions que j'ai posées n'étaient pas là forcément pour que tu te jettes dessus. C'était plus pour ré-orienter le débat qui devenait trop technique par rapport au sujet initial.

Justement, quel est le point architectural de privilégier une exposition spécifique ou universelle ? Quels sont les risques ? Est-ce que le WS est la réponse ? Est-ce que l'EJB est un élément technique ou un élement structurant dans une architecture Java distribuée? Quelles sont les raisons qui devraient mener à choisir des Web services ?

Excuse moi mais si tu t'arrêtes sur chaque composant de Java, c'est sans fin. XML, REST, Couche TCP, SQL...voici ce qui a été abordés dans les posts précédentes. Franchement on s'éloigne du sujet. Après on peut toujours ouvrir une autre file pour en discuter.

Et quelles solutions si elles n'ont pas choisi QUE java ? Ce qui reste le cas majoritaire.

Ca mérite d'être approfondi, comment ce fait le choix d'une techno dans un S.I. CQFD le choix de Java dans notre cas.

Et ça n'a rien à voir avec la multiplication des frameworks dans l'architecture et l'approche technologique ?
Apprendre la persistence, c'est différent pour un guru SQL et un noob en développement, l'approche MVC est différente entre un architecte qui se penche sur le pattern et le développeur qui en utilise une implémentatio dans un framework. Pire que ça, il y a les design fondamentaux : API, Services, composants, programmation par convention, para / multithread...
Il y a aussi les contaminations entre les frameworks :
- Dépendances logicielles
- Multiplication des équivalences (n versions du même framework, ou de fraemwork équivalent mais liés à d'autres framework)
- Fermeture technologique (faut-il un framework qui fasse tout - spring - ou un framework dont les responsabilités sont définies - guice)
- Fermeture intellectuelle : faut-il n'utiliser qu'un ORM ou faut-il moduler l'approche en fonction des cas ?
....

Là on est dans le vif du sujet dommage que tu n'appronfondis pas

Concernant les performances, sur quelle base ??? C'est le doux rêve du benchmark universel.
La seule performance valable est celle d'usage. Je ne connais pas un seul vrai architecte qui sacrifiera la perf de l'appli au profit de modes architecturales douteuses. (Comme la prolifération des interfaces ou des aspects)

Sans aller jusqu'au Benchmark universel, on sait dire aujourd'hui chiffre à l'appuie si une solution est couteuse ou non. L'usage je veux bien mais il faut avoir quelques certitudes avant de se lancer sinon tes usagers vont s'étrangler devant leur clavier.

Question stupide. Coût du choix de l'architecture. Le coût du développement en Java lui même est économiquement non intéressant.
La vraie question de ce sujet est de dire : quel est le coût réel d'une architecture ouverte basée sur des frameworks hétérogénes et une architecture fermée basée sur un développement local. Quelle que soit la technologie. On ne fera pas du Web en C++, ni du calcul intensif en PHP, on ne fera pas de la progfonctionnelle en Java, on ne fera pas un client lourd en php....Sauf à considérer qu'il n'existe qu'une seule architecture viable qui existe pour ces 3 technos, voir pour toutes les technos, c'est juste une question polémique.

Quels avantages dans cette configuration offre la plateforme java ?
- Uniformité entre applications Java --> EJB
- Interopérabilité --> Web Services

Arf, c'est forcément à projet équivalent, ça va de soit non?
Ca valait le coût de comparer 2 projets équivalents et de voir les plus et les moins de chaque technos. J'ai eu des retours terrains parfois des gens qui ont regrettés d'avoir choisi tel ou tel technos.

C'est vrai que choisir Scala sur la JVM n'est pas technique et que de savoir qu'il y a une mode autour de ce langage est un point de très haut niveau dans une conception logicielle....

Oui cette question est plutôt technique mais t'es pas obliger de pondre du code tout de suite. On peut discuter de pourquoi ce langage existe, Java serait-il trop compliqué, trop verbeux ou inaccessible pour certains...

Non, le sujet, c'est au dessus de Java, c'est le coût réel des architectures objet basées sur des technologies libres / ouvertes.
Là où le sujet tombe à l'eau, c'est qu'aucun framework ne peut :
- Créer de la logique métier
- Anticiper un comportement métier
- Créer de la valeur fonctionnelle immédiate
Java n'a pas de défauts. Comme toutes les techno, il a son sweet spot et sa zone d'inutilité ou d'improductivité et ses manques. Java est et reste une technologie majeure, riche et fiable. Sauf que sa richesse devient son talon d'Achille dans le temps car c'est une richesse éparpillé car communautaire.

Java n'a pas de défauts, t'as tout dit là...le mec pond un article pour expliquer le contraire.

Avant de prendre de la hauteur, il faut savoir prendre du recul

Jolie formule, certains sont beaucoup trop près de leur clavier.

[B.AF]

Pour moi, il n'y a pas de gens trop proches ou trop loins du clavier.

Il y a ceux qui savent que pour faire une architecture optimale; il faut deux éléments :
- Le premier c'est la connaissance fonctionnelle nécessaire pour lever l'ambiguité de la modélisation métier
- La seconde c'est la connaissance technique nécessaire à orchestrer la modélisation métier dans un contexte d'utilisation.

Une plateforme n'a pas UNE architecture mais une somme d'architectures. Ce qui est important ce n'est pas que l'on puisse combiner les architectures, c'est que la conception soit centralisée.

Quand je dis que Java n'a pas de défaut, je le pense, je pense que le défaut c'est plutôt ceux qui s'en servent sans maitriser. C'est comme si on devait dire la langue Française a des défauts; alors que c'est dans l'usage qu'il y a des problèmes.

Quand tu parles Français, tu as le choix de parler verlan par exemple, mais ce n'est pas la bonne solution pour trouver un emploi et faire une bonne impression dans la société, en revanche, c'est possible, et les problèmes liés à l'usage du "Framework Verlan" ne sont pas dus à la langue française, mais à son contexte d'usage.

[B.AF]

Excuse moi mais si tu t'arrêtes sur chaque composant de Java, c'est sans fin. XML, REST, Couche TCP, SQL...voici ce qui a été abordés dans les posts précédentes. Franchement on s'éloigne du sujet. Après on peut toujours ouvrir une autre file pour en discuter.

Oui parce que c'est là qu'est le loup. Quand on aura un jour compris que Java ce n'est pas Spring, ce n'est pas Hibernate, ce n'est pas JBoss, ce n'est pas Tomcat, ce n'est pas Strut; ce sera une GRANDE avancée.

Java, c'est une technologie. Et tous les jours on méprend son usage (faire du java) avec son emploi (faire du java avec des frameworks tiers).

Utiliser Spring, ce n'est pas faire du Java. C'est faire du Spring. C'est une API particuliére, avec une fonction particuliére, ses bugs, ses fonctionnalités, sa sédimentation et surtout UNE vision de Java. Pas LA vision de Java.

Ce que je dis est très simple : aujourd'hui faire des Web services ou des EJB, ce n'est pas faire du java, c'est faire un choix technique d'usage en employant des API existantes. Si ces api sont incompatibles, ca n'invalide pas Java. Ca invalide juste le processus qui améne le choix.

Pour utiliser Java j'ai besoin de :
- Un éditeur de texte
- Le compilo

Pour le reste, je prends le parti de prendre le résultat du travail d'autrui (payé ou non) et de faire l'ingenierie par assemblage.

Le choix de l'IDE, du gestionnaire de source, du faire du JSF, du JPA, du JDO, du Seams, du Guice, du Clojure, du drools, du tarabiscotta; c'est mon choix de productivité Java.

Si avec le choix de la techno et des outils que j'assume je ne produis pas le bon résultat, c'est que le problème vient de moi en tant qu'architecte.
Soit je n'ai pas cerné le sujet, soit j'ai utilisé des composants que je ne maitrise pas, soit même j'ai choisi la mauvaise techno.

Mais au milieu de ça, je ne peux pas reprocher à Java d'avoir des défauts car ça voudrait dire que j'ai utilisé un techno fondamentale pour faire une architecture sans en comprendre les risques.

Et typiquement; ça veut souvent dire que le paradigme objet n'est pas correctement mis en oeuvre. Ce qui signifie aussi qu'avec un autre langage, le résultat serait strictement identique.

Et c'est aussi le défaut des vendeurs de techno : ils vendent la derniére techno comme étant la meilleure, tout le monde s'engouffre et les platres ne peuvent pas toujours s'essuyer.

[OButterlin]

Oui parce que c'est là qu'est le loup. Quand on aura un jour compris que Java ce n'est pas Spring, ce n'est pas Hibernate, ce n'est pas JBoss, ce n'est pas Tomcat, ce n'est pas Strut; ce sera une GRANDE avancée.

Java, c'est une technologie. Et tous les jours on méprend son usage (faire du java) avec son emploi (faire du java avec des frameworks tiers).

Utiliser Spring, ce n'est pas faire du Java. C'est faire du Spring. C'est une API particuliére, avec une fonction particuliére, ses bugs, ses fonctionnalités, sa sédimentation et surtout UNE vision de Java. Pas LA vision de Java.

Ce que je dis est très simple : aujourd'hui faire des Web services ou des EJB, ce n'est pas faire du java, c'est faire un choix technique d'usage en employant des API existantes. Si ces api sont incompatibles, ca n'invalide pas Java. Ca invalide juste le processus qui améne le choix.

Pour utiliser Java j'ai besoin de :
- Un éditeur de texte
- Le compilo

Pour le reste, je prends le parti de prendre le résultat du travail d'autrui (payé ou non) et de faire l'ingenierie par assemblage.

Le choix de l'IDE, du gestionnaire de source, du faire du JSF, du JPA, du JDO, du Seams, du Guice, du Clojure, du drools, du tarabiscotta; c'est mon choix de productivité Java.

Si avec le choix de la techno et des outils que j'assume je ne produis pas le bon résultat, c'est que le problème vient de moi en tant qu'architecte.
Soit je n'ai pas cerné le sujet, soit j'ai utilisé des composants que je ne maitrise pas, soit même j'ai choisi la mauvaise techno.

Mais au milieu de ça, je ne peux pas reprocher à Java d'avoir des défauts car ça voudrait dire que j'ai utilisé un techno fondamentale pour faire une architecture sans en comprendre les risques.

Et typiquement; ça veut souvent dire que le paradigme objet n'est pas correctement mis en oeuvre. Ce qui signifie aussi qu'avec un autre langage, le résultat serait strictement identique.

Et c'est aussi le défaut des vendeurs de techno : ils vendent la derniére techno comme étant la meilleure, tout le monde s'engouffre et les platres ne peuvent pas toujours s'essuyer.

Je suis d'accord sur le fond, il y a un problème d'assimilation du langage java avec les apis (EE/SE).

Je pense que java (langage) n'a pas de gros défaut, il a ses contraintes, comme d'autres langages ont les leurs.

Ce n'est pas java qui manque de productivité, le choix des outils par contre

[B.AF]

Je pense que java (langage) n'a pas de gros défaut, il a ses contraintes, comme d'autres langages ont les leurs.

En langage pur, non il n'a pas de gros défauts. Une grosse contrainte plus que défaut pour moi est la gestion des accesseurs et mutateurs. En revanche, sur le langage pur, les annotations et les enumérations sont super agréables à utiliser.
La gestion des exception est bonne aussi et permet de se poser des bonnes question plutôt que de trapper et de debugger constamment.
J'avoue que j'ai envie de voir les closures arriver car là Java prendra un tournant d'usage fabuleux.

Je pense que la vision d'un éditeur (qui pensera aussi au côté "bankable" de sa techno) devrait apporter du mieux sur les points de productivité.

[OButterlin]

Une grosse contrainte plus que défaut pour moi est la gestion des accesseurs et mutateurs.

Tu voudrais éviter de coder les accesseurs/mutateurs par défaut ou tu vois autre chose ?

[thelvin]

Ben disons que bof bof
Je ne nie pas la multitude des besoins mais je constate simplement que l'on a très peu, voir pas du tout de solutions tout intégrées comme on a pû avoir à l'époque des L4G. Et sans vouloir refaire des L4G, je trouve qu'il y a encore une marge entre les frameworks unitaires que l'on peut trouver et un semblant de liant entre tout ça.

J'adore. J'avais terminé en disant et qu'on vienne pas me dire "moi je dis juste que" et évidemment ça n'a pas raté.

Un prêté pour un rendu, voilà tout. Si ces solutions sont moins à la mode il y a des raisons. Certaines sont logiquement débiles (ou en tout cas fort de café du point de vue des concepteurs,) et d'autres répondent simplement à un besoin bien réél.
Quelque chose qui est bien intégré à lui-même est moins bien intégré au reste. Et l'absence réelle de besoin de s'intégrer au reste, ça n'existe que pour de petites applets. Le monde informatique n'est pas, actuellement, constitué de petites applets. Elles ne sont presque que des jouets sans autre rôle que divertir.

[B.AF]

Tu voudrais éviter de coder les accesseurs/mutateurs par défaut ou tu vois autre chose ?

Au niveau du langage oui; j'aime bien la notion de propriétés en .Net; je trouve ça plus élégant.

Après c'est vraiment dans l'implémentation dans les api que ça fera la différence (notamment en liaison de données). Typiquement en .Net, les propriétés sont un bon concept, mais l'implémentation d'INotify est vraiment lourde et enléve du charme. Un peu comme changeListener.

Typiquement j'aimerai (dans les deux cas)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
public interface IBeanBehavior
{
@AfterSet(Mamethode)
@BeforeSet(Mamethode2)
@BeforeGet(Mamethode3)
@AfterGet(Mamethode4)
@NotifyChange
double maProp{get;set;}
 
}
 
public class MonBean implements IBeanBehavior
{
public double maProp {private get;set}
}

A cela, j'aime bien le code de Google sur la programmation par contrat.
Mais ça permet de garder les pojo/poco les plus objets possible; et de déléguer les manipulations à un contrat de service; et si c'est de l'implémentation d'interface de pouvoir généraliser des comportements dans tout le design.
Bref, si quelqu'un veut la liste des drogue que je prends....

[professeur shadoko]

j'ai pas eu le temps de tout lire ... désolé.
Mais le document initial me navre ...
j'ai un point de vue très particulier:
- je suis formateur professionnel
- je suis suffisament agé (age de la retraite dépassé) pour avoir entendu ça sur à peu près n'importe quel langage ("de mon temps on faisait du solide on ne perdait pas de temps avec des abstractions d'intellectuels ")

de mon point de vue égoïste ce qui me navre c'est que quand on propose à un DSI de former ses équipes, d'avoir une politique de formation et de bien payer les bons programmeurs on est pris pour un martien!
curieusement ceux qui comprennent le message nous disent après qu'ils voient d'un autre oeil les aspects "couts global" du développement.
J'espère certes qu'un jour on aura encore mieux que Java mais les arguments avancés dans ce papier relèvent de jugements péremptoires un peu courts (j'emploie de doux euphémismes car je sens là un client potentiel !)

[OButterlin]

Bref, si quelqu'un veut la liste des drogue que je prends....

Ouaip, c'est d'la bonne !

Tant qu'on y est, j'aimerais avoir accès "automatiquement" au fait qu'une propriété est été changée, voir à la valeur précédente si possible...
quitte à ce que seules les propriétés implémentant Comparable soient prises en compte.

Un autre truc, plus spécifique, ce serait bien que lorsqu'un Entity étend une classe abstraite, les annotations de la classe abstraite soient traitées.
On vient de se rendre compte que ce n'était pas le cas (@PreUpdate @PrePersist...) mais là, on n'est moins dans le langage... enfin, je suppose...

[B.AF]

Dans le principe moi ce que j'aimerai c'est que l'on puisse faire des objets simples sans plomberie, et de pouvoir les décorer par des contrats de service.

En gros, considérer que la propriété est un service rendu par l'objet.

[batataw]

Pour moi, il n'y a pas de gens trop proches ou trop loins du clavier.

Il y a ceux qui savent que pour faire une architecture optimale; il faut deux éléments :
- Le premier c'est la connaissance fonctionnelle nécessaire pour lever l'ambiguité de la modélisation métier
- La seconde c'est la connaissance technique nécessaire à orchestrer la modélisation métier dans un contexte d'utilisation.

Une plateforme n'a pas UNE architecture mais une somme d'architectures. Ce qui est important ce n'est pas que l'on puisse combiner les architectures, c'est que la conception soit centralisée.

Quand je dis que Java n'a pas de défaut, je le pense, je pense que le défaut c'est plutôt ceux qui s'en servent sans maitriser. C'est comme si on devait dire la langue Française a des défauts; alors que c'est dans l'usage qu'il y a des problèmes.

Quand tu parles Français, tu as le choix de parler verlan par exemple, mais ce n'est pas la bonne solution pour trouver un emploi et faire une bonne impression dans la société, en revanche, c'est possible, et les problèmes liés à l'usage du "Framework Verlan" ne sont pas dus à la langue française, mais à son contexte d'usage.

Je vois ce que tu veux dire, j'ai deux remarques :

- La première c'est bien de Java et de son éco-système dont il est question dans l'article. C'est impossible de les dissocier. Personne n'utilise le notepad pour développer on est obligé de parler d'Eclispe ou de Netbeans. C'est aussi vrai pour les Frameworks, API, les conteneurs...

- Pour le langage je suis pas tout à fait d'accord, Java a des défauts dans le sens où on pourrait modifier des choses pour qu'il se bonifie. Pour preuve, Java au fil de ses versions apporte ces améliorations. Certaines améliorations sont bien syntaxiques. Et puis je l'ai déjà dit mais l'existence même de Scala au sein de projets professionnels est un signe fort à méditer.

[thiphoenix]

Bonjour à tous,

Je suis nouveau sur ce site, mais pas dans la profession, j'ai des années d'expérience dans le développement J2EE avec JBoss, Seam, Hibernate et Richfaces...

Il est vrai que la complexité du projet augmente avec le nombre de briques que l'on intègre. La difficulté d'intégration n'est pas non plus une moindre affaire. Il faut du temps, je dirais même beaucoup de temps avant d'utiliser correctement une brique qu'elle soit open source ou pas d'ailleurs.

Je pense quand même que Java/J2EE peut être un bon atout. Il ne faut tout de même pas négliger cependant les autres langages. J2EE permet vraiment de faire certaines choses très bien, mais il faut être réaliste, il reste limité dans les services "temps réel".
Pour ma part, il faut donc choisir le langage approprié au service que l'on veut rendre, on peut donc avoir plusieurs langages au sein d'un même projet que l'on relie en les interconnectant par le biais d'adaptateur.

Le développement d'un projet J2EE peut être très rapide mais peut être aussi très long.
Le nombre de compétence nécessaire est aussi très important. Il faut un spécialiste en base de donnée (même si hibernate le fait pas si mal que ça, mal configuré ou les beans mal écrit, c'est pas évident de toujours trouver l'erreur), un spécialiste en Java/J2EE et JSP/JSF, et un graphiste. Bien sûr, je parle de compétence, une seule personne peut les avoir toutes. De toute façon, cela a un coût qui n'est pas négligeable.
Je suis révolté à voir des programmeurs développer du code et toujours le même, alors qu'il suffit de développer ou d'utiliser des outils qui permettent d'ailleurs de rendre le code plus maintenable puisqu'il a été généré dynamiquement.

La maintenance d'aujourd'hui des projets Java représente un coût considérable, et je trouve cela complètement débile. Au jour d'aujourd'hui où les langages deviennent de plus en plus performant et de plus en plus complexe, on s'acharne à vouloir encore programmer à la main des algorithmes et des beans alors que l'on peut mettre en place des systèmes sémantiques permettant d'alléger la maintenance et le développement de tel projet.

J'ai justement créer une entreprise qui a pour but de développer ces systèmes.
Imaginer permettre à un graphiste de mettre en place le design directement sur la plateforme ou grâce à un kit. Imaginer qu'un ingénieur qui n'y connait rien en programmation puisse interconnecté 2 systèmes à priori incompatible sans écrire le moindre code.

Ah, ce beau jour, où les développeurs pourront se concentrer sur le développement de nouvelle application. Ils n'auront plus à réinventer la roue. Ce jour-là, le métier de développeur redeviendra un métier hautement respecté.

[tchize_]

Prenons de la hauteur donc. J'admet que java a pléthore d'outils pour faire plein de truc. J'admet aussi que mes connaissances en .net sont plus que limitées puisque je m'y met à peine. Mais c'est un fait dès qu'on entame le .net. Il y a aussi pléthore d'outils, tout n'est pas géré par la solution .net. Je ne suis pas à la moitié du tutorial de C#qu'on est déjà occupé de m'expliquer comment installer spring framework et Nunit, qu'on m'explique que si je veux un système de gestion automatique des dépendances j'ai besoin d'outils comme http://npanday.codeplex.com/, qui paradoxalement font tourner un maven en java . Que si je veux faire tourner mon application .net sous unix, je dois utiliser les ponts gtk.net ou qt.net plutot que l'api IHM fournie par windows, etc.

Java n'a pas l'apanage des outils annexes qui poussent partout. Ce qui compte c'est d'utiliser l'outil dont vous avez besoin et quand vous en avez besoin. Ce devraient être les besoins des développeur et uniquement eux qui détermine quel outils on fait rentrer dans l'application, car ce sont eux les bénéficiaires exclusifs de cet outil. Le client il s'en contre fiche de ce qu'ils ont mis comme plomberie. Ce qui lui importe c'est que la plomberie mise en place lui permet d'obtenir ce qu'il a demandé dans des délais raisonnables.

Et quand tu respecte ces règles simples, il n'y a pas de raisons que java coute plus cher que .net.

[tchize_]

mais il faut être réaliste, il reste limité dans les services "temps réel".

Il existe bien des JVM temps réel! Et celles-ci sont encadrées par une spécification précise. http://java.sun.com/javase/technolog...time/index.jsp

[B.AF]

Heu c'est plutôt Nuget que tu cherches en fait...

[dolby]

Si on veut comme souvent aller très vite dans la production avec des développeurs qui ne voudront pas prendre un peu de temps pour se former, effectivement Java est le mauvais choix. Mais dans une optique ou l'on veut améliorer de plus en plus la qualité du code que l'on génère au prix d'un apprentissage peut-être un petit peu plus long alors Java est un bon choix.
Toute le question est veut ton construire dans le temps ou veut t'on juste aller vite et vendre vite ! Je crois qu'il n'y a pas que sur le choix des langages que l'on peut avoir le même raisonnement !

[B.AF]

Si on veut comme souvent aller très vite dans la production avec des développeurs qui ne voudront pas prendre un peu de temps pour se former, effectivement Java est le mauvais choix. Mais dans une optique ou l'on veut améliorer de plus en plus la qualité du code que l'on génère au prix d'un apprentissage peut-être un petit peu plus long alors Java est un bon choix.

Ca n'est pas propre à Java. Tout langage est substituable.
C'est de faire de la qualité qui est le bon choix dans le temps.

[OButterlin]

C'est de faire de la qualité qui est le bon choix dans le temps.

Raisonnement de développeur...
Une société de service (la plupart) se fout royalement de faire de la qualité, elle veut vendre vite et à moindre coût.
L'intérêt de java et de sa plate-forme EE est de miser sur une technologie portable et durable, certainement pas pour sa facilité d'apprentissage... à moins bien sûr qu'on ne parle de langage qui lui est plutôt facile à appréhender.

[B.AF]

J'espére bien qu'en bossant dans l'informatique j'ai un raisonnement de développeur (et j'en suis fier).

Et ce n'est pas vraiment en développeur, mais en entrepreneur :
Faire de la qualité dans le temps ne fait qu'être moins orienté avant vente.

On peut encore vendre, à un prix cohérent et faire des choses correctes. Au contraire, tant qu'il y aura des SSII pour bosser comme ça dans mon secteur, je sais que j'aurai toujours du chiffre. Non seulement je suis sollicité sur des sujets plus "funky", mais en outre, j'ai une tarification qui est en moyenne 35% plus élevée minimum que les SSII.

Je ne vois toujours pas en quoi faire de la qualité coute plus ?
Disons plutôt la réalité :
La plupart des décideurs sont frileux et préférent payer peu longtemps, qu'investir (c'est à dire une mise de départ et un résultat rapide).
Effectivement dans le premier cas, on peut mettre 1 an avant de voir arriver l'échec.

Je trouve que ta remarque prouve bien que le culte du résultat est encore bien en retrait par rapport à celui du process.

Quand on veut réussir, il faut savoir prendre des risques, et cela inclue le risque économique.Et la compétence n'est pas liée exclusivement à la techno.