Une checklist go / no-go transforme « ça a l'air prêt » en une décision que tu peux expliquer. Chaque critère a un responsable, un seuil et une preuve. Si tu es développeur solo, tu es tous les responsables, et l'écrire t'empêche quand même de sauter les points gênants.
Modèle à copier-coller
DÉCISION DE MISE EN PRODUCTION : [App], version [x.y.z] (build [n]), date [date]
Décideur : [nom]
| # | Critère | Responsable | Preuve (lien / note) | Go ? |
|---|------------------------------------------------------|-------------|--------------------------|------|
| 1 | Aucun plantage ni perte de données ouvert sur le build | [nom] | [liste des bugs, log de crash] | O/N |
| 2 | Les parcours principaux passent sur le build de production | [nom] | [notes de test, date] | O/N |
| 3 | Installation et mise à jour depuis la version précédente | [nom] | [appareil, versions] | O/N |
| 4 | Bugs connus documentés et acceptés | [nom] | [liste des bugs connus] | O/N |
| 5 | Connexion, paiements et autorisations fonctionnent | [nom] | [notes de test] | O/N |
| 6 | La fiche store, les notes et les captures correspondent | [nom] | [lien du brouillon] | O/N |
| 7 | Un plan de retour arrière ou d'arrêt existe | [nom] | [lien du plan] | O/N |
| 8 | Quelqu'un surveille les plantages après la sortie | [nom] | [qui, jusqu'à quand] | O/N |
Un « N » sur les points 1 à 3 ou 5 = NO-GO, sauf si le décideur écrit pourquoi.
Décision : GO / NO-GO / GO avec conditions : [conditions]
Exemple (fictif)
DÉCISION DE MISE EN PRODUCTION : Pocket Budget, 1.2.0 (build 57), 2026-10-17
Décideur : Sam
1 Plantage/perte de données : aucun ouvert - liste des bugs vérifiée à 10 h 15 - O
2 Parcours principaux : ajout, modification, suppression passent sur le build de production - O
3 Mise à jour depuis 1.1.4 : testée sur deux appareils - O
4 Bugs connus : export CSV lent, accepté - O
5 Connexion/autorisations : le chemin de refus de la notification n'a pas été testé - N
...
Décision : GO avec conditions : teste le chemin de refus d'autorisation avant l'envoi.
Comment l'adapter
- Adapte les critères à ton app. Une app hors ligne d'abord a besoin d'une ligne « hors ligne » ; une app avec achats in-app a besoin d'une ligne achats.
- Écris les seuils en oui/non. « Ça a l'air stable » n'est pas un critère. « Aucun bug de plantage ouvert sur le build de production » en est un.
- Teste le build de production, pas le build de debug. Le comportement peut différer ; une preuve issue du mauvais artefact ne compte pas.
- Nomme le décideur une seule fois. Les groupes qui votent dérivent. Une seule personne décide après avoir entendu les responsables.
- Garde la version remplie. À la prochaine version, tu vois ce que tu as accepté la fois précédente.
Liens associés : checklist de hotfix, plan de retour arrière et d'arrêt, et le hub checklists de test d'apps mobiles.
Besoin de testeurs sur le build de production avant de décider ? Commencer gratuitement.