Internaliser la maintenance d'applications mobiles, différents scénarios

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 majoritaires 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. Comment alors s’organiser, existe-t-il différents scénarios ? Voyons quelques éléments de réponse à travers un retour d’expérience.

 

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 évolution très lente et risquée

 

Les premières engendrent quelques régressions douloureuses ! Or, la roadmap de l’année qui suit est chargée et débute notamment par une restructuration complète de la navigation.

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 et ceci 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 plus que 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 promettant une intégration rapide de composants natifs, le problème me semble à minima contournable.

 

L’étude de retour sur investissements vise à chiffrer les 3 scénarios : garder les applications telles quelles, les refondre sans changer de technologie (rester sur du natif) ou les refondre 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, ce qui donne les besoins suivants en termes de membres d’équipes à mobiliser sur le sujet :

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.

 

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

Pierre Segalen

Architecte technique, SQLI

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !