Réponse directe
Une application est prête lorsque les parcours critiques convenus fonctionnent dans un environnement proche de la production, que les échecs importants sont maîtrisés, que les contenus de diffusion et exigences externes sont à jour, que supervision et support ont des responsables et que la récupération a été répétée. Cette préparation ne signifie ni zéro défaut ni garantie d’approbation, d’adoption ou de revenu. Classez chaque point ouvert par impact et réversibilité, attachez une preuve à chaque jalon et laissez le décideur nommé publier, limiter ou arrêter. Revérifiez les règles de plateforme juste avant la soumission.
Fixer la frontière de lancement et les règles d’arrêt
Écrivez audience, environnements, appareils et navigateurs supportés, classe de données, canal de diffusion et plus petit résultat utilisateur complet. Marquez les exclusions. Définissez les motifs d’arrêt: perte de données, autorisation incorrecte, action dangereuse, récupération indisponible, validation juridique ou politique manquante et tout autre risque inacceptable propre au produit.
Séparez préparation contrôlée par l’entreprise et approbation externe. L’équipe prouve un build signé, un déploiement testé, des métadonnées complètes ou un compte de revue fonctionnel. Apple, Google ou un autre fournisseur décide de sa validation. Rendez cette dépendance visible et prévoyez un repli pertinent: annonce retardée, accès progressif ou onboarding web.
Inventorier parcours, dépendances et responsables
Listez inscription, connexion, tâche principale, paiement éventuel, récupération de compte, export ou suppression, support et administration. Pour chaque parcours, consignez données, services, permissions, échecs et responsable. Ajoutez domaines, certificats, email, mesure, notifications, identités de store, signature, SDK tiers et secrets sans copier les valeurs secrètes dans la checklist.
Capturez exigences de versions et règles fournisseurs depuis les sources officielles au moment de publier. Conservez liens et dates de revue car API cibles, règles de store et obligations SDK changent. Nommez qui renouvelle les accès, répond aux questions de revue et coupe une intégration nuisible. Un calendrier sans responsables n’est pas une préparation opérationnelle.
Répéter publication, observation et récupération
Déployez le candidat exact par la chaîne prévue avec revue et contrôles reproductibles. Testez parcours critiques dans des environnements représentatifs, avec saisies invalides, permissions refusées, dépendances dégradées, mises à jour et accessibilité. Vérifiez que logs et alertes montrent des pannes actionnables sans exposer de données, et qu’une personne les reçoit.
Exercez le rollback, la désactivation ou le correctif avant lancement. Vérifiez sauvegarde et restauration si nécessaires. Préparez canal d’incident, sévérités, décideur et communication utilisateur. Un document affirmant qu’un rollback existe est moins probant qu’une répétition contrôlée montrant qui agit et quel état de données en résulte.
Tenir une revue go, go limité ou no-go
Réunissez rapports de test, défauts ouverts, constats sécurité et accessibilité, contenus de store, supervision, récupération et confirmations des responsables dans un dossier de release. Décidez selon les règles écrites. Un lancement limité réduit audience ou capacité si le risque restant est compris, observable et réversible. Ne renommez pas une panne critique inconnue pour protéger une date.
Définissez la recette par des preuves observables, par exemple un parcours testé, un build approuvé, des contrôles reproductibles, un runbook d’incident et une transmission vérifiée. Rien de cela ne prouve rétention, revenu ou adéquation marché. Séparez preuve de livraison, approbation d’un fournisseur externe et résultat business.
Relier la release à la maintenance et à l’apprentissage
Consignez version déployée, configuration, limites connues, rotation support, première fenêtre d’observation et prochaine revue. Confirmez qui prend les défauts, mises à jour, retours fournisseur et communication. Conservez les preuves avec le dépôt et la transmission pour qu’un autre opérateur comprenne ce qui a été approuvé et pourquoi.
Gardez dépôts, domaines, stores, analytics, organisations cloud et identifiants de production sous une propriété explicite de l’entreprise. Accordez des accès limités et révocables, puis répétez la transmission avant la dernière facture. L’étiquette du prestataire compte moins que la capacité d’une autre personne autorisée à inspecter, déployer, reprendre et poursuivre le produit.
Critères de décision
Posez les mêmes questions à chaque option avant de choisir.
| Option | Utile lorsque | À vérifier avant de choisir |
|---|---|---|
| Publier auprès de l’audience prévue | Toutes les règles d’arrêt sont closes et les preuves de release, supervision, support et récupération sont à jour. | Consigner candidat exact et décideur, puis observer les signaux sans prétendre à un résultat business. |
| Faire un lancement limité | Le risque restant est borné, observable et réversible avec une audience ou des capacités réduites. | Écrire limitation, responsable, seuil d’escalade et condition d’élargissement avant ouverture. |
| Reporter et fermer un écart critique | Une règle d’arrêt portant sur données, autorité, sûreté, récupération ou conformité externe reste ouverte. | Assigner la preuve manquante et la prochaine revue au lieu de publier dans l’inconnu. |
| Revenir au cadrage ou réduire | La release ne peut répondre à une question utile ou dépend d’une hypothèse non maîtrisée. | Réduire ou redessiner pour obtenir une preuve interprétable dans une frontière exploitable. |
Questions fréquentes
Quand commencer la préparation au lancement ?
Dès la définition de la release. Diffusion, comptes, données, sécurité, accessibilité, support et récupération peuvent modifier architecture et périmètre.
La checklist garantit-elle une application sans bug ?
Non. Elle indique que les critères et risques nommés ont des preuves actuelles. Consignez les limites et décidez si leur impact est acceptable et réversible.
Qui décide le go ou no-go ?
Nommez un responsable produit ou release, éclairé par ingénierie, sécurité, exploitation, support et spécialistes nécessaires. Évitez le consensus sans propriétaire.
La préparation garantit-elle validation ou adoption ?
Non. Les stores contrôlent leur revue et les utilisateurs leur adoption. Approbation, disponibilité, usage et résultats commerciaux sont des preuves ultérieures distinctes.
Sources primaires et preuves
- À propos d’IVRYN 2026-08-15
- Travaux et preuves IVRYN 2026-08-15
- Méthodologie produit IVRYN 2026-08-15
- Guide GOV.UK de la phase de découverte 2026-08-15
- Guide GOV.UK de la phase alpha 2026-08-15
- Cadre NIST de développement logiciel sécurisé 2026-08-15
- Règles de validation de l’App Store 2026-08-15
- Exigences Google Play pour l’API cible 2026-08-15
- Ingénierie de mise en production Google SRE 2026-08-15