Un bug en production sur un site web, c’est une mauvaise heure : on corrige, on déploie, et la page suivante que charge l’utilisateur est la bonne. Sur une application mobile, le même bug peut durer des jours. Il faut produire une nouvelle version, la soumettre à Apple et à Google, attendre leur validation, puis attendre que chaque utilisateur installe la mise à jour. Certains ne le font qu’au bout de plusieurs semaines. Pendant ce temps, le bug est toujours là, dans leur poche.
Ce que les règles autorisent
La règle générale est stricte. Chez Apple, la règle 2.5.2 interdit à une application de télécharger ou d’exécuter du code qui introduit ou modifie ses fonctionnalités. Chez Google, une application distribuée sur Google Play ne peut pas se mettre à jour par un autre moyen que le mécanisme de mise à jour de Google Play.
Mais les deux textes prévoient une ouverture pour le code interprété, celui qu’un moteur embarqué dans l’application lit et exécute, ce qui est le cas d’une partie des applications multiplateformes. Le contrat des développeurs Apple l’autorise, à condition que ce code ne change pas l’objet principal de l’application tel qu’il a été annoncé, ne contourne pas les protections du système et ne crée pas de boutique d’applications. Google exclut de sa restriction le code qui tourne dans une machine virtuelle ou un interpréteur n’accédant qu’indirectement au système.
En pratique, pour une application construite de cette façon, corriger un bug, ajuster un texte ou réparer un écran peut se faire à distance. Ajouter discrètement une fonction que la validation n’a jamais vue, non : c’est précisément ce que les règles visent, et le risque est le retrait de l’application.
Ce qui passe toujours par les stores
- Tout ce qui touche au code natif : un nouveau module, une nouvelle autorisation (caméra, localisation, notifications), une mise à jour du système de base.
- Ce qui change la nature de l’application : une nouvelle fonctionnalité importante mérite une vraie version, décrite aux équipes de validation.
- L’identité de l’application : son nom, son icône, ses captures et sa fiche sur les stores.
Les garde-fous à poser
Pousser du code sur des milliers de téléphones sans passer par personne est un pouvoir qui demande de la discipline. Une mise à jour à distance mal maîtrisée peut casser l’application pour tout le monde en une minute, ce qu’aucun bug isolé ne fait. Quatre précautions font la différence :
- Signer chaque mise à jour, pour que l’application refuse tout ce qui ne vient pas de vous.
- Respecter la compatibilité : une mise à jour ne doit atteindre que les versions installées capables de la faire tourner.
- Tester sur une copie de la production avant de publier, avec de vraies données et de vrais parcours.
- Pouvoir revenir en arrière en un geste, si malgré tout quelque chose se passe mal.
La mise à jour à distance est un filet de sécurité, pas une porte dérobée.
Le meilleur correctif ne demande aucune mise à jour
Une autre façon de gagner en réactivité est de laisser au serveur les décisions qui peuvent changer : ce qu’on affiche, à qui, dans quel ordre. Une règle qui vit sur le serveur se corrige pour tout le monde instantanément, sans rien publier sur les téléphones. C’est l’approche que nous avons suivie sur Nakama, notre réseau social de l’anime et du manga : le voile anti-spoiler est décidé par le serveur, et pour le reste, une correction atteint les téléphones dès l’ouverture suivante de l’application, signée par nos soins, après avoir été éprouvée sur une copie de la production.
Si votre application met des jours à recevoir un correctif, ou si chaque mise à jour est une source d’angoisse, c’est un chantier qui se mène sans tout reconstruire. Il fait partie de ce que nous entendons par un produit, jamais une démo, et de notre travail en ingénierie produit. Parlez-nous de votre application : nous regarderons ce qui peut se corriger à distance, et comment le faire sans risque.