Discussion:Java Card

Erreur de définition

Java Card n'est pas un framework mais un environnement d'exécution (platform) : Java Card technology is the leading open, interoperable platform for smart cards and secure tokens. Voir : http://www.oracle.com/technetwork/java/javacard/specs-138637.html

... Gilles.Grimaud (d) 25 octobre 2011 à 11:01 (CEST)

A propos des sources

A propos de sources utilisées, il me semble important de rappeler qu'une source wikipédia pour appuyer un propos est invalide. Une source knol n'est guère plus pertinente. Cela est d'autant plus dommageable que l'article knol que vous pointez est en fait un article de misc (la célèbre revue francophone sur la sécurité informatique). Il est donc bien plus pertinent de pointer l'article misc en utilisant un référencement d'article et pas un site web.

Par ailleurs, l'objet d'une source et de donner à un auteur la source d'un propos, pas de pointer le site web/organsime dont l'article parle à un moment. Donc, je m'attends à trouver la référence à l'article de misc à la fin d'une phrase, pas au milieu...

Bonne contribution.

Gilles.Grimaud (d) 8 novembre 2011 à 09:21 (CET)

Quelques remarques rapides

Bonjour,

Après une rapide lecture, je vous retourne quelques premières remarques de base. Dans la section historique, vous avez rédigé un paragraphe évasif que j'ai mis en lumière. Consultez le lien pour comprendre ce qui est attendu. De plus, vous utilisez le terme anglophone smardcard qui est la traduction de carte à puce. Si vous souhaitez rédiger l'article en anglais, je n'y vois aucune objection, mais si vous rédiger votre document en français, alors utilisez les termes francophones. Par ailleurs, j'ai pointé quelques affirmations qui nécessitent une référence. Je vous rappelle qu'il vous est demandé d'appuyer, dans l'article, toute vos affirmations par des sources de qualité.

A propos des références

Enfin, lorsque vous donnez des références, vous ne le faite pas correctement. Sur l'exemple suivant :

De plus, des applications peuvent être chargées en toute sécurité sur la [[Carte à puce|SmartCard]] après qu'elle a été fournie au client <ref>[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=806977 Java Card, From hype to reality - Introduction]</ref>.

En guise de référence pour cette affirmation, vous pointez un lien web : http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=806977 . Or le serveur ieeexplore est un serveur (de la société savante IEEE) qui sert de librairie numérique. L'article que vous y avez trouvé est un document publié dans une édition du journal « IEEE Concurrency » (édité par la société savante IEEE qui gère la librairie numérique). L'article, rédigé par M. Baentsch, P. Buhler, T. Eirich, F. Horing et M. Oestreicher du Secure Syst. Group d'IBM Res. Div. à Zurich est intitulé : « JavaCard-from hype to reality ». Il a plus précisément était imprimé dans le Volume 7, numéro 4 du journal, entre octobre et décembre 1999 (ISSN: 1092-3063) des pages 36 à 43. De plus l'article scientifique dispose d'un identifiant unique, DOI (Digital Object Identifier) : 10.1109/4434.806977 (qui permet de le retrouver via le service web doi.org ). Il doit être présenté, en tant que tel dans la section bibliographie :

• (en) M. Baentsch, P. Buhler, T. Eirich, F. Horing et M. Oestreiche, « JavaCard-from hype to reality », IEEE Concurrency, vol. 7, n^o 4, , p. 36-43 (ISSN 1092-3063, DOI 10.1109/4434.806977)
  Secure Syst. Group, IBM Res. Div. Zurich

Pour obtenir cette entrée bibliographique j'ai utilisé le modèle {{article}} comme suit :

* {{article | lang = en | id = Baentsch1999 | prénom1 = M. | nom1 = Baentsch | prénom2 = P. | nom2 = Buhler | prénom3 = T. | nom3 = Eirich | prénom4 = F. | nom4 = Horing | prénom5 = M. | nom5 = Oestreiche | titre = JavaCard-from hype to reality | périodique = IEEE Concurrency | volume = 7 | numéro = 4 | issn = 1092-3063 | année = 1999 | mois = octobre-décembre | pages = 36-43 | doi = 10.1109/4434.806977 | commentaire = Secure Syst. Group, IBM Res. Div. Zurich }}

Une fois cette entrée bibliographie saisie dans la section bibliographie, vous pouvez créer une référence au standard Harvard dans l'article. Pour cela il faut utiliser le modèle {{harvsp}} comme suit :

De plus, des applications peuvent être chargées en toute sécurité sur la [[Carte à puce|SmartCard]] après qu'elle a été fournie au client <ref>{{harvsp|Baentsch|1999|p=???|id=Baentsch1999}}</ref>.

Sur l'article vous obtiendrez un simple lien en indice: « ² » qui renverra vers une référence. la référence, elle, aura la forme suivante :

