Discussion :

[_skip]

Bonjour,

Qui n'a pas été amené un jour à devoir choisir entre plusieurs API et frameworks disponibles pour réaliser une application sans avoir suffisamment de temps pour toutes les passer au crible?

Dans ces situations, j'ai personnellement tendance à rechercher des comparatifs entre les différents choix pour essayer d'en savoir plus sur leurs avantages et inconvénients respectifs. Je vois un argument qui revient souvent dans le monde Java :

Why should you use xxx?
...
...
...
"because it's a standard !" (sous-entendu : you can't be wrong.)


La dernière fois que j'ai vu ceci, c'était dans un débat concernant les frameworks de présentation web (qui sont légions en java). Et cet argument fatal du standard est sorti en faveur de JSF.
Dans d'autres situations il aurait pu sortir pour jaxb, jaxp, EJB, JDO, JTA, JPA et Dieu sait quoi encore.

Je serais intéressé de savoir quel est le poids accordé à cet argument dans vos propres décisions (ou celles de votre entreprise) et si possible les raisons.

-Avez-vous l'impression que c'est une assurance qualité supplémentaire?
-Une garantie sur la pérennité dans le cas d'un projet de longue haleine?
-La possibilité à terme d'obtenir plus de support où une meilleure interopérabilité avec d'autres technos?

Pour continuer dans l'exemple de java, j'ai aussi l'impression que l'adoption d'un standard est souvent sujet à controverse...

[el_slapper]

L'avantage d'un standard, c'est qu'on trouvera plus facilement des erssources pour assurer la maintenance, même quand les gens à l'origine du projet seront partis. C'est le seul avantage, mais il est non négligeable. Après, il faut quand même que le standard en question réponde aux besoins.....

[Mac LAK]

Sans oublier que les standards d'un jour ne le sont pas forcément plus tard... Je pense qu'il est crucial de parler de "nouveau standard" et de "standard pérenne" plutôt que simplement de "standard"...

Un petit exemple concret dans la vie de tous les jours : savez-vous que beaucoup d'entre vous peuvent lire les DVD audio sur leur platine de salon ? C'est un standard. Est-il pérenne ? Absolument pas, et encore moins depuis l'apparition du Blu-Ray... Le HD-DVD est également un standard, tout comme le format de cassette VHS, Betamax ou V2000.


Un standard, c'est simplement que quelque chose a été défini précisément, formellement et que toute implémentation du standard est forcément compatible avec toute autre implémentation dudit standard. C'est très important en soi, bien entendu, pour ne pas dire "fondamental"... Un PC, par exemple, est justement le produit logique et naturel d'une foule de standards, c'est ce qui vous permet d'acheter "une" carte réseau (et qu'elle marche !) plutôt que de devoir acheter "LA" carte réseau, la seule qui fonctionne...


Revenons à nos moutons : un standard, c'est fondamental, donc. La chose est entendue.
Mais qui a défini ledit standard ?? Si c'est l'ISO, c'est un gage de sérieux et de qualité, de la part d'un organisme international et indépendant. C'est un des plus haut gage de qualité d'un standard.

Maintenant, des standards, n'importe qui peut en écrire un : il suffit en fait de décrire toutes les fonctions, tous les cas possibles d'utilisation, et tout tout ce que le standard laisse libre d'interprétation.
Est-ce que ce standard sera utilisé ? Diffusé ? Plébiscité ? Nul ne le sait à priori... Ceux qui ont vécu les "guerres de standards" des cassettes vidéo, des disques optiques, de la vidéo HD devraient comprendre qu'un "bon" standard n'est pas forcément le meilleur, c'est celui qui gagne...
Ayant possédé, à l'époque, un magnétoscope V2000, je peux vous garantir que la qualité d'image était largement supérieure à celle du VHS... Qui a pourtant gagné.

C'est en ce sens qu'il faut voir si le "standard" en question est nouveau (=potentiellement mort la semaine prochaine), ou pérenne (=existant depuis des années, et soutenu par une diffusion lourde). En tout cas, dire "c'est standard" est tout simplement idiot : ça ne veut RIEN dire de plus que "c'est documenté", en gros !!

Un standard ouvert (=public) sera par exemple plus souvent choisi qu'un standard fermé (=payant et/ou secret), car les utilisateurs savent que, au besoin, quelqu'un pourra toujours réimplémenter le standard et continuer à le faire vivre. En logiciel, c'est souvent un standard open-source, mais pas obligatoirement.

Ensuite, il faut aussi voir la conformance aux sous-standards ou aux standards "frères" : par exemple, une bibliothèque de transfert de fichiers sera sûrement plus populaire si elle s'appuie sur des standards existants (FTP, TFTP, HTTP) que si elle implémente sa propre sauce, qu'elle soit plus performante ou pas !
Tout comme un protocole de communication a plus de chances d'être populaire s'il s'appuie sur TCP/IP ou UDP/IP plutôt que sur un protocole inconnu....

Dernier point à considérer lors de l'adoption d'un standard : son coût de remplacement... Est-ce quelque chose de "tentaculaire", donc difficile à éliminer d'un projet complexe ? Est-ce que c'est une librairie autonome ?

