Discussion :

[Stéphane le calme]

France : la PME Nexedi assigne Apple en justice à cause du moteur Webkit
qui est le seul autorisé sur iOS malgré son énorme retard en support des standards web

Nexedi, la PME française spécialisée dans les logiciels open source pour les entreprises, a entrepris d’assigner Apple au tribunal de commerce de Paris. Dans un billet de blog, la société s’explique : « la raison principale qui motive notre décision d'entreprendre cette action en justice est d'aider Apple à mieux supporter, et le plus rapidement possible, les versions les plus récentes des standards du Web dont HTML5 sur la plateforme iOS, le système d'exploitation de tous les iPhones ».

Pour illustrer ses propos, elle a vérifié le support de la technologie Web HTML5 sur iPhone sur la plateforme HTML5test qui est résumé dans le graphique ci-dessous. Nexedi estime qu’il apparaît que « le nombre de fonctionnalités couvertes par iOS est de loin inférieur à la couverture proposée par d'autres plateformes » .

La PME dirigée par Jean-Paul Smets qui compte 30 salariés pour un chiffre d’affaires annuel de 1,5 million d’euros n’hésite pas à monter au créneau avec le Goliath en face d’elle. Voici une liste de choses que vous ne pouvez pas faire sur un iPhone en Octobre 2016, et que vous pouvez faire sur n'importe quelle autre plate-forme, regrette la PME :

