Mettre à jour une application mobile sans passer par les stores - #1 Pourquoi
Le monde est changeant et incertain, et les applications mobiles ne sont pas épargnées. On a un besoin de s’adapter rapidement. Parce qu’on veut expérimenter en production, parce qu’une nouvelle fonctionnalité provoque des crashs, parce qu’on veut intégrer continuellement, parce qu’on s’est planté sur une hypothèse.
On a cependant deux barrières de taille au changement rapide dans le développement mobile : les stores (App Store et Google Play), et les utilisateurs.
Pour un site web ou un backend, on peut avoir la totale maîtrise du déploiement. Si on veut mettre en ligne la toute dernière version, on peut le faire en quelques secondes - c’est notre serveur, on décide de ce qu’il exécute. Les utilisateurs y auront accès tout de suite et n’auront d’ailleurs pas le choix - derrière l’url de notre site web, il y a toujours notre dernière version.
Pour une application mobile, je disais qu’on a deux barrières. D’abord, les stores.
C’est notre première halte sur la route du déploiement. Ici, on ne maîtrise pas. On est chez Apple et chez Google. Il y a une étape de vérification de l’application que l’on soumet. Le temps d’analyse est variable et dépend d’eux, et ils peuvent refuser comme bon leur semble. Côté Apple, c’est d’ailleurs un sport national - les règles sont plus strictes et l’application peut soudainement être refusée pour un élément qui est en prod depuis plusieurs versions.
Une fois que l’application est acceptée et déployée sur les stores, on ne peut pas encore crier victoire - c’est au tour des utilisateurs d’installer l’application.
Seconde halte pour le déploiement donc, et on ne maîtrise toujours pas. Les utilisateurs vont mettre à jour quand ça leur chante : le jour même, le lendemain, 2 semaines après, 6 mois, jamais. Les utilisateurs ne sont d’ailleurs pas spécialement notifiés qu’une nouvelle version est disponible. Ils doivent aller sur les stores eux-mêmes.
Et ceux qui activent les mises à jour automatique ? Elles ne sont pas instantanées pour autant. Le système décide de lancer le téléchargement lorsque certaines conditions sont réunies (connexion à un réseau Wi-Fi, batterie en charge, heure de la journée, utilisation du téléphone).
Ce qui veut dire que si ma nouvelle fonctionnalité provoque un crash en production, il faut passer par toutes ces étapes pour corriger le problème. Un processus long, et sans garanti. Les utilisateurs auront peut-être désinstallé l’application avant que ce ne soit réglé et livré.
Face à ce risque, certaines équipes vont entrer dans ce que je trouve être un cercle vicieux : on a peur de faire des erreurs parce que le changement sera long, donc on s’ajoute du contrôle et des process, ce qui allonge le temps avant de livrer, donc on a encore plus peur, on contrôle davantage, on allonge d’autant le délai, etc. Au final, cette équipe va se figer, les livraisons deviendront douloureuses et les problèmes se multiplieront.
D’autres équipes vont plutôt se diriger vers des pratiques vertueuses. Elles vont par exemple chercher à intégrer et déployer en continu (CI/CD) chaque changement. J’entends bien plus souvent ces sujets dans le monde du web, et surtout du backend. Cependant, sur mobile, il existe aussi des techniques pour s’approcher des principes de CI et CD malgré les deux barrières que sont les stores et les utilisateurs.
On peut effectuer des changements sur une application mobile en prod sans pour autant devoir déployer une nouvelle version sur les stores. Et ça tombe bien, j’avais envie de faire un petit tour d’horizon pour faire découvrir quelques possibilités avec cette série d’articles.
Mettre à jour une application mobile sans passer par les stores :
- #1 Pourquoi
- #2 Remote config, Feature Toggle & co
- #3 Backend for Frontend (BFF)
- #4 Server-Driven UI
- #5 Interpréteur de code
- #6 Over-the-air update (OTA)
- #7 En résumé, mes options
La suite est à venir et peut changer en fonction de mes réflexions et de discussions.