Discussion :

[ymajoros]

Ben non, on attend désespérément qu'un génie dans ton genre nous éclaire de son incommensurable connaissance... et pour le moment, on attend encore... à part être grossier, tu n'as rien démontré, tu avances des choses sans plus d'éléments pour les étayer, bref, tu fais exactement ce que tu reproches à l'auteur de l'article.

C'est un forum où on demande l'avis sur un article ? Je l'ai donné, mais tu aurais préféré du blabla condescendant pour dire que ce baratin est génial ? Je dis juste que l'avis de ce type n'est rien de plus qu'un avis (pourri en plus).

C'est à l'auteur d'argumenter, de montrer les recherches disant qu'il a raison, que tous les ORM ont un problème plutôt que le morceau d'Hibernate qu'il a vaguement compris, etc. Relis l'article original, il s’évertue juste à dire que d'autres sont contre les ORM mais qu'ils n'ont rien compris non plus. Et il réinvente une sorte d'ORM maison sous ce même prétexte (juste non standard et laborieux).

C'est quoi le but du forum ?

[Mingolito]

C'est un forum où on demande l'avis sur un article ? Je l'ai donné, mais tu aurais préféré du blabla condescendant pour dire que ce baratin est génial ? Je dis juste que l'avis de ce type n'est rien de plus qu'un avis (pourri en plus).

C'est à l'auteur d'argumenter, de montrer les recherches disant qu'il a raison, que tous les ORM ont un problème plutôt que le morceau d'Hibernate qu'il a vaguement compris, etc. Relis l'article original, il s’évertue juste à dire que d'autres sont contre les ORM mais qu'ils n'ont rien compris non plus. Et il réinvente une sorte d'ORM maison sous ce même prétexte (juste non standard et laborieux).

C'est quoi le but du forum ?

Au cas ou tu l'aurais pas compris "l'auteur" de ce billet n'est pas sur le forum, il y à juste eu une personne qui à relayé ce troll pour lancer un débat, et qui semble ne pas participer au débat non plus. Bref tu chie dans le vide.
Ce qui est dommage c'est que justement tu ne semble pas avoir compris l'intérêt d'un forum, à savoir de pouvoir débattre entre gentleman et échanger des idées et des témoignages, alors que apparement tu penses que un forum est un WC qui te sert à faire caca sur tous le monde. Après tout si ça peu te défouler amuse toi...

[masivelo]

La raison d'être d'un ORM est l'impedence mismatch entre l'object model et le relational model. Si l'approche objet serait accepté comme étant la meilleure pour la programmation, le fait de dire que l'ORM est une grosse erreur revient à dire que c'est le modèle relationnel même qui est une grosse erreur. Il faut dans ce cas trouver une autre façon de persister et interroger les objets avec au moins les mêmes performance que celle du modèle relationnel et on a même pas besoin de SQL-Speaking-Object !

[ymajoros]

Au cas ou tu l'aurais pas compris "l'auteur" de ce billet n'est pas sur le forum, il y à juste eu une personne qui à relayé ce troll pour lancer un débat, et qui semble ne pas participer au débat non plus. Bref tu chie dans le vide.

Merci de ne pas imaginer ce que j'ai ou non compris, c'est juste faux.

Ce qui est dommage c'est que justement tu ne semble pas avoir compris l'intérêt d'un forum, à savoir de pouvoir débattre entre gentleman et échanger des idées et des témoignages, alors que apparement tu penses que un forum est un WC qui te sert à faire caca sur tous le monde. Après tout si ça peu te défouler amuse toi...

Parce que je critique l'article (= débattre du sujet, non ?), tu me parles de toilettes et de faire caca sur tout le monde ?

Je crois juste que developpez comme d'autres forums ont leur "culture" et leurs habitués et qu'il n'est pas de bon ton de changer de ton ou de penser autrement ;-)

Quel lynchage juste parce que je dis que l'article de base est mauvais comme tout. Ça, je suppose, c'est "débattre entre gentlemEn" et je n'ai rien compris.

[santana2006]

