Tout le monde regarde la courbe des DAU. Presque personne ne regarde les logs de crash.
Demande à un acheteur ce qu'il a vérifié avant de racheter un business d'appli mobile, et tu auras un topo assuré sur le MRR, l'ARPU, la rétention à J30, la courbe d'installs. Demande-lui à quoi ressemblait le taux de sessions sans crash sur les deux dernières versions, et la plupart resteront muets. Personne ne l'a mis dans le tableau, parce que personne ne l'a demandé au vendeur.
C'est un vrai angle mort, et différent de celui d'un site web. Un site lent te coûte des conversions. Une appli instable peut te coûter la visibilité sur le store — Google Play et l'App Store utilisent tous deux des signaux de stabilité technique pour décider comment (et si) une appli est mise en avant. Racheter une appli avec un taux de crash qui grimpe doucement, ce n'est pas juste hériter d'un backlog de bugs. C'est hériter d'un problème de classement que les captures d'écran du vendeur ne montraient jamais.
La due diligence technique pour une appli mérite son propre passage, distinct de la checklist codebase générique que tu ferais pour un site ou un SaaS. La due diligence financière te dit ce que l'appli a rapporté. L'audit de santé te dit si elle continuera à rapporter.
Pourquoi la stabilité est un problème de visibilité store, pas juste d'expérience utilisateur
Les stores ne sont pas des tuyaux neutres. Les deux plateformes suivent la stabilité comme un critère de qualité continu : la documentation "vitals" d'Android signale qu'un taux de crash au-delà d'environ un pourcent des utilisateurs actifs quotidiens est un "mauvais comportement" qui peut réduire la visibilité et l'éligibilité à la mise en avant d'une fiche. Apple fait remonter des signaux de qualité équivalents dans les analytics d'App Store Connect, avec un benchmark par groupe de pairs.
Ça veut dire qu'une appli techniquement fragile n'embête pas que ses utilisateurs actuels — elle peut déjà être en train de perdre discrètement la découverte organique qui alimente les nouvelles installs, bien avant que le revenu n'en montre les dégâts. Le temps qu'une baisse d'installs apparaisse sur une capture d'écran, le problème de stabilité sous-jacent traîne généralement depuis des mois.
Les cinq chiffres à récupérer avant de faire une offre
| Métrique | Ce qu'elle te dit | Où la trouver |
|---|---|---|
| % de sessions sans crash | Stabilité globale sur l'ensemble des utilisateurs | Play Console, App Store Connect, ou un outil de crash reporting (ex. Crashlytics) |
| % d'utilisateurs sans crash | Si l'instabilité est isolée ou généralisée | Mêmes dashboards |
| Taux d'ANR (Android uniquement) | Gels et interfaces qui ne répondent plus, distinct des crashs francs | Vitals Android dans Play Console |
| Tendance de note par version d'appli | Si une version précise a introduit une régression | Avis du store triés par date, croisés avec les notes de version |
| SDK cible / version OS minimale | À quel point l'appli est en retard sur les exigences de plateforme actuelles | Fiche du store vs exigences SDK Android/iOS actuelles |
Aucun de ces chiffres n'apparaît sur un compte de résultat. Tous apparaissent dans ta boîte support et ton tunnel install-vers-revenu dans le trimestre qui suit la reprise.
À quoi ressemble un "bon" chiffre
Les benchmarks varient un peu selon la catégorie, mais la tendance générale tient pour les applis grand public : un taux de sessions sans crash confortablement au-dessus de 99,5% est une base raisonnable, 99,9%+ est ce qu'atteignent les équipes qui surveillent activement leur stabilité, et les plus rigoureuses visent 99,99%. À l'inverse, les applis qui descendent sous environ 99,9% de sessions sans crash ont nettement plus de chances de se retrouver sous une moyenne de 3 étoiles — stabilité et note sont étroitement corrélées, parce qu'un utilisateur qui subit des crashs répétés est bien plus enclin à laisser un avis qu'un utilisateur satisfait.
Prends ça comme des repères directionnels, pas comme un couperet. Une appli à 99,7% avec une cause claire et corrigible n'est pas automatiquement un mauvais deal — c'est un levier de négociation, exactement comme un mois de revenu un peu faible.
Comment récupérer ces données en tant qu'acheteur
- 1. Demande des captures de dashboard datées de moins de deux semaines, pas un export historique vieux de plusieurs mois. Le taux de crash peut bouger vite après une seule version ratée.
- 2. Demande un accès en lecture seule à Play Console ou App Store Connect pendant la due diligence si la taille du deal le justifie. Un vendeur qui résiste sur un deal de taille moyenne ou plus mérite une conversation directe sur le pourquoi.
- 3. Trie les avis du store par date récente et cherche un vocabulaire récurrent — « plante au lancement », « se fige », « ne se charge pas » — regroupé autour d'une date précise. Cette date, c'est la régression à interroger.
- 4. Croise l'exigence de version OS minimale de l'appli avec les versions de plateforme actuelles. Un grand écart est un indicateur du temps écoulé depuis la dernière vraie maintenance du code.
- 5. Demande quel outil de crash reporting est branché, et si quelqu'un le regarde vraiment. Un outil installé mais jamais consulté t'en dit autant que l'absence d'outil.
- 6. Télécharge l'appli toi-même et utilise-la quinze minutes sur les parcours principaux. C'est l'étape de vérification la moins chère de toute la liste, et les acheteurs la sautent tout le temps.
De la dette technique cachée derrière un chiffre de revenu propre
Une appli qui a l'air stable peut quand même porter une dette qui n'apparaît qu'une fois que tu es propriétaire. Surveille les SDK tiers — régies pub, prestataires de paiement, services de push — non mis à jour depuis un an ou plus ; les plateformes imposent périodiquement des relèvements de SDK cible minimum, et une appli construite sur des dépendances vieillissantes peut se retrouver dans l'urgence (voire suspendue du store) quand l'échéance tombe. Surveille aussi un code qui dépend de la configuration locale ou du compte développeur personnel d'une seule personne pour pouvoir publier une mise à jour. Ce n'est pas une métrique de stabilité, mais c'est le même type de risque : invisible dans les chiffres jusqu'au jour où tu en as besoin et que ça n'est plus là.
Signaux d'alerte à ne pas ignorer
| Signal | Pourquoi c'est important |
|---|---|
| Sessions sans crash en baisse sur les 2-3 dernières versions | Instabilité active et qui s'aggrave, pas un incident isolé |
| Avis une étoile mentionnant des crashs regroupés juste après une version précise | Indique une régression peut-être pas encore corrigée |
| L'appli cible une version SDK plusieurs générations en retard | Vrai risque d'échéance store forcée ou de retrait, et signale un code vieillissant |
| Le vendeur ne peut pas fournir d'accès dashboard récent ou de captures | Tu valorises le deal sur la seule métrique que tu ne peux pas vérifier toi-même |
| SDK cœur non maintenus depuis 12+ mois sans plan de migration | Coût de refonte caché derrière une fiche par ailleurs propre |
Aucun de ces signaux ne doit automatiquement faire tomber un deal à lui seul. Ce sont des éléments de prix et de négociation — un business avec une vraie dette technique peut rester une acquisition juste au bon prix, avec un plan et un budget clairs après la reprise pour corriger ce qui ne va pas.
Où placer ça dans ton calendrier de due diligence
Fais la version rapide — captures de dashboard plus quinze minutes d'utilisation de l'appli — avant de soumettre une LOI. Si quelque chose cloche, fais de l'accès dashboard en lecture seule une condition explicite de la due diligence approfondie, et fais refléter tes constats dans le prix ou une garantie plutôt que de te fier à une réassurance orale.
Rien de tout ça ne constitue un conseil juridique ou financier — considère ça comme une checklist de départ et fais appel à un professionnel technique ou juridique qualifié avant de t'appuyer dessus pour structurer une offre. Mais la stabilité d'une appli est une affirmation sur le business exactement comme un chiffre de revenu, et elle mérite le même niveau de rigueur avant d'aller voir les deals.FAQ
Je dois être développeur pour faire cette vérification ?Non. Chaque métrique ci-dessus vit dans un dashboard (Play Console, App Store Connect, ou un outil de crash reporting) lisible par un acheteur non technique dès qu'on lui donne un accès ou une capture d'écran.
Une mauvaise note d'appli, c'est toujours un problème technique ?Pas toujours — beaucoup de mauvaises notes concernent le prix, des choix d'UX, ou des fonctionnalités manquantes. Mais quand les avis négatifs mentionnent précisément des plantages, des gels ou une appli qui ne s'ouvre pas, c'est un signal de stabilité à vérifier dans les dashboards, pas juste une question de goût.
Et si le vendeur refuse de partager l'accès au dashboard de crash ?C'est une demande légitime à défendre pour tout deal au-delà d'une petite taille. S'il ne bouge pas, pondère davantage les avis du store comme preuve et intègre l'incertitude dans le prix plutôt que de le croire sur parole.
Je dois abandonner un deal avec un taux de crash élevé ?Pas automatiquement. Traite-le comme n'importe quel autre constat de due diligence : intègre-le au prix, négocie une garantie de passif, ou obtiens un engagement de correction ferme avant la clôture, selon la gravité et l'ancienneté de l'instabilité.
Le taux de crash et les données "vitals" du store font partie des vérifications les moins chères de toute la due diligence — une capture de dashboard et quinze minutes avec l'appli — et les sauter, c'est comme ça que des acheteurs héritent d'un problème de classement qu'ils ne savaient pas avoir acheté. Ajoute ça à ta checklist avant d'aller voir les annonces Flippa ou les deals Dotmarket, et crée une alerte deals pour avoir le temps de faire cet audit correctement plutôt que de le bâcler sous la pression d'une fiche qui va bientôt partir.