Questions d’entretien Développeur Mobile multi-plateformes au Sénégal

📌 Pilier : Carrière développeur Mobile au Sénégal — guide complet (à créer)
Voisins : Développeur Full-Stack · DevOps Engineer · Développement mobile 2026 : Flutter, React Native, Expo, stores

Que fait un Développeur Mobile multi-plateformes ?

Un développeur mobile multi-plateformes construit des applications iOS et Android à partir d’une base de code unique, avec Flutter (langage Dart) ou React Native (langage TypeScript). Sur l’offre Développeur Mobile scrapée en mai 2026 sur emploisenegal, les missions couvrent la conception et le développement d’écrans, l’intégration de services backend via APIs REST ou Firebase, la mise en place de notifications push, l’optimisation des performances sur appareils anciens (réalité du marché ouest-africain), et la publication sur le Play Store et l’App Store. Vous travaillerez chez des startups locales (fintechs, e-commerce, logistique), des éditeurs régionaux qui visent plusieurs pays africains avec la même app, et de plus en plus en remote pour des sociétés européennes qui cherchent des profils Flutter ou React Native.

Stack technique attendue à Dakar

Sur l’offre Développeur Mobile observée (mai 2026, huit technologies détectées), le marché ouest-africain attend la stack suivante :

• Flutter (Dart) — framework Google qui gagne du terrain depuis 2023, particulièrement chez les fintechs et les éditeurs régionaux. Voir Build d’un Android App Bundle Flutter et publication sur Play Console.
• React Native (TypeScript) — alternative historique, encore très demandée chez les sociétés liées à l’écosystème JavaScript. Voir React Native avec Expo et EAS — premier projet de bout en bout et React Native tutoriel PME : démarrer concrètement.
• Firebase — backend-as-a-service quasi systématique pour les apps mobiles ouest-africaines : authentification, base de données, notifications push. Voir Push notifications en Flutter avec Firebase Cloud Messaging.
• TypeScript ou Dart — langage typé, exigence sur les nouveaux projets sérieux.
• Android Studio et Xcode — outils de build et de signature, à comprendre même si on code en cross-platform.
• APIs REST et GraphQL — consommation côté client, gestion du cache (TanStack Query côté RN, dio_cache_interceptor côté Flutter — l’écosystème Dio standard pour la mise en cache HTTP).
• Git et CI/CD mobile — workflows par branches, build sur EAS Build (Expo), Codemagic, Bitrise ou Fastlane lanes auto-hébergées. Microsoft App Center, longtemps utilisé pour la distribution interne, a été retiré le 31 mars 2025 (seul le module Analytics & Diagnostics reste maintenu jusqu’au 30 juin 2026).

Si vous débutez et devez choisir un ordre d’apprentissage, commencez par Flutter + Dart ou React Native + TypeScript selon ce que demandent les offres autour de vous (vérifier le marché local), puis ajoutez Firebase pour le backend, et finissez par la publication sur les stores. Le panorama complet est dans Développement mobile 2026 : Flutter, React Native, Expo, stores.

Salaire moyen au Sénégal pour ce poste

Sur l’offre Développeur Mobile observée en mai 2026, le salaire n’était pas affiché. Le marché mobile cross-platform est tiré par les fintechs et les startups bien financées. Croisé avec les fourchettes du marché ouest-africain (sources : Talent.com, Glassdoor, Talent2Africa, Africashore) :

En freelance, le TJM d’un profil confirmé tourne autour de 80 000 – 130 000 – 230 000 FCFA. Flutter et React Native sont équivalents en salaire, mais Flutter prend des parts de marché depuis 2023 et offre une meilleure visibilité internationale pour le télétravail. Le natif (Kotlin pour Android, Swift pour iOS) paie systématiquement mieux mais le marché est plus étroit au Sénégal. Pour cadrer la négociation : Négocier son salaire de dev en CFA et USD — guide Afrique de l’Ouest.

Questions d’entretien & réponses

Question 1 : Quelle est la différence entre StatefulWidget et StatelessWidget en Flutter (ou entre composant fonctionnel avec et sans hooks en React Native) ?

