Introduction

En tant que développeur et formateur WPF depuis plusieurs années les nouvelles orientations de Microsoft pour les plateformes clientes, avec la montée en puissance du tout nouveau WinRT, m’ont quelque peu inquiétées.

Et pour cause : j’ai directement subi l’échec et l’abandon de Silverlight et comme dit le proverbe “chat échaudé craint l’eau froide”.
Depuis 2009 j’ai beaucoup investi, personnellement et professionnellement, dans WPF, l’utilisant pour développer des applications LOB dans le secteur financier, et désormais je dispense même des formations sur le sujet.
Par conséquent le futur de WPF est critique pour moi, c’est pourquoi j’ai étudié cette question de l’avenir de WPF plus en détails, mettant en oeuvre mon expertise sur le sujet et ma récente découverte de WinRT.

Dans cet article je partagerai avec vous les résultats de cette “étude” en toute objectivité et transparence, afin de vous aider en tant que partie prenante dans votre veille technologique.
J’espère que vous fournirez vos propres informations, afin que la communauté toute entière puisse avoir une meilleure vision des perspectives pour WPF.
Dans la dernière partie de l’article je fournis des stratégies pour les entreprises et les développeurs utilisant WPF.

Des raisons de s’inquiéter

Je commence par vous présenter les signes qui m’inquiètent, et devraient également vous inquiéter si vous êtes partie prenante WPF.

Le blog de l’équipe WPF est inactif

Comme toute équipe technique Microsoft, l’équipe responsable du développement de WPF possède un blog où ses membres partagent avec la communauté leur expertise WPF.
Le dernier article de ce blog a été publié en mai 2011 soit il y a plus de 3 ans, précisément au moment où WinRT commençait à apparaître comme le prochain projet majeur de Microsoft.
Un blog inactif peut signifier beaucoup de choses mais à mon avis rien de bon : très probablement l’équipe a été dégraissée au strict minimum et l’animation du blog n’est plus une priorité, peut être que les meilleurs éléments ont été affectés à d’autres projets comme WinRT, et peut être est-ce intentionnel pour envoyer un signal à la communauté…

En termes de communication un blog actif est essentiel car il montre que la technologie évolue et est développée par des développeurs enthousiastes et fiers de leur travail souhaitant partager avec la communauté.
Il faut noter que souvent les blogs MSDN ne sont pas des plus actifs, celui d’Entity Framework faisant exception, grâce à Rowan Miller qui publie régulièrement de nouveaux articles, et c’est l’une des raisons pour lesquelles j’apprécie cette technologie : elle est développée par des gens brillants et investis.

Le toolkit officiel n’est plus développé

Le Toolkit WPF est un projet gratuit et open-source développé par les équipes de Microsoft et conçu pour servir d’antichambre aux versions officielles de WPF.
Par exemple la DataGrid ne faisait pas partie de la version initiale de WPF (3.0 + 3.5) mais était disponible via le toolkit, et elle ne fût ajoutée officiellement qu’à partir de WPF 4.
Le toolkit a fait son office jusqu’en 2010, mais depuis le projet est inactif, donc il semblerait qu’il n’y ait plus grand chose en magasin pour une éventuelle prochaine version de WPF.
Signe de cette inactivité : la recherche “WPF Toolkit” sur Google classe le toolkit officiel second après un non-officiel (je reviendrai sur celui-ci dans la seconde partie de l’article).

Plus de certification

La certification WPF officiel (70-511) ne sera pas prolongée et arrivera à expiration à l’été 2015.
C’est sans doute l’un des signes les plus forts envoyés aux développeurs WPF : ils ne devraient pas investir plus de temps dans cette technologie et au contraire devraient consacrer du temps à WinRT qui lui bénéficie d’un nouveau cycle de certification.
Peut-être que Microsoft renoncera et repoussera un peu ce retrait comme cela a été le cas pour d’autres certifications après que les développeurs se soient plaints, mais cela ne changera rien au fait que WPF n’est plus la priorité.

Personnellement j’hésite encore à la passer tout simplement parce que j’ai peu de garantie que le temps et l’argent (oui en tant qu’entrepreneur c’est bibi qui paye) dépensés valent le coup.
Pour le moment je préfère monter en compétences sur WinRT et préparer les certifications qui y sont dédiées et qui devraient être valables encore de nombreuses années.

