recruter-un-freelance-mobile

TJM développeur mobile, les fourchettes constatées selon l'expérience

8 min de lecture
TJM développeur mobile, les fourchettes constatées selon l'expérience

Le TJM développeur mobile, ou taux journalier moyen, est la donnée que tout le monde cherche et que personne ne peut fixer une fois pour toutes. Il dépend de l’expérience, de la technologie, du type de mission, du canal par lequel elle passe et, dans une moindre mesure, de la région. Les chiffres qui suivent sont des fourchettes de marché prudentes, observées en France pour des missions de développement Android natif ou multiplateforme. Ils servent de repère pour un client qui prépare un budget comme pour un indépendant qui fixe son prix, sans constituer une grille officielle : aucune n’existe pour ce métier.

Ce que recouvre le TJM développeur mobile

Le taux journalier est le prix facturé pour une journée de travail, généralement hors taxes. Il ne se compare pas à un salaire divisé par le nombre de jours travaillés, car il doit couvrir bien davantage qu’une rémunération.

Un développeur indépendant finance lui-même ses cotisations sociales, sa protection en cas de maladie, sa retraite, son matériel, ses logiciels, sa formation et ses congés. Il supporte aussi les périodes sans mission entre deux contrats et le temps passé à prospecter, qui ne sont pas facturés. Un taux qui paraît élevé ramené à la journée l’est beaucoup moins ramené à l’année.

Deux autres éléments brouillent les comparaisons. D’abord, le taux affiché n’est pas forcément le taux perçu : lorsqu’une mission passe par une société de services ou une plateforme, une marge ou une commission s’intercale entre le prix payé par le client final et ce que touche le freelance. Ensuite, le TJM concerne surtout les missions en régie. Sur un projet au forfait, le prix est global, même s’il est souvent construit à partir d’une estimation en jours.

Les fourchettes selon l’expérience

Graphique sur un écran comparant les taux journaliers des développeurs mobiles selon leur niveau d’expérience

L’expérience reste le premier facteur de variation. Les fourchettes ci-dessous correspondent à des missions de développement mobile en France, hors Paris pour la colonne de gauche et en Île-de-France pour celle de droite. Elles reflètent des ordres de grandeur constatés sur le marché, à prendre avec prudence : un profil rare ou une mission très spécifique peut sortir de ces bornes.

NiveauExpérience indicativeTJM hors Île-de-FranceTJM en Île-de-France
JuniorMoins de 3 ansEnviron 300 à 400 €Environ 350 à 450 €
Confirmé3 à 7 ansEnviron 400 à 550 €Environ 450 à 600 €
SeniorPlus de 7 ansEnviron 500 à 700 €Environ 550 à 750 €
Expert ou leadArchitecture, encadrementSouvent au-delà de 650 €Souvent au-delà de 700 €

Ces niveaux ne se résument pas au nombre d’années. Un profil junior sait développer des écrans et des fonctionnalités encadrées, mais a besoin d’appui sur l’architecture et les choix structurants. Un profil confirmé est autonome sur une application complète, de la conception à la publication. Un profil senior sait en plus reprendre une base de code difficile, arbitrer entre plusieurs solutions techniques, encadrer d’autres développeurs et anticiper les évolutions de la plateforme.

Le marché des indépendants débutants est par ailleurs plus étroit : beaucoup de missions en régie exigent plusieurs années d’expérience. Un junior qui se lance trouve plus facilement des projets au forfait de petite taille, souvent à un niveau de prix modeste. Les étapes pour démarrer sont détaillées dans l’article sur le fait de se lancer comme développeur Android freelance.

Ce qui fait varier le taux au-delà de l’expérience

À expérience égale, deux développeurs mobiles peuvent afficher des taux sensiblement différents. Plusieurs facteurs expliquent ces écarts.

La technologie. Les profils natifs Android avec une solide maîtrise de Kotlin et de Jetpack Compose restent très demandés. Les profils capables de travailler à la fois sur Android et iOS, ou sur une base multiplateforme comme Flutter, React Native ou Kotlin Multiplatform, peuvent valoriser cette polyvalence. Une base de code ancienne en Java, avec un historique lourd, demande aussi des compétences spécifiques. Le choix de langage est analysé dans l’article Kotlin ou Java pour Android.

Secteur du client. Banque, assurance, santé ou grands médias imposent souvent des exigences de sécurité, de conformité et de qualité qui justifient des taux plus élevés. Une jeune entreprise en phase de lancement a généralement un budget plus contraint.

Le canal. Une mission obtenue en direct auprès du client permet de facturer le taux complet. Via un intermédiaire, le freelance perçoit le taux négocié moins la marge ou la commission, dont le montant varie selon les acteurs.

Mode de travail. Le travail à distance a élargi le marché : un développeur installé en province peut travailler pour un client parisien. Les écarts régionaux se sont ainsi resserrés, sans disparaître pour les missions qui exigent une présence sur site.

Durée et urgence. Une mission longue et stable s’accompagne parfois d’un taux un peu plus bas en échange de la sécurité. Une intervention courte et urgente, comme le sauvetage d’une application bloquée avant une échéance, se facture plus cher.

