Audit d'une application mobile : la checklist avant refonte ou reprise

Commencer par la décision à prendre

Formulez la question avant d'ouvrir le dépôt de code. L'application peut-elle accompagner le prochain marché ? Pourquoi les réservations chutent-elles ? Une autre équipe peut-elle la reprendre sans interruption ? Une reconstruction coûterait-elle moins cher que des corrections successives ? Précisez également l'horizon : sauver une version dans six semaines et préparer trois années d'évolution ne demandent pas la même profondeur.

Délimitez les plateformes, pays, rôles, versions, services backend et intégrations concernés. Un périmètre explicite évite une étude sans fin et permet de rattacher chaque vérification à une décision concrète.

Constituer un dossier de preuves et d'accès

Rassemblez objectifs, modèle économique, parcours, avis des stores, demandes d'assistance, motifs de résiliation, analytics, rapports de crash, historique des versions et maquettes. Ajoutez ensuite dépôts, documentation d'API, environnement de test et services tiers.

Un registre d'accès doit préciser qui possède App Store Connect, Google Play Console, l'hébergement, les domaines, le code, les analytics, les notifications, le paiement et les certificats. Un compte absent peut bloquer une livraison ; ce n'est pas une simple formalité. Notre guide de documentation et de transfert décrit ce qu'une équipe entrante devrait recevoir.

Tester les parcours qui portent la valeur

Demandez au responsable produit d'indiquer l'utilisateur prioritaire et le résultat qu'il doit atteindre lors de sa première session. Confrontez ensuite cette promesse au produit. Pour une place de marché, le traitement côté vendeur peut compter davantage que l'accueil de l'acheteur. Pour une application de formation, la reprise de progression peut être plus critique que le catalogue.

Classez les tickets, entretiens et avis par parcours et par conséquence. La fréquence ne suffit pas à fixer la priorité : deux paiements débités sans commande confirmée sont plus graves que de nombreuses demandes de changement de couleur. Lorsque les preuves manquent, inscrivez cette incertitude au rapport.

Sélectionnez cinq à huit tâches. Testez installation neuve, retour d'un utilisateur, connexion dégradée, autorisation refusée, session expirée, paiement interrompu et reprise après erreur, sur de vrais appareils. Pour chaque essai, conservez l'état initial, l'action, le résultat attendu, le résultat obtenu et une preuve.

Vérifier les analytics avant de commenter l'entonnoir

Un événement envoyé deux fois gonfle une conversion. Un achat déclaré avant la confirmation du paiement transforme un échec en succès apparent. Comparez le plan de marquage à l'implémentation, puis faites passer un compte connu par l'inscription, la réservation ou l'achat. Vérifiez nom, moment et paramètres, et rapprochez les transactions du backend ou du prestataire de paiement.

Les données de test ne doivent pas contaminer la production. Les versions doivent être identifiables et iOS comme Android doivent partager les mêmes définitions. Tant que la mesure reste douteuse, les conclusions de conversion sont provisoires. Notre guide de mise en place des analytics mobiles fournit une base exploitable.

Mesurer stabilité, performance et accessibilité

Segmentez crashs et blocages par version, appareil, système, marché et parcours. Android Vitals suit notamment les crashs perçus par l'utilisateur et les ANR ; la documentation Android Vitals détaille ces indicateurs et les problèmes propres à certains appareils. Côté Apple, App Store Connect App Analytics réunit des signaux d'acquisition, d'usage et de performance.

Chronométrez lancement, connexion, recherche, paiement, envoi de fichier et synchronisation avec différents réseaux et volumes de données. Une moyenne acceptable peut cacher une catégorie de clients qui attend dix secondes à chaque action.

L'accessibilité se teste au sein de ces parcours : agrandissement du texte, contraste, ordre de focus, libellés du lecteur d'écran, taille des zones tactiles, animations et erreurs. Un scanner automatique ne remplace pas la navigation avec une technologie d'assistance. Le guide d'Accessible.org sur l'audit mobile natif explique ce complément manuel.

Suivre une action de l'écran jusqu'à la base de données

La revue du code doit mesurer le risque de modification, pas défendre un framework. Examinez limites des modules, règles dupliquées, dépendances anciennes, tests, gestion des erreurs, secrets, configuration et capacité à générer l'application sur une machine propre. Un dépôt que seule une personne sait compiler constitue un risque opérationnel.

Suivez deux parcours de bout en bout : application, API, base de données et services tiers. Où se fait la validation ? Comment les nouvelles tentatives et les appels répétés sont-ils gérés ? Que met-on en cache ? Comment une migration est-elle publiée et annulée ? Cette lecture révèle des défauts invisibles dans le seul code mobile.

Examinez aussi les données collectées, leur localisation, leur durée de conservation, leur export et leur suppression. Santé, enfance, finance et géolocalisation exigent des compétences juridiques et de sécurité adaptées. L'audit général doit signaler ce besoin sans prétendre remplacer ces contrôles.

Faire démontrer la mise en production

Demandez à l'équipe de produire une version signée, lancer les tests, déployer le serveur et expliquer un retour arrière. Comparez la pratique aux instructions. Contrôlez séparation des environnements, intégration continue, secrets, alertes, interrupteurs de fonctionnalités et responsabilités en cas d'incident.

Vérifiez les droits sur le code, les maquettes, les polices, les médias et les bibliothèques payantes. Les comptes principaux appartiennent à l'entreprise ; chaque personne reçoit un accès nominatif limité à son rôle. Un mot de passe personnel partagé ne sécurise pas une reprise.

Choisir entre conserver, corriger, remanier, redessiner et remplacer

Évaluez séparément l'impact et la solidité de la preuve. Un défaut de paiement probable mais non reproduit exige une investigation rapide, pas l'annonce immédiate d'une reconstruction.

Attribuez une action à chaque composant :

• Conserver s'il fonctionne, est maîtrisé et soutient la feuille de route.
• Corriger si le défaut est isolé et sa réparation directe.
• Remanier si le comportement convient mais que la structure interne rend les évolutions risquées.
• Redessiner si la technique fonctionne mais que le parcours bloque les utilisateurs.
• Remplacer si une évolution progressive coûterait davantage ou conserverait un risque majeur.

Un remplacement complet demande un motif démontré : technologie non maintenue, traitement de données dangereux, livraison impossible à reproduire ou coût de changement structurel. L'ancienneté du code ne suffit pas. Consultez notre comparaison entre refonte et modernisation et le guide du coût d'une refonte mobile.

Le livrable qui permet réellement d'agir

Le rapport doit contenir périmètre, registre des preuves, architecture actuelle, parcours testés, niveau de confiance des analytics, base de stabilité, lacunes de propriété, recommandations prioritaires et plan par étapes. Chaque constat majeur indique conséquence, preuve, recommandation, dépendance, responsable et ordre de grandeur.

Séparez un plan de stabilisation sur 30 jours de la feuille de route. Les accès, crashs et paiements urgents ne doivent pas disparaître dans un chantier graphique. Cette séparation rend également l'estimation plus juste, car l'équipe chiffre un travail observé plutôt qu'un grand volume d'inconnues.

Chez Appfyl, l'audit sert à préserver les éléments utiles. Il peut déboucher sur une version de correction limitée, une refonte de quelques parcours ou le renforcement du backend. Nous ne conseillons une reconstruction complète que lorsque les preuves montrent qu'une évolution progressive coûterait plus cher ou laisserait un risque significatif. Le brief d'estimation Appfyl permet de décrire l'état actuel et les besoins.

Questions fréquentes