Cet article décrit les différents prérequis qu'une application doit satisfaire avant de pouvoir être publiée par le Firefox Marketplace. Ces critères sont pensés pour répondre aux besoins des développeurs d'applications du Firefox Marketplace autant qu'à ceux de leurs utilisateurs. Les développeurs attendent des critères équitables, universels et réalistes auxquels ils peuvent se fier pour concrétiser leurs idées. D'un autre côté, les utilisateurs veulent être assurés que les applications soient sûres, fonctionnelles et fassent bien ce qu'elles sont censées faire. Les prérequis listés ci-dessous servent à trouver un équilibre délicat entre ces différents besoins.

D'après Mozilla, les modalités d'une évaluation d'application sont :

  • Les critères doient être appliqués de manière équitable, juste et cohérente. Le processus d'évaluation d'application ne doit pas être un obstacle mais bien un point de contact qui fournit des commentaires permettant d'aider les développeurs à aboutir.
  • Les évaluateurs n'ont pas pour vocation d'être une équipe de contrôle de qualité ! Durant le processus d'évaluation, quelqu'un regardera le manifeste de l'application et passera quelques minutes à l'utiliser comme un utilisateur lambda.
  • Si l'application échoue, le développeur recevra une explication claire sur les problémes rencontrés ainsi que la maniére de les reproduire. Si possible, l'évaluateur indiquera au développeur la bonne direction par la fourniture de liens vers les documents pertinents ou de recommandations sur les changements nécessaires.
  • Les évaluateurs ne jugent pas l'apparence d'une application, mais seulement son fonctionnement. Par exemple, une application avec un paragraphe en texte rouge écrit sur fond orange ne sera pas rejetée parce qu'elle est hideuse mais pourra l'être si le paragraphe est illisible.
  • Nous laissons toujours le bénéfice du doute aux développeurs. Si nous hésitons à refuser une application, des évaluateurs poseront toujours des questions avant de la rejeter. Les applications ne sont pas (sciemment) refusées pour des problémes de compatibilité avec une platefoirme (qui ne sont pas contrôlables par les développeurs) ; cependant nous pouvons différer notre approbation si nous ne parvenons pas à faire fonctionner l'application.

Sécurité

Tous les détails de l'architecture de sécurité des applications sont disponibles ici : https://wiki.mozilla.org/Apps/Security

  • Le manifeste d'application doit être disponible à la racine de l'application.
  • Le manifeste d'application doit contenir l'en-tête Content-Type de application/x-web-app-manifest+json.
  • Les applications ne doivent pas utiliser de redirection ou d'"iframes" pour charger le contenu que le développeur n'est pas autorisé à utiliser.
  • Les permissions requises doivent être spécifiées dans le manifeste de l'application, avec la description des raisons pour lesquelles ces autorisations sont nécessaires.
  • Les applications de type privileged recevront des vérifications supplémentaires, incluant notamment un contrôle du code, pour vérifier l'absence d'activité malveillante et de perte de données utilisateur rendues possibles par les APIs privileged.
  • La politique de sécurité du contenu (CSP) définit, dans le manifeste d'application, ce que le code source de l'application peut faire. La valeur par défaut, si elle n'est pas spécifiée, pour les applications non privilégiées est la même que pour n'importe quel site Web ; les applications de type privileged doivent répondre à une CSP plus restrictive. Le rapport de validation créé à la soumission d'une application sur le Firefox Marketplace indiquera les violations potentielles de la CSP dans votre application - méfiez-vous malgré tout des faux positifs et des demandes de certains modules de bibliothèques tierces que vous n'utilisez pas.

Confidentialité

Le développeur devra fournir un lien vers la politique de confidentialité utilisée pour son application lors de sa soumission. Il n'y a, en revanche, pas de restriction concernant le format ou le contenu de cette politique de confidentialité. N'hésitez-pas à utiliser notre modèle de politique de confidentialité. Regardez également nos directives sur la politique de confidentialité.

Contenu

  • Toutes les applications qui enfreignent nos directives de contenu, spécifiées ci-après, ne seront pas autorisées. Si vous pensez être dans une situation limite, n'hésitez pas à demander des explications à l'équipe d'évaluation, et ce, même si l'application n'est pas encore prête pour une soumission. Nous voulons vous aider à rester sur la bonne voie, plutôt que d'investir du temps de développement dans un contenu qui sera rejeté.
  • A partir de janvier 2014, toutes les applications doivent recevoir une note de la part de l'International Age Rating Coalition (IARC). Pour obtenir cette note, nous vous dirigeons vers un bref questionnaire au cours du processus de soumission, et vous recevrez immédiatement la note. Des informations supplémentaires sur le processus d'évaluation sont disponibles ici.
  • Les captures d'écran et descriptions soumises sur le Firefox Marketplace doivent représenter l'application avec précision. Vous pouvez inclure 1 ou 2 images vendeuses, qui prouvent la compatibilité, comparent les caractéristiques, ou de manière générale, suscitent l'intérêt, mais il doit aussi y avoir au moins une capture d'écran de l'application en fonctionnement, pour que les utilisateurs puissent prévisualiser ce qu'ils vont réellement obtenir. Si l'une de vos captures d'écran montre un écran de démarrage ou de lancement, vous devez également inclure une capture d'écran de la partie fonctionnelle de l'application.
  • Dans le manifeste de l'application, les clés locale doivent correspondre aux localisations que votre application prend en charge. En spécifiant une clé locale en polonais, les utilisateurs s'attendent à ce que votre application soit disponible dans cette langue.
  • L'icône de l'application doit suivre le Firefox OS app icons style guide. Seule une icône 128x128 est obligatoire, mais nous vous recommandons également une icône 512x512 (pour plus de détails, voir Icon implementation for apps.)  À noter, ces icônes peuvent être rondes, carrées aux angles arrondis ou carrées, selon le guide de style.