1. Baentsch 1999, p. ???

Et le lien reverra à l'entrée bibliographique appropriée. Notez au passage que la référence doit indiquer un numéro de page au sein de l'article. J'ai saisie ??? car je ne sais pas à quel page de l'article vous avez trouver l'affirmation que vous rapportez ici. Je vous laisse donc mettre le numéro de page approprié.

Notez que lorsque vous souhaiterez faire référence à un autre passage du même document (comme dans la phrase : « Il s'occupe aussi de la promotion des APIs (Application Programming Interface) JavaCard pour qu'il devienne la plate-forme standard de développement des applications pour les SmartCard². » Il vous suffira de saisir :

Il s'occupe aussi de la promotion des APIs (Application Programming Interface) JavaCard pour qu'il devienne la plate-forme standard de développement des applications pour les SmartCard <ref>{{harvsp|Baentsch|1999|p=YYY|id=Baentsch1999}}</ref>.

Dans ce cas, YYY indique la nouvelle page utilisée pour appuyer votre affirmation dans la section « Références » :

2. Baentsch 1999, p. YYY

Mais le lien vers l'entrée bibliographique reste inchangé...

Merci d'appliquer scrupuleusement ces conventions de référencement.

A propos de la section « Historique »

Comme je l'ai indiqué, le premier paragraphe de cette section est trop évasif. Je m'attends a trouver dans un historique technologique, une description des principales avancées qui ont progressivement façonnées la technologie tel qu'on la connait. Entre Javacard 1.0 et 2.0, il y a une "révolution"... laquelle ? Idem entre 2.0 et 3.0 connected... Qui en sont les acteurs, comment ont-ils révolutionnés la technologie ? Pourquoi ?

Par ailleurs, je ne pense pas que la place de l'historique soit en section 1. Je pense que pour comprendre l'évolution technologique il faut ce faire une idée de ce qu'est la technologie en question... Cette section viendrait donc après la description du rôle de Java Card, de son architecture actuelle, et peut-être des mécanismes de sa sécurité.

A propos de la section « JavaCard par rapport à Java »

Dans cette section vous ne traitez pas des différences entre Java Card et Java. Pour preuve, vous listez dans la sous-section « Avantages » Intéropérabilité, Sécurisé, Application multi capability, Dynamique, Compatible avec les normes existantes...

Java aussi est interopérable, sécurisé, ... Toute cette section est à revoir, et le contenu actuel à déplacer ailleurs. Peut-être dans une section « ambition de la technologie » qui viendrait en tout début d'article (en première section).

In fine, l'idée de présenter les avantages et les inconvéniant de Java Card par rapport à Java me semble une entreprise bien périlleuse... Après tout, comme Java Card étant défini comme un sous-ensemble de Java, elle ne peut qu'en partager un sous-ensemble des avantages, et en chaque partie de java exclue de Java Card peu sembler être un inconvénient... La section inconvénient est d’ailleurs bien peut convaincante en l'état. Vous semblez victime des campagnes promotionnelles de cette technologie, et vous ne parvenez à définir les limitations de cette technologie que par rapport à ses évolutions récentes... Cherchez de meilleures sources !

Enfin, une simple remarque de forme : Vous avez utilisé une police grasse pour pointer les entrées que vous définissez :

• Intéropérabilité : les Applets développées avec la technologie JavaCard fonctionneront sur n'importe quelle type de SmartCard (et indépendament du matériel sous-jacent).

Cette manière de faire est impropre. Lorsque vous définissez des termes, utilisez la syntaxe suivante : ; terme : définition du terme. vous obtiendrez le formatage attendu par les standards éditoriaux.

A propos de la section « Sécurité des javacard »

Relisez cette section. Qu'es-ce qu'un JCM ? Qu'es-ce qu'un vérificateur ? Que vérifie-t’il ? Quand ? Ou (dans la carte, sur le PC qui charge le code dans la carte ?) ? Comment fait-il ? Vous pourrez trouver une foule de publications qui propose des mécanismes de vérifications de code javacard... Vous devez améliorer vos sources.

A propos de la section « Concept de programmation »

Il me semble que ce qui est présenté ici vient trop tardivement. Il s'agit, aprés tout, d'expliquer comment les Java Cards jouent le rôles qui leur à été attribué. Cela pourrait donc être intégré en sous-section de la première section que je vous ai conseillé de rédiger. Il me semble aussi qu'un exemple de code minimaliste (un exemple d'application Java Card à la "Hello World"), en encart peut-être, pourrait être une illustration pertinente du propos. Par ailleurs, cette section n'est absolument pas sourcer... Elle est donc irrecevable en l'état.

Bonne contribution,