Pas d’intégration Windows 8

Pour ceux qui se souviennent de la sortie de WPF 4, une grande partie des nouvelles fonctionnalités étaient dédiées à l’intégration Windows 7 comme la personnalisation des éléments de la barre des tâches (jump-lists, progression, overlay…).
Ce ne fût pas le cas avec WPF 4.5 qui ne bénéficie pas d’un tel effort d’intégration avec les nouvelles fonctions de Windows 8+ comme la charm-bar et les nombreux contrats applicatifs, bien qu’il y ait des interfaces d’interopérabilité.
Si Microsoft n’a pas investit dans cette intégration cela démontre clairement que WPF n’est plus une technologie de 1^er ordre au sein de Windows et que tout l’effort de développement est concentré sur WinRT, ce qui à mon avis est une décision sensée.

Pas de support Windows RT

Microsoft, historiquement un vendeur de logiciel, diversifie ses activités en devenant un vendeur de matériel, imitant ainsi ses concurrents Apple et Samsung.
A cette fin Microsoft a acquis Nokia afin de bénéficier de sa présence historique sur le marché de la téléphonie mobile.
Côté tablettes et ordinateurs portables, pour concurrencer les tablettes Apple iPad ainsi que ses ordinateurs portables MacBook Pros, Microsoft a lancé la gamme Surface.
Il y a 2 déclinaisons des Surface 1 et 2 en fonction de l’architecture matérielle : x86 et ARM, ce dernier bénéficiant d’une verison dédiée de Windows : Windows RT (à ne pas confondre avec WinRT qui est une couche logicielle commune).
Mais Windows RT ne supporte pas (du moins officiellement) les anciennes APIs comme le bon vieux Win32, et donc ne supporte pas toutes ses “surcouches” comme WinForms et … WPF, donc il n’est pas possible d’exécuter des applications WPF sur toutes les versions de la Surface.
Et si Microsoft n’a pas investit dans cette compatibilité c’est aussi parce qu’il tente de se débarrasser de Win32 qui doit être remplacé par WinRT qui est spécialement conçu pour répondre aux nouveaux besoins.

La nouvelle stratégie de Microsoft

En février 2014 Microsoft nomma un nouveau CEO, Satya Nadella, qui est issu du département cloud de Microsoft.
Il a remplacé Steve Ballmer, qui n’avait pas pris la mesure du marché du mobile (d’abord l’iPhone puis Android) ce qui est probablement l’une des raisons pour lesquelles Microsoft a complètement raté le coche et doit désormais se battre pour se faire une place en grapillant pourcent après pourcent des parts de marché à la concurrence (Apple, Samsung).
En opposition avec son prédécesseur la nouvelle stratégie globale pour Microsoft de Satya Nadella est “cloud first and mobile first“, mettant donc de côté le modèle traditionnel PC de bureau, et de nouveau c’est une stratégie des plus sensée.
Mais WPF a précisément été conçu pour le “vieux” modèle : celui des applications de bureau dites “lourdes”, alors que WinRT répond à un modèle totalement différent, prenant en compte les nouveaux besoins mobiles.
Bien sûr le marché du PC est loin d’être mort, mais il n’est plus désormais le modèle exclusif et prédominant.

Le Windows Store

Afin de capturer une part des revenus des vendeurs d’applications la plupart des propriétaires de plateformes logicielles comme Apple et Microsoft ont créé des “stores” par lesquels il faut passer pour publier et acheter les applications.
Et malheureusement à ce que je sache les applications Windows Store doivent reposer sur WinRT, donc les applications WPF ne peuvent y être distribuées.
Notez que ce n’est pas un souci pour les entreprises qui déploient leurs applications en interne et n’ont aucun besoin d’un store, ni pour les éditeurs de grosses applications professionnelles comme les ERPs qui utilisent leurs propres réseaux commerciaux pour vendre et déployer leurs applications, mais c’est un vrai problème pour les petits éditeurs, souvent individuels, qui ont besoin de la visibilité du store et ne pas l’utiliser c’est prendre le risque de se faire manger des parts de marchés par un concurrent.
Désormais de plus en plus de personnes utilisent mécaniquement les stores pour rechercher de nouvelles applications donc il est impossible de passer à côté.
Par conséquent si vous planifier de développer votre prochaine application en WPF vous risquez d’avoir de grandes difficultés à la distribuer, d’autant plus si vous comptez la vendre, donc vous devriez plutôt utiliser WinRT.

