Deux types d'équipes publient des offres de tech lead mobile : les équipes natives (Swift et SwiftUI sur iOS, Kotlin et Jetpack Compose sur Android) et les équipes cross-platform sur Flutter ou React Native. Certaines demandent aussi le back-end qui sert l'application, sous forme de BFF en .NET ou en Kotlin. Le poste réunit l'architecture du code, l'outillage de build et de signature, la publication sur l'App Store et Google Play, puis le suivi des crashs.
Les stores imposent leur calendrier. Depuis le 28 avril 2026, Apple n'accepte que des builds faits avec Xcode 26 et le SDK iOS 26. Google Play demande de cibler Android 16 (API 36) pour toute nouvelle version depuis le 31 août 2026, avec une prolongation possible jusqu'au 1er novembre. Côté React Native, le code de l'ancienne architecture a été retiré en février 2026 avec la version 0.84.
Un développeur mobile senior connaît sa plateforme. Le tech lead doit en plus expliquer comment l'équipe livre, mesure et rattrape une version ratée, sachant qu'une partie des utilisateurs garde l'ancienne pendant des mois. Demandez les chiffres qu'il suivait : taux de crash, temps de démarrage, part des utilisateurs par version. Dans le PDF, 30 questions, un cas pratique de 20 minutes et une grille.
Plateformes et outils d'un tech lead mobile
Swift et SwiftUI
Le langage et le framework d'interface d'Apple. SwiftUI remplace peu à peu UIKit, encore très présent dans les applications existantes. Swift 6 vérifie la concurrence à la compilation, ce qui oblige à reprendre le code multithread des anciens projets.
Kotlin et Jetpack Compose
Le pendant Android : Kotlin, les coroutines pour l'asynchrone et Compose pour l'interface déclarative, avec encore des écrans en XML dans les applications plus anciennes. Hilt pour l'injection, Room pour la base locale et WorkManager pour les tâches de fond reviennent dans la plupart des projets.
Flutter, React Native, Kotlin Multiplatform
Trois façons de partager du code entre iOS et Android. Flutter dessine sa propre interface en Dart. React Native pilote des composants natifs en TypeScript. Kotlin Multiplatform partage la logique et, avec Compose Multiplatform, l'interface. Le tech lead doit justifier le choix de son équipe et ce qu'il coûte.
Architecture et modularisation
MVVM ou MVI, un état d'écran immuable, des modules Gradle ou des packages Swift par fonctionnalité. Le découpage en modules réduit le temps de compilation et limite les dépendances croisées quand plusieurs équipes travaillent sur la même application.
CI/CD mobile : fastlane, Xcode Cloud, Bitrise, GitHub Actions
Les builds iOS demandent des machines macOS et des certificats de signature, les builds Android une clé d'upload. fastlane automatise la signature, les numéros de version et l'envoi vers TestFlight ou les pistes de test de Google Play. Un tech lead ne laisse pas la publication dépendre du Mac d'un développeur.
Publication progressive et feature flags
Google Play permet un déploiement par pourcentage d'utilisateurs, que l'on peut arrêter. L'App Store propose une publication par phases sur sept jours. Les feature flags et la configuration à distance, avec Firebase Remote Config ou un outil équivalent, coupent une fonctionnalité sans attendre une nouvelle version.
Crashlytics, Sentry et Android vitals
Les outils qui remontent les crashs, les ANR (blocages du thread principal sur Android) et le temps de démarrage. Au-delà de certains seuils, Google Play peut réduire la visibilité de l'application. Demandez quels indicateurs la personne regardait après chaque version.
Sécurité et exigences des stores
Jetons rangés dans le Keychain iOS ou chiffrés avec le Keystore Android, référentiel OWASP MASVS, manifestes de confidentialité exigés par Apple, formulaire Data safety chez Google. Un oubli sur ces points se paie par un refus à la revue et une sortie décalée.
Dans une équipe native, le tech lead mobile maîtrise une plateforme et lit couramment l'autre, ou encadre deux référents iOS et Android. Dans une équipe Flutter ou React Native, il écrit aussi du Swift et du Kotlin pour les modules que le framework ne couvre pas. Certaines offres ajoutent le BFF qui sert l'application ou une part d'avant-vente. Dans tous les cas, la publication occupe une place que le web ne connaît pas : signature, revue des stores, versions anciennes qui restent installées, exigences de SDK qui changent chaque année.
Sur quoi évaluer un tech lead mobile
- Architecture et modularisation mobile
- Natif et cross-platform
- Données locales et hors-ligne
- Performance et stabilité
- Build, signature et publication
- Tests et sécurité mobile
Cinq cas de production pour un tech lead 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.
Question 1 · confirmé
Une version publiée hier fait planter l'application au démarrage chez une partie des utilisateurs Android. Que faites-vous dans l'heure ?
Une bonne réponseIl mesure l'étendue dans Crashlytics ou Sentry et dans Android vitals : version, version d'Android, modèles touchés. Il arrête le déploiement progressif dans la Play Console pour que personne d'autre ne reçoive la version. Si le crash vient d'une fonctionnalité derrière un flag, il la coupe à distance. Puis il livre un correctif avec un numéro de version supérieur, en déploiement progressif lui aussi. Après coup, il cherche pourquoi les tests et la piste de test interne ne l'ont pas attrapé.
Signal d'alerte« On attend de voir les avis », ou l'idée de remettre l'ancien APK en ligne tel quel, alors que Google Play exige un numéro de version supérieur à chaque envoi.
Question 2 · senior
Le produit veut une seule base de code pour iOS et Android. Comment arbitrez-vous entre natif, Flutter, React Native et Kotlin Multiplatform ?
Une bonne réponseIl part de l'équipe et du produit. Une équipe web en TypeScript ira plus vite sur React Native ; une équipe Android en Kotlin peut partager la logique avec Kotlin Multiplatform et garder des interfaces natives, ou partager aussi l'interface avec Compose Multiplatform ; Flutter convient à une interface très personnalisée identique sur les deux plateformes. Il liste ce qui restera natif dans tous les cas (widgets, extensions, Bluetooth, tâches de fond, paiements intégrés) et propose un prototype sur la fonctionnalité la plus risquée avant de décider.
Signal d'alerteUn avis de goût (« Flutter est toujours plus rapide ») ou une décision sans regarder l'équipe en place ni le code existant.
Question 3 · senior
L'application compte 300 écrans dans un seul module et une compilation prend douze minutes. Comment la découpez-vous ?
Une bonne réponseEn modules par fonctionnalité (modules Gradle, packages Swift), plus quelques modules communs (réseau, design system, analytics). Il sépare l'interface publique d'un module de son implémentation pour limiter les recompilations, interdit qu'une fonctionnalité dépende directement d'une autre et fait passer la navigation par des contrats. Il mesure avec les build scans Gradle et le rapport de temps de build de Xcode, active le cache de configuration, et découpe par étapes en commençant par les modules feuilles.
Signal d'alerteUn découpage par couche technique (tous les ViewModels dans un module), ou un grand découpage en une seule fois.
Question 4 · senior
Les utilisateurs saisissent des données sans réseau. Comment synchronisez-vous sans perdre ni dupliquer d'enregistrement ?
Une bonne réponseLa base locale (Room, SwiftData ou Core Data, SQLite) sert de source de vérité pour l'écran. Chaque modification entre dans une file d'opérations en attente, avec un identifiant généré sur l'appareil (UUID) qui rend l'envoi idempotent côté serveur. L'envoi passe par WorkManager ou BGTaskScheduler avec relances espacées. Il définit une règle de conflit (dernier écrit, numéro de version côté serveur, fusion par champ) et montre à l'utilisateur ce qui n'est pas encore synchronisé.
Signal d'alerteGarder les requêtes en mémoire et les renvoyer au retour du réseau, ou laisser le serveur générer les identifiants d'objets créés hors ligne.
Question 5 · confirmé
La Play Console signale un taux d'ANR élevé. Comment trouvez-vous ce qui bloque le thread principal ?
Une bonne réponseIl part des regroupements d'ANR dans Android vitals et de leurs traces, puis reproduit avec StrictMode en debug et une trace Perfetto. Causes fréquentes : lecture disque ou base sur le thread principal, travail lourd au démarrage, appel synchrone à un service système, verrou tenu par un autre thread. Correction : coroutines sur Dispatchers.IO, initialisations différées, Baseline Profiles pour le démarrage.
Signal d'alerte« On augmente le délai », ou ignorer les ANR parce que le taux de crash est bon.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Tech lead mobile : les questions des recruteurs
Faut-il un tech lead natif ou cross-platform ?
Prenez celui qui correspond à votre base de code et à celle que vous visez dans deux ans. Sur une application Flutter ou React Native, cherchez quelqu'un qui a déjà écrit du code natif pour les cas que le framework ne couvre pas. Sur deux applications natives, le tech lead doit lire couramment Swift et Kotlin, même s'il pratique surtout l'un des deux. Une migration de l'un vers l'autre se prépare avec lui, pas avant son arrivée.
Un tech lead web peut-il prendre une équipe mobile ?
Une partie de l'expérience se transpose, surtout vers React Native : organisation du code, tests, revue. Le reste est propre au mobile : signature et publication sur les stores, versions anciennes qui restent installées, cycle de vie des applications, permissions, crashs natifs, contraintes de batterie et de réseau. Sans pratique de ces sujets, prévoyez un développeur mobile senior à ses côtés pendant la prise de poste, ou cherchez un autre profil.
Que donner en test technique à un tech lead mobile ?
Une revue de code sur un petit projet existant donne une bonne image du niveau. Préparez un écran qui fait un appel réseau sur le thread principal, stocke un jeton en clair, perd sa saisie à la rotation et ne gère pas la perte de réseau, avec un fichier de pipeline incomplet. Laissez 30 minutes. La personne classe les défauts par gravité et explique comment elle les détecterait automatiquement. L'exercice se décline en Swift, en Kotlin ou en Flutter.
Quels indicateurs un tech lead mobile doit-il savoir citer ?
Le taux d'utilisateurs sans crash, le taux d'ANR sur Android, le temps de démarrage à froid, la taille de l'application et la répartition des utilisateurs par version. Un candidat qui a tenu une application en production connaît ces chiffres pour la sienne, ou au moins leur évolution après une correction. S'il ne cite que la note sur les stores, il a sans doute peu suivi la production.
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.
