Les 10 signes qu'une application mobile est mal construite

Une application mobile mal construite se reconnaît sans lire une ligne de code : elle plante ou se fige plus souvent que les seuils fixés par Google Play, chaque petite modification prend des semaines, les correctifs cassent autre chose, et vous n'avez pas la main sur le code ni sur les comptes des stores. Un signe isolé n'est pas une condamnation ; trois ou quatre signes cumulés indiquent en général une dette technique réelle, qu'un audit permet de mesurer avant de décider s'il faut corriger, mettre à jour ou reconstruire.

Cet article s'adresse aux fondateurs et chefs de produit non développeurs qui soupçonnent que leur app, construite par une agence, un freelance ou un outil no-code ou d'IA, pose problème. Les seuils cités sont vérifiés sur les documentations officielles à la date d'octobre 2026.

Comment savoir si une application mobile est bien construite sans lire le code ?

On juge une application mobile sans lire le code en observant trois choses : son comportement chez les utilisateurs (plantages, lenteurs), le coût de son évolution (délais, régressions) et sa maîtrise (accès, versions, outillage, sécurité). Chacun des dix signes ci-dessous se vérifie avec un accès aux consoles des stores ou une question posée à votre prestataire.

Un bon code ne se voit pas : il se remarque par l'absence de mauvaises surprises. Une app mal construite finit toujours par se trahir, chez vos utilisateurs ou sur votre facture.

Quels sont les 10 signes d'une application mobile mal construite ?

Les dix signes d'une application mobile mal construite sont les plantages, la lenteur, le coût des petites modifications, les régressions, l'absence de tests, l'absence d'accès au code et aux comptes, un framework très en retard, les avertissements des stores, l'absence d'outillage et les failles de sécurité. Pour chacun : ce que ça signifie, comment le vérifier, sa gravité.

1. L'app plante ou se fige régulièrement

Ce que ça signifie. Un plantage (crash) ferme brutalement l'app. Un ANR (Application Not Responding) est un blocage : l'app ne répond plus et Android propose de la fermer. Des plantages fréquents traduisent des erreurs non gérées ou des problèmes de mémoire.

Comment le vérifier. Dans la Play Console, ouvrez Android vitals. Selon l'aide Play Console, le seuil de mauvais comportement est atteint quand au moins 1,09 % des utilisateurs quotidiens subissent un plantage perçu, ou 0,47 % un ANR, tous appareils confondus (8 % sur un modèle de téléphone donné). Côté iPhone, selon la documentation Xcode, les plantages des utilisateurs TestFlight et App Store qui partagent leurs données apparaissent dans l'organiseur Crashes de Xcode.

Gravité : élevée. Selon la page Android vitals, au-delà de ces seuils, évalués sur 28 jours, Google Play peut réduire la visibilité de l'app et afficher un avertissement sur sa fiche.

2. L'app est lente à démarrer ou à afficher ses écrans

Ce que ça signifie. Une app lente charge trop de choses au démarrage, multiplie les appels au serveur ou affiche des listes mal optimisées. C'est souvent le premier symptôme d'une architecture fragile.

Comment le vérifier. Chronométrez l'ouverture de l'app sur un téléphone d'entrée de gamme. La page App startup time d'Android vitals juge excessif un démarrage à froid (app fermée) de 5 secondes ou plus, un démarrage tiède de 2 secondes ou plus et un démarrage à chaud (app restée en mémoire) de 1,5 seconde ou plus.

Gravité : moyenne à élevée, selon que la lenteur touche un écran secondaire ou le parcours principal (inscription, paiement).

3. Chaque petite modification prend des semaines et coûte cher

Ce que ça signifie. Changer un texte ou ajouter un champ devrait prendre des heures, pas des semaines. Quand chaque détail est chiffré lourdement, c'est souvent que le code est dupliqué, enchevêtré, ou que personne n'ose y toucher.

Comment le vérifier. Notez sur trois mois les demandes simples et leur délai réel jusqu'à la publication. Demandez pourquoi une modification mineure est longue : une réponse précise (« ce champ existe dans quatre écrans écrits différemment ») est déjà un diagnostic.

Gravité : moyenne, mais croissante : c'est le coût de la dette technique, payé à chaque évolution.

4. Chaque correctif casse autre chose