La mobilité

Vous consommez probablement une grosse partie des contenus digitaux via votre téléphone mobile en utilisant des applications web ou natives donc vous comprenez à quel point il est important aujourd’hui d’être présent sur le marché du mobile : il est quasi obligatoire de fournir une version mobile de vos applications.
WPF n’a jamais été destiné au développement mobile et il n’est donc pas un acteur de ce marché, et pendant des années l’alternative mobile fût Silverlight for Windows Phone qui a été le support de référence jusqu’à Windows Phone 7.
Mais utiliser un outil différent par plateforme est loin d’être idéal, bien qu’il était possible de partager la plupart du code procédural (C#) et de balisage (XAML).
WinRT est une réponse à ce problème car il constitue un outil commun conçu pour faciliter le développement sur toutes les plateformes Windows qui sont elles-mêmes de plus en plus uniformisées au niveau même de l’OS avec Windows 8+.

A noter que pour un véritable développement multi-plateforme visant en plus Android et iOS Microsoft ne fournit aucun outil, et il faut se tourner vers Xamarin qui est un projet très prometteur.

Les coûts de maintenance

Si vous travaillez avec les technologies Microsoft depuis quelques années vous savez que Microsoft dépense son argent avec parcimonie, et pour de bonnes raisons : premièrement en tant qu’entreprise elle doit gagner de l’argent pour survivre, sans compter que de nos jours les actionnaires sont plus gourmands, donc un sou est un sou ; de plus la moindre petite fonctionnalité peut vite devenir très coûteuse parce que le processus de développement est très strict ; Eric Lippert en donne un aperçu dans cet article : How many Microsoft employees does it take to change a lightbulb?
Donc quand la communauté réclame une correction de bug ou une nouvelle fonctionnalité, l’implémentation n’en sera faite que si l’impact est conséquent :
– soit d’une grande criticité comme une faille de sécurité, où même un nombre réduit de clients impactés justifie le développement
– ou bien mineur mais gênant un grand nombre de personnes.
Déveloper à la fois WPF et WinRT impliquerait de répondre à toutes les demandes de fonctionnalités et correction de bug des deux outils, ce qui n’est clairement pas envisageable, particulièrement en cette période de dégraissage chez Microsoft.

Portabilité

Ce qui aurait pu “sauver” WPF serait d’éventuels cas d’utilisation de niche, par exemple en tant qu’outil multiplateforme de développement d’applications client, mais ce n’est malheureusement pas le cas.
Il y a bien une version multiplateforme de .Net (de la CLI pour être pointilleux) : Mono, qui tourne sous Windows bien sûr mais aussi sur Linux, Unix et Mac OS.
Et Mono est loin d’être un jouet, il fonctionne réellement, je l’ai moi-même utilisé pour monter un serveur d’intégration continue Jenkins sur Ubuntu Server.
Mono supporte la plupart des fonctionnalités du framework .Net mais un des rares composants manquant est WPF ; si je me souviens bien il a existé un projet d’implémentation nommé “Olive” mais il n’a jamais vraiment été démarré en raison de la quantité de travail que cela représente, notamment au niveau des couches basses de rendu.
La seule technologie pour le développement d’interfaces graphiques implémentée par Mono est WinForms qui ironiquement grâce à cette portabilité pourrait survivre à WPF.

Le syndrome Silverlight

En tant qu’ex-développeur Silverlight j’ai appris à mes dépends que les technologies peuvent disparaitre beaucoup plus rapidement que prévu.
Retour en 2008/2009 : RIA est un buzz-word, Microsoft fait la promotion de son propre framework, Silverlight, présenté lors des différents évènements Microsoft comme le futur, et tout logiquement les décideurs IT se mettent à l’intégrer à leurs écosystèmes.
Donc de 2010 à début 2011 nous aussi commençâmes à développer des applications Silverlight.
Mais très vite, dès 2011 donc, lors d’un évènement technique, à propos du web, étrangement Silverlight n’était plus sur le devant de la scène, et au contraire on nous faisait la promotion de l’écosystème HTML5 (avec CSS et JS) en totale contradiction avec le discours des années précédentes.
Officiellement toutefois rien n’avait changé pour Silverlight, mais étant un peu suspicieux, et malgré les propos officiels lénifiants, nous avons décidé d’arrêter les développements Silverlight, qui de toute façon n’avaient pas apportés les bénéfices escomptés (par exemple le déploiement n’étaient pas plug-and-play, et il fallait être administrateur pour installer le plugin Silverlight :/), pour nous concentrer sur WPF.
Heureusement la majorité (peut être 85%) du code XAML et C# était partagée avec WPF, donc de ce côté peu fût perdu, et nous avons stoppé alors que nous n’étions pas encore complètement engagé.
Ce fût la bonne décision car en 2013 la fin de Silverlight fût officiellement annoncée, et plus d’un responsable IT furent surpris par ce revirement car ils n’avaient pas vu les signes avant-coureurs.
Je ne pense pas que cela sera aussi violent pour WPF, loin de là, mais quand vous avez vécu une telle déception vous arrêter de tout croire naïvement et devenez même méfiant, ce qui à mon avis est une qualité dans le contexte informatique actuel.

Des raisons de ne pas paniquer

A la lecture de la première partie de cet article vous avez peut être commencé à flipper, mais comme souvent les choses ne sont pas complètement noires, elles sont d’un gris plus ou moins foncé.
La seconde partie va vous aider à diluer en grande partie ce noir avec du blanc, donc n’arrêter pas votre lecture ici…

Toujours une équipe active

Si l’on en croit Greg Levenhagen (Is WPF Dead? – NO!) il y a toujours une équipe de développement activé dédiée à WPF.
Greg ne fournit pas de chiffres donc il est difficile de mesurer l’effort de développement effectif.
Bien qu’à mon avis il est évident que Microsoft n’abandonnera pas une technologie utilisée par des millions de personnes, y consacrer des développeurs dédiés, non mélangés à d’autres équipes, est une bonne chose.
Et toujours selon Greg cette équipe ne serait pas seulement dédiée à la maintenance des versions existantes mais serait aussi en train d’en préparer une nouvelle (WPF 5?).
Cependant sans prendre connaissance du change-log de cette version il est difficile d’être totalement optimiste : sans doute une version corrigeant des bugs et améliorant les performances, sans nouvelle fonctionnalité majeure.

Toujours un effort de développement [MAJ 2014-11]

En novembre 2014 l’équipe WPF a publié un article, The Roadmap for WPF, montrant que WPF était toujours activement développé.
L’équipe travaille principalement sur des questions importantes comme les performances, qui ont été améliorées continuellement depuis les débuts de WPF, et les outils de debug complètement intégrés dans Visual Studio.
Sans doute l’amélioration la plus importante est le support complet du tactile et des affichages haute-densité.
Pourquoi est-ce si significatif ? Parce que ce sont des fonctionnalités des périphériques comme les tablettes et les téléphones mobiles, et WPF a été délaissé au profit de WinRT précisément parce que ce dernier avait été conçu spécialement pour ces périphériques.
Ce n’est peut-être pas un revirement complet de la part de Microsoft en faveur de WPF, mais cela montre que Microsoft a entendu et pris en compte les demandes de la communauté.
Pour plus d’informations regardez cette vidéo avec 2 des développeurs de WPF : The Future of WPF on Channel 9.

De nouvelles version des outils

Du côté de l’outillage officiel on peut noter un signe positif : Prism, un ensemble d’outils et de bonnes pratiques pour développer des applications XAML, a été mis à jour à la version 5, et au côté de la version dédiée à WinRT on trouve une nouvelle version pour WPF.

Comme indiqué dans la première partie le toolkit WPF officiel n’est plus développé, mais un autre projet a pris le relai : l’Extended WPF Toolkit.
Il est fourni par un vendeur bien connu d’extensions, Xceed, donc par des experts WPF (et d’autres technologies Microsoft au passage), il est très riche fournissant notamment de nombreux composants additionnels, et surtout le projet est toujours activement développé, la dernière version actuellement (septembre 2014) datant de juin 2014, donc d’il y a moins de 3 mois.

Enfin, les deux frameworks MVVM de référence, MVVM Light Toolkit et Caliburn.Micro, sont également actifs, les dernières versions ayant aussi moins de 3 mois.

Donc l’écosystème WPF est toujours bien vivant et même en évolution, ce qui est particulièrement rassurant pour les entreprises qui ainsi ne se retrouvent pas avec un tas de dépendances non maintenues.

Des changements de management

A la fin de 2012 Steven Sinofsky, alors Président de la Division Windows, quitta Microsoft.
En quoi cela pourrait-il être un bon signe pour WPF ? Parce que Steven Sinofsky était connu pour sa haine de .Net et sa mauvaise volonté quand il s’agissait de travailler avec d’autres équipes (peut-être la raison première de son départ).
C’est ce qui expliquerait partiellement, avec de véritables raisons techniques, pourquoi .Net ne fût pas utilisé comme pierre angulaire des nouvelles versions de Windows alors que c’est l’un des meilleurs outils logiciels jamais développé par Microsoft.
Mais de l’extérieur il est difficile de distinguer la part de potins des véritables sentiments de Steven Sinofsky et leur impact effectif sur la conception de Windows 8+.

L’inertie du marché des OS

Un autre bon point pour WPF est le fait que les entreprises et les particuliers ne migrent pas immédiatement vers chaque nouvelle version de leur OS, et pour beaucoup de bonnes raisons : ça coûte de l’argent, ça prend du temps, c’est risqué, et c’est souvent tout simplement inutile.
Changer d’OS est une tâche très lourde notamment en raison de la nécessité d’assurer la compatibilité des applications : celles fournies par des tiers comme Microsoft avec Office et celles développées par les équipes internes, et de mon expérience c’est un processus qui peut facilement prendre 2 ans.
Actuellement (mi-2014) les parts de marché de WinRT sur le marché du PC sont plutôt réduites :
– Windows 8 + 8.1 : ~15%
– Windows 7 : ~55%
– Windows Vista : ~5%
– Windows XP : ~25%
Donc sur plus de 80% des postes PCs il est impossible d’utiliser WinRT et le seul choix reste WPF.
Et dans certains environnement c’est encore pire pour Windows 8+ : dans les entreprises que je connais dans le secteur financier la part de marché est simplement 0%, la migration vers Windows 7 n’étant même pas finie partout, certains continuant même à tourner sous XP notamment parce que le setup des applications de production n’est pas trivial.

En considérant que le cycle de renouvellement est d’environ 5 ans WPF devrait rester l’unique alternative pour de nombreuses entreprises d’ici la fin de la décennie.

L’inertie de l’ALM

Comme vous le savez probablement décommissionner les applications est coûteux: d’abord il faut organiser tout un tas de réunions et d’études préliminaires pour évaluer l’impact sur le métier, et vous devez souvent travailler dur pour convaincre certains utilisateurs qui vont quelquefois dégainer le joker du “risque opérationnel” ; puis il faut les remplacer par de nouvelles applications et s’assurer qu’il n’y a aucune régression, souvent en exécutant les deux versions côte à côte pendant une période tampon avant de complètement migrer ; de plus il faut éventuellement faire appel aux équipes BDD pour migrer les données, aux équipes réseau pour adapter les règles de firewalling…

C’est pourquoi les entreprises ne migrent leurs applications que quand il y a une véritable justification métier, et une toute nouvelle couche technique n’en est pas une, donc les applications WPF existantes, et il y en a énormément, sont là pour encore quelques temps, ce qui implique que les compétences WPF seront toujours nécessaires à court et moyen terme, et pour s’en convaincre il suffit de compter le nombre d’applications WinForms toujours en production, de nouvelles étant même créées chaque jour, et ce alors que WPF est sensé le remplacer depuis 2006.

De plus, d’un point de vue technique, bien que WPF et WinRT soient très similaires, il ne sont pas complètement compatibles : il y a toujours des fonctionnalités manquantes en WinRT 8.1 et des petites surprises : pour projeter un namespace vers XAML on utilise clr-namespace en WPF et using en WinRT, ce qui est suffisant pour casser la compatibilité du XAML et décourager toute velléité de sauter le pas !

WPF est mature

La réduction importante de l’effort de développement de WPF est évidente et peut être inquiétante, mais IMHO le développement ne fait que suivre un processus naturel que chaque développeur a déjà expérimenté : un gros effort de développement initial pour la première version, puis un effort toujours soutenu pour la version suivante qui bénéficie du feedback de la communauté, et finalement un effort minimal pour maintenir l’application.

C’est exactement le chemin suivi par WPF dont les premières versions (WPF 3.0 (à mon avis en réalité une bêta) et 3.5) qui apportèrent une nouvelle façon de développer des applications Windows, puis WPF 4 apporta de nouveau composants majeurs venant du toolkit, comme la DataGrid, et améliora les performances, et finalement WPF 4.5 introduisit seulement le Ribbon et continua à améliorer les performances.

Plus une technologie est mature moins elle nécessite un effort de développement important, et après 8 ans WPF est vraiment une technologie mature, donc les besoins de nouvelles fonctionnalité et de correction de bugs sont bien moindre.
WPF est très probablement désormais entré dans la phase de maintenance de son cycle de vie donc il ne faut pas s’attendre à un développement frénétique.

La niche du LOB

S’il y a bien un domaine dans lequel WPF peut survivre et même continuer à briller c’est celui des applications LOB (Line Of Business).
Tout d’abord parce que l’expertise requise pour les développer repose en grande partie sur .Net qui est une plateforme mature que de nombreuses entreprises utilisent pour développer leurs applications LOB sur Windows, et elle ne vont pas faire une croix sur cette expertise, et bien au contraire essayer de la rentabiliser au maximum.

Certains outils .Net essentiels au développement LOB ne sont pas encore disponibles pour WinRT, comme les ORMs tels NHibernate ou Entity Framework, que la plupart des applications LOB utilisent pour accéder à leurs données relationnelles.

De plus pour certaines applications LOB importantes comme les plateformes de trading il n’y a aucun intérêt à utiliser WinRT parce qu’on n’a pas besoin de la mobilité et même parfois on ne la veut tout simplement pas pour des raisons de sécurité.
Et ce type d’applications va même à l’encontre des directives officielles de Microsoft pour la conception des applications WinRT : elles devraient ne cibler que peu de fonctionnalités et n’afficher qu’un jeu de données minimal.

L’intégration de Windows Forms

Depuis plus de 10 ans les entreprises ont développé de nombreuses applications WinForms, et même les nouvelles applications utilisent souvent WinForms, malgré la disponibilité de son remplaçant WPF depuis 8 ans.
Bien sûr les entreprises ne vont pas jeter toutes ces applications, composants et expertise juste pour utiliser de nouveaux jouets, elles veulent rentabiliser cet investissement au maximum.

Et à ma connaissance WinRT n’est pas encore capable d’intégrer des composants WinForms, donc WinRT n’est pas une option si vous voulez bénéficier de votre investissement WinForms.

Au contraire WPF a lui été conçu dès le départ pour permettre l’intégration avec WinForms : grâce au WindowsFormsHost il est possible d’embarquer des composants WinForms dans les applications WPF.
Et mieux encore, on peut même intégrer des composants WPF dans les applications WinForms grâce à l’ElementHost.
Tout cela permet de migrer en douceur vers WPF en évitant l’effet big-bang.

La courbe d’apprentissage

Si vous êtes un développeur WPF expérimenté sans le savoir vous êtes probablement déjà un développeur WinRT à environ 80%, et si vous êtes une entreprise vous possédez déjà 80% de l’expertise nécessaire au développement d’applications WinRT.
En effet la plupart des outils fondamentaux pour développer des applications WPF sont les mêmes en WinRT :
– mêmes langages procéduraux : C#, VB.Net…
– même langage de balisage : XAML,
– même façon de connecter vue et données : liaison de données, DataTemplates…
– architecture applicative similaire : structuration générale, ressources…
– mêmes design-patterns et implémentations : MVVM, INotifyPropertyChanged, INotifyCollectionChanged, ICommand…
Donc tout investissement dans d’autres plateformes XAML comme WPF et Silverlight peut être en grande partie rentabilisé pour WinRT, réduisant ainsi la pente de la courbe d’apprentissage (vous souvenez-vous de celle de WPF quand vous étiez débutant ? ;))