L'exemple parfait d'un mauvais standard, c'est une librairie d'abstraction de l'OS : par nature, ce genre de librairie est totalement tentaculaire, et est présente partout dans le code. La remplacer est horriblement coûteux...

A l'inverse, une librairie de chargement / sauvegarde d'un format de fichier précis peut être aussi bien facilement remplaçable que tentaculaire... Si la librairie fournit en gros deux fonctions "Load" et "Save" vers un format abstrait interne très simplifié, ou mieux, vers un AUTRE standard, c'est facilement remplaçable. Si par contre elle n'autorise pas à manipuler les données autrement que via ses propres fonctions, c'est une mauvaise librairie.

Par exemple, sous Windows, une librairie de chargement d'image renvoyant (ou demandant) un DIB pour fonctionner est "bonne", car c'est un élément standard de l'OS. De plus, elle peut être adaptée pour renvoyer un équivalent dans d'autres OS / systèmes graphiques (ex : un gtk.Image sous GTK), et donc être relativement portable.
A l'inverse, une librairie qui vous fournirait les fonctions de lecture/écriture via un format interne d'image, requérant des accès "raster" par exemple, serait mauvaise, car les appels à cette librairie seraient bien plus nombreux dans le code utilisateur.



Pour résumer, la réponse aux questions :
-Avez-vous l'impression que c'est une assurance qualité supplémentaire?
Uniquement si l'organisme ayant standardisé la chose est réputé, ce qui veut en général dire soit une très grosse société bien implantée (Microsoft, Appel, Sun), soit un organisme indépendant (ISO, ANSI). Les standards édictés par des communautés libres peuvent parfois être fiables, mais peuvent aussi être complètement détruits du jour au lendemain sans possibilité de compatibilité ascendante.

-Une garantie sur la pérennité dans le cas d'un projet de longue haleine?
Un nouveau standard n'est à priori jamais pérenne, même édicté par de "grosses pointures". Les chances sont toutefois nettement améliorées en cas de compatibilité ascendante totale avec "l'ancien" standard, ou par l'utilisation d'un standard déjà bien implanté mais rébarbatif (ce cas particulier concerne par exemple les librairies d'encapsulation, la génération de code, et les "méta-XXXX" de façon générale).

-La possibilité à terme d'obtenir plus de support où une meilleure interopérabilité avec d'autres technos?
Le support dépend en général beaucoup de qui a édicté le standard... Il est encore plus évident qu'un standard payant est en règle générale mieux supporté qu'un standard gratuit, qui finalement ne dépend que de la bonne volonté de ses acteurs (qui n'ont pas toujours du temps à perdre, faut-il le rappeler, ils ne sont pas payés, eux !).
Paradoxalement, le support d'un produit propriétaire non-standard (appelé aussi "fermé") est souvent bien meilleur au contraire, même s'il est cher... Du moins, tant que la société qui l'édite est en activité ! Certes, certaines sociétés ne "risquent rien" : le support Microsoft ou Intel existera encore de très nombreuses années, aucun doute là-dessus.
Après, restent aussi les standards "libres" (édictés ou non par de grosses sociétés), et les standards "de fait" (souvent issus d'une RFC, d'ailleurs). Pour ma part, j'ai plutôt tendance à faire confiance aux standards "de fait", et par transitivité aux standards s'appuyant dessus.

L'interopérabilité, elle, est uniquement fonction de la volonté d'ouverture du standard, ou des sous-standards sur lesquels il s'appuie. Il est évident, par exemple, qu'un standard prenant en entrée comme en sortie de processus des éléments eux-même standardisés est un gage lourd d'interopérabilité. A l'heure actuelle, cela veut dire par exemple utiliser de l'XML en entrée/sortie, des communications basées sur Ethernet et/ou TCP/IP, l'utilisation d'une couche POSIX, etc.
Il faut voir aussi le domaine dans lequel le standard évolue : il n'est pas forcément nuisible par exemple d'exporter ses données au format Excel, si le standard en question est destiné à administrer un réseau d'entreprise sous Windows ! En revanche, exporter des données au format XML sur des bus de terrain (type CAN ou ARINC, par exemple) serait d'une stupidité colossale...



Pour résumer (désolé du pavé, mais bon, c'est une question extrêmement générale après tout), choisir un standard plutôt qu'un autre demande à :

• Bien définir le domaine d'application dudit standard : un standard n'est valable que dans le domaine pour lequel il a été conçu.
• Vérifier la qualité et le type de support du standard : un support en hotline (payant hélas) est préférable à un support disponible exclusivement par les newsgroups, par exemple.
• Vérifier la durée de vie attendue du produit que l'on souhaite développer : un projet à court terme peut utiliser un nouveau standard, pas un projet prévu pour durer 20 ans.
• Vérifier le coût d'utilisation du standard, ainsi que son éventuel remplacement : un standard, ça évolue toujours...
• Le standard du client est toujours le meilleur...
• Un standard connu est toujours meilleur et moins coûteux qu'un standard inconnu, même si ce dernier est "mieux" sur le papier et/ou gratuit.