Du TJM au prix d’une application

Tableau blanc détaillant les fonctionnalités et l’estimation en jours d’une application mobile

Pour un client, la question qui compte est souvent le budget total. Il dépend du nombre de jours nécessaires, multiplié par le taux, auquel s’ajoutent le design, le back-end, les tests et la publication. Les ordres de grandeur suivants concernent une application Android développée par un indépendant ; ils restent indicatifs, car deux applications « simples » peuvent demander des charges très différentes.

Type d’applicationExemples de contenuCharge indicativeBudget indicatif
SimpleQuelques écrans, contenu statique ou peu dynamique, pas de compte utilisateurQuelques semainesEnviron 5 000 à 15 000 €
IntermédiaireComptes utilisateurs, API existante, notifications, mode hors ligne partielDeux à quatre moisEnviron 15 000 à 50 000 €
ComplexePaiement, temps réel, back-end sur mesure, forte exigence de sécuritéPlusieurs mois, souvent à plusieursSouvent au-delà de 50 000 €

Plusieurs postes sont fréquemment oubliés dans ces estimations. Le design d’interface, s’il n’est pas fourni, demande un designer ou des jours supplémentaires. Le back-end, s’il n’existe pas, peut représenter une part importante du budget. Les tests sur plusieurs appareils, la préparation de la fiche du Play Store et la conformité aux règles de Google prennent du temps. Enfin, une version iOS en natif double à peu près une partie du travail, d’où l’intérêt d’étudier les solutions multiplateformes présentées dans le comparatif Flutter ou natif.

Il faut aussi prévoir la suite. Une application publiée n’est jamais terminée : les nouvelles versions d’Android et l’évolution des règles du Play Store imposent des mises à jour régulières. Un budget annuel de maintenance, souvent exprimé en pourcentage du coût initial ou en nombre de jours par an, doit figurer dans le calcul dès le départ.

Comment un indépendant construit son taux

Comprendre la façon dont un développeur calcule son taux aide aussi le client à juger une proposition. La méthode la plus répandue part de l’année, et non de la journée.

Le point de départ est le nombre de jours réellement facturables. Une année compte environ deux cent cinquante jours ouvrés ; il faut en retirer les congés, les jours fériés, les périodes de formation, le temps de prospection et une marge pour les intercontrats et les arrêts éventuels. Beaucoup d’indépendants raisonnent ainsi sur un volume nettement inférieur, souvent autour de cent quatre-vingts à deux cents jours facturés dans une année correcte, parfois moins la première année.

Vient ensuite le revenu visé, auquel s’ajoutent les cotisations sociales, l’impôt, les frais professionnels (matériel, logiciels, assurance, comptabilité, déplacements) et une réserve de trésorerie. Diviser ce total par le nombre de jours facturables donne un taux plancher, en dessous duquel l’activité ne tient pas dans la durée.

Ce plancher est enfin confronté au marché. S’il se situe au-dessus des fourchettes du niveau d’expérience, il faut revoir le revenu visé, le volume de jours ou le positionnement. S’il se situe en dessous, l’indépendant a de la marge pour s’aligner sur les prix constatés. Cette démarche explique pourquoi deux freelances de même niveau, avec des charges et des objectifs différents, n’affichent pas le même taux.

Lire une proposition sans se faire piéger

Le taux journalier seul ne dit pas si une proposition est bonne. Un client a intérêt à regarder l’ensemble.

Une estimation très en dessous des fourchettes du marché cache souvent un périmètre mal compris, un profil moins expérimenté qu’annoncé ou un futur dépassement. À l’inverse, un taux élevé assorti d’une estimation précise, découpée en étapes et accompagnée d’hypothèses explicites, est souvent le signe d’un professionnel qui a déjà livré des projets comparables.

Quelques réflexes aident à comparer :

  • demander le détail de l’estimation en jours par grand bloc fonctionnel ;
  • vérifier ce qui est inclus (tests, publication, documentation, garantie) et ce qui ne l’est pas ;
  • comparer le nombre total de jours autant que le taux ;
  • se renseigner sur les conditions de facturation des demandes hors périmètre ;
  • prévoir une marge pour les imprévus, souvent indispensable sur un projet mobile.

Pour l’indépendant, la logique est symétrique. Fixer son taux à partir des fourchettes de son niveau, puis l’ajuster selon la mission, protège d’une sous-facturation qui serait difficile à rattraper. Expliquer son estimation au client, plutôt que d’annoncer un chiffre sec, aide à justifier un taux plus élevé que la moyenne. Les critères de sélection côté client sont développés dans le guide pour recruter un freelance en application mobile.

Le TJM d’un développeur mobile reste une donnée de marché, mouvante et négociée. Les fourchettes présentées ici donnent un cadre réaliste pour dialoguer, budgéter et éviter les écarts aberrants. La vraie mesure d’un bon prix, en définitive, reste le rapport entre ce qui est payé et ce qui est livré, publié et maintenu dans le temps.