WPF est riche

WinRT n’est pas un clone de WPF et certaines fonctionnalités n’y sont pas encore implémentées, donc si vous développez des applications seulement pour les clients lourds alors d’un point de vue technique WPF a toujours le dessus.
Cependant, et c’est pourquoi j’en parle en dernier, pour de nombreuses applications cet écart n’est pas rédhibitoire, et à mesure que WinRT évoluera il se réduira d’autant, mais il est probable que même à long terme certains développements avec des besoins très spécifiques ne puissent être faits qu’avec WPF.

Mais il faut bien garder en tête que la valeur ajoutée de WinRT n’est pas dans sa richesse technique intrinsèque mais plutôt dans son modèle de développement qui donne accès aux plateformes mobiles et au Windows store.

Stratégie pour le futur

Que vous soyez une entreprise ou un développeur individuel vous devriez sérieusement penser à ralentir votre investissement dans WPF, et commencer à monter en compétence sur WinRT.

Pour les entreprises

En tant qu’entreprise vous ne pouvez arrêter vos développements WPF tant que vous devez supporter d’anciennes versions de Windows, y compris Windows 7.
Concernant vos applications existantes il n’y a pas d’inquiétude à avoir, il n’est pas nécessaire de les migrer vers WinRT, sauf si vous souhaitez bénéficier de ses nouvelles capacité de déploiement via le Windows Store.
En effet Microsoft devrait continuer à assurer le support de WPF pour les années à venir ; la rétrocompatibilité est quelque chose que Microsoft prend très au sérieux.
Par exemple bien qu’il soit plus difficile de mettre en place un environnement VB6 dans les nouvelles versions de Windows cela reste possible, et une fois installées les applications continuent à s’exécuter sans problème.

