Développement rapide d’applications mobiles : la rapidité, mais pas sans compromis

Pour et contre le RMAD

Les outils de RMAD supportent des services de back-end en s’appuyant sur des connecteurs pour toutes sortes de bases de données, locales comme en mode Cloud, flux et API. Ces outils se chargent aussi de la plomberie des applications mobiles, comme la synchronisation de données hors connexion, les notifications en mode push, l’analyse d’usage, la gestion des identités, l’authentification et l’hébergement.

RMAD implique souvent environnement de développement (IDE) sans code, mais certains produits acceptent aussi l’intégration de scripts, de contenus Web ou encore de code natif. Certains IDE de RMAD permettent la création à main levée de n’importe quel type d’interface utilisateur, quand d’autres se concentrent sur des modèles ou sont conçus pour combiner des tâches courantes dans un workflows, ne laissant finalement que peu à la charge du créateur de l’application.

Mais comme pour chaque plateforme de développement d’applications mobiles, il y a des compromis. Lorsque l’on n’écrit pas l’application du sol au plafond en code natif, on se prive d’une part de flexibilité dans la conception, et certaines applications risquent de ne pas être en mesure d’utiliser des fonctionnalités particulièrement récentes ou spécifiques. Les performances peuvent également être en retrait.

De l’autre côté, les applications construites avec des outils de RMAD et d’autres approches non-natives peuvent malgré utiliser des fonctionnalités clés telles que la géolocalisation, les photos, la vidéo, les notifications. Le tout dans une interface moderne et aux performances globalement satisfaisantes. Pour des applications métiers internes visant à remplacer les applications lourdes ou les processus basés sur le papier, tout cela peut s’avérer plus que suffisant.

Le RMAD face aux attentes métiers

Utiliser des outils de RMAD pour créer des applications rapidement et à moindre coût présente de nombreux avantages. Les entreprises peuvent expérimenter en prenant moins de risques, et étendre leurs stratégies de mobilité en incluant des applications qui n’offriraient pas un bon retour sur investissement si elles devaient être développées à partir de rien.

Mais la technologie n’est qu’une partie du processus, et les usages, attentes et stratégies métiers contribuent bien plus à la réussite. En d’autres termes, un RMAD peut permettre de lancer une application, mais les métiers doivent continuer de s’assurer qu’il s’agit d’une bonne application.

Et puis le RMAD n’absout pas nécessairement les DSI de toute responsabilité pour d’autres tâches connexes. Elles devront penser sécurité des applications, s’assurer de leur déploiement auprès des bonnes populations, et mettre à jour ces applications à mesure que les terminaux et les besoins des métiers évoluent.

Compte tenu de la simplicité relative avec laquelle il est possible de créer une application sans code, avec un outil de RMAD, certains éditeurs poussent l’idée d’un développement « citoyen » d’applications. Derrière ce concept se cache l’idée selon laquelle les équipes IT non spécialisées, voire directement des responsables métiers ou des utilisateurs finaux, pourraient utiliser le RMAD pour créer seuls des applications.

Pour séduisante qu’elle puisse paraître, cette approche suppose qu’une intégration, une automatisation, et des contrôles de sécurité suffisants sont en place pour fournir les garde-fous nécessaires. Clairement, beaucoup restent sceptiques quant au potentiel d’adoption de l’approche.