Comme sur plein d'autres sujets nous sommes d'accord
Ca c'est la malédiction de notre métier, tout s'apprend à la dure... Il est sûrement possible d'être multi-sgdb si on se contente d'un certain sous-ensemble, mais c'est se priver de beaucoup de choses qui peuvent faire une différence. Je n'ai jamais vu d'entreprise dont le changement de SGBD n'entraînait pas une grosse remise en question de l'existant, un projet de migration sur le long terme, l'achat de nouveaux serveurs, des MAJ majeures de l'infra etc... Personne ne vient du jour au lendemain avec la lubie "Tiens et si on jetait tous nos serveurs X pour passer sur Y", c'est beaucoup plus compliqué que ça.



Ceux que j'ai vu faire ce genre de chose sont windev ou RoR avec son scaffold et chaque fois avec d'important compromis. C'est visible quelque part ça?

Non rien à avoir en commun avec Windev et compagnie coté possibilité.

Le principe est simple : Je suis architecte spécialisé en Java/JEE, et ayant un retour d'expérience sur pas mal de projets sur lesquels j'ai travaillé, de diverses natures et types, j'ai ma propre conception de ce qu'est une appli JEE multi-modules réussi, coté architecture, coté technologies, et coté facilité de développement. Plus le volet performance.

J'ai mis à part les frameworks classiques de génération de code, vu que c t un peu démodé et limité (style Andro MDA).

Je me suis orienté vers la technologie DSL (xText, xTend ..)

Après bcp de temps passé sur ce projet de générateur de code, basé essentiellement les standards sur JSF, CDI, EJB, JPA + Maven. J'ai obtenu :

• Un langage DSL personalisé
• Un plugin eclipse pour l'édition de mon langage
• Un générateur à base de mon langage

Les résultats que j'ai atteint sont intéressantes :

• 100% Xhtml
• 80% du code des beans JSF
• 90% de la couche DAO
• 0% SQL (Sauf pr les requêtes synthétique ou de reporting
• 100% d'API criteria avancé (grâce à elle j'ai pu atteindre le 0% SQL)
• 100% des clés des messages properties (internationalisation)
• 100% détachement entre couche présentation et ce qui vient plus bas (métier, dao).. Chose qui m'a permi de faire de la génération de couche Swing avec le même langage/syntaxe DSL.
• 80% de la couche Swing générée (Dans le cas de client lourd

Peut être les chiffres paraissent un peu exagérée, mais ils sont véridiques. C'est testé et approuvé.

Le seul truc à améliorer : la portabilité serveur, en effet actuellement les sources produits sont compatibles uniquement avec JBoss Wildfly.

Si besoin est, je travaillerais sur le support d'autre serveur.

C'est visible quelque part ça?

Malheureusement non, car je vais en faire un projet commercial.

[Logan Mauzaize]

Il est vrai que l'article est d'une grosse daube. Il n'y a qu'à voir les commentaires en bas de page. Par curiosité, j'ai été feuilleté le blog du monsieur et les idées (et les commentaires qui vont avec) sont tous du même acabit. Mais au-délà de la qualité de l'article, la question à le droit d'être posée ici.
Et je pense, comme tu le dis toi-même :

certains feront plus attention à la forme qu'au fond.

Et tu en fais partie. L'article est mauvais, ce n'est pas le sujet. Mais il soulève une question de fond, libre à toi de donner ton avis sur le fond (et non sur la forme).

Après juste pour recentrer l'idée de départ, il n'est pas question de remettre en cause le principe d'ORM mais la notion de "framework ORM".

Si tu es très SQL, je te conseille d'essayer jooq, un super outil pour ceux qui "pensent" SQL plutôt qu'objet.

Excellent conseil. Après je ne sais pas s'il est possible de vraiment "mapper" la base de données ou si on est obligé de rester très proche du modèle de la base ?
Sinon il y a également QueryDSL qui fonctionne également avec JPA et MongoDB et autres. C'est une sorte d'EntityFramework.

Concernant les DTOs, il sont quasiment obligatoires dès que l'on travaille avec des bases "legacy" ou plus généralement des bases relationnelles qui n'ont pas été conçues pour stocker de l'objet. Et comme les cours de conception de BDD relationnel ne présentent jamais cet aspect, je pense que les DTOs ont encore de beaux jours devant eux.
Ensuite il y a le problème des "vues" (différentes restitutions et manipulations des entités). Et les DTOs résolvent souvent très simplement ce problème. De plus, je trouve que l'approche de mapping par annotation force à considérer les entités comme des objets de la base de données.

La raison d'être d'un ORM est l'impedence mismatch entre l'object model et le relational model. Si l'approche objet serait accepté comme étant la meilleure pour la programmation, le fait de dire que l'ORM est une grosse erreur revient à dire que c'est le modèle relationnel même qui est une grosse erreur.

Pour rester dans le ton des fêtes, je trouve que le foie gras et le chocolat ne se marient pas bien. Mais cela ne remet pas en cause l'appréciation que j'ai de chacun séparément.
Pour faire plus pragmatique, on peut comparer une vis et un marteau.

Il faut dans ce cas trouver une autre façon de persister et interroger les objets avec au moins les mêmes performance que celle du modèle relationnel et on a même pas besoin de SQL-Speaking-Object !

Il y a de nombreuses autres façons de stocker les données d'un objet : relationnel, document, big table, graphe, BD orientée objet. Mais chacune nécessite des concessions.
En fait le problème est plus large que l'objet. Stocker/Restituer de l'information structurée est un problème en soit. Et notre métier c'est de trouver une solution convenable.

Parce que les NPE sont à l'origine de bugs qui a coûté des milliards à beaucoup de monde, et qu'il existe d'autres approches pour gérer l'absence de valeur comme tu peux le voir dans certains langages récents qui distinguent les types nullables et non nullable ou qui ont une gestion vérifiée par le compilateur, des sucres syntaxiques "Option(al)" etc....

A côté des NPE on peut rajouter les ClassCast, les overflow, les erreurs de signes et autres. En fait dès que l'on fait une supposition/hypothèse sur la nature de la donnée, on fait une erreur. C'est pourquoi j'apprécie énormément Ada et Ceylon (il y en a surement d'autres).
Concernant "Optional", je trouve que c'est une mauvaise idée car en son absence on est sûr de rien et avec, on ne sait pas si c'est nécessairement non-null.