Selon votre main d’oeuvre IT, vous devriez consacrer un peu de temps à la veille technique et avoir des développeurs qui commencent sérieusement à étudier WinRT : comment votre entreprise pourrait en profiter, typiquement en élargissant son audience, comment les nouvelles applications devraient être développées, comment les outils et codes existants peuvent-ils être réutilisés, quels sont les obstacles éventuels à anticiper…
Pour les applications qui pourraient bénéficier de WinRT pour le mobile et les tablettes vous pouvez commencer à élaborer des plans de migration, ce qui n’est pas évident car WinRT ne possède pas encore de nombreuses fonctionnalités de WPF sur lesquelles vos applications pourraient reposer.
Commencez à développer des applications prototypes pour valider la nouvelle technologie dans votre environnement particulier et voyez par vous même si cela apporte un quelconque bénéfice.

Pour les développeurs

Nous autres développeurs ne souhaitons pas investir dans des compétences techniques dont personne n’a besoin, et nous essayons souvent de nous construire un portefeuille de connaissances assez large afin de répondre aux besoins du plus grand nombre d’entreprises et de projets possibles, afin de réduire le risque d’être laissé au bord de la route.
Donc si vous êtes un développeur WPF expérimenté et que vous hésitez entre renforcer et étendre votre savoir-faire WPF pour devenir un expert, et commencer à monter en compétence sur WinRT, je vous conseille plutôt la seconde option.
Bien sûr vous aurez sans doute l’opportunité de faire les deux comme j’essaye, mais WinRT devrait être quelque part sur votre TODO-list sans toutefois être une priorité.

