Connecter vos comptes Apple et Google

Il y a quatre identifiants, et ils se ressemblent deux à deux

Deux pièges en découlent. Le compte de service de la Play Console n’est pas celui de Firebase : l’un publie l’app, l’autre envoie les notifications, et les deux sont des fichiers .json qui se ressemblent. Et la clé In-App Purchase n’est pas la clé App Store Connect : Apple les émet séparément, les deux sont des fichiers .p8 avec un bloc BEGIN PRIVATE KEY, et de l’extérieur elles sont indiscernables. C’est pourquoi la plateforme vérifie celle des achats auprès d’Apple au moment de l’enregistrer, au lieu de regarder sa forme.

Google Play

1. Créer l’app dans la console, avec l’identifiant exact

Dans la Play Console, Créer une application. Le nom du package doit être exactement l’identifiant affiché par l’onglet Application (un bouton copier est à côté).

L’API de Google ne crée pas l’app. Si le package n’y est pas, l’envoi échoue avec Package not found, et le nom du package ne peut pas être renommé ensuite.

2. Créer le compte de service

Le compte de service est l’utilisateur robot qui envoie les versions. Il se crée dans Google Cloud et s’autorise dans la Play Console. Google n’exige plus de lier le projet Cloud à la Play Console pour utiliser l’API, le chemin est donc direct :

1. dans la Google Cloud Console, créez (ou choisissez) un projet ;
2. activez-y la Google Play Android Developer API ;
3. dans API et services → Identifiants → Créer des identifiants → Compte de service, créez le compte. Aucun rôle n’est nécessaire ici : la permission qui compte est celle de la Play Console, à l’étape suivante ;
4. sur le compte créé, Clés → Ajouter une clé → Créer une clé → JSON. Le fichier se télécharge aussitôt, et c’est lui que vous envoyez à la plateforme.

Gardez ce .json comme un mot de passe : qui a le fichier peut publier dans votre Play Console.

3. Donner la permission dans la Play Console

C’est l’étape la plus souvent oubliée, et le symptôme trompe : le fichier est accepté ici et l’envoi est refusé là-bas.

Dans la Play Console, Utilisateurs et autorisations → Inviter un nouvel utilisateur, utilisez l’e-mail du compte de service (du type nom@projet.iam.gserviceaccount.com), ajoutez l’app dans l’onglet des autorisations par app et cochez :

• Publier des applications sur les canaux de test ;
• Publier en production, exclure des appareils et utiliser Play App Signing, si vous publiez en production.

Invitez. Le compte de service apparaît dans la liste comme n’importe quel autre utilisateur.

4. L’empreinte SHA-256 (facultatif)

Elle sert seulement à ce que les liens de votre site ouvrent dans l’app. Elle est dans Configuration → Intégrité de l’application → Signature d’application. Prenez celle du certificat de la clé de signature de l’app, pas celle de la clé d’importation : utiliser la clé d’importation est l’erreur classique, la valeur a l’air juste et la vérification des liens ne passe jamais.

Apple

1. La clé App Store Connect

Dans App Store Connect, sous Users and Access → Integrations → App Store Connect API → Team Keys, cliquez sur Generate API Key. Nommez-la et choisissez le rôle.

Le rôle doit être Admin. App Manager ne peut pas créer le certificat de signature, et cet échec n’apparaît qu’à la fin du build, après 20 minutes de compilation, dans un message sur un certificat qui ne dit pas « mauvais rôle ».

À la génération, Apple laisse télécharger le fichier .p8 une seule fois. Perdu, il est irrécupérable : révoquez la clé et générez-en une autre. Le même écran donne les deux autres champs : le Key ID (dix caractères, sur la ligne de la clé) et l’Issuer ID (un UUID, écrit au-dessus de la liste, identique pour toutes vos clés).

Confondre Issuer ID et Key ID est l’erreur la plus fréquente, car les deux viennent du même écran.

2. Le Team ID

Sur developer.apple.com → Membership, en haut à droite, à côté du nom de l’équipe. Dix caractères. Sans lui le build ne peut pas s’authentifier pour signer et échoue dans le cloud avec une erreur de certificat.

3. Garder l’identifiant

Le même identifiant qu’à l’étape Marque. C’est par lui qu’Apple reconnaît qu’une nouvelle version est la même app, et il ne change pas après la première publication.

Notifications Android : les deux fichiers Firebase

Android livre les notifications via Firebase Cloud Messaging, ce qui exige un projet Firebase à vous. Deux fichiers différents du même projet, et ils ne marchent qu’ensemble :

Créez l’app Android dans le projet Firebase avec le même identifiant que l’app. Si les deux fichiers viennent de projets différents, l’envoi de la notification échoue avec une erreur d’expéditeur qui ne le dit pas ainsi.

iOS n’utilise pas Firebase. Là, la livraison passe par Apple, avec l’identifiant que la plateforme crée déjà dans votre compte. Sans ces deux fichiers, le push marche sur l’iPhone et pas sur Android.

La clé In-App Purchase

Nécessaire seulement si vous vendez un abonnement ou un achat dans l’app sur iOS. Sous Users and Access → Integrations → In-App Purchase, cliquez sur Generate In-App Purchase Key. Elle aussi ne se télécharge qu’une fois, et le rôle exigé est Account Holder ou Admin.

Le guide Vendre des abonnements dans l’app couvre la suite du chemin.

Ce que la plateforme ne peut pas vérifier à votre place

Connecter le compte est la moitié du travail. L’autre moitié se passe dans la console du store, et de l’extérieur rien ne permet de voir si elle a été faite : si l’app existe dans la Play Console, si le compte de service a reçu sa permission, si la clé a le rôle Admin.

C’est pourquoi l’écran liste ces exigences sans bloquer le bouton. Il préfère vous laisser essayer et échouer avec un message clair plutôt que faire semblant de savoir ce qu’il ignore.

Liens officiels

• Play Console : ajouter des utilisateurs et gérer les autorisations
• Google Play Developer API : démarrer
• App Store Connect API : démarrer
• Apple : générer des clés In-App Purchase
• Expo : clé de compte de service pour FCM V1