Corriger l’erreur 10 de Google Sign-In en test fermé

Cet article traite d’une seule panne: la connexion Google native qui ne fonctionne plus dans la copie livrée par Google Play. Il la distingue d’autres erreurs qui lui ressemblent, puis aborde les frameworks, les autres fournisseurs de connexion et ce que les testeurs doivent signaler. Chaque page Google citée ici a été vérifiée le 16 octobre 2026, et les témoignages de la communauté sont signalés comme tels. Les sources sont listées à la fin.

Réparer Google Sign-In dans la version Play

Faites correspondre l’application installée par vos testeurs avec le nom de package et le SHA-1 de signature enregistrés pour elle. Suivez ces étapes dans l’ordre; les procédures Firebase et Google Cloud viennent ensuite.

Ajoutez le certificat Play dans Firebase

Sélectionnez l’application Android correspondante avant d’ajouter son empreinte de signature Play. Les étapes suivent l’aide de Firebase sur les empreintes et son guide de connexion avec Google.

1. Dans la console Firebase, ouvrez le projet utilisé par votre application, puis Project settings > General.
2. Sous Your apps, sélectionnez l’application Android dont le nom de package correspond à la version qui échoue.
3. Cliquez sur Add fingerprint, collez le SHA-1 de la signature d’application Play et enregistrez. Ajoutez-le à côté des empreintes existantes au lieu de les remplacer.
4. Sous Authentication > Sign-in method, vérifiez que Google est activé.
5. Si Firebase vous invite à télécharger un google-services.json mis à jour, remplacez le fichier dans votre projet. Selon Firebase, ce fichier “contient les informations du client OAuth nécessaires à la connexion avec Google”, donc un fichier modifié implique une nouvelle version. Vérifiez que son projet et son package correspondent à l’application qui échoue.

N’ajoutez un SHA-256 que lorsqu’un service Firebase précis le demande. L’authentification par téléphone, par exemple, utilise le SHA-256 pour son parcours Play Integrity; Google Sign-In lui-même s’appuie sur le SHA-1.

Configurer Google Cloud sans Firebase

Deux clients OAuth remplissent deux rôles différents. Le client Android enregistre votre application; l’ID client Web est celui qu’utilise votre demande de jeton.

1. Sélectionnez le projet qui a émis vos ID client, puis ouvrez Google Auth platform > Clients (aide Google Cloud).
2. Cherchez un client Android existant avec ce nom de package et ce SHA-1 avant d’en créer un autre.
3. S’il n’existe pas, choisissez Create Client, réglez Application type sur Android, saisissez un nom, le nom de package et le SHA-1 de la signature d’application Play, puis cliquez sur Create. Le formulaire Android comporte un champ SHA-1; un SHA-256 n’a rien à y faire.
4. Enregistrez chaque paire package et certificat dont vous avez besoin, par exemple debug, release locale et Play.
5. Laissez le client Web en place pour la demande de jeton, et ne mettez jamais de code secret du client dans l’application.

Prouvez la réparation

Une seule connexion réussie ne prouve pas que la version est réparée. Cette liste de contrôle est notre test d’acceptation recommandé, pas une règle de Google; la dernière ligne compte, car chez un développeur la connexion a réussi une fois puis a de nouveau échoué à la connexion suivante, un problème de session qu’une vérification unique n’aurait pas détecté.

Pourquoi la connexion fonctionne-t-elle en debug mais échoue-t-elle en test fermé?

L’application installée via Google Play peut avoir un signataire différent de l’APK que vous installez en local. Le guide d’authentification du client de Google rappelle que “Android Studio signe automatiquement votre application avec un certificat de debug.” Une version release que vous compilez vous-même utilise la clé configurée pour cette variante. Avec Play App Signing, votre clé d’importation signe le bundle que vous importez, et Google signe les APK que reçoivent vos testeurs avec la clé de signature d’application.