Ou bien encore vous pourriez continuer à investir dans WPF dans l’attente que le marché soit en manque de développeurs WPF, comme c’est le cas avec d’anciennes technologies comme COBOL et VB6, mais j’ai bien peur qu’il vous faille attendre une bonne décennie avant que cela n’arrive, car avec la croissance importante de l’IT au sein des entreprises, pour quasiment toute les technologies on trouve de nombreux développeurs sur le marché, et c’est particulièrement vrai pour les technologies mainstreams comme WPF, donc je ne compterais pas trop dessus.

Ne soyez pas abattu ou fâché par cette nième toute nouvelle technologie, c’est le business-model de notre secteur : il a besoin de créer de nouveaux produits à vendre à ses clients tout le temps (rappelez-vous le SOA qui déversa énormément d’argent directement dans les poches des entreprises informatiques, de leurs employés, de leurs actionnaires et des développeurs), de la même façon qu’Apple le fait avec ses iPhone 1, 2, 3, … maintenant 6 et bientôt 42.
C’est comme ça que ça fonctionne et nous avons la chance, en tant que développeurs, d’être du bon côté de la barrière, en faisant de cette entropie notre gagne pain, et en toute objectivité la plupart de ces technologies améliore la vie des entreprises et des particuliers.

Conclusion