Ce que ça signifie. Une régression est une fonction qui marchait et ne marche plus après une mise à jour. Des régressions fréquentes signifient que les parties de l'app dépendent trop les unes des autres et que personne ne vérifie l'ensemble avant de publier.

Comment le vérifier. Relisez les retours utilisateurs des dernières versions : les mêmes bugs reviennent-ils ?

Gravité : élevée. Chaque publication devient risquée, ce qui pousse à publier moins souvent.

5. Il n'existe aucun test automatisé

Ce que ça signifie. Les tests automatisés sont des programmes qui vérifient que l'app fonctionne après chaque modification. La documentation React Native distingue l'analyse statique, les tests unitaires, d'intégration, de composants et de bout en bout, ces derniers étant à réserver aux parcours vitaux comme la connexion et le paiement. Sans tests, tout repose sur des clics manuels, souvent incomplets.

Comment le vérifier. Demandez : « Combien de tests automatisés avons-nous, et sont-ils lancés à chaque modification ? » Une réponse floue vaut un non.

Gravité : moyenne. Ce n'est pas un bug en soi, mais cela explique souvent les signes 3 et 4.

6. Vous n'avez pas accès au code source ni aux comptes des stores

Ce que ça signifie. Si le code est uniquement chez votre prestataire et que l'app est publiée sur son compte, vous ne possédez pas vraiment votre application : impossible de changer de prestataire ou de publier un correctif en urgence.

Comment le vérifier. Vérifiez que vous avez accès au dépôt Git complet, que l'app est publiée sur vos propres comptes Apple et Play Console, et que vous savez qui détient la clé de signature Android. Selon la documentation Android sur la signature, sans Play App Signing, perdre cette clé empêche de publier toute mise à jour, et Google ne peut pas la récupérer. Une app publiée sur le compte d'un tiers peut être transférée (App Store Connect, Play Console), avec l'accord des deux comptes.

Gravité : critique. C'est le seul signe qui peut rendre une app impossible à maintenir, quelle que soit la qualité de son code.

7. Le framework a plusieurs versions de retard

Ce que ça signifie. Le framework (React Native, Expo, Capacitor, Flutter) et les librairies évoluent en permanence ; une app jamais mise à jour accumule un retard qui se paie d'un coup. Selon la page Releases de React Native, l'équipe ne maintient que les trois dernières séries de versions ; à la date d'octobre 2026, la 0.84 et toutes les précédentes sont classées non supportées. Depuis la 0.82, la New Architecture est aussi obligatoire (voir notre article sur la New Architecture React Native).

Comment le vérifier. Demandez la version de React Native ou d'Expo utilisée et la date de la dernière mise à jour des dépendances. Une app en React Native 0.6x ou 0.7x tourne sur une version qui n'est plus supportée depuis longtemps.

Gravité : élevée. L'app fonctionne encore, mais le retard finit par bloquer les publications (signe 8).

8. Apple ou Google vous envoient des avertissements

Ce que ça signifie. Les stores relèvent régulièrement leurs exigences techniques ; une app qui ne suit pas reste en ligne mais ne peut plus être mise à jour. Selon Android Developers, depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler Android 16 (API 36), avec une prolongation possible jusqu'au 1er novembre 2026, et une app existante qui cible Android 14 ou moins n'est plus proposée aux nouveaux utilisateurs des appareils récents. Selon la page Upcoming requirements d'Apple, toute app envoyée sur App Store Connect doit être compilée avec Xcode 26 depuis le 28 avril 2026.

Comment le vérifier. Consultez la boîte de réception de la Play Console et les e-mails reçus par le titulaire du compte Apple. Notre article sur le blocage Google Play API 36 détaille la marche à suivre.

Gravité : élevée à critique : le jour où un correctif urgent est nécessaire, il ne peut plus être publié.

9. Il n'y a ni recette, ni déploiement automatisé, ni suivi des plantages

Ce que ça signifie. Un environnement de recette (staging) est une copie de l'app et du serveur où l'on teste avant la production. Un déploiement automatisé (CI/CD) fabrique et vérifie chaque version de la même façon. Un outil de suivi des plantages remonte les erreurs avec leur contexte. Sans eux, les modifications sont testées directement sur vos utilisateurs.

