Questions d'entretien release manager mobile, de l'App Store à Google Play

Le release manager mobile tient le calendrier des versions iOS et Android : branche de release, builds signés, passage par TestFlight et par les pistes de test de Google Play, soumission aux revues d'Apple et de Google, puis déploiement progressif et suivi des crashs. Les offres françaises le présentent aussi comme chef de projet release, avec Jira, Confluence, un outil de changement comme ServiceNow, et une publication sur les stores ou une activation par toggles.

Sur les stores, on arrête un déploiement, on ne revient pas à la version précédente : il faut en publier une nouvelle. Un candidat qui a vraiment fait des sorties mobiles parle de versionCode, de publication progressive mise en pause, de certificats qui expirent et de version minimale imposée aux anciens utilisateurs. Un profil venu de la release web décrit souvent un retour arrière qui n'existe pas sur mobile.

Tout dépend de la nature du poste : surtout de la coordination, ou aussi l'automatisation avec fastlane et la CI. Dans le second cas, l'entretien aborde aussi la signature et les lanes. Le récit d'une sortie qui a mal tourné, avec la décision prise et le délai, en dit long. Le PDF propose 30 questions, un cas de 20 minutes et une grille de 1 à 4.

Stores et outils de publication du release manager mobile

App Store Connect et TestFlight

La console d'Apple pour soumettre les versions iOS à la revue, préparer la page de l'app et choisir le mode de sortie : manuelle, programmée ou progressive sur sept jours. TestFlight distribue les bêtas à 100 testeurs internes et jusqu'à 10 000 externes, avec une revue pour le premier build externe. Un build y reste testable 90 jours.

Google Play Console

L'équivalent chez Google, avec des pistes de test interne, fermé et ouvert, puis la production. Le déploiement progressif se règle en pourcentage et peut être arrêté, mais une version publiée ne se remplace que par une version au numéro supérieur. La console affiche aussi les Android vitals, dont les taux de crash et d'ANR qui pèsent sur la visibilité de l'app.

fastlane

L'outil open source qui automatise la publication : build, signature, envoi sur TestFlight, sur l'App Store ou sur Google Play, captures et métadonnées. Son module match partage les certificats et profils iOS de l'équipe dans un stockage chiffré. Un release manager qui automatise ses sorties l'a presque toujours utilisé.

Signature iOS et Android

Certificats et profils de provisionnement côté Apple, clé d'upload et Play App Signing côté Google. Un certificat qui expire bloque les nouveaux builds sans toucher aux versions déjà publiées. Les clés vivent dans les secrets de la CI, jamais sur le poste d'une seule personne.

CI mobile

GitHub Actions, GitLab CI, Bitrise, Codemagic ou Xcode Cloud. Les builds iOS exigent des machines macOS et une version d'Xcode fixée. Depuis le 28 avril 2026, Apple refuse les soumissions qui ne sont pas construites avec Xcode 26 et le SDK iOS 26.

Feature flags et kill switch

Firebase Remote Config, LaunchDarkly ou un service maison. Ils permettent de livrer du code désactivé, de l'activer à l'heure voulue et de couper une fonction en panne sans attendre une nouvelle revue. Sur mobile, c'est le seul vrai moyen de revenir en arrière rapidement.

Version minimale et mise à jour forcée

Un mécanisme dans l'application qui compare sa version à une version minimale lue à distance et bloque ou invite à mettre à jour. Sur Android, l'API In-App Updates le fait proprement. Sans lui, une API back-end doit rester compatible avec toutes les vieilles versions encore installées.

Crashlytics et suivi de stabilité

Firebase Crashlytics, Sentry ou un outil équivalent remontent les plantages par version. Ils ont besoin des dSYM côté iOS et du fichier de mapping R8 côté Android pour afficher des piles d'appels lisibles. Ce sont ces chiffres qui décident de poursuivre ou d'arrêter un déploiement.

Selon l'équipe, le poste penche vers la coordination ou vers l'outillage. Côté coordination, le release manager mobile tient le calendrier, anime le go/no-go, rédige les notes de version et suit les validations des stores, souvent en parallèle d'autres releases web ou back-end. Côté outillage, il écrit les lanes fastlane, gère certificats et clés, et automatise la promotion des builds entre pistes. Les deux demandent la même connaissance des règles d'Apple et de Google, qui changent chaque année : version d'Xcode exigée, niveau d'API Android ciblé, déclarations de confidentialité. Un bon candidat cite les dernières échéances qu'il a dû tenir et ce qu'elles ont changé dans ses builds.