Avant tout je tiens à rappeler que le principale avantage de L'ORM est la migration du SGDB, aujourd'hui on travaille avec mysql demain on migre vers oracle, postgresql ou même vers du NoSQL , en changeant juste le nom de ce dernier dans la config, bien sur si on a utilisé 100% du langage ORM.

Rien à voir avec l'ORM mais uniquement avec la conception de ta couche d'accès aux données. Bien sûr des solutions comme Hibernate offre des services pour faciliter tout cela. Mais rien ne t'empêche de concevoir une application non-portable avec Hibernate, ou même une application portable avec du pure JDBC. C'est d'ailleurs l'un des buts de JDBC : offrir une interface de communication unifiée pour tous les SGBDR.
Après dans les détails on remarque que ce n'est pas si simple entre un support partielle de JDBC et les bugs des Driver (côté client) et les différences de syntaxes/types de données des SGBDR (côté serveur), il faut souvent se limiter à quelques vendeurs.

[OButterlin]

Non rien à avoir en commun avec Windev et compagnie coté possibilité.

Le principe est simple : Je suis architecte spécialisé en Java/JEE, et ayant un retour d'expérience sur pas mal de projets sur lesquels j'ai travaillé, de diverses natures et types, j'ai ma propre conception de ce qu'est une appli JEE multi-modules réussi, coté architecture, coté technologies, et coté facilité de développement. Plus le volet performance.

J'ai mis à part les frameworks classiques de génération de code, vu que c t un peu démodé et limité (style Andro MDA).

Je me suis orienté vers la technologie DSL (xText, xTend ..)

Après bcp de temps passé sur ce projet de générateur de code, basé essentiellement les standards sur JSF, CDI, EJB, JPA + Maven. J'ai obtenu :

• Un langage DSL personalisé
• Un plugin eclipse pour l'édition de mon langage
• Un générateur à base de mon langage

Les résultats que j'ai atteint sont intéressantes :