Comment le vérifier. Demandez où l'équipe teste avant de publier, comment une version est fabriquée, et quel outil l'alerte quand l'app plante. Si la réponse est « les utilisateurs nous préviennent », le signe est confirmé.

Gravité : moyenne. C'est rapide à mettre en place, mais son absence en dit long sur la rigueur du projet.

10. Des clés secrètes ou des données sont exposées

Ce que ça signifie. Une app mobile est un fichier que n'importe qui peut télécharger et décortiquer. L'OWASP Mobile Top 10 place en tête la mauvaise gestion des identifiants et recommande de ne jamais les écrire en dur dans le code ou la configuration de l'app. Le cas est fréquent dans les apps Lovable ou Bolt sur Supabase : selon la documentation Supabase, la clé publique peut être exposée car la Row Level Security (les règles qui filtrent l'accès aux données ligne par ligne) limite ce qu'elle atteint, mais la clé secrète (service_role) contourne ces règles et ne doit jamais figurer dans une app publiée.

Comment le vérifier. Demandez où sont stockées les clés d'API et si la Row Level Security est activée sur toutes les tables. Testez aussi : un utilisateur connecté peut-il voir les données d'un autre en modifiant un identifiant ?

Gravité : critique. Une fuite de données personnelles engage votre responsabilité, bien au-delà de la qualité technique.

Quel tableau utiliser pour évaluer son application ?

Ce tableau résume les dix signes d'une application mobile mal construite, le moyen de les vérifier et leur gravité, pour un premier diagnostic en une heure.

Un seul signe critique justifie une action rapide. Trois signes élevés ou plus indiquent généralement un problème de fond plutôt qu'une série d'accidents.

Une app mal construite doit-elle être entièrement refaite ?

Une application mal construite ne doit pas forcément être refaite : souvent, des corrections ciblées, une mise à jour du framework et un outillage minimal suffisent. La reconstruction devient raisonnable quand plusieurs problèmes de fond se cumulent : code sans structure, aucun test, framework très ancien et chaque évolution hors de prix. Refaire une app « par principe » coûte cher et réintroduit de nouveaux bugs ; la décision doit s'appuyer sur un examen du code, pas sur une impression.

Quand faut-il faire auditer son application mobile ?

Il faut faire auditer une application mobile dès qu'un signe critique apparaît, ou que trois signes ou plus se cumulent, et avant toute décision coûteuse :

• avant de signer un devis de refonte ou de migration ;
• au moment de changer de prestataire, pour connaître l'état réel de ce que vous récupérez ;
• après un avertissement d'Apple ou de Google ;
• avant une levée de fonds ou une cession ;
• quand une app construite avec un outil no-code ou d'IA commence à avoir de vrais utilisateurs.

Un audit indépendant a un avantage : celui qui l'établit n'a pas écrit le code et n'a aucun intérêt à le défendre.

Si plusieurs de ces signes vous concernent et que le projet a déjà déraillé, notre guide Refonte d'application ratée : que faire maintenant ? détaille les premières étapes, et Refaire son application de zéro ou la sauver ? aide à choisir la suite.

Se faire accompagner

Si plusieurs de ces signes vous concernent, l'audit de reprise d'application de GUIGUI Tech coûte 1 500 € HT et est livré en 5 jours ouvrés, pour une app React Native, Expo, Capacitor, Ionic ou Cordova, une application web React, Next.js ou Vue.js, ou du code généré avec Lovable ou Bolt : récupération des accès, revue du code et de l'architecture, vérification rapide de la sécurité, état des dépendances et de la conformité aux stores, verdict chiffré (sauver, reprendre en partie ou refaire), rapport PDF et appel de restitution d'une heure. Son prix est déduit des travaux confirmés dans les 30 jours.

Selon le diagnostic, la mise à jour Expo SDK et New Architecture (à partir de 6 500 € HT, 2 à 4 semaines) ou la mise en conformité Google Play et App Store (à partir de 2 500 € HT, 1 à 3 semaines, même si votre développeur est parti) peuvent suivre. Si votre app React Native fonctionne et doit seulement monter de version, l'audit React Native suffit. Pour une app Lovable ou Bolt dont seule la sécurité vous inquiète, l'audit de sécurité Lovable coûte 1 200 € HT, en 3 jours ouvrés.