Un CV de développeur·se mobile est lu par deux publics distincts, souvent dans la foulée : un recruteur qui scanne les mots-clés de stack et un tech lead qui cherche la preuve d'avoir livré de vraies apps à de vrais utilisateurs. Un CV qui gagne les deux est structuré pour que le recruteur voie la stack dans le tiers haut et que le tech lead voie la preuve de livraison dans les puces d'expérience.
La plupart des CV mobile gèrent la première partie et ratent la seconde. Voilà ce qu'on corrige.
Les signaux spécifiques au mobile que les tech leads cherchent
Quand un·e ingé iOS ou Android senior relit un CV, les motifs qu'il·elle cherche ne sont pas génériques. Cinq signaux spécifiques au mobile portent l'essentiel du poids :
- Des apps en production avec un lien App Store / Play Store — le signal le plus fort à lui tout seul. Une app live avec un nombre de téléchargements et quelques avis bat cinq « pilotage du développement » qui ne mènent à rien de cliquable.
- Des versions de plateforme et minima OS précis — « iOS 15+ » ou « Android API 26+ » montre que vous avez pris de vraies décisions production sur le support d'appareils.
- Des chiffres de taille d'app et de performance — « Cold start réduit de 3,1 s à 1,4 s » ou « Taille du binaire baissée de 32 % » est le genre de métrique qu'un tech lead vérifie d'une question.
- Un niveau natif annoncé honnêtement — la plupart des CV mobile surévaluent la profondeur native sur la plateforme qu'ils n'ont pas vraiment construite. La solution est l'honnêteté : si vous avez écrit l'app iOS et relu les PR sur l'Android, dites-le.
- Le travail de distribution et de release — TestFlight, App Store Connect, pistes internes de la Play Console, déploiements progressifs, in-app updates. Ce sont des compétences opérationnelles spécifiques aux plateformes qui distinguent un·e dev mobile senior de quelqu'un qui n'a fait que des écrans.
Une structure qui fonctionne pour un CV de dev mobile
Pour un CV d'une page (junior à confirmé·e) ou de deux pages (senior+) :
Bloc en-tête
Nom, intitulé (ex. Senior iOS Engineer), localisation, GitHub, et le lien le plus important de tous : une URL de portfolio ou un lien App Store vers une app livrée. Si votre appli principale est sur l'App Store, le lien va ici, pas enterré dans un projet en bas.
Résumé (3 lignes, optionnel mais à fort effet de levier)
Trois lignes maximum : années d'expérience mobile, plateforme principale, une ou deux spécialités métier. Exemple :
6 ans à construire des apps iOS pour la fintech et la santé, 4 apps publiées sur l'App Store (400 000+ téléchargements cumulés). Spécialisé·e dans l'architecture offline-first et les migrations Core Data à l'échelle.
Cette seule ligne vous sort déjà de 80 % de la pile des CV mobile.
Section compétences
Groupez par catégorie et ordonnez par pertinence pour le poste visé. Pour un·e candidat·e iOS qui postule sur un poste Swift :
- Langages : Swift 5, Objective-C (maintenance uniquement)
- Frameworks iOS : SwiftUI, UIKit, Combine, Core Data, CloudKit, WidgetKit
- Architecture : MVVM, TCA, Clean Architecture, modularisation avec SwiftPM
- Outils : Xcode, Instruments, fastlane, Bitrise, Sentry
- Release : TestFlight, App Store Connect, déploiements phasés, rapports App Privacy
Quatre à six catégories, douze à vingt éléments. Si vous faites aussi de l'Android, une sous-section Android distincte se justifie — mais classez-vous honnêtement. Lister Kotlin, Jetpack Compose, Hilt, Room quand vous avez livré une seule app tuto en Kotlin, c'est le type de surclaim qui se détecte en 15 minutes d'écran technique.
Puces d'expérience — le format mobile
Les puces mobile les plus solides suivent cette forme :
J'ai fait[chose mobile précise]en utilisant[framework/outil précis]→ résultat[résultat mobile mesurable].
Quelques exemples pour un·e ingé iOS :
- Migration du parcours checkout d'UIKit à SwiftUI sur 18 écrans, divisant le temps de construction d'un écran de 40 % et baissant le taux de bug par feature en QA d'environ 25 %.
- Ré-architecture de l'accès Core Data via un coordinateur de sync, faisant passer le taux d'utilisateurs sans crash de 99,2 % à 99,85 % en deux releases.
- Ownership du pipeline de release App Store (fastlane + match), passant la prépa release de 2 jours à 90 minutes et permettant des releases hebdo.
- Livraison d'un widget WidgetKit pour le résumé finance sur l'écran d'accueil, repris par 38 % des utilisateur·ices actif·ves mensuel·les en six semaines.
Le motif : chaque puce a un artefact mobile précis (UIKit, Core Data, fastlane, WidgetKit), un verbe d'ownership (migration, ré-architecture, ownership, livraison), et un chiffre qu'un manager peut creuser en entretien.
Pour un·e ingé Android, les équivalents : migrations Jetpack Compose, schéma Room, réductions de temps de build Gradle, gestion de release Play Console, restructuration des modules Hilt, travail sur les Baseline Profiles pour le cold start.
Section projets — là où vivent les liens App Store
Si vous avez livré des apps en dehors du travail — même petites — listez-les. Chaque entrée : nom de l'app, lien App Store / Play Store, une ligne de contexte, une ligne de point technique fort.
TideTracker — app iOS de prévi surf, 12 000 téléchargements. Construite en solo en SwiftUI avec une prédiction de hauteur de vague en Core ML on-device. App Store : [lien].Trois entrées comme ça sur un CV suffisent presque toujours. Elles font office de preuve, pas de profondeur de portfolio.
CV iOS Android — le problème d'honnêteté cross-platform
La plupart des candidat·es revendiquent plus de fluidité cross-platform qu'ils·elles n'en ont, et les tech leads sont calibrés contre ça. Le cadrage honnête :
- Plateforme principale : celle où vous avez livré, débogué en prod et fait des choix d'architecture.
- Plateforme secondaire : celle où vous avez construit quelque chose de non trivial mais peut-être sans posséder la release.
- Familier·ère : lu du code, contribué à des reviews, capable de naviguer dans une base de code.
Écrire iOS (principal), Android (familier) est plus crédible que lister les deux à égalité et se faire prendre à l'écran technique. « Familier » se lit comme honnête et lucide — deux adjectifs qui font avancer.
Frameworks cross-platform — React Native, Flutter, Kotlin Multiplatform
Si votre background est React Native ou Flutter, traitez le framework comme la stack principale et listez les passerelles natives et le travail spécifique à la plateforme comme preuve d'appui. Les équipes mobile qui recrutent en RN veulent voir que vous avez :
- Livré sur les deux stores depuis la même base de code.
- Écrit ou débogué des modules natifs (Java/Kotlin ou Swift/Objective-C) au moins de temps en temps.
- Géré les bords spécifiques aux plateformes : notifications push, deep linking, achats in-app, escalades de review d'app.
Un CV qui liste React Native sans rien de tout ça se lit comme un·e dev web qui essaie le mobile. Les équipes mobile qui recrutent se soucient de qui a vraiment détenu le compte App Store, pas de qui a écrit des écrans.
Ce qu'on enlève
- Techs mobile dépassées — Cordova, PhoneGap, Xamarin en compétence principale en 2026.
- Puces génériques non mobile — « Écrit des tests unitaires » sans contexte plateforme. Précisez XCTest, JUnit, Espresso, etc.
- « Utilisé Git, JIRA, Slack » — outils universels, pas compétences. Ils prennent la place du spécifique mobile.
- Longues listes de tous les frameworks iOS que vous avez croisés — Combine, RxSwift, MapKit, ARKit, CoreImage, AVFoundation, MetricKit empilés signale du remplissage, pas de l'étendue.
L'équipe Postulit voit souvent des CV mobile générés depuis LinkedIn qui rapatrient tous les buzzwords des offres depuis une liste de compétences LinkedIn — le travail de curation pour un CV mobile est plus court et plus brutal que pour beaucoup d'autres rôles, précisément parce que les interviewers mobile testent profondément les rares affirmations qui leur importent.
Livrez une petite app, mettez le lien, écrivez trois puces avec des métriques App Store. C'est plus de signal qu'un nuage de 50 technos.
Un CV mobile qui se lit comme honnête, précis et livré bat un CV qui se lit comme exhaustif. À chaque fois.