Maintenance continue pour une application mobile : mises à jour, pannes, versions

Une application cesse d'être écrite le jour de sa publication et commence à être maintenue en vie. Les plateformes expédient une nouvelle version du système chaque année, les règles du magasin changent, les bibliothèques reçoivent des correctifs de sécurité, et rien de tout cela n'attend une semaine libre dans votre feuille de route. Une application que personne n'a touchée depuis six mois ne semble que rarement cassée — elle cesse simplement de se construire sur une machine propre, commence à planter sur les appareils les plus récents et descend dans le magasin parce que les avis récents parlent tous de gel et de perte de données. Payer pour une opération de sauvetage une fois par an coûte bien plus cher que de garder le projet en forme en continu, et le sauvetage arrive toujours au pire moment.

Je commence de la même manière à chaque fois : avec un regard honnête sur ce qui est réellement là. Je construis le projet à partir de zéro sur une machine propre, je lis comment il est assemblé, je liste les dépendances qui n'ont pas bougé depuis des années, je marque les endroits fragiles dans le code et je passe en revue les rapports de pannes provenant de vrais appareils. Cela vous donne un verdict écrit court — ce qui doit être corrigé maintenant, ce qui peut attendre et ce que chaque retard est susceptible de coûter. Après cela, le travail se déroule en cycles : mise à jour des dépendances et ajout de support pour les nouvelles versions du système d'exploitation, suivi des pannes jusqu'à une cause et correction, réduction du temps de démarrage à froid et de la consommation de batterie, réalisation des petites modifications que vous demandez, puis préparation, signature et expédition de la prochaine version. Je lis également les avis qui se plaignent de la technologie plutôt que du produit — pannes, gels, données disparues. Ces avis pointent presque toujours un défaut spécifique, et ils sont la source de travail la moins chère que je connaisse.

Trois choses que je dis à voix haute avant de commencer, afin que personne ne soit déçu plus tard. Les délais de révision dans les magasins d'applications ne sont pas sous mon contrôle : je prépare la publication, réponds à chaque objection et veille à sa publication, mais personne ne peut promettre une date de publication exacte, et je ne ferai pas semblant du contraire. Les rapports de pannes sont collectés anonymement et uniquement avec le consentement de l'utilisateur — le contenu de l'écran, le texte tapé et les données personnelles ne sont jamais envoyés, et là où ce consentement est absent, je travaille avec ce qui est disponible. Abandonner le support d'une version système plus ancienne est convenu en fonction de la part de vos utilisateurs encore dessus, pas en fonction de ce qui est pratique pour moi : je fournis les chiffres, vous prenez la décision.

Ce que la maintenance couvre :
— un examen de l'état actuel du projet et de sa construction, avec un verdict écrit ;
— mises à jour des dépendances et support pour les nouvelles versions du système d'exploitation ;
— triage des pannes à partir des rapports des appareils, analyse des causes profondes et corrections ;
— démarrage plus rapide, consommation de batterie et de trafic réduite ;
— petites améliorations et modifications à votre demande ;
— préparation de la publication et support lors de l'examen du magasin ;
— gestion des avis signalant des problèmes techniques ;
— transfert de connaissances à votre équipe et un plan de publication pour le trimestre.