Utilisez cette checklist de préparation Flutter pour préparer la signature, les flavors, le rapport de plantages, les textes de permissions et les assets du store afin que votre première soumission se passe calmement et complètement.
« Prêt pour la publication » n'est pas « l'app fonctionne sur mon téléphone ». Cela signifie que vous pouvez générer un build de production, l'installer sur un appareil propre et le soumettre au store sans surprises de dernière minute.
Ce qui casse juste avant une première soumission est en général ennuyeux mais pénible : clés de signature manquantes, upload d'un build debug par erreur, plantages sans logs exploitables, invites de permission suspectes, ou assets de store qui ne correspondent pas à l'app (icônes erronées, captures d'écran anciennes, texte de confidentialité manquant).
Pour une première soumission Flutter, « prêt pour la publication » se résume à quatre résultats :
Ce guide se concentre sur l'essentiel pour une première soumission : signature, flavors, rapport de plantages, texte et timing des permissions, et assets de store. Ce n'est pas un plan QA complet, un audit de performance ou une revue légale.
Prévoyez au moins quelques sessions ciblées. Un développeur solo peut souvent cocher tout ça en 1–2 jours. En équipe, assignez des propriétaires clairs (signature/builds, rapport de plantages, fiche store et copy) pour éviter que des tâches arrivent dans la dernière heure.
La plupart des problèmes de dernière minute proviennent de décisions prises trop tard. Verrouillez quelques bases maintenant et tout le flux en aval devient plus simple.
Commencez par l'identité : le nom exact de l'app que verront les utilisateurs et les identifiants internes utilisés par les boutiques (package name sur Android, bundle identifier sur iOS). Changer ces éléments tardivement peut casser les mises à jour, les deep links et l'historique d'analytics. Décidez aussi de la manière dont vous versionnez les releases, pour que chaque build ait un numéro clair et que vous n'ayez jamais à deviner ce qui est en ligne.
Ensuite, définissez les limites de plateforme : Android, iOS, ou les deux dès le jour 1, et les versions minimales d'OS qui correspondent à vos utilisateurs. Rehausser les minima tardivement peut forcer des changements de design ou exclure des appareils que vous pensiez supporter.
Notez ces décisions dans un endroit accessible à l'équipe :
Enfin, confirmez que vos comptes store existent et que vous pouvez publier. Rien ne bloque autant un lancement que l'attente d'une approbation de compte, des formulaires fiscaux manquants, ou l'absence de permission d'upload. Si vous générez l'app avec un outil comme Koder.ai ou codez à la main, ces décisions s'appliquent de la même façon.
La signature d'application prouve qu'une mise à jour vient bien de vous. Si la signature est mal configurée, la boutique peut rejeter l'upload, ou vous pouvez vous retrouver incapable d'envoyer des mises à jour.
Sur Android, signer signifie généralement une clé d'upload stockée dans un fichier keystore (avec mots de passe). Sur iOS, ce sont des certificats et profils de provisioning liés à un compte Apple Developer. Même si vous construisez avec Koder.ai et exportez le code source, vous devez avoir la propriété claire des comptes store et des assets de signature avant la première soumission.
Choisissez un propriétaire référentiel pour chaque plateforme, idéalement un compte entreprise plutôt qu'un compte personnel. Définissez des règles d'accès pour ne pas être dépendant d'un seul laptop ou d'une seule personne.
Gardez un court document qui répond à :
Une clé Android perdue peut bloquer les mises à jour futures du même package. Faites une sauvegarde chiffrée dans un emplacement séparé et testez sa restauration. Pour iOS, perdre l'accès se transforme souvent en une douloureuse récupération de compte, donc maintenez plusieurs admins de confiance et documentez qui ils sont.
Vérifiez la signature sur une machine propre (checkout frais, runner CI nouveau, ou le laptop d'un collègue). Si cela ne marche que sur un seul ordinateur, ce n'est pas prêt.
Les flavors évitent que « ça marche sur mon téléphone » ne devienne « on a publié le serveur de test ». En clair, un flavor est un build nommé qui utilise une configuration différente sans que vous ayez à éditer des fichiers avant chaque release.
La plupart des équipes devraient commencer avec deux flavors : dev (pour les tests) et prod (ce que vous soumettez). Si votre équipe utilise « staging », gardez ce nom. Des noms confus conduisent à partager ou téléverser le mauvais build.
Verrouillez ce qui diffère entre les flavors. Les différences les plus courantes : identité de l'app (nom et bundle ID), icônes, endpoints API, feature flags, paramètres analytics/rapport de plantages, et niveau de logging.
Gardez les valeurs sensibles hors du repo quand c'est possible. Utilisez des fichiers d'environnement, des secrets CI, ou des variables injectées au moment du build pour que les clés n'atterrissent pas dans des commits.
Avant de déclarer la tâche terminée, buildz chaque flavor que vous comptez utiliser, y compris un build de release propre. Les configurations manquantes apparaîtront ici, pas le jour du lancement.
Vous pouvez livrer un build propre et manquer quand même les problèmes du monde réel : appareils rares, réseaux instables, et chemins d'exécution limites. Le rapport de plantages transforme ces surprises en liste de tâches exploitables.
Choisissez un seul outil de rapport de plantages et intégrez‑le tôt. La marque importe moins que le fait que chaque release envoie des rapports utiles.
Beaucoup de situations « impossible à reproduire » viennent de symbols manquants. Faites-en une étape de release de téléverser :
Si c'est manuel, cela sera sauté pendant une semaine chargée.
Décidez de ce dont vous avez besoin le jour 1 : version/build de l'app, modèle d'appareil, version d'OS, locale, et le dernier écran ou action. Si vous avez des comptes, ajoutez un ID utilisateur anonyme stable et un indicateur « connecté/déconnecté ». Évitez les données personnelles dans les logs.
Capturez aussi les erreurs non fatales. En Flutter, beaucoup de problèmes apparaissent comme des exceptions qui ne plantent pas l'app (erreurs de parsing, timeouts, null inattendu). Envoyez-les comme événements non fatals avec un court message et quelques champs clé/valeur.
Testez cela avant la release : faites un build de staging, déclenchez un crash forcé (dans un menu debug ou un geste secret), et confirmez que vous voyez une stack trace lisible avec la bonne version et le bon contexte.
Les permissions sont un moyen rapide de perdre la confiance au premier lancement. Avant la sortie, listez chaque permission que votre app pourrait demander, la fonctionnalité qui en a besoin, et ce que l'utilisateur y gagne en retour. Si vous ne pouvez pas l'expliquer en une courte phrase, vous ne devriez probablement pas la demander.
Gardez le texte simple et spécifique. « Nous avons besoin d'accès à vos photos » est moins clair que « Autorisez l'accès aux photos pour joindre un reçu à votre dépense ». Évitez les termes techniques comme « stockage » sauf si vous expliquez ce que cela signifie sur le moment.
Demandez seulement lorsque l'utilisateur déclenche l'action liée. Ne demandez pas l'accès aux Photos au démarrage. Demandez lorsque l'utilisateur appuie sur « Ajouter une photo », après un court écran pré‑permission qui explique pourquoi.
Quand un utilisateur répond non, l'app doit rester utilisable. Planifiez la solution de repli à l'avance : gardez la fonctionnalité visible, expliquez ce qui est bloqué, offrez une alternative quand c'est possible, et sauvegardez la progression pour qu'il ne perde pas son travail. Si l'utilisateur choisit « Ne plus demander », orientez‑le vers les Réglages sans harceler.
Double‑vérifiez les textes spécifiques aux plateformes. iOS nécessite des descriptions d'usage claires dans Info.plist. Android requiert des entrées correctes dans le manifeste, et parfois une courte explication in‑app. Un texte manquant ou vague peut causer des retards de revue ou de l'abandon par les utilisateurs.
Ceci est une vérification légère destinée à attraper les problèmes qui n'apparaissent qu'avec un vrai build de release. Gardez‑la pour quelque chose que vous pouvez lancer en moins d'une heure.
Écrivez un script simple que n'importe qui peut suivre, même sans outils développeur. La règle : testez ce que font les utilisateurs, pas ce que les développeurs peuvent inspecter.
Faites‑le au moins sur un petit téléphone et un appareil plus grand (et idéalement sur une version d'OS plus ancienne) :
Après l'exécution, force‑fermez et relancez pour confirmer que l'app démarre proprement et ne dépend pas d'un état chaud.
Si quelque chose échoue, notez l'écran exact, la dernière action, et si cela n'arrive que sur une taille d'appareil. C'est souvent suffisant pour une correction rapide.
Beaucoup de stress de lancement vient des pages store, pas du code. Considérez la fiche comme une partie du travail de release pour éviter des demandes de design de dernière minute, des réponses de confidentialité manquantes, et le chaos des captures d'écran.
Rassemblez ce dont vous aurez presque certainement besoin : icône d'app, captures d'écran, un court sous‑titre, une description longue, et les graphismes spécifiques demandés par la plateforme. La vidéo promo est optionnelle et ne vaut la peine que si vous pouvez la maintenir à jour.
Pour les captures d'écran, choisissez vos tailles d'appareil tôt et tenez‑vous y. Gardez un ordre cohérent (onboarding, écran principal, fonctionnalité clé, paramètres, mise à niveau) pour que les mises à jour ne deviennent pas une course.
Rédigez la description comme un humain : une phrase claire sur ce que fait l'app, puis quelques lignes courtes sur les bénéfices, puis une note simple sur les abonnements ou comptes si vous en avez. Ne promettez pas ce que vous ne pouvez pas tenir.
Rassemblez aussi vos réponses sur la confidentialité et l'usage des données maintenant. On vous demandera du tracking, des types de données collectées et des permissions. Si votre app demande la localisation, les contacts ou les photos, expliquez pourquoi en termes simples.
Si vous gardez les assets organisés, les mises à jour deviennent routinières. Une structure simple suffit (icône, captures par type d'appareil, textes, notes de confidentialité, et notes de version).
Une répétition consiste à parcourir le flux de soumission du store comme si vous alliez lancer, mais en vous arrêtant avant Publier. Cela transforme des suppositions en réponses réelles.
Choisissez un build que vous seriez prêt à soumettre (même si vous ne le publierez pas). Téléversez‑le, remplissez les formulaires et sauvegardez tout en brouillon. Vous voulez trouver les informations manquantes tant que vous avez le temps de corriger.
Vérifiez :
Planifiez « quoi faire si la première release est mauvaise ». Décidez comment vous ferez un rollback (conservez l'artifact signé précédent), comment vous publierez un hotfix, et quels signaux déclenchent la pause d'un déploiement (pics de plantage, échecs de connexion).
Décidez aussi comment vous collecterez les premiers retours pendant les 48 premières heures. Un canal de petit groupe, une boîte de support que vous surveillez vraiment, et une option in‑app « Envoyer un retour » peuvent attraper des problèmes évidents avant qu'ils ne deviennent des avis 1 étoile.
La plupart des retards arrivent parce que le build que vous avez testé n'est pas celui que vous publiez. Un build debug ou profile peut paraître parfait, puis le build release échoue sur un appareil réel à cause de la minification, de valeurs de config différentes, ou de permissions runtime manquantes.
Une autre perte de temps fréquente est de mélanger settings de développement et production : publier l'URL API de staging, la mauvaise clé analytics, ou des modes de paiement de test. Traitez la production comme un environnement à part et vérifiez‑la sur l'artifact exact de release.
Ces pièges brûlent régulièrement les équipes :
Imaginez un upload un vendredi : un reviewer ouvre l'app, touche une fonctionnalité qui demande l'accès, et le texte est vague. Vous corrigez le texte, mais la clé de signature est sur le machine d'un collègue qui est hors ligne. Ce sont deux jours évitables.
Utilisez‑la la veille de la création du build store. Elle est courte par choix. Si un élément est « peut‑être », arrêtez‑vous et corrigez avant de perdre du temps sur les formulaires du store.
Si vous construisez avec une plateforme qui peut exporter le code source, comme Koder.ai (koder.ai), ajoutez une vérification : confirmez que le projet exporté produit le même build de release signé que celui que vous comptez téléverser.
Une petite équipe de trois personnes prépare sa première app Flutter pour les stores : un développeur, un designer et un PM à temps partiel. Ils traitent la première soumission comme une répétition.
Lundi, le développeur génère le build de release et réalise que la clé de signature est sur un laptop sur le point d'être réinitialisé. Ils règlent le problème ce jour‑là : déplacent la clé vers un coffre partagé avec contrôle d'accès, documentent la propriété, et confirment que la CI peut signer les builds.
Mardi, le PM lit à voix haute chaque invite de permission. Une invite ressort : le texte de permission photo disait « requis », alors que l'app n'en a besoin que pour des photos de profil optionnelles. Ils réécrivent le texte pour expliquer le bénéfice et déplacent la demande au moment où l'utilisateur appuie sur « Ajouter une photo ».
Jeudi, ils font une répétition complète de la soumission avec les captures finales, les notes de version, et le build production. Le store signale un décalage entre la description et une étiquette d'abonnement dans l'app. Parce que c'est un dry‑run, ils ajustent la formulation et re‑sauvegardent avant le jour du lancement.
Ils gardent une timeline simple pour la prochaine fois :
La première mise en ligne vous apprend à quoi ressemble réellement « prêt ». Capturez ces apprentissages pendant que c'est frais.
Assignez des propriétaires clairs. Même dans une petite équipe, « tout le monde » signifie souvent « personne », et des tâches clés glissent :
Transformez ce que vous venez de faire en checklist reproductible et en template de notes de release : commandes exécutées, approbations nécessaires, et fichiers téléversés. Ajoutez les pièges rencontrés aussi, comme quel flavor est production et quel texte de permission a posé problème en revue.
Planifiez une revue post‑release de 20 minutes dans la semaine suivante. Concentrez‑vous sur les corrections, pas sur les reproches :
Si vous construisez avec Koder.ai, Planning Mode peut vous aider à suivre les tâches de release en un seul endroit, et les snapshots peuvent vous donner un état connu‑bon avant les changements de dernière minute.
Prêt pour la publication signifie que vous pouvez produire un build de production (release) signé qui s'installe sur un appareil propre et peut être soumis sans corrections de dernière minute.
Une base pratique :
Créez un build de release, puis installez-le sur un appareil qui n'a jamais eu votre app.
Vérifiez :
Si vous n'avez testé que le debug/profile, supposez que vous n'avez pas vraiment testé ce que vous allez expédier.
Considérez les actifs de signature comme des identifiants de production :
Si la clé n'existe que sur un seul laptop, vous êtes à un incident près d'être empêché de publier des mises à jour.
Attachez la signature au compte Apple Developer avec des accès administratifs clairs.
Faites-le tôt :
Commencez avec deux flavors : dev et prod.
Différences typiques :
Le but est d'éviter d'éditer manuellement des fichiers juste avant la sortie.
Utilisez l'injection de secrets au lieu de les committer.
Bonnes pratiques :
Cela évite d'expédier des endpoints staging ou des modes de paiement de test par erreur.
Choisissez un outil de rapport de plantages et intégrez‑le tôt.
Configuration minimale :
Testez avec un crash forcé sur un build staging/release et confirmez que le rapport est exploitable.
Demandez les permissions seulement quand l'utilisateur déclenche la fonctionnalité.
Bon schéma :
Les invites vagues et les demandes dès le démarrage font souvent perdre la confiance et retardent la revue.
Faites un « smoke test » rapide de build de release, exécutable en moins d'une heure :
Notez : dernière action, écran, modèle d'appareil et si c'est reproductible.
Effectuez une soumission « dry‑run » et sauvegardez en brouillon.
Vérifiez que vous avez prêt :
Décidez aussi du plan de rollback/hotfix avant d'appuyer sur Publier.
