Ce que contient le modèle
Publier une application mobile n’est pas déployer un logiciel sur un serveur : quelqu’un d’autre décide quand votre build sera en ligne, et le plan doit le montrer. Le modèle sépare le travail que vous maîtrisez de l’attente que vous ne maîtrisez pas :
- Stabilisation du build — Gel des fonctionnalités, traitement des plantages et des blocages, travail sur les performances et la mémoire, accessibilité et tests sur le parc d’appareils, puis la version candidate. Jalon : version candidate prête.
- Tests bêta — Envois sur TestFlight et sur la piste interne Google Play, bêta interne, recrutement des testeurs externes, tour externe et traitement des retours. Jalon : critères de sortie de bêta atteints.
- Fiche du store et visuels — Recherche de mots-clés et de catégorie, nom et description, captures d’écran et vidéo de présentation, icône et visuels, déclaration de confidentialité des données et questionnaire de classification par âge.
- Dépôt et validation — Vérification de conformité avant dépôt, dépôt sur les deux stores, l’attente de validation, et une vraie marge pour un refus et un nouveau dépôt. Jalon : application approuvée.
- Déploiement progressif — Diffusion par paliers à 1 %, 10 % et 50 %, avec vérification du taux de sessions sans plantage à chaque palier avant d’élargir à l’ensemble des utilisateurs. Jalon : disponibilité générale.
- Correctif du jour un et suivi — Surveillance des plantages et des blocages, la fenêtre de correctif réservée, réponses aux avis sur les stores et lecture de la rétention à une semaine.
Comment l’adapter
- Fixer la date de dépôt et avancer depuis là plutôt que de remonter à rebours : la durée de validation ne vous appartient pas.
- Dédoubler les lignes de dépôt et de validation par store si vos versions iOS et Android n’ont pas le même rythme : les délais de validation diffèrent.
- Allonger la marge de refus s’il s’agit d’un premier dépôt, d’une application par abonnement, ou de tout ce qui touche à la suppression de compte, aux données de santé ou aux contenus publiés par les utilisateurs.
- Ajuster les paliers de déploiement à votre plateforme : le déploiement par étapes de Google Play et la diffusion échelonnée de l’App Store ne progressent pas de la même façon.
- Garder la fenêtre de correctif sur le planning avec des personnes nommées : une fenêtre sans équipe affectée n’est qu’une semaine vide.
- Marquer la version candidate, la sortie de bêta, l’approbation et la disponibilité générale en jalons : ce sont les quatre dates que l’on vous demandera.
Conseils de planification
- Préparez la fiche du store avant que le binaire soit figé. Captures d’écran, descriptions et déclaration de confidentialité s’élaborent et se relisent indépendamment : elles ne devraient jamais bloquer le jour du dépôt.
- N’annoncez pas une date de lancement adossée à une approbation que vous n’avez pas. Faites dépendre le marketing du jalon d’approbation, pour qu’un refus décale la campagne automatiquement.
- Surveillez le taux de sessions sans plantage à chaque palier. L’intérêt d’un déploiement progressif est de pouvoir s’arrêter entre deux paliers ; si personne n’est chargé de regarder les chiffres, le phasage ne sert à rien.
- Réservez la fenêtre de correctif avant le lancement, pas après. Les personnes qui écriraient un correctif du jour un sont celles que vous affecterez sinon au sprint suivant, le jour même du lancement.
- Recrutez les testeurs externes des semaines à l’avance. Réunir un nombre utile de testeurs sur appareils réels prend plus de temps que prévu, et une bêta trop mince ne trouve rien.
- Posez la référence à la version candidate. Tout ce qui précède relève de l’estimation ; après, le planning dépend surtout des files d’attente d’autres acteurs et se suit comme un écart.
Modèles associés
- Modèle de diagramme de Gantt pour un lancement produit
- Modèle de diagramme de Gantt pour un projet logiciel
- Plan de développement d’un nouveau produit
- Voir tous les modèles de diagramme de Gantt
Ce modèle est en français. Les pages associées non encore traduites s’ouvrent en anglais.
Questions fréquentes
Combien de temps prend la validation par les stores ?
La plupart des validations App Store aboutissent en un à deux jours et Google Play est souvent plus rapide, mais les deux peuvent être bien plus longues pour un premier dépôt ou une catégorie sensible. Le modèle prévoit dix jours plus une marge de refus.
Que doit contenir un plan de lancement d’application mobile ?
Stabilisation du build, tests bêta, fiche du store et visuels, dépôt et validation, déploiement progressif et une fenêtre de correctif du jour un. Les six sont préchargés, l’attente de validation étant modélisée comme une antériorité et non comme une hypothèse.
En quoi diffère-t-il d’un plan de lancement produit ?
Celui-ci est calé sur les stores : dépôt, validation et déploiement progressif. Pour le travail commercial plus large — prix, positionnement, campagnes — utilisez le modèle de lancement de produit en parallèle.
Faut-il un déploiement progressif ou une diffusion à tous ?
Progressif, sauf raison contraire. Une diffusion par paliers permet de s’arrêter à 1 % quand le taux de sessions sans plantage chute, ce qui coûte bien moins cher qu’un retour arrière en urgence sur l’ensemble des utilisateurs.
Le modèle de lancement d’application est-il gratuit ?
Oui. Téléchargements Excel, PowerPoint et CSV gratuits, et édition en ligne gratuite, sans compte ni filigrane.