mercredi 08 novembre 2017

IT Expert Magazine - Pierre Segalen :
Comment internaliser la maintenance d’applications mobiles ?

La démocratisation des applications mobiles de ces dernières années a conduit la plupart des grandes entreprises à créer au moins une application sur les deux plateformes que sont iOS et Android. Les compétences requises pour les faire évoluer étant pointues et assez différentes de celles historiquement répandues au sein des DSI, la maintenance est souvent externalisée.
Néanmoins, quand une application commence à générer beaucoup d’activité, la question de l’internalisation de sa maintenance devient vite stratégique. Alors comment s’organiser, existe-t-il différents scénarios ? Voyons quelques éléments de réponse à travers un retour d’expérience.

Un challenge de taille

Revenons quelques temps en arrière, j’effectue une mission en tant que Leader Technique de l’équipe chargée de la mobilité chez un acteur du e-commerce. Dans le périmètre de mon équipe entrent la maintenance évolutive du site mobile (site marchand dédié aux smartphones), celle du serveur d’API des applications iOS et Android et la relation fournisseur avec le prestataire assurant la maintenance de ces dernières. Un enchaînement d’évènements provoque une internalisation instantanée de cette maintenance évolutive au sein de l’équipe, m’incombe alors la tâche d’organiser ce transfert d’activité.

- Premier constat : nous manquons de compétences au sein de l’équipe, seul l’un d’entre nous possède les bases du développement d’applications natives Android. Je pars donc me former en urgence au développement iOS au sein de notre équipe spécialiste de la mobilité pour pouvoir assurer le minimum vital sur cette plateforme.

- Second constat : le rythme de travail des autres périmètres ne diminuant que très peu, il est impossible de mobiliser plus de 3 membres de l’équipe sur le sujet.

- Troisième constat : la forte dette technique des deux applications (elles ont connu 4 ans de pratiques différentes et 4 montées de versions majeures d’OS) rend toute modification très fastidieuse et risquée.

Les premières évolutions engendrent quelques régressions douloureuses… Or, la roadmap de l’année à venir est très chargée et débute notamment par une restructuration complète de la navigation.

Une démarche d’exploration

Lors d’une réunion pour trouver une solution durable aux problèmes multiples que la situation provoque, j’émets une hypothèse : créer de nouvelles applications plutôt que maintenir les existantes au moyen d’une technologie hybride afin de rationaliser les coûts. J’obtiens le budget pour mener une étude de retour sur investissement et de faisabilité via la réalisation d’un prototype. Le choix de la technologie hybride n’est pas simple car les décideurs souhaitent écarter les solutions comme Cordova qu’ils considèrent comme trop loin d’un rendu natif et Xamarin en raison de mauvais échos lors du développement de l’application d’un autre service. Lors de mon étude de marché, je prends connaissance du fait que Facebook développe une technologie qui semble très prometteuse : React Native.

Lorsque je la découvre, cette solution apparaît presque trop belle pour être vraie :

- Le langage de développement est Javascript : nous l’utilisons déjà au sein du site mobile ;

- Le rendu est natif : le code Javascript tourne dans un processus en fond et communique avec une couche native chargée de transformer les directives du code en composants natifs de la plateforme

- Les performances et la réactivité sont vendues comme étant impossibles à différencier avec celle des applications natives ;

- Le partage de code entre les plateformes est annoncé à 80%.

Le prototype que nous réalisons en deux semaines est prometteur et valide ces points sans faute, le partage de code grimpant même à 90%. Un point reste néanmoins dans l’ombre par manque de temps : l’intégration des SDK natifs des partenaires (les applications existantes en embarquent une douzaine chacune) et il s’agit d’un frein connu à l’essor des solutions hybrides. Sur ce dernier point, la documentation de Facebook promet une intégration rapide de composants natifs, le problème me semble au moins contournable.

L’étude de retour sur investissements vise à chiffrer les 3 scénarios :

1)  Garder les applications telles quelles,

2)  Refondre les applications sans changer de technologie (rester sur du natif)

3)  Refondre les applications en utilisant React Native.

Après avoir chiffré la Roadmap de l’année suivante, considérée comme référence pour les années suivantes quant au volume des évolutions, j’intègre au budget prévisionnel la charge de refonte sur la première année pour les scénarios 2 et 3.

Le résultat de l’étude place clairement le scénario 3 en tête en matière de budget et permet même (moyennant un effort budgétaire la première année) de réduire le budget ou d’augmenter le rythme de la Roadmap à partir de l’année suivante.

Un choix pertinent

Bien entendu, le budget n’est pas la seule donnée à prendre en compte pour un choix de ce type et faire le choix de la nouveauté (React Native est encore en cours de stabilisation au moment du choix) est souvent risqué. Néanmoins, lors de ma restitution, le DSI prend la décision de lancer le scénario 3 car le retour sur investissement promet une belle rétribution pour ce choix risqué.

Cette refonte a bien eu lieu et les résultats ont dépassé les prévisions : une fois la nouvelle version de l’application publiée sur les Stores, les performances commerciales de celles-ci se sont envolées et les notes des utilisateurs se sont sensiblement améliorées. Lors de ma restitution, j’ai émis l’idée qu’une étape suivante pourrait être la refonte du site mobile en React (technologie web dont React Native est issue) afin de partager la logique métier entre les applications et le site, ce projet est actuellement en cours.

Avec le recul, je peux affirmer qu’il s’agissait effectivement du meilleur choix pour la stratégie d’internalisation de ces applications mais chaque situation étant différente, il est possible que ce choix ne soit pas universel. L’important est de ne se fermer à aucune possibilité et de ne pas avoir peur de refaire entièrement une application à partir du moment où son âge devient important, il s’agit souvent de la meilleure option.

Pierre Segalen
Architecte Technique SQLI

  • Partagez
  • Facebook
  • Twitter
  • Linkedin
Contactez-nous

SQLI Paris

Immeuble le Pressensé

268 avenue du Président Wilson

93210 La Plaine Saint-Denis

+33 (0)1 55 93 26 00