Signature de l'app et testeurs : ce qui change

« Ça s'installe sur mon téléphone mais pas sur celui du testeur. » « La mise à jour échoue avec une erreur de signature. » Beaucoup de ces problèmes ont la même cause : une même app peut être signée avec des clés différentes selon la façon dont la build arrive sur l'appareil.

Les trois types de build

Build locale. Tu compiles et installes depuis ton ordinateur, généralement signée avec une clé de débogage ou ta propre clé. Personne d'autre ne peut la mettre à jour sans avoir la même signature.

Bundle signé avec la clé d'envoi. Tu signes ton bundle d'app avec ta clé d'envoi et tu l'envoies à Google Play. Selon l'aide de la Play Console sur Play App Signing, la clé d'envoi reste en ta possession et sert à Google pour vérifier ton identité.

Build livrée par Play. Avec Play App Signing, Google détient la clé de signature de l'app et signe avec elle les APK qu'il livre aux utilisateurs. La build qu'un testeur reçoit de Google Play est donc signée par une autre clé que le fichier que tu as envoyé. (Source : aide de la Play Console, consultée le 2026-10-23.)

Ce que cela casse, selon le symptôme

• « App non installée » ou conflit de signature lors de la mise à jour. La copie installée a été signée avec une clé, la nouvelle avec une autre. Cas typique : un testeur a installé ton APK local, puis essaie la version de test Play, ou l'inverse. Android ne met pas à jour entre des signatures différentes.
• Correction : désinstalle la copie existante et réinstalle depuis une seule source. Dis aux testeurs quelle source utiliser, et préviens-les que les données de l'app sont perdues à la désinstallation.
• Un fournisseur de connexion ou une API refuse l'app. Les services qui vérifient l'empreinte du certificat de signature peuvent ne connaître que la clé locale ou la clé d'envoi. Les builds livrées par Play portent le certificat de la clé de signature Play : enregistre aussi celui-là. Consulte la documentation actuelle de chaque fournisseur pour savoir où trouver et enregistrer les empreintes.
• Comportement différent entre ta build de débogage et celle du testeur. Les builds de débogage diffèrent souvent des builds de publication par plus que la clé, comme la réduction de code et les journaux. Teste la build de publication que Play livre.
• Inquiétude sur une clé perdue. Selon la même page d'aide, si tu perds ta clé d'envoi ou soupçonnes qu'elle a été compromise, tu n'es pas bloqué : tu en crées une nouvelle et demandes une réinitialisation dans la Play Console. Garde quand même ta clé d'envoi en lieu sûr.

Une règle pratique pour les builds de test

1. Choisis un seul mode de distribution par groupe de testeurs : soit la piste de test Play, soit l'APK direct, pas les deux.
2. Avant une série de tests, demande aux testeurs de retirer les anciennes copies installées autrement.
3. Vérifie l'empreinte attendue par tes services et compare-la avec la build que les testeurs reçoivent réellement.
4. Teste au moins une fois la build livrée par Play avant la publication, pas seulement ta build locale.

Ce qu'il faut dire aux testeurs

Une note courte suffit : « Installe uniquement depuis le lien d'invitation. Si tu as installé une version antérieure ailleurs, désinstalle-la d'abord. »

Retour au hub de test des apps Android. Voir aussi : test de la langue et de la région et test de la caméra et des médias.

AppReviewX propose un retour privé et structuré ainsi que des groupes de test pour Google Play (12 testeurs, 14 jours d'affilée, pour les apps Android). 1 retour = 1 crédit. Commence gratuitement.

Vérifie la page Google citée avant de t'appuyer sur les détails ; la gestion des clés peut changer.