Ce que cherche vraiment le recruteur

Question fondamentale qui sépare les juniors des candidats qui ont déjà publié une app. Le recruteur vérifie que vous comprenez le cycle de vie d’un widget ou d’un composant et la gestion de l’état local. Il guette une réponse claire sur quand utiliser chacun et un exemple concret.

Exemple de réponse

En Flutter, un StatelessWidget rend une interface qui ne change pas après sa construction : un texte fixe, une carte d’information, un bouton qui délègue son comportement à un callback. Il est plus performant car Flutter peut le mémoïser facilement. Un StatefulWidget porte un état mutable interne géré dans une classe State associée — un compteur, un formulaire en cours de saisie, une animation. La méthode setState() notifie Flutter qu’il faut reconstruire l’interface. En React Native, l’équivalent est un composant fonctionnel sans hook (équivalent du StatelessWidget) versus un composant fonctionnel qui utilise useState, useEffect ou d’autres hooks. Le principe est le même : on garde stateless tant que possible, on passe à stateful seulement quand on a besoin d’état local. Pour l’état partagé entre plusieurs écrans, on bascule plutôt vers un store (Provider/Riverpod en Flutter, Zustand/Redux en RN) que de remonter l’état via le widget racine.

Question 2 : Expliquez comment vous gérez la navigation et le routage dans une application mobile multi-écrans.

Ce que cherche vraiment le recruteur

Question qui couvre une partie centrale du métier, souvent mal traitée par les juniors qui empilent les Navigator.push sans plan. Le recruteur évalue votre maîtrise des routes nommées ou typées, du deep linking, et de la persistance d’état entre les écrans.

Exemple de réponse

En Flutter, j’utilise GoRouter ou auto_route pour déclarer les routes en typé, avec support natif du deep linking et de la restauration d’état. Pour un cas simple sans deep linking, le Navigator 2.0 ou même les routes nommées du Navigator 1.0 suffisent. En React Native, j’utilise React Navigation avec une structure en piles (StackNavigator), onglets (BottomTabNavigator) et tiroir (DrawerNavigator) selon le design. Le typage TypeScript des paramètres de route évite les erreurs classiques au moment de naviguer (navigation.navigate('Profil', { userId }) où userId est manqué ou mal typé). Pour le deep linking, je déclare le schéma d’URL dans le linking config, et chaque écran sait extraire ses paramètres. Pour la persistance, j’active la restauration d’état du navigator pour que l’utilisateur revienne sur le bon écran après un crash ou un kill du système.

Question 3 : Comment optimisez-vous une application mobile lente sur un téléphone d’entrée de gamme (4 Go RAM, processeur ancien) ?

Ce que cherche vraiment le recruteur

Question critique pour le marché ouest-africain où la majorité des utilisateurs sont sur des appareils modestes. Le recruteur cherche un candidat qui pense performance dès la conception, pas après le déploiement. Une bonne réponse mentionne le profilage, l’optimisation des images, la pagination des listes, et la prudence sur les animations.

Exemple de réponse

Je commence par profiler avec les Flutter DevTools ou le profiler de React Native pour identifier les frames perdues et les fuites mémoire. Les optimisations les plus rentables sont rarement glamour : compresser les images en WebP ou AVIF, redimensionner côté serveur plutôt que côté client, paginer les listes longues avec ListView.builder (Flutter) ou FlashList (React Native) au lieu de charger 500 items d’un coup. Pour les animations, je privilégie celles qui tournent sur le thread d’animation natif (transformations CSS-like en Flutter, Reanimated en RN) plutôt que sur le thread JS qui peut freezer. Je désactive les ombres complexes sur les appareils détectés comme low-end. Le cache des requêtes HTTP est crucial : une app qui re-fetch les mêmes données à chaque navigation consomme inutilement de la batterie et de la data, deux ressources rares chez nos utilisateurs. Enfin, je teste systématiquement sur un Android 6 ou 7 avec 2 à 4 Go de RAM, pas seulement sur un iPhone 14 Pro de l’équipe.

