La semaine dernière, à l'occasion de la conférence BUILD, Microsoft a révélé ce qui est désormais sa stratégie concernant les développeurs. Entre appel aux applications Android et iOS, ergonomie des créations pour Windows 10 et disponibilité des outils de développement sur toutes les plateformes, il est question d'une philosophie qui n’a plus rien à voir avec un Microsoft tout puissant. L'occasion de faire le point.
Microsoft n’est plus dans une attitude de « domination du monde ». La firme souhaite désormais s'organiser pour faire venir les développeurs sur sa plateforme, qui se présente comme capable d’accueillir tous les talents et pratiquement tous les langages de programmation. Le message est clair : quoi que vous fassiez, vous pouvez le faire pour Windows 10. Qu'il s'agisse d'applications ou de services exploitant .NET, HTML5/CSS/JavaScript, C++, Java, Objective-C, peu importe, puisque tout peut être importé dans Visual Studio.
Les applications universelles : la voie royale
Une application universelle, désormais appelée UWP (pour Universal Windows Platform), est représentée par un unique fichier binaire capable de s’exécuter partout où Windows 10 est présent. PC, tablettes, smartphones et Xbox One seront donc dans la boucle. Côté développeur, le code est le même, et en suivant certaines recommandations, l’application peut se charger elle-même d’adapter son interface à la taille de l’écran, exactement comme le « responsive web design » de certains sites.
À l’occasion de l'édition 2015 de sa conférence BUILD, Microsoft a lancé la Release Candidate de Visual Studio 2015, qui revêt une importance capitale dans cette nouvelle façon de s'organiser. L’environnement de développement est l'outil principal pour la création de ces applications universelles, qui reprennent le concept déjà introduit dans Windows 8.1, tout en le portant nettement plus loin. Rappelons d’ailleurs que les éditions et tarifs de la version 2015 ont déjà été dévoilés, et qu’une mouture Community, gratuite, sera bien présente pour ceux qui travaillent seuls ou dans de petites équipes.
Pour qu’une application puisse être UWP, elle doit surtout répondre à un critère essentiel : plus l’écran est grand, plus elle révèle d’informations. On peut facilement observer des exemples dans la dernière mouture de Windows 10 (10074) avec Photos, Outlook ou encore Calendrier. En réduisant la fenêtre au minimum, on obtient pratiquement ce que l’on peut voir sur un smartphone. Plus on l’agrandit, plus les informations affluent, faisant apparaitre notamment des colonnes qui n’étaient pas là avant. À charge pour le développeur de définir comment son application va se comporter. Un point d’autant plus crucial que Microsoft a fait la démonstration de futurs téléphones qui seront capables de se comporter comme des unités centrales quand ils se connecteront à un écran plus grand. Les applications s’y afficheront alors comme elles le feraient sur un PC classique. Reste à voir les performances.
Il faut quand même noter que le développeur pourra décider quels supports il compte toucher avec son application. Durant la BUILD, on a pu voir par exemple que WeChat et Viber travaillent déjà sur des applications universelles. Mais WhatsApp, qui n’autorise qu’une seule session active pour sa messagerie, pourrait ainsi choisir de ne distribuer son application que pour les smartphones, en bloquant l’utilisation sur tablettes, PC et Xbox One. En outre, Microsoft encourage les éditeurs à adopter une licence unique par application (réutilisable donc sur tous les supports), mais ce choix est encore laissé à leur discrétion.
La différence, parfois un avantage autant qu’un boulet
Cette idée d’une plateforme unique et d’un seul type de binaire pour tous les développeurs a de quoi séduire. Cependant, sa réalisation sera un peu plus compliquée, notamment parce que Microsoft change de fusil d’épaule sur de nombreux points touchant à l’ergonomie. Cette dernière, si particulière sur Windows Phone, est sur le point d'être modifiée pour se rapprocher largement de ce que l’on trouve sur les plateformes concurrentes. Pour comprendre la différence, il faut retourner un peu dans le passé.
L’identité visuelle d’un produit ou d’une marque repose sur divers éléments. Sur le marché mobile, lorsque Microsoft a abandonné Windows Mobile pour Windows Phone, un choix important a été fait sur la manière dont le système devait se présenter aux utilisateurs, et comment il devait être utilisé. Une ergonomie très particulière est alors apparue, et elle est restée connue pour beaucoup sous le nom de « Metro ». Elle se signalait par un parti pris radical sur les interfaces : aucune structure géométrique, une organisation fondée sur les textes et la taille des polices, une iconographie simple basée sur la signalétique des rues et un dépouillement assez extrême.
Ces choix ont réellement fait de Windows Phone un produit à part, générant des réactions souvent tranchées. Ainsi, une partie des utilisateurs en est réellement « fan » et tient à cette différence. Mais dans un monde qui évolue sans cesse, surtout dans le numérique, une ergonomie donnée peut-elle être préservée longtemps ? Avec l’arrivée de Windows 10, Microsoft donne sa réponse : non.
Le hamburger de la discorde
Beaucoup ont remarqué que les nouvelles applications intégrées à Windows 10 contiennent un menu « hamburger » (que Microsoft appelle Split View). Il s’agit de ce fameux bouton affichant trois petites barres horizontales. Ce qui n’a l’air de rien au premier coup d’œil montre une volonté de casser une grande partie de l’ergonomie spécifique de l'OS mobile. La Split View rassemble en effet tous les éléments de navigation de premier niveau. Dans Outlook par exemple, il s’agit des dossiers, tandis que dans Calendrier, on retrouve une vue réduite du mois en cours ainsi que les catégories d’évènements.
L’avantage de ce menu « hamburger » est qu’il répond à une problématique complexe : si une application est appelée à s’afficher sur toutes les tailles d’écran, comment créer des contrôles cohérents afin que l’utilisateur s’y retrouve de manière constante ? Quand elle vient à manquer d’espace, les éléments de navigation du premier niveau se replient : la colonne disparaît et devient accessible à travers ce menu. Et pourtant, cet élément a déclenché à lui seul une tempête chez les développeurs.
Beaucoup reprochent à Microsoft de sacrifier ce qui faisait l’unicité de la plateforme. Thomas Nigro, l’un des développeurs de VLC (versions spécifiques pour WinRT et Windows Phone), nous résume d’ailleurs la situation : « Une bonne partie de la communauté est inquiète car elle voit des changements qui ne plaisent pas toujours et qui cassent ce qu’on avait l’habitude de voir. C’est bien d’avoir des éléments qu’on va retrouver sur tous les écrans, mais en l’état actuel, la Split View n’est pas forcément pratique parce qu’elle demande qu’on aille appuyer en haut à gauche de l’écran. On ne peut pas ouvrir le menu avec une seule main. »
Quand soudain, des guidelines
Cependant, la vision de ce que doit être une interface de type Windows 10 est beaucoup plus claire désormais. Microsoft a en effet publié plusieurs pages d’explications, et la vision est désormais bien plus précise, comme le pointe Nigro : « Les changements décrits sont énormes. Les interfaces semblent beaucoup plus claires, en reprenant des éléments d’iOS et Android. Les icônes sont beaucoup plus fines, les espaces sont dégagés et s’appuient sur des couleurs unies, et on sait maintenant sur quels contrôles on peut vraiment s’appuyer. »
Les contrôles en question sont donc le menu hamburger, les pivots, les onglets et les vues imbriquées. Aucune n’est réellement obligatoire. Même si des applications ont un menu hamburger, Microsoft indique clairement qu’il n’a d'intérêt que si le développeur souhaite y mettre des éléments de navigation. Par contre, l’arrivée des onglets montre que mêmes les fameux pivots (qui permettent de basculer entre les catégories de contenus) ne sont plus obligatoires, alors qu’il s’agissait clairement d’un point fort sous Windows Phone 7/8.
Microsoft fait du pied aux développeurs Android et iOS
Le fait que l’éditeur ait cherché à composer une ergonomie à mi-chemin entre un peu tout ce qui peut se faire actuellement, et donc plus classique, n’est absolument pas un hasard. Outre la nécessité d’interfaces adaptables à tous les écrans, il fallait pouvoir donner des équivalents d’éléments ergonomiques aux développeurs Android et iOS. Pourquoi ? Parce que tout est fait désormais pour qu’ils puissent porter facilement leurs applications sur Windows 10.
Une stratégie qui passe notamment par le nouveau Visual Studio Code, un environnement de développement disponible sous Windows, OS X et Linux. Gratuit, il est aussi allégé en fonctionnalités, même s’il reprend IntelliSense, des outils de débogage ou encore le support natif de Git. En dépit de ce qui a pu être lu ici et là, VSC n’est pas bâti sur l’éditeur Atom, mais sur une version spécifique de Visual Studio Online. Il utilise bien cependant le framework Electron de GitHub pour fonctionner, et il est donc développé en HTML5 et JavaScript, le moteur de rendu de Chromium (Blink) s’occupant du reste.
L’idée est simple : si un développeur dispose par exemple d’une application iOS, il peut importer le code en Objective-C (projet Islandwood), en modifier quelques lignes et exporter son projet sous forme UWP. L'éditeur King était d’ailleurs présent durant la conférence d’ouverture de la BUILD pour montrer comment Candy Crush fonctionnait après une telle opération, avec peu de retouches dans le code (quelques pourcents selon l'équipe) :
Pour Android, la situation est un peu plus complexe. Le projet Astoria va permettra à Windows « Mobile » (smartphones et tablettes) d’embarquer une machine virtuelle équivalente à Dalvik afin de faire fonctionner directement les applications Android, avec une compatibilité grimpant jusqu’à Kit Kat. Qu’il s’agisse de code Java ou C++, il pourra ainsi s’exécuter sans modification.
Toutes les applications ne fonctionneront cependant pas. Celles prévues spécifiquement pour ART (Android RunTime) et visant donc Lollipop ne pourront pas se lancer. Pour le reste, Microsoft devra préciser ce qu’Astoria sait faire ou non. La firme a indiqué que les API d’AOSP seraient pour la plupart supportées, mais la situation est beaucoup plus trouble pour les Google Play Services (GPS). Or, ces derniers sont uniquement fournis par Google et utilisés par de nombreuses applications.
Mais quid des interfaces ? Il y aura un « binding » automatique vers des classes .NET équivalentes, afin que l’application puisse s’afficher sous une forme qui rappellera Windows 10, sans pour autant offrir une apparence « native ».
Un mauvais message pour les développeurs ?
Les deux approches peuvent réellement permettre une accélération du remplissage du Store. Cependant, elles ont des défauts évidents. Le premier est l’aveu implicite d’échec et sa reconnaissance par Microsoft. Le message envoyé aux développeurs provoque la déception et rappelle bien trop l’histoire d’un BlackBerry obligé d’ouvrir les portes aux applications Android, notamment à travers un partenariat avec Amazon, pour rester attractif. D’un autre côté, Microsoft assume et procède avec un angle particulier.
Heureusement d’ailleurs, car le second problème est réel : la cohérence des interfaces. L’idée qui se cache derrière les importations et le fonctionnement des applications d’Android est de trouver des équivalents dans les classes .NET pour que tout fonctionne correctement. Mais si les développeurs veulent se contenter du chemin de moindre résistance, les applications qui apparaîtront de cette manière ne ressembleront pas à celles qui seront créées spécifiquement pour Windows 10.
Malheureusement, il semble que Microsoft n’ait pas eu le choix. Diverses sources nous ont ainsi indiqué que de grosses entreprises faisaient pression pour pouvoir réutiliser la plus grande partie possible de leur code. Il s’agissait d’ailleurs du gros point noir de Windows Phone : Android et iOS représentant à eux deux plus de 90 % des ventes de smartphones, il était délicat d’imposer de nouveaux outils et surtout une ergonomie particulière qui demandait un sérieux travail de préparation.
Il y a donc pour l’instant une véritable dichotomie, une séduction à deux visages. D’abord à ceux qui peuvent ou veulent partir directement sur des applications UWP, et qui réaliseront donc des interfaces clairement pensées pour Windows 10. Ensuite, un appel lancé à ceux qui sont sur des plateformes concurrentes, pour leur faire comprendre que les barrières qui pouvaient exister se sont estompées. Pour les entreprises travaillant sur du multiplateforme, le choix sera donc de savoir s’ils veulent aller au plus vite, ou s’ils ont le temps (et donc les moyens) de créer une application plus spécifique.
Très bien, mais que fait-on des applications de bureau ?
Pour autant, même si le SDK s’avère nettement plus riche, Microsoft ne compte pas forcer la main des développeurs vers WinRT : la plupart des applications Win32 classiques pourront être vendues directement dans le nouveau Store.
Toutes ne le pourront pas, car la technologie retenue pour y parvenir s’appuie sur AppV et fait donc intervenir en partie la virtualisation. Les programmes seront de ce fait encapsulés dans des conteneurs, qui seront alors exécutés sur le système, mais sans nécessairement avoir tous les droits, notamment ceux de l’administrateur. Pas question dès lors de toucher au bas niveau, d’accéder de manière précise au matériel ou de vouloir installer un pilote. Une situation qui conviendra pourtant à une grande majorité de logiciels existants. Adobe était d’ailleurs à la BUILD pour montrer une version fonctionnelle de Photoshop Elements ainsi empaquetée.
Globalement, toutes les technologies Microsoft utilisées jusqu’ici peuvent être reprises pour envoyer des applications dans le Store. Il y a plusieurs bénéfices à faire ainsi transiter les applications par la boutique. Les procédures d’installation et désinstallation sont bien plus « propres », tout ce qui provient du Store laissant nettement moins de traces. Surtout, elles pourront recevoir des mises à jour comme n’importe quelle application standard.
Un changement radical de stratégie
Il ne semble plus question pour Microsoft de dominer, du moins pour un bon moment. La société a perdu sur plusieurs terrains, et sa stratégie a été transformée pour s’adapter. Désormais, il faut considérer Windows 10 comme la plateforme sur laquelle venir développer, puisque tous les langages ou presque sont reconnus, d’une manière ou d’une autre. Et c’est précisément pour cette raison que la firme est en train de simplifier largement l’obtention de ses nouveaux produits.
Voilà pourquoi les tarifs de Visual Studio 2015 ont été revus à la baisse et l’édition Community reconduite. Voilà pourquoi Visual Studio Code débarque sur OS X et Linux. Voilà pourquoi Windows 10 sera gratuit durant sa première année de commercialisation pour ceux qui ont déjà une licence Windows 7 ou 8. Voilà pourquoi la licence du système ne coûtera rien sur tout appareil embarquant un écran de moins de 8 pouces (et donc une grande majorité d’objets connectés).
Mais même si la stratégie semble logique et bien pensée, elle n’est en rien une garantie de succès. La firme a compris depuis un moment que sa plus grande force réside dans ses outils de développement, et elle a donc décidé de se reposer complètement sur eux. Il manque cependant de nombreuses informations et beaucoup ont été déçus par exemple de n’avoir rien de vraiment neuf sur DirectX 12 ou sur la Xbox One mais peut-être que le prochain E3 sera l'occasion de quelques détails supplémentaires.
De plus, une autre conférence fait suite à la BUILD. Baptisée Ignite, elle remplace l’ancienne TechEd et est centrée sur l’entreprise. D’autres annonces devraient y prendre place cette semaine, notamment concernant les versions Server et la suite Office, qui a droit à une Preview de sa version 2016. Microsoft pourrait également en profiter pour lancer une nouvelle build de Windows 10 pour les smartphones, avec cette fois le Lumia 930 dans la boucle.
