Chapitre 13.6 — Après la publication : vivre avec une app publique

Où on en est : Drill est en ligne. La publication n’est pas une fin — c’est un régime : mises à jour sous review, rollouts progressifs, avis à gérer, et les métriques de santé (vitals) que Google surveille À VOTRE PLACE.

⏱️ TL;DR — Le cycle de mise à jour publique : OTA pour le JS (immédiat), AAB + review pour le natif — désormais en staged rollout (10 % → 50 % → 100 %, arrêtable). Les Android vitals (taux de crash < 1,09 %, ANR < 0,47 %) conditionnent votre visibilité — les dépasser fait chuter l’app dans les recherches. Les avis : répondez (publiquement, vite, pro) — et les 1 étoile injustes se signalent. La routine complète tient en 30 min par semaine.

🎯 Objectifs

• Publier une mise à jour en staged rollout (et savoir l’arrêter).
• Lire les Android vitals et connaître les seuils qui pénalisent.
• Gérer les avis : réponse, signalement, et la boucle produit.
• Poser la routine hebdomadaire du dev solo publié.

Les mises à jour publiques : le circuit complet

L’arbre du ch. 12.6 gagne une branche « review » :

• Contenu (questions) : git push — rien ne change, aucun guichet.
• JS : eas update --channel production — tous les utilisateurs du Store à la prochaine ouverture, SANS review. (La discipline : rien qui contredise vos déclarations de fiche.)
• Natif : AAB → review → puis staged rollout :

Production → nouvelle release → déploiement à 10 %
   → 48 h de vitals sains ? → 50 % → 24 h ? → 100 %
   → problème ? → ARRÊTER le rollout (bouton dédié) → fix → nouvelle release

Le staged rollout est votre assurance : un crash qui a échappé aux tests ne frappe que 10 % des appareils (choisis aléatoirement), et le bouton « Interrompre » gèle l’hémorragie. Un rollout arrêté ne se reprend pas — on publie une release corrigée par-dessus. Avec l’OTA en plus : le fix JS peut même arriver AVANT que le rollout natif ne reprenne.

Android vitals — les chiffres qui vous classent

Console → Qualité → Android vitals. Google mesure sur les appareils réels (opt-in utilisateurs) et pénalise la visibilité au-delà des seuils de « mauvais comportement » :

Au-dessus : l’app recule dans la recherche et peut afficher un avertissement sur la fiche. Pour une app RN saine, ces seuils sont larges — nos assurances : les erreurs JS attrapées (Sentry, P14, complètera les vitals côté JS), le SQL hors du thread principal (expo-sqlite async — ch. 8.1), pas de gros calculs JS bloquants (ch. 6.1). L’ANR est LE truc à surveiller en RN : un thread JS gelé ne fait pas d’ANR (c’est le thread natif qui compte), mais un module natif mal utilisé, si.

Les avis — la boucle qui compte double

Chaque avis est public, votre réponse aussi — et les DEUX sont lus par les futurs installeurs :

• Répondez vite et pro aux négatifs constructifs : « Corrigé dans la 1.2 déployée aujourd’hui — merci du signalement. » Un avis 1★ avec une réponse impeccable vaut mieux qu’un 3★ silencieux (et les auteurs ré-évaluent souvent après un fix).
• Signalez les avis hors-charte (spam, insulte, mauvaise app) — Google les retire vraiment.
• Sollicitez au bon moment : l’API In-App Review (expo-store-review) affiche la demande de note native — à déclencher sur un MOMENT de satisfaction (nouveau record !), jamais au premier lancement. Quota système : quelques affichages/an/app — dépensez-les bien.

La routine du dev solo publié (30 min/semaine)

• Vitals : crash & ANR dans les seuils ? Un modèle d’appareil qui se détache ?
• Avis : répondre aux nouveaux (négatifs d’abord), signaler l’abusif.
• Statistiques : installations/désinstallations — les tendances, pas les valeurs.
• Politiques : la bannière d’alerte Console (Google change ses règles en continu — target SDK annuel obligatoire, nouvelles déclarations : les deadlines y apparaissent).
• Backlog produit : 3 lignes — ce que les avis/retours suggèrent, trié.

L’item « politiques » mérite l’insistance : chaque année, Google impose un target SDK minimum (l’API level de l’année précédente) — une app jamais rebuildée finit masquée du Store. Traduction Expo : suivre les montées de SDK Expo (~1/an suffit) n’est pas du confort, c’est de la survie réglementaire.

⚠️ Piège — La désinstallation de la version TEST fermé chez vos 12 testeurs : ils restent opt-in de la piste — pensez à les basculer (ou à ce qu’ils re-optent) vers la production, sinon ils reçoivent les releases de test À VIE. Et gardez la piste fermée active : c’est votre canal de pré-production pour les grosses mises à jour (les testeurs historiques re-servent).

💡 Pour un dev Next.js — Le régime de croisière ressemble finalement au web : monitoring (vitals ≈ votre APM), feedback (avis ≈ support), deploys (rollout ≈ canary). La différence culturelle : tout est PUBLIC (vos crashs influencent votre rank, vos réponses aux avis sont de la vitrine) et le rythme réglementaire est imposé (target SDK). Une app publiée est un engagement — c’est exactement pourquoi la voie perso (P12) reste le bon défaut pour tout ce qui n’a pas VOCATION au public.

✏️ Exercices

1. Configurez la demande de note au bon moment : In-App Review après un nouveau record, max 1 fois par mois, jamais les 3 premiers jours d’utilisation.

const REVIEW_KEY = 'lastReviewAsk'
async function maybeAskReview() {
  const first = await AsyncStorage.getItem('firstLaunchAt')   // posé au 1er lancement
  const last = await AsyncStorage.getItem(REVIEW_KEY)
  const now = Date.now()
  if (first && now - Number(first) < 3 * 86_400_000) return
  if (last && now - Number(last) < 30 * 86_400_000) return
  if (await StoreReview.hasAction()) {
    await StoreReview.requestReview()
    await AsyncStorage.setItem(REVIEW_KEY, String(now))
  }
}

2. Rédigez trois réponses d’avis types : le 1★ rageur mais fondé (« ça crash »), le 2★ demande de feature, le 1★ hors sujet (« je voulais une app de muscu »).

3. Votre rollout 10 % montre un pic de crashs sur Samsung Android 14 uniquement. Déroulez la procédure complète, outils des 13 dernières parties à l’appui.

🧠 Quiz

1. Décrivez le staged rollout et son bouton de sécurité.

2. Quels sont les deux seuils de vitals à connaître ?

3. Quand et comment demander une note ?

4. Quelle obligation annuelle impose Google aux apps publiées ?

5. Que devient la piste de test fermé après la publication ?

👉 Partie suivante : Partie 14 — Qualité — TS strict, tests unitaires et E2E, crash reporting : l’outillage qui rend tout ce qui précède DURABLE.