Question 4 : Quelle est la limite de Firebase pour une application qui devient grosse, et comment la contournez-vous ?

Ce que cherche vraiment le recruteur

Question de maturité qui sépare le développeur junior (qui utilise Firebase sans réfléchir) du confirmé (qui sait quand le quitter). Le recruteur cherche à voir si vous comprenez les modèles de coût Firebase, les limites de Firestore en mode hot-spotting, et les alternatives.

Exemple de réponse

Firebase est excellent pour démarrer vite : authentification, base de données temps réel, fonctions cloud, hosting, le tout intégré. Les limites apparaissent à trois moments. Premièrement, le coût : Firestore facture par lecture, et une application qui s’abonne à de larges collections en temps réel peut générer des factures inattendues. Solution : pagination stricte, structures dénormalisées limitant la profondeur des requêtes, indexation soignée. Deuxièmement, les patterns de hot-spotting : Firestore plafonne à environ une écriture par seconde de manière soutenue sur un même document, et autour de 500 écritures par seconde sur une même collection avant que le load splitter doive intervenir. Sur un compteur de vues d’article par exemple, écrire mille fois par seconde sur le document articles/foo/stats provoquera des erreurs de contention — il faut éclater le compteur en N shards aléatoires (par exemple dix sous-documents) puis sommer à la lecture pour absorber le volume. Troisièmement, le verrouillage : passer de Firebase à un backend custom (Supabase, PostgREST, ou une vraie API maison) demande un effort important. Stratégie : abstraire dès le début l’accès aux données derrière un repository, pour que le swap soit possible sans réécrire les écrans. Sur une app qui dépasse 100 000 utilisateurs actifs mensuels, je commence à étudier sérieusement une migration partielle ou totale.

Question 5 : Vous reprenez un projet React Native d’un développeur parti subitement, le code ne compile pas et il y a 200 warnings. Comment procédez-vous ?

Ce que cherche vraiment le recruteur

Mise en situation très réaliste de prestation. Le recruteur évalue votre méthode pour reprendre du code étranger sans tout reprendre depuis zéro. Une bonne réponse suit une séquence : compiler d’abord, comprendre ensuite, refactorer en dernier.

Exemple de réponse

Première étape : faire compiler le projet. Je clone le dépôt, je lis le README s’il existe, je vérifie les versions Node et React Native attendues. Les erreurs de compilation viennent souvent de dépendances natives mal liées : je purge node_modules et ios/Pods, je relance npm install puis cd ios && pod install. Si une dépendance est cassée, je vérifie le changelog pour passer à une version compatible. Une fois le projet qui démarre, je laisse les 200 warnings de côté et je vérifie que les fonctionnalités principales marchent — login, navigation, écran d’accueil. Ensuite, je cartographie : combien d’écrans, quelle architecture (Redux, Zustand, contexte React), quelles APIs consommées. Je documente cette cartographie pour moi et pour la suite. Pour les warnings, je les classe : ceux liés à des dépendances obsolètes (à mettre à jour groupées), ceux liés à du code mort (à supprimer), ceux liés à des patterns dépréciés (à corriger progressivement quand je touche un fichier). Je ne lance jamais de grand refactor en parallèle d’une livraison de feature.

Question 6 : Décrivez un projet où vous avez publié une application sur le Play Store ou l’App Store et géré les premières mises à jour.

Ce que cherche vraiment le recruteur

Question comportementale au format STAR qui vérifie une compétence souvent absente chez les juniors : la publication. Le recruteur cherche une expérience concrète, avec les pièges du process (rejet pour règles non respectées, délai d’examen, gestion de la versioning).

Exemple de réponse