Je pense que la somme de tous ces faits est plutôt claire : WPF est le passé et le présent, dans le future proche il sera en concurrence direct avec WinRT, mais plus tard quand Windows 8+ aura acquis plus de parts de marché alors WPF deviendra plus ou moins obsolète comme le sont aujourd’hui, à des degrés divers, d’anciennes technologies Microsoft telles que VB6 ou WinForms.

Surtout il ne faut pas tomber dans le déni, et rester lucide sur les changements en cours, et ne pas ignorer les faits pessimistes de son esprit.
Il ne faut pas espérer une renaissance de WPF, il n’existe rien te tel en informatique (bon il est vrai que COM est plus ou moins de retour avec WinRT), WPF n’est de toute évidence pas taillé pour les nouvelles tendances, les nouveaux outils comme WinRT le sont.

Bien sûr tout n’est pas sombre: WPF n’est ni mort et obsolète ni mourant et obsolescent, il a juste atteint son apogée et risque de doucement disparaître à mesure que les entreprises migrent leur infrastructure vers Windows 8+ leur permettant de choisir WinRT pour leurs futurs développements.

Soyez pragmatique et transparent: utilisez WPF tant qu’il apporte de la valeur à vos clients et portez ces faits à leur connaissance, et aidez les à préparer l’avenir.
J’ai moi même commencé à mettre à jour mes supports de formation en y intégrant des morceaux de WinRT, et en ajoutant une page résumant ces faits, les mettant en évidence selon leur importance.

