X

Migration web de mes applications ou mourir. Vraiment ?

Le temps est venu de migrer de technologie et votre directeur TI ne jure que par le Web. Il veut que toutes vos nouvelles applications (ou presque…) soient « Web ».  Son argument majeur étant que toutes ces applications web seront beaucoup plus faciles à déployer et à maintenir. Vous sauverez donc des frais importants sur ces deux plans. Devez-vous faire une migration web?

Ah ! Web, quand tu nous tiens !

Certaines de vos applications actuelles recèlent, en fait, beaucoup d’intelligence d’affaires et vos usagers ont l’habitude d’y accéder d’une certaine façon depuis plusieurs années.  Est-ce qu’une migration Web vous permettront tout autant de préserver l’intégrité de votre intelligence d’affaires et de maintenir le niveau actuel de convivialité ?

Afin de dissiper vos doutes, en discutant avec vos informaticiens, ces derniers vous expliquent que le Web traditionnel n’existe plus.  Les solutions Web d’aujourd’hui sont extrêmement performantes, bonifiées qu’elles sont de plugins, d’Ajax et de Flash; sans compter l’avènement du HTML 5 dont tous vantent les vertus… à  venir.   Il ne se fait plus, à proprement parler, de développement HTML pur et dur.  L’avenir de la structure technologique des entreprises ressemble de plus en plus à une infrastructure hybride d’applications d’arrière-boutique (back-end applications) avec services Web tirant profit des clients/browsers gonflés aux stéroïdes de plugins (Flash, Silverlight, Air, etc.) ou encore d’applications clientes déployées localement sur les postes de travail (SmartClient, .Net Framework ou Java Runtime).

Les applications d’aujourd’hui utilisent des services Web et possèdent des fonctionnalités d’interface et une capacité de présentation presque égales à des applications conventionnelles lourdes, cela implique qu’elles doivent absolument utiliser des « Framework » du côté Client afin de pouvoir tirer profit (lire / interpréter) de ces fonctionnalités.  Dans le fond, ça ressemble à l’architecture Client / Serveur que nous connaissons bien comme  développeur TI, à la différence près que le côté Client utilise un navigateur (browser) Internet… gonflé aux plugins !

La frontière entre les deux mondes, Web vs Windows, est devenue très floue et la meilleure solution n’est probablement plus l’une ou l’autre mais, fort probablement, une combinaison des deux types de Clients (browser avec plugins + client personnalisé local).

Migration web ?

« Je suis un décideur, je demande donc qu’on me schématise une architecture Web et une architecture Windows afin d’en avoir le cœur net… (oups !). Et, décider si une migration web s’impose.  »

Et vous vous direz, avec raison : « ma foi, ça se ressemble pas mal ». D’un côté, on a un serveur (soit pour les services Web ou les applications d’arrière -boutique). De l’autre, des postes Clients avec browsers et de multiples plugins ou des applications locales qui s’appuient sur le EFramework .Net ou le Java Runtime.

En fait, la similitude vous incite à regarder d’autres critères pour vous aider à décider. D’abord, vous devez évaluer l’expertise en place: Sun (Java, PHP, MySql, Air, Adobe) ou Microsoft (.Net, C#, VB, SQL) ou encore Force.com et considérer le bassin de développeurs actuels pour chacune de ces technologies.

Ensuite, comme le monde de l’Open Source (Java) est un monde ouvert à tous. Où vous pouvez retrouver beaucoup de modules, technologies, API et plugins « gratuits ». Vous devez vous assurer de la compétence de vos fournisseurs.  Du côté Microsoft, si vous allez à l’externe, il vous faut valider la pérennité et la compétence de la firme sélectionnée pour faire votre migration web.

Par la suite, selon le niveau de convivialité, de compatibilité, de performance et d’autonomie requis; vous déciderez, pour chaque application, de son niveau de développement. Une migration web peut avoir différents niveaux de développement.

Et il y a toute la question du web 2.0 aussi… et de l’Entreprise 2.0… mais, ça !

Bonne semaine,

Michel et Denis

Commentaires (6)

Articles connexes