Applications mobiles · Mixte

Versions et compatibilité ascendante dans les applications

En une ligne : Les utilisateurs conservent d'anciennes versions pendant des mois — le serveur doit les prendre en charge et savoir quand arrêter.

La réalité

Même avec la mise à jour automatique activée, la répartition des versions s'étale sur des mois. Tout changement cassant dans l'interface serveur fait tomber de vrais utilisateurs sans qu'ils comprennent pourquoi.

Donc : étendez, ne modifiez pas. Ajoutez des champs, n'en supprimez pas ; ajoutez des routes, ne changez pas le comportement des existantes.

Mécanismes de contrôle

Version d'interface. Déclarez-la à chaque requête pour savoir qui vous parle.

Mise à jour forcée. Un écran qui bloque les versions qui ne sont plus prises en charge. Économique, et doit être là dès le premier jour — on ne peut pas l'ajouter rétroactivement à une ancienne version.

Interrupteurs de capacité. Activer et désactiver les capacités à distance, par version et par pourcentage d'utilisateurs.

Quand arrêter le support

Décidez par données, pas par ressenti : quand moins d'un pour cent de l'utilisation active provient d'une version, et après un préavis dans l'application. Documentez la politique pour ne pas la renégocier à chaque publication.

Pour aller plus loin

Exécutez des tests d'intégration des deux dernières versions prises en charge contre l'interface actuelle à chaque publication serveur. La compatibilité ascendante non testée automatiquement se casse silencieusement, et ne se révèle que dans les avis de la boutique.