[La question qui tue] Portabilité des applications métier de Windows Mobile 6.5 vers Windows Phone 7

“Je suis un pro, j’ai fait le choix de Windows Mobile il y a des années, je vois plein de buzz positif autour de Windows Phone 7 mais il parait que la compatibilité n’est pas assurée… Or j’ai des collaborateurs avec des applications d’entreprise, comment je fais ?”

Mauvaise nouvelle, il n’y a pas de réponse simple. Ce n'’est pas si grave que ça non plus, parce qu’il y a quand même toujours une réponse :) Chaque cas étant particulier c’est difficile de faire des généralités pertinentes, mais on va essayer quand même de se faire une opinion et de “dégrossir” le terrain. En tous cas, On va lister quelles questions et avec quelles informations appeler votre serviteur pour trancher sur une potentielle migration de Windows Mobile 6.x vers Windows Phone 7.

L’usage: terminal durci ou pas?

D’abord si vous faites dans les terminaux durcis… Windows Phone 7 ne devrait pas être dans vos plans. Je ne dis pas que ça n’arrivera jamais (qui sait de quoi le futur est fait…) mais ce n’est pas pour ce type de terminaux que cet OS a été pensé. Windows Phone 7 est avant tout grand public, et l’OS, le SDK, les applications et le mode de déploiement des applications ont été pensées avec le grand public en tête. En plus les spécifications matérielles minimales de Windows Phone 7 sont souvent incompatible avec le milieu durci (écran capacitif obligatoire par exemple).

Ceci étant dit, il existe tout une population “d’information worker” qui utilisent un terminal grand public pour des taches métiers: commerciaux ou agents de terrain avec une application de CRM, chauffeurs, etc. Sans compter la volonté pour un certain nombre d’entreprises de faire une application “intranet” ou “note de frais”. Toutes ces populations pourraient être concernées par des applications métier sur un smartphone sexy avec Windows Phone 7. Ca vaut vraiment le coup de se poser la question. Ou plutôt les questions, car il n’y en a pas qu’une… et tant qu’à faire autant commencer par la question la plus épineuse: le déploiement de l’application en question sur les terminaux.

Le déploiement passe obligatoirement par le Marketplace public

C’est le point sensible. Autant on pourra quasiment toujours contourner une difficulté technique, autant, celle là, ce n’est pas possible. Votre application sera visible par tout le monde. Voire, téléchargeable part tout le monde (à condition d’y mettre le prix que vous fixerez). Ca peut être un showstopper, comme une grande force: après tout, un simple système d’authentification peut vous permettre de protéger votre application tout en garantissant que vous êtes visible sur le Marketplace: prenons un exemple simple: vous avez une application “note de frais” qui est customizable par chaque client: la configuration du client lui est propre et ne doit pas forcément se trouver sur Marketplace. Quelqu’un d’anonyme qui téléchargerait l’application pourrait la voir en mode “restreint” et avoir l’option de vous contacter pour en savoir plus: Marketplace devient alors un vecteur de publicité et de leads. Dans le même genre d’optique, vous pouvez aussi utiliser l’authentification pour débloquer par exemple l’accès à des services spéciaux (internes par exemple) et sans authentification proposer à vos clients une application publique qui pourrait leur servir indépendamment de votre backend.

Si votre application est faite par l’interne, pour l’interne, le cas est plus délicat: quoiqu’il en soit Microsoft étudie toutes les possibilités pour offrir aux entreprises la possibilité de déployer leur application sans passer par les moyens du grand public et saura revenir, on l’espère le plus vite possible, avec des propositions: dans tous les cas, ce n’est pas encore annoncé, et donc pas encore roadmapé…

La technologie / Les fonctionnalités

Une fois l’écueil “publication sur Marketplace” passé, reste à savoir si vous pouvez implémenter votre application sur Windows Phone 7 et combien ça va vous coûter.

Tout a changé avec Windows Phone 7: l’OS, mais aussi le SDK, et le modèle applicatif. Pour de plus amples informations, je vous conseille l’article Comprendre la plateforme Windows Phone 7 sur MSDN. Du coup, il n’y a pas de compatibilité binaire entre Windows Phone 7 et les versions précédentes de l’OS ou entre le kit de développement Windows Phone 7 et les kits de développement précédents. D’une manière ou d’une autre il faudra réécrire l’application. Toute? Pas forcément… tout dépend de votre technologie de départ et de la modularité de votre code. Si vous avez opté pour le Compact Framework par le passé, alors il y a de fortes chances que vous puissiez réutiliser vos couches métiers, même s’il faudra vraisemblablement revoir la partie réseau. En ce qui concerne la couche de présentation en revanche, elle est à oublier, il faudra tout refaire avec Silverlight. Si vous aviez opté pour des technologies natives (C/C++, Win32, MFC…) alors il faudra tout bonnement tout réécrire.

Une fois la décision sur la réécriture/portage validée, il faudra s’intéresser aux fonctionnalités du SDK. La bonne nouvelle est qu’il y a 98% de chances qu’il soit possible d’écrire une application iso-fonctionnelle à l’ancienne, même s’il faudra surement utiliser quelques ressources de la communauté, et peut-être un peu de malice. En effet, sans background processing par exemple il faudra peut-être recourir à un service online et des notifications en push pour provoquer des synchronisations de données par exemple . Un autre exemple, s’il y a besoin d’une base de donnée locale, Microsoft n’a pas encore porté SQL CE sur Windows Phone 7, mais SQLite existe déjà dans la communauté. Du coup, il est fort probable que votre application puisse, moyennant un peu d’adaptation, être portée. En revanche, il faut rester honnête, certain scénarios vont être impossible à implémenter pour le moment : par exemple le suivi de véhicule avec une application tournant en background dans le téléphone et uploadant régulièrement sa position GPS (il faudrait que l’application soit affichée à l’écran pour que cela marche), ou alors l’accès aux couches basses ou aux API de l’OS comme l’interfaçage avec un équipement particulier qui requiert l’accès à un port série et une pile Bluetooth.

Après cette longue lecture, vous devriez avoir une idée un peu plus claire mais pas forcément très positive de l’idée du portage de votre application: cela représente de toutes façons pas mal de travail. Mais ce travail peut en valoir la peine. Windows Phone 7 marque une nouvelle page de l’histoire des smartphones avec une ergonomie différente centrée sur l’utilisateur. A vous de voir en fonction des usages, des besoins de vos collaborateurs et de l’image que vous voulez véhiculer. Les points bloquants mentionnés tout au long de cet article sont-ils réellement bloquants? ils ne l’ont pas forcément été pour d’autres! Dans tous les cas, toute l’équipe mobile chez Microsoft saura répondre aux questions et dissiper les doutes éventuels. Cet article n’est là que pour expliquer la base, car encore une fois il est impossible de faire des généralités sur les applications métiers… Alors contactez-nous!!