Maintenance et refonte d’application mobile

La maintenance d’une application mobile n’est pas un luxe. Une app qu’on ne touche plus finit par planter sur les téléphones récents, puis par ne plus pouvoir être mise à jour sur les stores. Et le jour où un bug bloque les paiements, il faut quelqu’un qui connaisse le code et ait accès aux comptes.

Je maintiens les applications que je développe, et je prends en charge la reprise d’une application mobile développée par d’autres, en Flutter ou en vue d’une migration vers Flutter. Ce service complète mon offre de développement d’application mobile : voici ce que recouvre la maintenance, comment je reprends une app existante et quand une refonte s’impose.

Pourquoi maintenir son application (OS, stores, sécurité)

Parce qu’une application vit dans un environnement qui change sans vous : nouvelles versions d’iOS et d’Android chaque année, exigences des stores qui se durcissent, dépendances qui vieillissent, failles découvertes. C’est pour cela qu’AppliWin assure la maintenance des applications après leur publication. Sans maintenance, l’app finit par planter sur les téléphones récents, puis par ne plus pouvoir être mise à jour du tout.

• Google Play impose chaque année de cibler une version récente d’Android (targetSdk) pour publier une mise à jour ; une app trop ancienne n’est plus proposée aux nouveaux utilisateurs des appareils récents.
• Apple exige régulièrement de compiler avec un SDK et une version de Xcode récents pour soumettre une mise à jour.
• Les dépendances (paquets Flutter, SDK Firebase, paiement, cartographie) évoluent, corrigent des failles et abandonnent les anciennes versions.
• Les règles de confidentialité se renforcent : déclarations des stores, manifestes de confidentialité des SDK chez Apple, suppression de compte dans l’app.
• Le back-office et l’API vieillissent aussi : versions de PHP, extensions, certificats.

Si votre application repose sur WordPress, le back-office se maintient au même rythme que l’app : voyez la maintenance WordPress. Les deux vont de pair, car une mise à jour côté serveur peut casser l’application si personne ne vérifie l’API.

Sur LSF-CFB, l’application de langue des signes que j’ai développée, le travail a continué après la livraison de la première version : ajustements exigés par la revue d’Apple, correction d’un chargement sans fin après un achat intégré, ajout de délais d’expiration réseau. C’est la réalité d’une app vivante : la livraison n’est jamais la dernière version.

Maintenance corrective, évolutive, préventive, adaptative

La maintenance corrective répare les bugs. La préventive anticipe : mises à jour de dépendances, surveillance, sauvegardes. L’adaptative suit les nouvelles versions d’iOS et d’Android et les règles des stores. L’évolutive ajoute des fonctions. Confiées à un prestataire externe, elles forment ce qu’on appelle la TMA, ou tierce maintenance applicative.

Type	Objectif	Exemples
Corrective	Réparer ce qui ne fonctionne pas	Plantage au démarrage, paiement bloqué, écran mal affiché
Préventive	Éviter les pannes	Mise à jour des dépendances, surveillance, sauvegardes
Adaptative	Suivre l’environnement	Nouvelle version d’iOS ou d’Android, exigence des stores
Évolutive	Faire grandir l’app	Nouvelle fonction, nouveau parcours, refonte d’un écran

La préventive et l’adaptative sont les plus négligées, et les plus rentables. Suivie chaque trimestre, une dépendance demande souvent une heure de travail ; trois ans de retard se paient en jours, parfois en réécriture. C’est la dette technique : invisible jusqu’au jour où elle bloque tout.

Formules et tarifs

Je travaille de deux façons : à l’intervention, pour une app stable qui a rarement besoin de moi, ou en suivi régulier, défini après audit, qui couvre les mises à jour annuelles, la surveillance et un volume d’heures. Les évolutions sont chiffrées à part. Le tarif horaire moyen constaté sur mon profil Codeur.com est de 75 € HT.

Formule	Pour qui	Contenu
Intervention ponctuelle	App stable, besoin occasionnel	Correctif, mise en conformité, publication, au temps passé ou sur devis
Suivi régulier	App active, chiffre d’affaires en jeu	Maintenance préventive et adaptative, surveillance, publications, volume d’heures défini après audit
Évolutions	Nouvelles fonctions	Chiffrées au forfait après définition du périmètre

Un contrat de maintenance d’application en suivi régulier comprend typiquement :

• la mise à jour des dépendances et des outils de compilation, à un rythme planifié ;
• l’adaptation aux nouvelles versions d’iOS et d’Android et aux exigences annuelles des stores ;
• la surveillance des plantages et des erreurs de l’API, avec un point régulier ;
• la publication des mises à jour sur les deux stores, fiches et déclarations comprises ;
• un volume d’heures pour les corrections et petites évolutions.

Je ne publie pas de forfait fixe : le volume dépend de l’âge du code, du nombre de dépendances, de l’activité de l’app et du back-office. Je le chiffre après l’audit, par écrit. Si vous avez besoin d’un engagement de délai d’intervention (SLA), nous le définissons ensemble, en fonction de ce que je peux réellement tenir en tant que freelance.