Ces clés ont des rôles différents, mais leurs valeurs ne sont pas toujours différentes: vous pouvez fournir votre propre clé de signature, et certaines configurations utilisent une même clé pour deux rôles. Comparez les empreintes réelles plutôt que les noms des clés.

Lisez les empreintes vous-même

Pour les versions compilées sur votre machine, le rapport de signature Gradle affiche le SHA-1 et le SHA-256 de chaque variante, et keytool lit directement le keystore de debug (saisissez le mot de passe du keystore quand il est demandé):

./gradlew signingReport

keytool -list -v -alias androiddebugkey -keystore ~/.android/debug.keystore

Un rapport de signature local ne vous dit pas ce qui a signé la copie Play. Pour vérifier la version qui échoue elle-même, installez-la depuis le test fermé sur un appareil, récupérez-la avec adb et affichez ses certificats avec apksigner, dont Google indique qu’il affiche “des informations sur les certificats de signature de l’APK.” Remplacez le nom de package et utilisez le chemin affiché par la première commande:

adb shell pm path com.example.app
adb pull /data/app/.../base.apk failing-play.apk
apksigner verify --print-certs failing-play.apk

J’ai ajouté le SHA-1 et la connexion échoue toujours

Comparez le certificat de l’APK qui échoue, son ID d’application final et les ID client avant de modifier d’autres paramètres. Descendez cette échelle; chaque ligne écarte une couche.

La ligne 4 n’a rien de théorique. Dans un cas Expo signalé en septembre 2026, l’ajout d’empreintes n’a rien changé; le correctif était une faute de frappe dans l’ID client accepté par le backend.

Plusieurs certificats de signature ou clés mises à niveau

Une même application peut nécessiter l’enregistrement de plusieurs identités de signature. L’aide actuelle de Google sur Play App Signing décrit une signature hybride avec trois clés de signature d’application et demande d’enregistrer les empreintes de chacune, et une application dont la clé de signature a été mise à niveau peut encore avoir des installations signées par une ancienne clé. Enregistrez les identités que portent réellement vos installations et ne supprimez pas les anciennes entrées qui fonctionnent encore. La rotation des clés dépasse le cadre de cet article, et ce n’est pas un correctif de connexion.

Un autre projet possède déjà ce package et ce SHA-1

L’aide de Firebase sur les conflits indique qu’une paire nom de package et SHA-1 “doit être unique dans l’ensemble des projets Firebase et Google Cloud.” Si la console refuse votre empreinte parce qu’un autre projet la détient, trouvez quel projet possède ce client OAuth avant de supprimer quoi que ce soit. L’assistance Google peut vous aider à localiser le conflit; ne supprimez pas de clients ou de projets actifs pour avancer à l’aveugle.

L’erreur 10 est-elle la même que 12500, 12501 ou canceled?

Non. Lisez l’erreur exacte et la bibliothèque qui l’a produite avant de traiter chaque échec de connexion comme un seul et même problème. La référence des codes d’état courants de Google définit DEVELOPER_ERROR = 10 comme “L’application est mal configurée.” Les autres codes ci-dessous proviennent de l’ancien SDK play-services-auth 21.6.0 de Google.

L’ancien Google Sign-In et Credential Manager

Les notes de version des services Play de Google mentionnent l’abandon des API Google Sign-In dans play-services-base le 16 avril 2024, et Google a annoncé le passage à Credential Manager le 11 septembre 2024. Les API ont ensuite été retirées de play-services-auth 22.0.0 le 26 août 2026 et de play-services-base 18.11.0 le 17 septembre 2026, avec la mention “Retrait des API liées à Google Sign-in.” Il s’agit d’un changement de SDK; cela ne fixe aucune date d’arrêt pour les applications déjà installées. Le nouveau code et les mises à niveau doivent suivre le guide de migration de Google.

Les deux API échouent différemment. Credential Manager n’a pas d’erreur 10; son guide de dépannage avertit qu’“un volume élevé d’"annulations" peut en réalité indiquer une mauvaise configuration.” Une annulation peut donc être une erreur de configuration ou une véritable annulation, et NoCredentialException est encore un autre signal.