Règles de contenu

Cette liste décrit les types de contenu qui ne sont pas appropriés sur le Firefox Marketplace. Cette liste est indicative, non définitive, et peut donc être mise à jour. Si une application est jugée contraire à ces règles de contenu, Mozilla a le droit de retirer immédiatement l'application du Marketplace Firefox.

  • Pas de matériaux pornographiques obscènes, ou de représentations graphiques de sexualité ou de violence.
  • Pas de contenu violant les droits de quelqu'un, y compris la propriété intellectuelle ou d'autres droits de propriété, ou les droits de confidentialité ou de publicité.
  • Pas de contenu visant à nuire à Mozilla ou à ses utilisateurs (tels que du code malveillant, des virus, des logiciels espions...).
  • Pas de contenu illégal ou faisant la promotion d'activités illégales.
  • Pas de contenu trompeur, frauduleux, conçu pour le phishing ou autres vols d'identité.
  • Pas de contenu faisant l'apologie des jeux d'argents.
  • Pas de contenu faisant la publicité de produits ou services illicites ou contrôlés.
  • Pas de contenu exploitant des enfants.
  • Pas de contenu qui dégrade, intimide, menace, incite à la violence, ou encourage des actions préjudiciables contre quelqu'un ou un groupe basées sur l'âge, le sexe, la race, l'origine ethnique, l'origine nationale, la religion, l'orientation sexuelle, le handicap, la religion, la situation géographique ou toute autre catégorie protégée, ou qui constitue un discours de haine.
  • Aucun contenu qui trompe un utilisateur et le pousse à prendre une décision d'achat.

Fonctionnalité

  • L'évaluateur doit être en mesure de mettre en oeuvre les fonctionnalités annoncées de l'application. Les défauts superficiels et les inconvénients mineurs seront signalés au développeur, mais n'empêcheront pas l'approbation d'une application.
  • L'application ne doit pas compromettre les performances ou la stabilité du système.

Ergonomie

  • Le développeur doit tenter raisonnablement d'optimiser la mise en page de l'application pour la plate-forme cible. L'objectif de cette exigence est d'empêcher des échecs évidents, tels que :
    • Une application soumise pour mobile qui est de façon évidente pour un site de bureau.
    • Une application qui visiblement ne s'étend pas pour remplir l'espace d'écran disponible (imaginez une application de 320x480 qui ne prend que le coin supérieur sur une tablette, le reste de l'écran demeurant vierge. Ce n'est certainement pas attendu !)
  • L'application doit mettre en œuvre sa propre méthode de navigation et ne pas compter sur le bouton Chrome du navigateur ou un bouton arrière du matériel qui ne sera pas présent sur tous les périphériques.
    • Par exemple, une application sera rejetée si l'évaluateur navigue quelque part dans l'application et ne peut pas revenir en arrière. Les applications ne sont PAS nécessaires pour implémenter une barre de boutons commune aux applications natives.
    • Sur Firefox OS v1.1 et versions ultérieures, vous pouvez ajouter la propriété de manifeste chrome pour ajouter des contrôles de navigation minimaux.
  • Les éléments de navigation, tels que les boutons et les liens, doivent être faciles à cliquer ou à utiliser.

Politique de blocage

Nous espérons que nous ne devrons jamais l'utiliser, mais nous nous réservons le droit de supprimer ("blocklist" (en) "liste noire" ou "liste de blocage" (fr)) toute application publiée qui est plus tard considérée comme contraire aux exigences de sécurité, de confidentialité ou de contenu ; ou des applications qui dégradent sérieusement les performances du système ou du réseau. Les développeurs seront informés de la situation avant qu'une application soit bloquée ; ils seront présupposés être de bons citoyens, à moins que nous ayons des preuves précises. Nous recevrons une assistance complète de l'équipe d'évaluation des applications pour communiquer sur ce qui se passe et résoudre le problème. Des exemples spécifiques, de situations où la liste de blocage est justifiée, comprennent :

  • Phishing
  • Spamming
  • Modification du contenu de "Images de poupées v1.0" à "Violence brutale v1.0" (sans actualiser la note de contenu)
  • Un mauvais comportement (grave) de l'application pour un grand pourcentage d'utilisateurs - dégradant les performances du téléphone, provoquant des redémarrages, provoquant une perte de données utilisateur, etc. - pour lequel les utilisateurs ne peuvent pas dire que c'est à cause de l'application et s'il n'est pas résolu en redémarrant l'appareil.
  • Une application utilisée pour des attaques sur le réseau, tel qu'un déni de service distribué (DDOS)

Plus d'informations

Les ressources suivantes fournissent plus d'informations sur le processus d'évaluation des applications et les commentaires :

  • Reviewers test criteria — cette page décrit les tests que les évaluateurs effectueront sur votre application.
  • App reviewers — comment contacter l'équipe d'évaluation et participer à l'examen des applications.

 

Étiquettes et contributeurs liés au document

Contributeurs à cette page : loella16, BBavouzet, arkzy, teoli
Dernière mise à jour par : loella16,