• Utiliser le tableur HTML5 OfficeJS en mode non-connecté (car iOS n'implémente pas les service workers) ;
• Participer à une vidéo-conférence Hubl.in (manque de WebRTC) ;
• Regarder des vidéos encodées dans le format webm (manque du support webm).

Nexedi rappelle qu’il ne s’agit pas là d’une situation nouvelle : les progrès d'iOS en termes de support HTML5 sont moins rapides que pour d'autres plateformes. D’ailleurs, le fossé entre iOS et les autres smartphones a même plutôt tendance à se creuser. Mais pour quelles raison ? La PME voit un vecteur : Safari, le navigateur web d’Apple. Et de rappeler que « Safari est aussi en retard sur les stations de travail MacOS, en termes de support HTML5 ». Sur 555 critères de compatibilité étudiés, Safari obtient une note de 370 seulement, très loin derrière Google Chrome (492), Firefox (461) ou même Microsoft Edge (460).

En général, pour palier à cette situation, Nexedi recommande, à ses utilisateurs ainsi qu’à ses clients, d'installer un autre navigateur web sur MacOS afin qu’ils puissent ainsi profiter d'un meilleur support HTML5. « Nous avons essayé cette même approche concernant iOS. Nous avons essayé Chrome sur iOS et nous nous sommes rendus compte que le support HTML5 de Chrome sur iOS est globalement le même que le support HTML5 de Safari sur iOS. En d'autres termes, Chrome sur iOS est en retard par rapport à Chrome sur n'importe quelle autre plateforme », a indiqué Nexedi.

Après avoir mené sa petite enquête, l’entreprise a compris la raison pour laquelle cette situation a été possible : « nous avons compris qu'Apple exigeait des développeurs souhaitant publier leurs applications sur l'AppStore de se conformer à un contrat. Dans sa version Française, ce contrat stipule qu'Apple n'autorise pas la publication dans son App Store de toute application qui télécharge et exécute un logiciel externe, à l'exception du Webkit intégré d'Apple ».

Or, « un navigateur web est une application qui, entre autres, télécharge et exécute du code Javascript. En conséquence, il est interdit de publier un navigateur web sur l'App Store d'Apple, à moins qu'il ne s'agisse d'un navigateur web construit sur la bibliothèque Webkit intégrée par Apple. Voici donc pourquoi le navigateur Chrome sur iOS dépend de la bibliothèque Webkit d'Apple plutôt que de sa propre bibliothèque plus moderne, Blink, utilisée sur toutes les autres plateformes. Voici aussi pourquoi le support HTML5 de Chrome sur iOS n'est pas significativement meilleur que celui de Safari ».

Nexedi rappelle que nombreuses sont les entreprises qui ont souffert de cette situation : « Certaines d'entre elles ont d'ailleurs déjà supplié Apple d'améliorer le support d'HTML5 sur iOS sans résultat significatif ».

Alors pourquoi ne pas simplement se résoudre à abandonner iOS ? La PME estime que cette option n’est pas envisageable car sur de nombreux segments de marché comme les dirigeants du monde entier ou les classes moyennes-supérieures en Chine, l'iPhone est dominant et ses utilisateurs sont loyaux. Aussi, « arrêter la prise en charge d'iOS signifierait pour Nexedi d'arrêter le support de nos applications sur l'un des marchés les plus importants du monde (la Chine), ainsi que celui des personnes qui décident ou non de payer nos factures (les dirigeants d'entreprises dans le monde entier) ».

Pour le moment, la seule option choisie par Nexedi est de contourner les limitations du support HTML5 pour iOS. Un effort qui représente un coût supplémentaire de 50.000 euros par an pour son logiciel phare ERP5, le progiciel libre de gestion intégré en licence open source et concurrent de celui de SAP. L’entreprise évoque jusqu’à 770.000 euros de préjudice mis bout à bout en comptant le personnel à embaucher spécifiquement, les tests et débogages nécessaires, etc. « Le même effort que nous dépensons actuellement pour prendre en charge iOS en rendant rétro-compatible notre code HTML5 aurait pu être utilisé pour développer de nombreuses innovations ou contenus libres », regrette l’entreprise.

Le tribunal de commerce est donc appelé à sanctionner « toute clause ou pratique contraire à la loyauté et à l’équilibre des relations commerciales ». « Apple propose de très bons produits, appréciés par nos clients, mais nous voulons les conduire à faire des produits meilleurs, non excluants » , explique Jean-Paul Smets

Source : Nexedi

Voir aussi :

Dash est banni de l'App Store : Apple accuse le développeur d'avoir payé pour de faux commentaires, la situation provoque une vague de mécontentement

Révocation des certificats WoSign/StartCom : Apple a décidé de les bloquer sur iOS et OS X pour une durée indéterminée

[Patatruc]

Je vois peut-être les choses trop en noir, mais j'ai toujours eu le sentiment que cette firme, connue pour son faible appétit financier, limitait volontairement les capacités de son navigateur afin de pénaliser les applications Web et drainer un maximum de clients vers son store (il faut que ce soit et que ça reste un réflexe). Le web ne lui rapportant aucun revenu.

En tout cas, je ne vois pas trop comment expliquer autrement à la fois le blocage de tout navigateur réellement alternatif sur iOS et cet immobilisme par rapport aux normes actuelles, alors que cette société brasse les milliards et pourrait sans problème faire aussi bien que Chrome et consorts.

[HippoBaro]

je ne vois pas trop comment expliquer autrement [...] le blocage de tout navigateur réellement alternatif sur iOS

Pour le coup je comprend la position d'Apple. Le problème n'est pas d'interdire les navigateurs concurrents, mais d'interdire la compilation/exécution de code par une app tierce.
Un moteur javascript, essentiellement, compile Juste A Temps (JIT) un code javascript en bytecode natif, puis le dump dans un segment de mémoire, et demande au système d’exécuter ce code. Cela ouvre la porte à de très, très nombreux problèmes de sécurité.
Apple est très prudent avec les applications tierces : sandboxing intégral, aucun accès au système sauf au travers de ces Frameworks. C'est ce qui fait la force de l'écosystème.

[TiranusKBX]

Je les comprend à râler, moi même sur les WebApp je passe 1/3 de mon temps de dev à faire la compatibilité IOS à cause du comportement aberrant de leur moteur JS et sa sur-consommation mémoire obligeant à mettre des temporisations sur les traitements un peut long si l'on veut éviter les freeze.
Il ya aussi le fait qu'il est impossible d'avoir une Websocket et une requête AJAX en même temps obligeant à l'usage d'un WebWorker dédié pour chaque connexion.
Mais aussi un support du SVG lamentable(en dehors d'une balise image)
Dans le genre blague de mauvais goût il y a aussi le clavier qui n'apparait pas si le haut et le bas de la page son en position:fixed;
bon je ne vais pas tout lister sinon je vais en avoir pour des heures et cela ne ferait que me frustrer d'avantage, mais même faire les adaptation pour IE6 est moins chiant

[Elepole]

Pour le coup je comprend la position d'Apple. Le problème n'est pas d'interdire les navigateurs concurrents, mais d'interdire la compilation/exécution de code par une app tierce.
Un moteur javascript, essentiellement, compile Juste A Temps (JIT) un code javascript en bytecode natif, puis le dump dans un segment de mémoire, et demande au système d’exécuter ce code. Cela ouvre la porte à de très, très nombreux problèmes de sécurité.
Apple est très prudent avec les applications tierces : sandboxing intégral, aucun accès au système sauf au travers de ces Frameworks. C'est ce qui fait la force de l'écosystème.

Sauf que qui dit que leur le webkit intégrée a iOS est vraiment sécurisé ? Apple n'a pas un historique très glorieux concernant la sécurité, c'est assez ironique de bloque la concurrence pour des raison de "sécurité" alors qu'il est très probable que la concurrence serait probablement mieux sécurisé qu'eux.

[HippoBaro]

Sauf que qui dit que leur le webkit intégrée a iOS est vraiment sécurisé ? Apple n'a pas un historique très glorieux concernant la sécurité, c'est assez ironique de bloque la concurrence pour des raison de "sécurité" alors qu'il est très probable que la concurrence serait probablement mieux sécurisé qu'eux.

Sources ? Apple a des soucis de sécurité comme les autres. Pas plus, pas moins. Mais oui, effectivement, n'autoriser que WebKit permet de limiter les vecteurs d'attaques.

[Tagashy]

@Hippoberro
Je pense que ce que elecole veut dire c'est plus en rapport avec le fait que longtemps apple a crasher sur les chercheurs en sécurité et au lieu de les récompenser quand il trouvais des failles, il leur colle un proces
Pour preuve regarde le programme bug bounty d'apple il est tres recent

[frfancha]

Pour le coup je comprend la position d'Apple. Le problème n'est pas d'interdire les navigateurs concurrents, mais d'interdire la compilation/exécution de code par une app tierce.
Un moteur javascript, essentiellement, compile Juste A Temps (JIT) un code javascript en bytecode natif, puis le dump dans un segment de mémoire, et demande au système d’exécuter ce code. Cela ouvre la porte à de très, très nombreux problèmes de sécurité.
Apple est très prudent avec les applications tierces : sandboxing intégral, aucun accès au système sauf au travers de ces Frameworks. C'est ce qui fait la force de l'écosystème.

Admettons.
Cela pourrait justifier de forcer d'utiliser "leur" webkit.
Mais cela ne justifie pas qu'Apple minimise son investissement dans le développement de son webkit et d'en faire un truc à la ie6. Au contraire même puisque c'est le seul dispo.

[HippoBaro]

Admettons.
Cela pourrait justifier de forcer d'utiliser "leur" webkit.
Mais cela ne justifie pas qu'Apple minimise son investissement dans le développement de son webkit et d'en faire un truc à la ie6. Au contraire même puisque c'est le seul dispo.

Complètement d’accord. Surtout que c'est contre-productif de leur part.

[Battant]

Bonjour,
Je ne comprends pas pourquoi cette société fait un procès. A-t-elle essayé de rentrer en négociations avec Apple quitte a engagé un médiateur ?
Une petite question parallèle
Meilleures salutations

[Battant]

Bonjour,

Est-ce que le langage python travaille aussi avec le Justin Time compilèrent ? Si oui Apple pourrait également interdire l'utilisation du langage python comme c'est le cas pour Java pour le développement d'applications iPhone ou iPad . Est-ce que c'est vrai ?
Merci pour le renseignement