Vérifications pour Flutter, React Native, Expo et Unity

Les vérifications d’identité native ci-dessus s’appliquent à tous les frameworks, mais la configuration, l’initialisation et la configuration de compilation diffèrent. Suivez la procédure de votre framework et la version de bibliothèque que votre application résout réellement.

Pour React Native, les mainteneurs de la bibliothèque fournissent une vérification de configuration que vous pouvez lancer depuis la racine du projet:

npx @react-native-google-signin/config-doctor

Qu’est-ce qui change pour Supabase, Facebook, Apple ou Auth0?

Le fournisseur et le parcours de connexion déterminent quel certificat, quel ID client ou quel callback doit correspondre. Un SHA-1 Google est la réponse pour la connexion Google native; pour d’autres fournisseurs, il peut s’agir du mauvais hash, du mauvais format, ou d’un élément sans rapport.

Que doivent envoyer les testeurs au développeur?

Un rapport utile identifie la version Play qui échoue et le moment exact où la connexion s’arrête. Un testeur ne peut pas réparer un enregistrement OAuth en réessayant: son rôle est d’apporter des preuves, pas d’insister. Copiez ce modèle et envoyez-le à vos testeurs:

Application et lien de test Play:
Version ou build de l’application installée:
Installée depuis: test fermé Play / autre moyen
Appareil et version d’Android:
Date, heure et fuseau horaire:
Texte exact de l’erreur ou capture d’écran masquée:
Où cela s’est arrêté: avant le sélecteur de compte / après le choix d’un compte / après le retour dans l’application
Une autre méthode de connexion a-t-elle permis d’ouvrir l’application?
Résultat et version du nouveau test:

Demandez aux testeurs de rester inscrits au test pendant que vous corrigez le problème. Ne demandez jamais de mots de passe, de jetons OAuth, de clés privées ni d’accès à la Play Console. Après votre modification, demandez au même testeur d’ouvrir une fonctionnalité qui exige une connexion, puis de se déconnecter et de se reconnecter, et de noter la version et le résultat.

L’erreur 10 affecte-t-elle mon test fermé ou l’accès en production?

Une erreur de configuration de la connexion est distincte de l’inscription. L’erreur 10 n’est pas un code de refus lié aux règles Play, et aucune règle Google que nous avons trouvée n’indique qu’elle remet à zéro la période d’inscription de vos testeurs. La page sur les exigences de test de Google vous encourage à améliorer l’application pendant le test fermé: gardez donc vos testeurs inscrits et déployez le correctif dans le même canal fermé. C’est une lecture des règles publiées, pas une promesse valable dans tous les cas.

Une connexion cassée reste un problème. Le règlement sur les fonctionnalités de Google Play indique: “Nous n’autorisons pas les applications qui plantent, forcent la fermeture, se figent ou présentent tout autre dysfonctionnement”, et un mur de connexion empêche les testeurs d’accéder aux fonctionnalités qu’ils sont censés tester. Corrigez-le avant de demander un accès en production, et fournissez aux examinateurs des identifiants de connexion qui fonctionnent. Si un examen a déjà rendu sa réponse, consultez le refus pour Broken Functionality.

Pour rappel: les comptes de développeur personnels créés après le 13 novembre 2023 doivent avoir au moins 12 testeurs inscrits sans interruption pendant 14 jours avant de demander un accès en production pour l’application concernée. Une fois la demande envoyée, Google indique que “l’examen prend généralement sept jours ou moins, mais peut parfois prendre plus de temps.” S’il manque des testeurs dans le décompte, vérifiez comment ils ont été invités avant de toucher à la connexion.

Questions fréquentes

L’essentiel

Les libellés des menus de la Play Console et de Firebase sont les informations de cette page qui changent le plus vite. Si un chemin indiqué plus haut ne correspond plus à votre console, cherchez la signature d’application Play sous Protected with Play, et les empreintes sous votre application Android dans les Project settings de Firebase.