• 100% Xhtml
• 80% du code des beans JSF
• 90% de la couche DAO
• 0% SQL (Sauf pr les requêtes synthétique ou de reporting
• 100% d'API criteria avancé (grâce à elle j'ai pu atteindre le 0% SQL)
• 100% des clés des messages properties (internationalisation)
• 100% détachement entre couche présentation et ce qui vient plus bas (métier, dao).. Chose qui m'a permi de faire de la génération de couche Swing avec le même langage/syntaxe DSL.
• 80% de la couche Swing générée (Dans le cas de client lourd

Peut être les chiffres paraissent un peu exagérée, mais ils sont véridiques. C'est testé et approuvé.

Le seul truc à améliorer : la portabilité serveur, en effet actuellement les sources produits sont compatibles uniquement avec JBoss Wildfly.

Soyons clairs, je ne remets pas du tout en cause ta compétence, j'exprime juste une expérience différente qui m'amène à d'autres choix.
Je suis moi même spécialiste des architectures JEE que je pratique depuis 2000, particulièrement pour les applications web (RIA).
J'ai créé 2 frameworks liés à ce type d'applications, un (en 2000) était assimilable à struts1, l'autre (en 2005) une approche dictionnaire : on tape une requête sql, le framework s'occupe de la mettre en forme sur la base du dictionnaire, pareil pour un écran de mise à jour, tous les contrôles et l'apparence des éléments sont décris dans le dico.
Bref, une démarche comme une autre, et au final, les problématiques de tous framework, la règle des 80 - 20 (ça fait très bien 80% du boulot, et pour les 20% qui restent, on galère plus ou moins à contourner le framework).
Au final, j'ai une préférence pour les frameworks "bas niveau", qui font juste ce qu'il faut dans leur domaine de compétence (par exemple JSF pour orchestrer, Primefaces pour l'affichage, EJB pour le modèle "métier").
Je ne crois pas au "super framework" qui sait tout faire, même les éléments que j'ai cité avant ne sont "que" pour des applications web typées "client lourd".
Avec une contrainte haute disponibilité ou un nombre très important de clients, je choisirais autre chose.

En résumé, des briques de base bien faites, et pour lier le tout, il reste notre tête pour bien faire

Pour la couche persistence (il faut bien revenir au sujet de base), j'utilise bien souvent un modèle hybride, sql natif pour la performance et la souplesse, JPA pour la gestion d'entités "métier" (CRUD).
L'ORM est un outil comme un autre, il a des côtés intéressants, d'autres bien limitant...
D'un point de vue de la syntaxe, je ne trouve pas le JPQL très simple pour les requêtes complexes, je préfère SQL
Pour ce qui est de la mise à jour/création d'enregistrements dans la DB, je le trouve largement mieux (un bon vieux PreparedStatement me suffirait... mais plus verbeux)

Le plus dur avec tout ce qu'on a à disposition comme outils ou frameworks reste de faire le bon choix

[masivelo]

De plus ample explication serait nécessaire pour mieux comprendre la motivation de l'article.

[santana2006]

Soyons clairs, je ne remets pas du tout en cause ta compétence, j'exprime juste une expérience différente qui m'amène à d'autres choix.
Je suis moi même spécialiste des architectures JEE que je pratique depuis 2000, particulièrement pour les applications web (RIA).
J'ai créé 2 frameworks liés à ce type d'applications, un (en 2000) était assimilable à struts1, l'autre (en 2005) une approche dictionnaire : on tape une requête sql, le framework s'occupe de la mettre en forme sur la base du dictionnaire, pareil pour un écran de mise à jour, tous les contrôles et l'apparence des éléments sont décris dans le dico.
Bref, une démarche comme une autre, et au final, les problématiques de tous framework, la règle des 80 - 20 (ça fait très bien 80% du boulot, et pour les 20% qui restent, on galère plus ou moins à contourner le framework).
Au final, j'ai une préférence pour les frameworks "bas niveau", qui font juste ce qu'il faut dans leur domaine de compétence (par exemple JSF pour orchestrer, Primefaces pour l'affichage, EJB pour le modèle "métier").
Je ne crois pas au "super framework" qui sait tout faire, même les éléments que j'ai cité avant ne sont "que" pour des applications web typées "client lourd".
Avec une contrainte haute disponibilité ou un nombre très important de clients, je choisirais autre chose.

En résumé, des briques de base bien faites, et pour lier le tout, il reste notre tête pour bien faire

Pour la couche persistence (il faut bien revenir au sujet de base), j'utilise bien souvent un modèle hybride, sql natif pour la performance et la souplesse, JPA pour la gestion d'entités "métier" (CRUD).
L'ORM est un outil comme un autre, il a des côtés intéressants, d'autres bien limitant...
D'un point de vue de la syntaxe, je ne trouve pas le JPQL très simple pour les requêtes complexes, je préfère SQL
Pour ce qui est de la mise à jour/création d'enregistrements dans la DB, je le trouve largement mieux (un bon vieux PreparedStatement me suffirait... mais plus verbeux)

Le plus dur avec tout ce qu'on a à disposition comme outils ou frameworks reste de faire le bon choix

Je partage ton avis à un certain degré.

D'ailleurs c la raison derrière mes travaux.

pr JPA effectivement le JPAQL est très fort, dans mon fameux framework l'API criteria est générée à 100% sur mesure, ce sont des classes qui correspondent à mes entités métier, le code JPA final produit suite à la config de ces classes est meilleur que ce que peut faire le développeur humain en terme d'usage des jointures, du fetch et du distinct .. elle dépasse de loin l'approche du static model generator de JPA 2. le JPAQL est juste généré au runtime, suivant les données passés en paramétre, ce qui induit 0% d'erreur de syntaxe SQL, et la possibilité de rendre toutes les relations lazy et faire le fetch à la demande. Je ne suis pas entrain de parler des petites appli de HelloTechno.

Je reviens vers la partie présentation, où avoir du 100% généré induit bien entendu une maitrise parfaite de l'outil JSF, Ajax, binding, converting, .., combiné à une biblio de composants telles que PrimeFaces, tu peux faire bcp de choses.

Sinon, avoir du 100% suppose avoir un Bean JSF bien conçu, et là le générateur génére toutes les informations liées à l'affichage dans le Bean, et prépare tous les attributs et méthodes nécessaires, avec un niveau de profondeur illimité car recursif.

La maitrise des techno DSL de Xtext et Xtend permettent de rendre très faisable des trucs genre : la génération des properties pour l'internationalisation pour chaque composant rencontré.

[professeur shadoko]

Parce que les NPE sont à l'origine de bugs qui a coûté des milliards à beaucoup de monde, et qu'il existe d'autres approches pour gérer l'absence de valeur comme tu peux le voir dans certains langages récents qui distinguent les types nullables et non nullable ou qui ont une gestion vérifiée par le compilateur, des sucres syntaxiques "Option(al)" etc....
.

ça mériterait un flux de discussion distinct.
Que faire quand une donnée est "optionnelle" ? ... s'assurer que le code qui la manipule tient compte de cette absence...
par contre le fait d'avoir des objets "neutres" (comme on le voit parfois dans certaines préconisations) est une erreur encore pire .... on a quelque chose ou on ne l'a pas!

[ymajoros]

Il est vrai que l'article est d'une grosse daube. Il n'y a qu'à voir les commentaires en bas de page. Par curiosité, j'ai été feuilleté le blog du monsieur et les idées (et les commentaires qui vont avec) sont tous du même acabit. Mais au-délà de la qualité de l'article, la question à le droit d'être posée ici.
Et je pense, comme tu le dis toi-même :
>certains feront plus attention à la forme qu'au fond.
Et tu en fais partie. L'article est mauvais, ce n'est pas le sujet. Mais il soulève une question de fond, libre à toi de donner ton avis sur le fond (et non sur la forme).

C'est bien ce que j'ai fait, je crois que mon avis sur le fond est très clair. La forme, je m'en fous. Le fond ? Je me tue à répéter qu'il n'y en a pas ! Si tu as une application orientée objet, et qu'on parle à une db, on fait de l'ORM. Le faire en réinventant la roue (carrée) au lieu d'utiliser un standard existant ne change rien.

[Logan Mauzaize]

C'est bien ce que j'ai fait, je crois que mon avis sur le fond est très clair. La forme, je m'en fous. Le fond ? Je me tue à répéter qu'il n'y en a pas ! Si tu as une application orientée objet, et qu'on parle à une db, on fait de l'ORM. Le faire en réinventant la roue (carrée) au lieu d'utiliser un standard existant ne change rien.

Relis bien l'article et mes propos :

Après juste pour recentrer l'idée de départ, il n'est pas question de remettre en cause le principe d'ORM mais la notion de "framework ORM".

[ymajoros]

Relis bien l'article et mes propos :

> Après juste pour recentrer l'idée de départ, il n'est pas question de remettre en cause le principe d'ORM mais la notion de "framework ORM".

Euh, je ne critique pas tes propos mais l'article, dont le titre est "L'ORM serait-il une 'grosse erreur' ?". Le titre original est "ORM Is an Offensive Anti-Pattern" (avec l'adjectif ki-va-bien). Ou bien l'idée de départ n'a rien à voir avec le titre (on n'est plus à une contradiction près).

[ddoumeche]

Personnellement je pense que c'est plutôt le sql qui est un antipattern : en avoir fait l'API de référence alors qu'il s'agit d'un langage d'interaction conçu pour les humains, oblige a des contorsions et du parsing coûteux de chaque requête.
Oui il y a les procédures stockés mais ce ne sont que des palliatifs imparfaits.

Les ORM et notament leur Api ont su s'imposer parce qu'ils définissent une API standard d'accès aux données, c'est aussi une des raisons du succès des serveurs NoSQL (même si je n'aime pas ce que recouvre cette technologie en réalité).
Si vous regarder cette petite merveille d'architecture de Mysql cluster, vous serez surpris de voir qu'un client évite le plus souvent la couche SQL en se connectant directement au moteur de données (NDB) et en utilisant l'api JPA (meme si le drivers en dessous est spécifique).

[santana2006]

Le SQL n'est pas aussi mal que ça. Il a tjrs sa place vu les millions d'applis pr entreprise ou autres, qui nécessitent une base de données.

L'ORM n'a pas pr but de remplacer le SQL, donc les comparer c'est pas vraiement ce qu'on doit faire, n'oublier pas que l'ORM a sont propre QL à lui (JPAQL, HQL..).

Disons qu'avec un ORM on obtient :

• Une séparation nette entre la couche données et l'application
• Moins de lignes de codes à taper pour la conversion Objet <---> SQL
• On délégue la gestion des connexions, l'aspect transactionnel, le vérouillage et autres trucs aux couches sous jascentes
• On sépare néttement entre le monde relationnel, et le monde objet, on se concentre sur le raisonnement/conception/modélisation/développement orienté objet, et on laisse l'ORM faire le reste

ORM et SQL ne se contredisent pas.

[OButterlin]

Personnellement je pense que c'est plutôt le sql qui est un antipattern : en avoir fait l'API de référence alors qu'il s'agit d'un langage d'interaction conçu pour les humains, oblige a des contorsions et du parsing coûteux de chaque requête.
Oui il y a les procédures stockés mais ce ne sont que des palliatifs imparfaits.

Les ORM et notament leur Api ont su s'imposer parce qu'ils définissent une API standard d'accès aux données, c'est aussi une des raisons du succès des serveurs NoSQL (même si je n'aime pas ce que recouvre cette technologie en réalité).
Si vous regarder cette petite merveille d'architecture de Mysql cluster, vous serez surpris de voir qu'un client évite le plus souvent la couche SQL en se connectant directement au moteur de données (NDB) et en utilisant l'api JPA (meme si le drivers en dessous est spécifique).

SQL antipattern, c'est comme dire Java antipattern... C'est un langage de requête normalisé, ni plus, ni moins...
Qui plus est, l'ORM s’appuie sur JDBC pour accéder à la base de données sous-jacente, la comparaison n'est vraiment pas appropriée

Et l'ORM ne définit pas du tout un standard, il suffit de voir les différences entre Hibernate natif et EclipseLink ou JPA.
JPA est un standard JEE, c'est tout.

Maintenant, dire que l'ORM est bien parce qu'on s'affranchit du langage SQL me laisse toujours dubitatif... C'est plus assimilable à de la paresse intellectuelle qu'à une réelle valeur ajouté.
Je ne vois pas non plus de lien avec "...oblige a des contorsions et du parsing coûteux de chaque requête"...
Il n'y a pas plus proche du modèle physique que JDBC, donc je suppose que tu fais références à des changements de type entre le modèle physique et l'objet représentant les données... ça, l'ORM le fait de façon paramétrable à la place du développeur (et c'est à mon avis sûrement la meilleure partie de l'ORM) mais bon, ça ne représente pas non plus une charge de travaille importante et on peut facilement générer cette phase par un outil.

L'ORM est un outil de plus mis à la disposition des développeurs, il a des avantages et des inconvénients comme tout autre framework.
C'est sa bonne ou mauvaise utilisation que fera la différence.

[santana2006]

C'est sa bonne ou mauvaise utilisation que fera la différence.

J'aime bien. ça resume tout.