Checklist de préparation à la publication Flutter pour une première soumission sans accroc

Ce que « prêt pour la publication » signifie réellement

« 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 :

• Vous pouvez créer un build de production reproductible et identifier en toute confiance l'artifact que vous soumettez.
• Vos credentials de signature sont détenus, sauvegardés et pas enfermés sur l'ordinateur d'une seule personne.
• Si l'app plante en conditions réelles, vous le verrez rapidement avec suffisamment de détails pour corriger.
• Votre fiche store est complète : texte, icônes, captures d'écran et déclarations requises.

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.

Décisions préalables à verrouiller avant de builder

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 :

• Nom de l'app, package/bundle ID, et une règle simple de versionnage
• Plateformes supportées et versions minimales d'OS
• Environnements (dev, staging, production) et ce qui diffère entre eux
• Qui a l'appel final « ship » ou « hold »
• Accès comptes store : identifiants, rôles et méthodes de récupération 2FA

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.

Signature de l'app : clés, propriété et stockage sûr

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.

Décider de la propriété et des accès

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 à :

• Quels comptes détiennent les clés de signature (Google Play, Apple Developer)
• Où se trouvent le keystore et les fichiers de signature iOS (vault, stockage chiffré)
• Qui peut couper des releases et qui peut faire tourner/renouveler les credentials
• Comment récupérer l'accès (codes de récupération 2FA, rôles admin)

Sauvegardes et plan « clé perdue »

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.

Flavors de build : séparer dev et production

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.

Rapport de plantages et logs de release

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.

Faire des symboles et du mapping une étape de release

Beaucoup de situations « impossible à reproduire » viennent de symbols manquants. Faites-en une étape de release de téléverser :

• Les fichiers dSYM iOS (pour rendre les stack traces lisibles)
• Le mapping d'obfuscation Android (si vous minifiez/obfusquez)
• Le numéro de build exact et le commit git (ou tag) lié au téléversement

Si c'est manuel, cela sera sauté pendant une semaine chargée.

Logger ce qui aide à corriger

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.

Permissions : textes conviviaux et bon timing

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.

Un passage de test pratique pour la release (pas un plan de test complet)

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.

Un script rapide de QA pour la release

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) :

• Installez le build de release (pas debug) et confirmez qu'il se comporte comme une app du store (pas de bannière debug, pas de menus dev).
• Complétez l'onboarding et la connexion depuis zéro (y compris réinitialisation de mot de passe ou lien magique si vous en avez).
• Déclenchez votre flux « monétaire » le plus important (abonnement, achat in‑app, checkout ou paywall) avec des comptes de test réels.
• Vérifiez les notifications bout à bout : invite de permission, réception d'une notification, et tap pour ouvrir l'écran attendu.
• Testez hors‑ligne et sous réseau dégradé : ouvrez l'app en mode avion, puis récupérez la connexion.

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.

Assets de la fiche store : préparez‑les avant d'en avoir besoin

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).

Faites une répétition générale de la soumission pour éviter les surprises

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 :

• Le numéro de version/build correspond à ce que vous attendez, et les notes de version sont prêtes.
• Les questions de conformité sont répondues de façon cohérente (collecte de données, pubs, chiffrement, login requis, permissions sensibles).
• Pays supportés, tarifs (le cas échéant) et classification d'âge sont corrects.
• Coordonnées prêtes : email de support, emplacement du texte de politique de confidentialité, et éventuelles notes pour le reviewer.
• Les informations pour la revue sont complètes : compte démo (si nécessaire) et étapes claires pour atteindre les fonctionnalités clés.

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.

Pièges courants qui font perdre des jours juste avant le lancement

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 :

• Tester « proche de la release » au lieu de l'artifact signé exact que vous uploaderez.
• Expédier les mauvais endpoints ou feature flags parce que les configs ne sont pas clairement séparées.
• Rejets en revue à cause d'invites de permissions vagues ou manquantes.
• Rapports de plantage impossibles à exploiter parce que symbols/mapping n'ont pas été téléversés.
• Clés de signature et seul setup fonctionnel vivant sur le laptop d'une personne.

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.

Checklist rapide de préparation à la publication (imprimable)

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.

• La signature fonctionne sur une machine propre. Un checkout frais peut builder un release signé sans chercher des fichiers. Les clés/certs sont sauvegardés, l'accès est limité, et la propriété est claire.
• Tous les flavors buildent. Dev, staging (si utilisé) et production buildent sans retouches manuelles. La config production est confirmée (bundle id/applicationId, nom de l'app, icônes, endpoints API, clés analytics).
• Le rapport de plantages fonctionne sur un build release. Un crash ou événement test depuis un build release arrive avec symbols/mapping pour rendre les stack traces lisibles.
• Les permissions sont justifiées et lisibles. Chaque permission a un texte clair et humain, et l'app reste partiellement utilisable si l'utilisateur refuse. Le timing est contextuel.
• Les assets de la fiche store sont prêts. Icônes, captures, graphismes requis, descriptions courte/longue, email de support, labels de confidentialité et classification d'âge sont rédigés et revus.

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.

Exemple : semaine de première soumission sans panique

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 :

• Mon : Gel des fonctionnalités, vérification de la signature et du build production
• Mar : Relecture des permissions et du copy in‑app
• Mer : Smoke test sur appareils réels, confirmation analytics et rapport de plantages
• Jeu : Dry‑run de soumission store
• Ven : Soumettre pour revue et prévoir du tampon pour corrections

Prochaines étapes : facilitez la prochaine release

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 :

• Stockage de la signature et gestion des clés
• Vérifications finales sur appareils et appel go/no‑go
• Assets et copy de la fiche store
• Étapes de soumission et suivi du reviewer

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 :

• Qu'est‑ce qui nous a surpris pendant la soumission ou la revue ?
• Qu'est‑ce qui a pris plus de temps que prévu, et pourquoi ?
• Que pouvons‑nous préparer plus tôt la prochaine fois (assets, copy, boîte de support) ?

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.