Sur un projet d’app de gestion de petites caisses pour des commerçants, j’ai porté la publication sur le Play Store du premier build à la version 2.3. La première soumission a été rejetée pour deux raisons : permissions déclarées trop larges (j’avais demandé l’accès à la localisation alors que la feature n’était plus dans l’app), et description du Play Console qui mentionnait une fonctionnalité encore en bêta. J’ai corrigé les deux points, retiré les permissions inutiles dans le manifest, ajusté la description, et la soumission a passé en 48 heures. Pour les mises à jour, j’ai mis en place une versioning sémantique avec montée automatique du versionCode à chaque build via un script CI, ce qui évite l’erreur très fréquente du versionCode non incrémenté qui bloque l’upload. Pour les ruptures de compatibilité côté API, j’ai introduit un mécanisme de version minimum forcée : l’app reçoit du backend un message qui demande la mise à jour si elle est trop ancienne, sinon elle bloque la session. Sur deux ans, l’app a fait dix-huit releases sans incident grave de publication.

Difficulté de l’entretien

6 / 10 — Moyen

Le process Développeur Mobile suit le schéma standard frontend : pré-qualification RH, entretien technique d’une heure avec un développeur senior ou un tech lead, test à la maison (écran à coder ou bug à corriger dans une mini-app fournie), entretien final avec le manager. Le live-coding court est moins fréquent que sur les postes backend, sauf chez les éditeurs internationaux. Pour les missions remote européennes, l’anglais oral est vérifié. Une démo de votre application personnelle publiée sur les stores fait souvent la différence — préparez un lien et 5 minutes de pitch.

Difficulté du métier

7 / 10 — Difficile

Le métier demande de jongler avec deux plateformes (iOS et Android) qui ont des particularités persistantes malgré le cross-platform : permissions différentes, écosystème de notifications distinct, règles de publication divergentes. Le quotidien combine codage, debug sur émulateur puis appareil réel, optimisation de performance, et gestion de la chaîne de publication. La veille techno est dense : Flutter et React Native publient des versions majeures fréquentes, l’écosystème de packages est mouvant, les SDK Firebase et tiers évoluent. Le risque opérationnel est modéré sur la fonctionnalité (un bug visuel n’est pas critique), mais un crash en démarrage poussé en production peut bloquer 100 % de la base utilisateur en attendant la révision Apple ou Google.

Pré-requis pour ce poste

• Diplôme Bac+3 à Bac+5 en informatique, ou expérience démontrée équivalente (bootcamp + 1 ou 2 apps publiées).
• Expérience minimale typique : 0 à 2 ans (junior), 3 à 5 ans (confirmé).
• Maîtrise solide de Flutter avec Dart OU React Native avec TypeScript ; idéalement les deux pour la polyvalence.
• Pratique opérationnelle de Firebase (auth, Firestore, Cloud Messaging).
• Compréhension des cycles de vie iOS et Android (background, push, deep links).
• Pratique de Git, des branches de release, des CI/CD mobile (EAS Build, Codemagic, Bitrise, GitHub Actions — Microsoft App Center retiré depuis mars 2025).
• Expérience de publication sur Play Store et App Store (idéalement les deux) — à mettre en avant explicitement.
• Bases en consommation d’APIs REST ou GraphQL avec gestion de cache.
• Anglais technique lu et écrit ; anglais oral pour les missions internationales.

Pour aller plus loin

Si vous visez aussi un poste plus polyvalent comme Développeur Full-Stack, ou si vous voulez basculer côté infrastructure avec DevOps Engineer (chemin de plus en plus courant pour les mobile devs qui industrialisent leur CI/CD), notre bibliothèque d’articles entretien aide à comparer les attentes.

Pour solidifier votre stack mobile en vue d’un entretien, parcourez le panorama Développement mobile 2026 : Flutter, React Native, Expo, stores, puis attaquez React Native avec Expo et EAS — premier projet de bout en bout ou Build d’un Android App Bundle Flutter et publication sur Play Console. Pour la fonctionnalité push, presque toujours demandée : Push notifications en Flutter avec Firebase Cloud Messaging.

→ Voir tous les articles du cluster (à créer)

Autres entretiens techniques

• Réussir un entretien technique en anglais : préparation, scripts, mock interviews
• Questions d’entretien DevOps Engineer au Sénégal
• Questions d’entretien Développeur Full-Stack au Sénégal
• Questions d’entretien Développeur Frontend Angular au Sénégal
• Questions d’entretien Data Scientist au Sénégal