Mobilité : développez une fois et déployez sur tous les systèmes

La difficulté de déployer une solution mobile disponible depuis n'importe quel terminal et n'importe quel système d'exploitation peut être surmontée. Reste à faire les bons choix.

Lorsque Netscape et Internet Explorer utilisaient des balises différentes, nous considérions cela comme « complexe ». Certains modules fonctionnaient avec un navigateur, mais pas avec l'autre, contraignant les développeurs à passer davantage de temps pour rendre leurs pages compatibles avec les deux. Certains problèmes pouvaient être résolus avec quelques lignes supplémentaires de code, mais des différences majeures de mise en page à l'écran demeuraient. Le problème n'était pas seulement de passer le double de temps en développement et en test de qualité, il résidait également dans le fait d'imposer aux utilisateurs des pratiques différentes.
 
L'incompatibilité - entre navigateurs, mais aussi entre systèmes d'exploitation - empoisonne l'industrie du logiciel depuis que celle-ci existe. Aujourd'hui, l'utilisation croissante des équipements mobiles ajoute encore une dimension à cette problématique. Non seulement chaque appareil dispose d'un système d'exploitation et d'un navigateur préinstallé différents, mais il possède de plus un écran dont la taille et  la résolution lui sont propres.
 
La propagation des applications Web a pratiquement résolu les deux premiers problèmes.

Les applications Web sont des pages HTML qui s'adaptent aux caractéristiques de l'interface utilisateur de chaque appareil.

En d'autres termes, elles intègrent des scripts Java permettant de supporter les fonctions tactiles, les zooms et les autres interactions utilisateur auparavant réservées aux seules applications natives. Alors que les applications Web n'offrent pas forcément toutes les commandes tactiles nécessaires pour créer un jeu sur le Web, par exemple, elles sont cependant suffisantes pour manipuler du contenu BI sur les tablettes et les smartphones sans compromettre l'expérience utilisateur - ce qui fût l'une des plus grandes craintes des professionnels de l'informatique. En réalité, les applications Web permettent à l'informatique de ne plus avoir à recourir à l'App store propriétaire pour déployer des applications. Les équipes IT conservent un contrôle complet sur l'application, tout en offrant aux utilisateurs la meilleure expérience possible.
 
C'est pourquoi de nombreux sites comme Gmail, Facebook ou encore Twitter ont commencé à migrer des applications natives vers des applications Web. Et c'est aussi pourquoi certaines technologies de reporting ont déjà été transposées en applications Web, afin de permettre aux équipes IT de développer une seule fois et de déployer sur tous les appareils.
 
Le facteur « taille » est celui qui pose le plus gros problème. La taille de l'écran est critique, parce qu'il y a tout simplement trop à faire pour un seul et même écran. Un rapport de grande taille - disons 400 lignes par 400 colonnes - peut être visualisé facilement sur un ordinateur portable, ou même une tablette, mais sera impossible à lire sur un smartphone. Par le passé, de nombreuses entreprises ont essayé de mettre en place des outils de conversion automatique, afin d'adapter de tels contenus à des écrans de plus petite dimension. Certains types de mise en page sont plus adaptés à cette approche.

Par exemple, un tableau de bord contenant quatre graphiques peut facilement être converti en un tableau unique, où l'utilisateur passe de graphique en graphique. Mais qu'en est-il du rapport évoqué précédemment, celui qui contient 400 lignes et 400 colonnes ? Il existe de nombreuses manières pour l'utilisateur de le visualiser, et il est bien difficile de déterminer la meilleure.
 
Dans ces cas-là, la « requête média » est la meilleure approche. Le développeur associe différentes mises en page - conçues pour chaque écran d'appareil - à chaque rapport et tableau de bord. Lorsque le rapport est exécuté par l'utilisateur final, la technologie reconnaît l'appareil et utilise le document spécifiquement mis en page par le développeur pour le type d'écran concerné. Cela peut sembler éloigné du principe du « développement unique compatible avec tous les appareils », mais ce n'est pas le cas.

En effet, le rapport est développé une seule fois, mais les outils permettent aux développeurs de le pré-visualiser pour une multitude d'écrans, et de faire les ajustements de mise en page nécessaires pour chacun. Par conséquent, le travail de développement pour construire et contrôler la qualité du rapport est le même. La seule différence concerne les ajustements de disposition du contenu à l'écran, qui peuvent être faits par drag-and-drop avec la plupart des outils. Cette approche permet d'offrir aux clients une expérience entièrement personnalisable pour n'importe quel appareil, à un coût très faible.