Un audit d'application mobile sert à répondre à une question simple : dans quel état est vraiment l'app, et par quoi faut-il commencer ? On le demande souvent au moment d'un changement : une équipe qui part, un prestataire qui reprend, une levée de fonds, une mise à jour que les stores refusent, ou une app qui plante de plus en plus sans que personne ne sache pourquoi.
Voici ce que je vérifie, dans l'ordre où je le fais.
1. Est-ce que l'app se construit encore ?
Premier test, et plus révélateur qu'il n'y paraît : récupérer le code sur une machine propre et produire un build. Si cela demande une demi-journée d'aide, des variables que seul un ancien développeur connaissait ou une version d'Xcode introuvable, c'est déjà une conclusion. Une app qu'on ne sait pas reconstruire est une app qu'on ne sait pas corriger rapidement.
2. Architecture et dépendances
- Comment l'app est découpée, et quelles parties résisteront à la prochaine fonctionnalité.
- Les bibliothèques abandonnées, qui n'ont plus de version compatible avec les dernières versions d'iOS ou d'Android.
- Les bibliothèques en double, qui font la même chose à deux endroits.
- Le code mort, et les zones que plus personne n'ose toucher.
Le but n'est pas de juger le style du code, mais de repérer ce qui va coûter cher au prochain changement.
3. Stabilité
Je pars de vos propres données de crash, dans Firebase Crashlytics, Xcode Organizer ou la Play Console. Les questions sont concrètes :
- quels crashs touchent le plus d'utilisateurs ;
- sur quels appareils et quelles versions du système ;
- ce qu'ils veulent dire dans le code, et s'ils ont une cause commune.
Souvent, une poignée de causes explique la majorité des crashs. Les trouver, c'est le correctif le plus rentable du rapport.
4. Performance
- Le démarrage à froid : le temps entre le tap sur l'icône et un écran utilisable.
- Les écrans qui saccadent, en particulier les listes longues.
- La mémoire qui grimpe au fil de l'utilisation.
- Ce que l'app consomme en réseau et en batterie dans un usage normal.
5. Sécurité et données
Côté app, pas un test d'intrusion : c'est un autre métier. Je regarde :
- où vivent les clés, les jetons et les secrets, et s'il y en a dans le code ;
- comment les données sont stockées sur le téléphone et envoyées au serveur ;
- la connexion, les sessions et leur expiration ;
- les permissions demandées, et si chacune sert encore ;
- les données personnelles que l'app collecte vraiment, comparées à ce qu'elle déclare.
6. Conformité aux stores
C'est souvent là que l'urgence se cache. Je vérifie si les builds passent encore les exigences actuelles d'Apple et de Google : la version d'Android visée, le SDK utilisé pour iOS, les déclarations de confidentialité, et tout ce qui bloquerait la prochaine mise à jour. En 2026, deux échéances ont déjà changé la donne : Xcode 26 pour l'App Store et l'API 36 pour Google Play.
7. Chaîne de livraison
- Qui peut publier une version aujourd'hui, et avec quels accès.
- Les certificats et clés de signature : où ils sont, et à qui ils appartiennent.
- Les tests, là où ils comptent.
- Le temps réel qu'il faut pour livrer un correctif, du commit à l'app sur le store.
Ce que vous recevez
Un rapport priorisé : chaque point avec son impact et l'effort pour le corriger, classé pour que vous puissiez arrêter de lire quand le budget s'arrête. Puis un appel d'une heure pour le parcourir avec votre équipe.
Je ne corrige rien pendant l'audit, pour que le rapport reste honnête. Les corrections sont une mission séparée, avec votre équipe ou avec moi.
Ce qu'il faut préparer
- Un accès en lecture au dépôt et aux configurations de build.
- Un accès en lecture à App Store Connect et à la Play Console, ou des exports des données de crash et de release.
- Une personne qui peut répondre aux questions produit pendant la semaine.
Avec cela, cinq jours suffisent pour les apps natives iOS et Android, comme pour les apps Kotlin Multiplatform et Flutter.
Si vous voulez un audit
Le déroulé jour par jour et les conditions sont sur la page Audit d'application mobile. Le prix est fixe, annoncé après un appel de 20 minutes et avant de commencer. Si votre app n'a pas besoin d'un audit, je vous le dirai pendant l'appel.