Pour estimer un budget annuel avant de me contacter, lisez mon article sur le coût de maintenance d’une application mobile. Et si la refonte se rapproche d’une nouvelle application, les fourchettes du prix de création d’une application donnent un premier ordre de grandeur.

Reprise d’une application mobile existante : audit de code

Avant de reprendre une application développée par un autre prestataire, je réalise un audit : accès aux sources et aux comptes des stores, capacité à compiler et publier, état des dépendances, qualité du code, sécurité. Vous obtenez un état des lieux écrit, des risques classés et une recommandation claire : maintenir, corriger ou refaire.

• Accès : code source, dépôt, App Store Connect, Google Play Console, Firebase, hébergement, nom de domaine. Tout doit être à votre nom.
• Compilation : l’app se construit-elle aujourd’hui avec des outils à jour ?
• Dépendances : versions, paquets abandonnés, failles connues.
• Architecture et qualité : organisation du code, tests, dette technique.
• Sécurité : clés exposées dans l’app, stockage des données, protection de l’API.
• Conformité : version Android ciblée, déclarations de confidentialité, suppression de compte.

Un cas courant : un développeur injoignable et des comptes de store à son nom. Apple comme Google prévoient une procédure de transfert d’application d’un compte à un autre, qui exige l’accord du titulaire actuel. D’où l’importance de le contacter tôt, et de toujours ouvrir les comptes développeur au nom de votre entreprise. Sans le code source, en revanche, il faut généralement repartir de zéro.

L’audit se conclut par un document que vous pouvez montrer à n’importe quel prestataire : constats, risques classés par gravité, estimation des corrections prioritaires et recommandation argumentée. Vous restez libre de la suite. Si je reprends l’application, je commence par sécuriser les accès et par publier une première mise à jour de contrôle, pour vérifier que toute la chaîne fonctionne.

Refonte : quand et comment

Une refonte s’impose quand corriger coûte plus cher que reconstruire : technologie abandonnée, dette technique qui ralentit chaque évolution, plantages récurrents, design daté qui fait fuir, back-office inutilisable. Elle se mène sans casser l’existant : même fiche sur les stores, comptes et données migrés, transition planifiée pour les utilisateurs.

La règle d’or : publier la nouvelle version sous le même identifiant d’application (bundle ID chez Apple, nom de package chez Google), avec la même clé de signature côté Android. Les utilisateurs reçoivent alors une simple mise à jour, et vous conservez les avis, les notes et l’historique de la fiche.

1. Audit de l’existant et liste des fonctions à garder, abandonner ou ajouter.
2. Maquettes de la nouvelle version, testées auprès de quelques utilisateurs actuels.
3. Développement, avec migration des comptes et des données.
4. Publication progressive, puis écran de mise à jour obligatoire pour les anciennes versions.

Migration vers Flutter

Migrer vers Flutter consiste à remplacer deux applications natives, en Swift et en Kotlin, ou une app hybride vieillissante (Cordova, Ionic, Xamarin) par un seul code pour iOS et Android. La maintenance devient plus simple et moins coûteuse : une correction, deux plateformes. La migration se fait écran par écran ou d’un bloc.

Xamarin n’est plus pris en charge par Microsoft depuis mai 2024 : les apps qui en dépendent doivent migrer. Pour une grosse application native, Flutter permet une migration progressive, en intégrant des modules Flutter dans l’app existante (add-to-app). Pour une app plus modeste, la réécriture complète est souvent plus rapide et plus propre.

Pour vos utilisateurs, la migration doit être invisible ou presque : même icône, même fiche de store, mêmes identifiants de connexion, données conservées. Ce qui change, c’est la suite : une seule base de code à faire évoluer, des corrections publiées en même temps sur iOS et Android, et un budget de maintenance qui ne se paie plus deux fois.

Le choix de Flutter et ses limites sont détaillés sur ma page développeur Flutter, et la publication sur les deux stores sur celle consacrée aux applications iOS et Android.

Monitoring, crashs, sauvegardes

Une application maintenue se surveille : rapports de plantage avec Firebase Crashlytics ou Sentry, alertes sur les erreurs de l’API, suivi des avis sur les stores, sauvegardes régulières du back-office. L’objectif est double : découvrir un problème avant vos utilisateurs, et pouvoir revenir en arrière si une mise à jour se passe mal.

• Rapports de plantage avec la ligne de code en cause, l’appareil et la version du système.
• Erreurs de l’API journalisées et signalées dès qu’elles dépassent un seuil.
• Avis des stores lus régulièrement : ils révèlent souvent un bug avant les outils.
• Sauvegardes du back-office et des données, avec restauration testée.
• Déploiement progressif des mises à jour, par paliers sur Google Play et sur l’App Store.
• Copies sécurisées des certificats, clés de signature et accès, stockées hors de l’ordinateur du développeur.

Votre application a besoin d’une maintenance sérieuse, d’une reprise ou d’une refonte ? Contactez-moi pour un premier échange, ou demandez un devis avec le lien de votre app : je commence par un audit, puis je vous dis franchement ce que demande la maintenance de votre application mobile.

Questions fréquentes sur la maintenance d’application