Comment créer un keystore Android (guide étape par étape)

Un keystore est un fichier chiffré qui contient la paire de clés privée/publique utilisée pour signer une application. Google Play exige que chaque AAB que vous téléversez porte une signature valide ; un paquet non signé ou mal signé est rejeté par Play Console dès le téléversement.

Flutter et Android Studio génèrent automatiquement un « debug keystore » pour le développement local ; il est livré avec un mot de passe fixe, n'est destiné qu'aux tests sur votre propre appareil, et aucune boutique ne l'accepte. Le paquet que vous téléversez sur une boutique doit être signé avec un keystore « release » ou « upload » que vous générez vous-même.

Chaque mise à jour ultérieure de la même application doit être signée avec la même clé (ou une chaîne de signature reconnue par Google) ; sinon, Play Console rejette la mise à jour au motif « signée avec un certificat différent », obligeant les utilisateurs à désinstaller puis réinstaller. Votre fichier keystore fait donc partie intégrante et permanente de l'identité de votre application.

keytool est un outil en ligne de commande fourni avec le Java Development Kit (JDK) ; comme votre installation Flutter ou Android Studio inclut déjà un JDK, vous n'avez généralement pas besoin d'une installation séparée. La commande standard recommandée dans la documentation officielle de Flutter est : keytool -genkey -v -keystore upload-keystore.jks -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias upload. L'option -storetype JKS compte ici : depuis Java 9, le type de dépôt par défaut de keytool est PKCS12, donc sans cette option, le fichier obtenu porterait l'extension .jks mais contiendrait en réalité des données PKCS12.

-keyalg RSA -keysize 2048 définit l'algorithme et la longueur de la clé, -validity 10000 la rend valide pendant environ 27 ans, et -alias upload est le nom court que vous donnez à la clé, que vous réutiliserez dans key.properties. Lors de l'exécution de la commande, elle demande dans l'ordre un mot de passe de dépôt (store password), un mot de passe de clé (key password), puis vos informations de nom/organisation.

Sur macOS et Linux, keytool s'exécute directement depuis le terminal si le JDK est dans votre PATH. Sous Windows, exécutez d'abord flutter doctor -v pour voir exactement quel JDK est utilisé, puis repérez la ligne « Java binary at: » dans sa sortie ; keytool se trouve dans le dossier bin de ce répertoire (supposer « %JAVA_HOME%\bin\keytool » peut pointer vers le mauvais JDK si la variable n'est pas définie ou si plusieurs JDK sont installés). Ajustez le chemin de fichier du paramètre -keystore à votre propre répertoire utilisateur, et notez le répertoire depuis lequel vous avez lancé la commande — vous en aurez de nouveau besoin à l'étape suivante.

Créez un fichier nommé key.properties dans android/ et ajoutez les lignes storePassword, keyPassword, keyAlias et storeFile (le chemin complet vers votre fichier keystore). Ce fichier est en texte brut et contient vos mots de passe en clair ; il ne doit donc jamais être versionné — ajoutez une ligne key.properties à votre .gitignore dès la première étape.

Dans android/app/build.gradle.kts (le DSL Kotlin actuel), vous lisez ce fichier et définissez un bloc signingConfigs.release, avec keyAlias, keyPassword, storeFile et storePassword récupérés depuis key.properties. Vous assignez ensuite signingConfig = signingConfigs.getByName("release") au build type release afin que chaque paquet release produit soit signé avec cette clé.

Si la réduction R8/ProGuard (isMinifyEnabled=true) est activée, testez le paquet release signé sur un appareil réel avant de le téléverser sur la boutique ; certains paquets s'appuyant sur la réflexion sont affectés par la réduction et ne plantent que dans le build release. Cela n'a rien à voir avec la signature elle-même, mais c'est un oubli fréquent à cette même étape.

Depuis 2021, Google impose Play App Signing pour les nouvelles applications, et l'option de désactivation n'existe plus. Ce modèle comporte deux clés distinctes : l'« upload key » que vous générez avec keytool et utilisez pour signer chaque AAB, et l'« app signing key » que Google conserve dans sa propre infrastructure sécurisée et utilise pour apposer la signature finale sur le paquet distribué aux utilisateurs. Vous ne voyez ni ne détenez jamais l'app signing key vous-même.

Si vous perdez votre upload key (le fichier ou ses mots de passe) mais que vous êtes inscrit à Play App Signing, il existe une solution : dans Play Console, accédez à Protected with Play > Play Store protection > Manage Play app signing, puis ouvrez une demande « Request upload key reset » depuis la section « Upload Key Certificate ». Le processus se déroule ainsi : générez un nouveau keystore upload avec keytool, exportez son certificat au format PEM avec keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem, puis téléversez ce fichier PEM dans Play Console accompagné d'une note expliquant le motif de la réinitialisation. Une fois que Google a examiné et approuvé la demande, la nouvelle upload key devient active ; comme la véritable clé de signature n'a jamais quitté les mains de Google, l'identité de votre application sur la boutique, ses avis et son nombre d'installations restent intacts.

Si vous n'avez jamais adhéré à Play App Signing — typiquement le cas d'anciennes applications publiées avant qu'il ne devienne obligatoire — et que vous perdez votre unique clé de signature, il n'y a pas de retour en arrière : vous ne pourrez plus jamais téléverser de mise à jour pour cette application. La seule option est d'ouvrir une toute nouvelle fiche sous un nouvel applicationId, ce qui signifie perdre les avis existants, le nombre d'installations et le classement dans les recherches.

Conserver le fichier keystore sur un seul disque local est risqué : une panne de disque, un formatage ou un changement d'ordinateur peuvent le faire perdre définitivement. Gardez au moins une sauvegarde chiffrée (disque externe, stockage cloud chiffré) et n'ajoutez jamais ce fichier au dépôt de votre projet — comme key.properties, le fichier keystore doit lui aussi figurer dans .gitignore.

Stockez le store password et le key password dans un gestionnaire de mots de passe, et notez aussi le nom de l'alias ; sans ces trois éléments, le fichier lui-même est inutilisable. Ne partagez jamais les mots de passe en clair par e-mail ou messagerie ; si vous travaillez en équipe, limitez l'accès aux seules personnes qui en ont besoin.

Le Coffre Keystore Vibeloy stocke votre fichier keystore et vos mots de passe avec un chiffrement de bout en bout ; au lieu de garder le fichier comme copie locale unique, vous pouvez le conserver en sécurité dans un coffre lié à votre compte, accessible depuis n'importe quel appareil. Il s'agit d'une fonctionnalité premium de Vibeloy.