Gilles.Grimaud (d) 11 novembre 2011 à 11:42 (CET)

Style encyclopédique...

Bonjour,

Décidément, la phrase suivante (et celles qui sont construite de la sorte) me pose problème :

« Les marchands de cartes à puces ( tel que Gemplus, Axalto,Oberthur Technologie,...) implémentent les nombreuses et uniques fonctionnalités de Java Card tel que¹: »

Point par point :

• « Les marchands de carte à puces ». Je suis surpris par l'usage du terme « marchand » : Un marchand est le terme générique appliqué aux intermédiaires qui s'occupent de la revente de marchandises... Gemalto & co ne sont pas, en premier lieu, des marchands, mais des producteurs ! Ils spécifient, produisent, et distribuent des cartes à puce... De plus ils ne vendent pas une carte avec des puces mais des cartes avec une puce...
  Soyez précis dans l'usage des termes.
• « ( tel que Gemplus, Axalto,Oberthur Technologie,...) ». Ici il y a une accumulation d'erreurs de conventions de ponctuation :
  • La parenthèse doit être suivie du premier caractère du mot, sans espace,
  • si une virgule suit effectivement immédiatement le dernier caractère du mots précédent, elle est précédée d'un espace avant le premier caractère du mot suivant (entre Axalto et Oberthur),
  • les « ... » ne doivent pas être précédé d'une virgule lorsqu'on veut suspendre une énumération,
    En résumé, respecter les Conventions de ponctuation d'usage en français.