Cependant IMHO vous ne devriez pas non plus trop investir dans WinRT.
Pourquoi ? Parce que plus je joue avec WinRT et y réfléchis moins je le trouve pertinent :

• si vous développez une application LOB, votre seule plateforme cible est sans doute le PC Windows, et vous avez besoin d’être rétro-compatible avec les “anciennes” versions de Windows, au moins Windows 7, donc WinRT n’est clairement pas une option et vous devez utiliser WPF,
• si vous souhaitez cibler les tablettes et les téléphones vous ne pouvez faire l’impasse sur 90% du marché, iOS et Android, donc WinRT n’est pas une option, et vous devez utiliser soit la stack web (JavaScript/HTML/CSS) soit des frameworks natifs cross-plateformes comme Xamarin (C#) ou QT (C++).

Donc pour la plupart des cas d’utilisation WinRT n’est tout simplement pas une option.

De plus notez que Microsoft investit lourdement dans les technologies sus-citées.

Il est sans doute trop tôt pour vous demandez “Est-ce la fin de WinRT (en tant que plateforme de développement finale) ?” mais je serais relativement surpris si WinRT arrivait à décoller et à devenir une plateforme de développement majeure.

IMHO WinRT est une bonne plateforme seulement pour les équipes Microsoft qui peuvent ainsi partager plus de code entre les différentes versions de l’OS Windows, imitant l’effort d’Apple ; mais pour le développeur final les cas d’utilisation de WinRT sont bien trop limités : partager du code entre PC, tablettes et téléphones mais seulement pour les périphériques Windows.
Sans doute que certaines entreprises n’ont que ce besoin mais je doute qu’elles soient nombreuses car désormais les application sont souvent utilisées depuis les appareils personnels des employés (BYOD) qui peuvent être n’importe quoi et le plus souvent de l’iOS ou de l’Android.