Release manager mobile : les compétences à vérifier

• Publication App Store et TestFlight
• Pistes et déploiement progressif sur Google Play
• Versionnement et branches de release
• Signature, certificats et fastlane
• Flags, versions minimales et mise à jour forcée
• Stabilité après publication : crashs et vitals

Cinq questions d'entretien sur la publication mobile

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Vous activez la publication progressive sur l'App Store. Qui reçoit la nouvelle version le premier jour, et que pouvez-vous faire si un problème apparaît ?

   Une bonne réponseLa publication progressive dure sept jours : 1 %, 2 %, 5 %, 10 %, 20 %, 50 % puis 100 %, tirés parmi les utilisateurs qui ont les mises à jour automatiques. N'importe qui peut quand même installer la version à la main depuis l'App Store. On peut mettre en pause, 30 jours au total, ou tout ouvrir d'un coup. Il n'existe pas de retour à la version précédente : il faut soumettre une nouvelle version corrigée.

   Signal d'alerteCroire qu'on peut revenir en arrière comme sur un serveur, ou que la pause bloque aussi les installations manuelles.

2. Question 2 · confirmé

   Sur Google Play, une version déployée à 20 % fait remonter des crashs. Que pouvez-vous faire, et que ne pouvez-vous pas faire ?

   Une bonne réponseArrêter le déploiement (Halt rollout) : plus personne ne reçoit la version, ceux qui l'ont déjà la gardent. On ne republie pas l'ancienne version. Il faut une nouvelle release avec un versionCode supérieur, soit un correctif, soit l'ancien code reconstruit avec un numéro plus haut. Un déploiement repris touche le même groupe d'utilisateurs, et le pourcentage ne monte jamais tout seul. Si la fonction fautive est derrière un flag, il la coupe en attendant.

   Signal d'alerte« Je republie l'APK précédent », ou ignorer que le versionCode doit augmenter.

3. Question 3 · junior à confirmé

   Comment numérotez-vous les versions iOS et Android, et qu'est-ce qui doit augmenter à chaque envoi ?

   Une bonne réponseSur Android, versionName est affiché, versionCode est un entier qui doit croître à chaque envoi. Sur iOS, CFBundleShortVersionString porte la version visible et CFBundleVersion le numéro de build, qui doit être unique pour une même version. Le numéro de build vient de la CI (numéro de pipeline ou horodatage), la version visible est la même sur les deux OS pour simplifier le support, et chaque release a son tag Git.

   Signal d'alerteDes numéros modifiés à la main dans le code, puis des envois refusés pour doublon.

4. Question 4 · confirmé

   Un certificat de distribution iOS expire dans dix jours. Qu'est-ce qui casse s'il expire, et comment vous organisez-vous ?

   Une bonne réponseLes versions déjà publiées sur l'App Store continuent de fonctionner. On ne peut plus signer de nouveaux builds avec ce certificat, et les builds Ad Hoc ou Enterprise qui en dépendent cessent de s'ouvrir. Il renouvelle à l'avance et régénère les profils. Avec fastlane match, le renouvellement se fait une fois dans le stockage chiffré partagé, et la CI se contente de lire. Pour les notifications push, il préfère une clé d'authentification APNs (.p8), qui n'expire pas, à un certificat.

   Signal d'alerte« L'application ne marchera plus chez les utilisateurs », ou un certificat renouvelé sur le Mac d'un développeur sans être partagé.

5. Question 5 · confirmé

   Comment obligez-vous les utilisateurs restés sur une version vieille de deux ans à mettre à jour ?

   Une bonne réponseUne version minimale supportée, lue au démarrage dans une configuration distante ou renvoyée par l'API, avec un écran bloquant en dessous et une invitation simple au-dessus. Sur Android, In-App Updates en mode immédiat. Le mécanisme doit exister dans l'application bien avant le jour où on en a besoin. Le seuil se décide sur la part d'utilisateurs par version et sur le coût de maintien des anciennes API, et le support est prévenu.

   Signal d'alerteCouper l'ancienne API sans prévenir, ou forcer la mise à jour à chaque version.

Release manager mobile : les questions fréquentes

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.