• « implémentent les ». Si ce sont des marchands ils n'implémentent rien, comme dit précédemment, et pour aller plus loin, es-ce que c'est le fait qu'ils implémentent ces fonctionnalités qui est l'action essentielle ici ?
• « nombreuses et uniques ». nombreuses, si vous voulez, mais cela ne représente que 5 ou 6 points ; unique, certainement pas ! une foule d'autres Système d'exploitation pour carte à puce font de même, notamment MULTOS qui fait une proposition différente de celle de java, pour chacun des items que vous pointez (interopérabilité, sécurité...). Ce qualificatif est donc impropre ou à préciser ;
• « Java Card tel que ¹: ». En premier lieu, au niveau convention typographique, les deux points doivent être précédé d'un espace, mais la référence permettant de vérifier l'affirmation doit suivre immédiatement (sans espace) le dernier mot de la phrase. Cependant le principal problème provient ici du fait que cette référence n'est pas correctement construite. Lorsque vous voulez référencer une page web qui fait autorité (ce que je vous concède ici), vous devez ajouter cette page dans la section liens externes (sous section de Voir aussi), en utilisant le modèle {{lien web}} :
  *{{en}} {{Lien web | url = http://www.oracle.com/technetwork/java/javame/javacard/overview/about/index.html | titre = About Java Card Technology | en ligne le = 14 novembre 2011 | id = JavaCard }}
  Puis, en référence, je vous demande de respecter les convention Harvard : <ref>{{harvsp|Oracle|2011|id=JavaCard}}</ref>. En effet, lorsqu'il s'agit de documents techniques et que ni le nom de l'auteur, ni l'année d'édition n'est indiquée, je vous demande d'indiquer la nom de la compagnie propriétaire de la technologie, et l'année de consultation du document. En effet, c'est aujourd'hui Oracle (enseignement Sun) qui est responsable des affirmations que vous présentez dans cette phrase. Notez que le champ "en ligne le" du modèle {{Lien web}} a été renseigné et qu'il permettra au lecteur de savoir à quelle version du document web vous faites référence.

Je fais un exemple sur cette phrase, pour illustrer la manière dont vous devez aborder la rédaction.

Par ailleurs, j'ai noté que vous avez voulu ajouté une entré bibliographique en saisissant :

* ''Java Card Technology for Smart Cards: Architecture and Programmer's Guide'' , Zhiqun Chen 
,Addison Wesley, June 2000

Cela ne convient pas, vous devez utiliser le modèle {{Ouvrage}} comme suit :

 * {{Ouvrage
    | id            = Chen2000
    | langue        = en
    | prénom1       = Zhiqun
    | nom1          = Chen
    | titre         = Java Card Technology for Smart Cards: Architecture and Programmer's Guide
    | éditeur       = Addison Wesley
    | lien éditeur  = Addison–Wesley
    | jour          = 18
    | mois          = septembre
    | année         = 2000
    | pages totales = <!-- à renseigner -->
    | isbn          = <!-- à renseigner -->
    | lire en ligne = http://java.sun.com/developer/Books/consumerproducts/javacard/
   }}

cela donne ce rendu :

• (en) Zhiqun Chen, Java Card Technology for Smart Cards: Architecture and Programmer's Guide, Addison Wesley, 18 septembre 2000 (lire en ligne)

Bonne continuation,

Gilles.Grimaud (d) 14 novembre 2011 à 12:05 (CET)

A propos des références multiples

Bonjour,

Aprés une rapide relecture, je voulez vous faire remarquer que lorsque vous citez plusieurs fois la même page de la même source, comme c'est le cas pour les références 6, 7 et 8, vous devez faire une référence à entrée multiple. J'ai fait un exemple sur la référence 6 et 7. Dans le source wiki vous aviez écris, pour la référence 6 : <ref>{{harvsp|Technology for Smart Cards: Architecture and Programmer's Guide|2000|p=37|id=Chen2000}}</ref> Je l'ai remplacé par : <ref name=Chen200_37>{{harvsp|Technology for Smart Cards: Architecture and Programmer's Guide|2000|p=37|id=Chen2000}}</ref>. une fois cela fait, j'ai pu remplacé la référence suivante à la même page par : <ref name=Chen200_37/>. Il n'y a plus qu'une entrée dans les ref et plusieurs dans le texte...

par contre, a propos des refs, je vous rappelle que vous devez utiliser le nom du premier auteur et pas le titre, dans la ref. Elle devrait donc être : {{harvsp|Chen|2000|p=37|id=Chen2000}}. Je vous demande d'appliquer ces conventions bibliographique systématiquement...

Gilles.Grimaud (d) 17 novembre 2011 à 13:55 (CET)

Après une rapide lecture

Bonjour,

J'ai rapidement parcouru le début de la section "Architecture". Globalement, le style de l'écriture s'est amélioré. Il y a cependant différents problèmes que j'énumère ci-dessous :

Les affirmations gratuites

J'ai pointé dans le texte les phrases qui comportent des affirmations non sourcées. Vous devriez quasiment avoir une référence par phrase, ou du moins par groupe de phrases qui rapporte une affirmation. On est loin du compte pour l'instant.

les graphiques

Je vous encourage fortement à continuer d'enrichir votre article avec des figures et des images, comme vous avez commencé à le faire. Cependant, j'attire votre attention sur le fait que les figurent doivent être en Français (elles sont en anglais actuellement), vous devez les traduire. par ailleur, les figurent que vous présentées donnent à voir plus de choses que le texte n'en décrit. Vous devez recentrer vos figurent sur ce que vous décrivez dans le texte, ou décrire dans le texte l'ensemble de ce que vos figurent présentent.

Mise en forme

Vous ne devez pas utiliser de mise en forme particulière pour la présentation de votre article. Vous devez respecter les standards. Par exemple, vous ne devez pas mettre de balises HTML dans le texte. Vous utilisez <br /> fréquemment. Supprimez ces balises. Lorsque vous avez rédigez un paragraphe passez à la ligne, puis laissez une ligne blanche avant de commencer le paragraphe suivant, comme le prévoit wikipédia. Lorsque vous voulez définir des termes, ne les mettez pas en gras, mais utilisez le format de définition d'un terme :

; <terme à définir> : <définition...>

Par ailleurs, je vous rappelle que les conventions typographiques définissent une mise en forme précise. je vous invite par exemple à consultez la section Espaces qui précise ou et comment doivent être placez les espaces. Ils ne doivent pas être avant un point, mais après, pas avant une virgule, mais après, par contre ils doivent précédez un ":" ou un ";"... Corrigez votre texte en conséquence.

Anglicisme

Évitez les anglicismes dans le texte. Lorsque vous utilisez un terme anglais (ou dans toute autre langue) il doit être mis en italique, et lors de sa première utilisation, il doit être suivi d'une note de bas de page qui en propose une traduction en Français. pour faire une note de bas de page, il suffit d'écrire : <ref group=note>JCVM : ''Java Card Virtual Machine'' ou encore « Machine virtuelle Java » en Français).</ref>.

Le titre de section ou de sous-section ne devraient jamais être dans une autre langue que le Français.

Structure du plan

Je pense par ailleurs, que votre plan sur la section architecture est trop détaillé. Les sous-sous-sous sections devraient être évitées. En l’occurrence, chacune ne contient, au plus qu'un petit paragraphe de deux ou trois phrases pour décrire un sous-composant du système Java Card (Instaler, industry-specific extensions...). Vous pourriez donner la définition de ces sous-composants en les décrivant dans le cadre d'une définition (cf. #Mise en forme). Il me semble aussi très important de détailler les interactions entre chacun de ces sous-composants au sein du composant auquel ils prennent part, ce que vous ne faites pas actuellement.

Bonne continuation.

Gilles.Grimaud (d) 17 novembre 2011 à 14:43 (CET)

Bonjour, Nous prenons en compte vos remarques et nous essayons d'y répondre. En effet, globalement le format wikipedia n'est pas respecté car nous ne l'avions pas forcément définit comme une priorité, mais il est temps de revoir cet aspect avant de trop dériver. Pour ce qui est des références, la révision du style devrait nous aider. Enfin, nous allons essayer d'être plus limpide dans la définition de l'architecture et enchainement du fonctionnement. A venir : Concept de Programmation ( javacard/java et évolution des versions). Merci. (A.Gobeyn,R.Ryngot,L.Citerin,S.Coirre)

Grave problème d'utilisation des sources

Bonjour,

Je constate que vos références sont toujours incorrectes. En l'état je ne validerais pas votre travail.

Sur la forme, vous ne respectez pas le modèle harvard {{harvsp}} dans la section référence. J'ai pourtant fait un exemple. j'y reviens encore une fois. Vous devez utiliser la mise en forme de Harvrd pour vos références. Wikipédia propose pour cela un modèle qui s'occupe de mettre en forme pour vous vos entrées, pour peu que vous le respectiez :

<ref>{{harvsp|Nom1|Année|p=Page|id=Identifiant}}</ref>

Où :

Nom1

Nom1 est le Nom du premier auteur, et pas le prénom, ni le prénom suivi du nom. Lorsque vous vous référez à un document d'entreprise pour lequel vous n'arrivez pas à déterminer le nom du premier auteur, vous pouvez utiliser le nom de l'entreprise (Oracle, Gemalto...). Cependant ce type de document est une source faible au regard d'un document scientifique évalué par les pairs lors d'une conférence ou lors de la soumission à un journal scientifique. En effet, ces documents ne sont exploitable qu'en tant que spécification technique, pour le reste ils sont nécessairement partiales (produit d'une entreprise) et sujet à caution (non évalué par des détracteurs). Un article qui ne reposerait que sur ce type de document serait au mieux un résumé de documentation technique, ce qui n'est pas l'exercice demandé ici.

Année

année de publication du document. Cette information est essentielle, car elle permet de mettre en perspective historique le propos que vous rapportez. Cela permet par exemple de savoir si cette affirmation à eu lieu avant ou après une autre, avant ou après un changement dans la technologie... Elle doit Toujours être indiquée.

Page

Il s'agit d'indiqué le numéro de la page à laquelle vous faites référence, dans le document utilisé. Ce numéro doit toujours être indiqué. par exemple vous citez abondamment Oracle 2011 qui est un document pdf daté non pas de 2011 mais de 2002 (et dont l'auteur n'est effectivement pas indiqué). Ce document fait 24 pages. Sans indiquer le numéro de la page à laquelle vous faites référence vous obligé le lecteur à consulter tout le document pour retrouver votre affirmation. Je n'ai pas le temps nécéssaire pour cela, je considère donc la référence invalide.

Identifiant

L'identifiant doit permettre de faire la correspondance entre la référence et une entrée de la section bibliographie. Cela implique que toutes vos références doivent être associées à des entrées bibliographiques ou à des liens externes. On est bien loin du compte, l'immense majorités pointent directement des URLs pour lesquelles vous ne donnez aucune information permettant de les apprécier.

Aujourd'hui seule l'entrée 2 (que je vous avez donné en référence) et l'entrée 15 sont correctement formatée. Les entrées 20, 21, 22 et 23 ne donnent pas la bonne date, et n'indiquent pas de page. Les entrées 9 et 19 ont une erreur de syntaxe dans l'usage du modèle {{harvsp}} et surtout, elle n'indique pas de page. Les entrées : 1, 3, 4, 6 et 18 sont des liens vers des pages Wikipédia. Wikipédia n'est pas une source ! Elles sont donc invalides. les entrées : 5, 7, 10, 11, 12, 13, 14 et 16 ne font pas référence au nom du premier auteur, mais au titre du document référencés. Elles doivent être corrigées en conséquences. les deux restantes sont des liens vers des pages web et doivent donc pointées vers un lien externe (section liens externes) qui lui, fera référence au site web.

Sur le fond, vos références sont faibles car essentiellement issues de l'industrie qui produit le matériel et qui ne peut donc qu'en donner une vision partiale. Variez donc vos sources. par ailleurs, Il y a un changement de technologie majeur entre « Java Card 2.x » et « Java Card 3.0 connected edition » qui vous a complètement échappé. De fait, vous rapportez des affirmations qui sont vrai pour l'une de ces version, et fausse pour l'autre, sans vous en rendre compte. Aussi certains de vos paragraphes (notamment autour de la sécurité et de l'architecture) sont simplement faux, dans un cas ou dans l'autre.

Rien de tous cela n'est insurmontable, mais il est tant de mettre un coup de collier. Bonne fin de rédaction.

Gilles.Grimaud (d) 26 novembre 2011 à 13:05 (CET)

Relecture du 28/11/2011

Bonjour,

Je vous fais quelques retours sur la forme et le fond, après une nouvelle relecture, section par section

Section « 1. Architecture »

Relisez le paragraphe qui présente les généralités au sujet de l'architecture des machines virtuelles Java Card. Les informations qui y sont rapportées ne sont pas cohérentes avec celles du tableau que vous présentez en section "Java Card plateforme Version 3". Il me semble que dans la mesure ou il existe deux architectures distinctes (« Java Card 3 version classique » et « Java Card 3 version connectée ») vous devriez donner dans ce premier paragraphe les informations qui permettent de comprendre ce qui a amenée à ces deux architectures distinctes (la seconde englobant la première). Dans la suite de votre propos vous rapportez parfois des affirmations qui n'ont de sens que pour « l'architecture Java Card 2/Java Card 3 version classique ». Veillez à rester générique dans votre propos ici.

Sur la forme, ne sautez pas plus d'une ligne pour séparer deux paragraphes. Cela gène la lecture en altérant l'enchainement des paragraphes. Pensez aussi à laisser un espace avant un « : » (ainsi qu'avant un « ; »). Je vous encourage à consulter les Conventions typographiques notamment a propos de la ponctuation dans les listes à puce.

Enfin, dans cette avant sous-section, j'ai l'impression que vous auriez pu fusionner l'énumération des composants de la plateforme Java Card et les spécifications qui leurs sont associées. Cela rendrait le style moins pataud et la lecture plus fluide. A voir.

« Section 1.1 Composants »

Attention à ne pas laisser d'espace avant un « . ».

Le titre "Java Card Virtual Machine" est un anglicisme, vous devriez utiliser un terme français : Machine Virtuelle Java Card (puisque l'on admet que la technologie est désignée par le terme anglais Java Card). Dans l'avant sous-section vous utilisiez ce terme, restez homogène.

Sur le fond, tous ce que vous décrivez dans cette section est spécifique aux version 2.x de Java Card et aux versions "Java Card 3 version classique". Vous devriez réviser le titre en conséquence, et veiller à rendre cet état de fait explicite dans le texte. Par exemple vous affirmez :

« La capacité des cartes à puces étant trop limitée pour contenir toutes les informations des fichiers de classe Java, [...] »

Cela n'est plus vrai pour les versions 3 connectées. soyez donc plus précis dans vos affirmations pour éviter l'erreur. Ce problème se poursuit par la suite. Le convertisseur et le vérificateur ne fonctionnent sur un PC que pour la technologie « Java Card 3 version classique » et pour la technologie « Java Card 2.x ». La notion d'APDU (section « Java Card Runtime Environement » que vous auriez du intituler « Environnement d'exécution Java Card ») ou encore celle d'Applet sont elles aussi spécifiques.

Sur la forme, je vous rappelle qu'il n'y a pas d'espace après une « ( » ni avant une « ) ». je vous rappelle aussi que l'usage des caractères en gras est a prescrire. Si vous devez définit un terme utilisez la syntaxe :

; <terme à définir> : <Définition>.

Enfin, je vous rappelle que toute affirmation devrait être sourcée. On est trés loin du compte, dans une section comme la section « 1.1.3 API »

« 1.2 Java Card plateforme Version 3 »

Je pense que cette section devrez être renommée « Java Card Version 3 » connectée et ne traiter que de la spécificité de la version connectée. Cela suppose que vous ayez aménagé la section précédente pour qu'elle soit présentée comme « Java Card Version 2 et version 3 classique ».

Sur le fond cette section doit être détaillée. Le lecteur ne peut pas comprendre, en l'état, ce qui change véritablement entre les versions antérieures et cette version là. Pourtant, cette machine virtuelle n'est plus spliter, elle charge des fichiers .class et les vérifie elle-même. Elle ne repose plus sur la définition d'une Applet, mais d'une Servlet... Cette section doit entièrement être reprise et détaillée.

Je vous rappelle aussi que je n'accepte pas les liens direct vers l'extérieur depuis le texte. Si le document référencé est une source, il doit apparaitre dans la bibliographie et être cité en référence. La description des limitations du moteur de servlet de Java Card version 3 connecté est insuffisamment détaillée pour que le lecteur puisse les juger.

« 2. Intérêts »

Sur le fond, je ne comprends pas l'objet de cette section. S'il s'agit de présenté le rôle des plateformes Java Card alors cette présentation, qui tient lieu de mise en situation de la technologie, aurait du être faite, avant la section « 1. Architecture ». S'il s'agit de dire quel sont les bénéfices de cette technologie, alors la position de la section est bonne, mais le contenu trop succins et, en l'état incompréhensible.

Lorsque le lis :

« Les producteurs de cartes à puces (tel que Gemplus, Axalto, Oberthur Technologies,...) implémentent les fonctionnalités de Java Card suivantes³⁰ : »

D'une part, je crois comprendre que les producteurs de cartes à puce n'implémentent pas toutes les fonctionnalités de java Card mais seulement un sous-ensemble que vous allez m'indiquer après le « : ». D'autre part, je m'attends à trouver une liste de fonctions (fonctionnalités) comme des fonctions cryptographiques, des fonctions d'allocation mémoire, des fonctions d'interprétation... Mais cela n'est pas ce que je trouve. Je ne pense pas qu'une industrie implémente l’interopérabilité, la sécurité, la possibilité d'applications multiples, ou la dynamique. Selon moi, le « rôle » de la technologie Java Card est de proposer, aux différents producteurs de cartes à puce, des moyens effectifs d'assurer :

• l'interopérabilité des plateformes : ... ;
• la sécurité des applications : ... ;
• le déploiement d'applications multiples au sein d'une même carte : ... ,
• la compatibilité avec les normes et standards existants : ... .

Dans le même esprit, cette affirmation : « Les développeurs d'applications pour Java Card approuvent l'utilisation du langage de programmation Java³¹ : » est purement commerciale. Vous pourriez a minima la neutraliser un peu en expliquant que les bénéfices que les développeurs peuvent espérer de l'usage du langage Java sur les plateformes Java Card sont...

« 3. Sécurité des javacard »

En l'état, cette section n'est pas satisfaisante.

Sur la forme, je vous rappelle encore une fois qu'il y a des usages prescrit pour la ponctuation des listes à puce (cf. Conventions typographiques). Je vous rappelle aussi que ces mêmes convention typographiques limitent le recours aux caractères en gras. Si vous voulez mettre en avant un concept important, donnez en une définition avec la syntaxe appropriée.

Sur le fond, il y a deux problèmes majeurs :

D'une part vous faites une confusion notable entre les mécanismes de sécurité cryptographiques promus par la « version 3 connectée », et ceux promus par les autres versions. Seul la version 3 dispose de communication réseaux sécurisées, d'HTTPS et des protocoles soujacents (TLS/SSL). Et cette version embarque aussi les moyens de vérifier, elle-même, les propriétés du bytecode lors d'un déploiement. Il convient donc que vous fassiez le tri dans vos affirmations selon la technologie à laquelle elle se rapporte, mais aussi que vous complétiez ces affirmations.

D'autre part, vous, ne traitez que des solutions de sécurités annoncées par la spécification. Il existe d'innombrables travaux sur les problématiques de sécurité liées aux mécanismes de partage de Java, aux mécanismes de contrôle d’accès et à tant d'autres aspects. En l'état, vos sources sont trop limitées et trop peu exploitées pour vous permettre de couvrir le sujet... Vous devez sortir le nez de la spec de Sun!

« 4. Historique »

En l'état, l'historique me parait bien courte et très centrée sur la spec. de la plateforme. Quid de la création des consortiums industriels. Quid de la sortie de plateformes équivalentes chez les concurrents. Quid des volumes de la date du premier milliard de Java Card vendues dans le monde...

« 5. Version Java Card »

Je ne comprends pas le rôle de cette section. En l'état il me semble qu'elle reprend les informations rapportées dans la section « 1.2 Java Card plateforme Version 3 ». Pour moi ces informations étaient bien ou elles étaient, mais elles semblent un peu plus complètes ici.

« 6. Concept de programmation »

En l'état, cette section ne traite pas de la version 3 connectée. L'idée de faire un parallèle entre les deux me semblerait être la bienvenue.

Sur la forme, les illustrations devraient être placées sur la droite, et le texte devrait en faire abstraction. Je vous rappelle qu'elles ne sont là que pour faciliter la lecture. Le lecteur qui n'aurait que le texte devrait quand même pouvoir comprendre. Par ailleurs le texte manque de références. Donnez la description d'une APDU selon le modèle ISO 7816-4. Évitez les sauts de ligne inutiles (utilisez des listes à puces et des définitions lorsque nécessaire). Présentez un graphique qui illustre ce que le lecteur envoi et ce que la carte répond dans les différents cas. Et surtout expliquer ce qui déclenche l'exécution de l'exemple que vous avez donné, et comment s'enchaine les octets.

« 7. Marché »

Cette section n'est pas satisfaisante. Vous parlez du marché des cartes à puce et pas du marché des plateformes Java Card. Je m'attends à trouver ici, la liste exhaustive des fabricants qui souscrivent au Java Card Forum (fin 2011) et la/les versions de la technologie qu'ils vendent. Je m'attends aussi à trouver une descriptions des différents domaines d'application des cartes à puce qui utilisent des cartes java, la part de marché de Java Card dans ces différents domaines. Je m'attends encore à trouver des informations de benchmark entre les différents produits proposes par les concurrents. Bref, cette section doit être enrichi avec des informations provenant de sources plus variées et donnant des éléments plus convaincants sur le déploiement de la technologie dans notre monde.

Bonne fin de rédaction.

Gilles.Grimaud (d) 28 novembre 2011 à 17:16 (CET)

Pour finir

Bonsoir,

Je ne ferais plus de relecture. Cependant, une fois votre travail de rédaction complété, je vous demande de revoir l'orthographe, de refaire une relecture complète (à la chasse aux phrases mal formées) et de vérifier votre document au regard de cette liste :

Liste de vérification

Liste de vérification

Type de remarque	À vérifier	Explication détaillée	Fait ?
Accessibilité	Les pratiques facilitant la lecture par les logiciels pour malvoyants ou pour non-voyants sont prises en compte dans la mesure du possible (un gadget peut être activé pour y aider).	Wikipédia:Atelier accessibilité/Bonnes pratiques
Conventions bibliographiques	Il existe sur Wikipédia des conventions bibliographiques, à respecter tant dans les références que dans la partie « Bibliographie » et dans les renvois bibliographiques.	Wikipédia:Conventions bibliographiques. Et voir les modèles {{ouvrage}}, {{chapitre}}, {{article}} et {{lien web}}
Guillemets	Si l'article contient des guillemets anglais : " ", il faut les remplacer par ceux-ci : « ».	Wikipédia:Conventions typographiques#Guillemets
Images	Les images n'ont pas de taille fixée, les schémas de plus de 350 px sont centrés, les photographies avec un ratio autre que 4/3 ou 3/4 sont réglées avec un « upright » ou « redresse » (équivalent) adéquat. Les images non indispensables sont supprimées, et les pages sur Commons sont liées. Les descriptions des fichiers des images (Commons inclus) devraient disposer d'une version en français.	Wikipédia:Mise en forme des images
Italique	L'italique est à réserver à un nombre de cas limités, comme l'emploi de termes étrangers et les titres d'œuvres (livres, albums musicaux, titres de chansons, etc.)	Wikipédia:Conventions typographiques#Italique
Langue des références	Les références en langue(s) étrangère(s) sont précédées du modèle l'annonçant : Anglais > {{en}} > (en), Allemand > {{de}} > (de), etc. Le paramètre langue= est à préférer pour les références utilisant des modèles bibliographiques.	Catégorie:Modèle d'indication de langue
Liens externes dans le corps du texte	Un lien externe ne doit pas figurer dans le corps de l'article mais doit être transféré en référence.	Wikipédia:Liens externes
Liens internes dans les titres	Les liens internes sont à éviter dans les titres des sections et les sous-sections de l'article.	Wikipédia:Liens internes#Accessibilité
Ligatures	L'article parle d'« oeuvre » (ou « Oeuvre ») et de « soeur » ? Il faut écrire « œuvre » (ou « Œuvre ») et « sœur ».	Wikipédia:Fautes d'orthographe/Courantes#Ligature
Majuscules	Une lettre normalement accentuée doit l'être également quand elle apparaît sous la forme d'une majuscule.	Wikipédia:Conventions typographiques#Accentuation
Nombre	La syntaxe formatnum ({{formatnum:123456789}}) permet de mettre en forme les chiffres isolés. {{Unité}} ou {{nobr}} est indispensable pour les chiffres suivis ou précédés d'une unité ou d'un nom.	Wikipédia:Conventions typographiques#Nombres et espaces
Note à appels multiples	Si deux passages de l'article sont sourcés par exactement la même référence, on utilisera <ref name=..> ou mieux {{Note|...}} ou {{sfn|...}}.	Aide:Note (aide détaillée)#Notes à appels multiples
Points	Mettre un point final à la fin de chaque phrase, verbale ou non ; en particulier, les légendes d'illustrations, les notes, les références de sources, etc.	Wikipédia:Conventions typographiques#Points
Ponctuation	Mettre une espace avant et après les ponctuations doubles (point-virgule, double point, point d'interrogation, point d'exclamation) ; une espace après les ponctuations simples.	Wikipédia:Conventions typographiques#Signes de ponctuation
Références et ponctuation	Les références précèdent la ponctuation et collent au dernier mot. Lorsque plusieurs références se suivent, elles sont séparées par {{,}}.	Aide:Note#Règles relatives à la ponctuation
Traduction	Lors d'une traduction, l'apposition du modèle {{Traduction/Référence}} sur l'article est obligatoire si un résumé de modification ne fournit pas l'information complète nécessaire.	Aide:Crédit d'auteurs#Modèles de crédit des auteurs

 

Bon fin de rédaction.

Gilles.Grimaud (d) 29 novembre 2011 à 00:40 (CET)