Ce qui est réellement vendu
Pour produire écran natif ou multiplateforme, le Développeur mobile prépare les informations, utilise Xcode ou Android Studio et organise les validations avec éditeur d’application. Le devis précise aussi la remise de build signé et la conduite à tenir lorsque refus du store apparaît.
Clients et contextes
- éditeur d’application
- startup produit
- DSI mobile
Livrables vérifiables
- écran natif ou multiplateforme
- build signé
- plan de tests appareils
Compétences qui changent le niveau d’autonomie
- Swift ou Kotlin
- architecture mobile
- performance batterie
- publication store
Outils courants : Xcode ou Android Studio, Git, outil de crash reporting, ferme de tests. Pour ce métier, le devis doit préciser qui finance et administre ces outils lorsqu’ils conditionnent le livrable.
Repères de TJM et hypothèses par niveau
Ces montants sont des estimations éditoriales. Les bornes basse et haute correspondent à une sensibilité de ±15 % appliquée au repère central, et non à des quantiles statistiques observés.
| Niveau | Basse | Indicative | Haute | Hypothèse de mission | Ce qui fait varier le montant |
|---|---|---|---|---|---|
| Junior | 300 € | 350 € | 400 € | Périmètre borné, validation fréquente et première pratique de Swift ou Kotlin. | refus du store ; écran natif ou multiplateforme |
| Confirmé | 470 € | 550 € | 630 € | Autonomie sur écran natif ou multiplateforme et relation directe avec éditeur d’application. | architecture mobile ; fragmentation des appareils |
| Senior | 680 € | 800 € | 920 € | Arbitrage, prévention de refus du store et responsabilité sur build signé. | performance batterie ; régression sur ancienne version |
Le tarif monte notamment quand…
- maîtrise démontrée de Swift ou Kotlin sur un livrable comparable
- responsabilité directe face à refus du store
- capacité à livrer build signé sans supervision quotidienne
- urgence, disponibilité contrainte ou coordination de plusieurs décideurs
Une baisse peut se discuter quand…
- périmètre stable sur une mission longue réellement engagée
- travail à distance sans astreinte ni contrainte de présence
- lot très cadré avec documentation et critères d’acceptation disponibles
Missions types : contexte, livrable et vigilance
Ces cas servent à construire un devis ; ils ne décrivent ni un échantillon de missions observées ni une promesse de durée.
| Mission | Contexte et livrable | Durée | Facturation et bande simulée | Vigilance |
|---|---|---|---|---|
| migration d’un module mobile obsolète Confirmé | éditeur d’application avec un besoin borné de livrer des applications mobiles compatibles avec les contraintes des stores et des appareils. Livrable : écran natif ou multiplateforme | 2 semaines | Forfait borné ou régie 470 à 630 € / jour | refus du store |
| préparation d’une version pour publication Senior si arbitrages | startup produit recherchant davantage d’autonomie et de coordination. Livrable : build signé | de 2 semaines à 6 mois | Temps passé avec jalons 680 à 920 € / jour | fragmentation des appareils |
Cas pratique — simulation
Tester la cohérence économique du tarif
Les valeurs ci-dessous sont des hypothèses modifiables, pas des statistiques sur les Développeur mobile.
Hypothèses visibles
- Jours facturés par an
- 160
- Jours non facturés
- 60
- Objectif disponible avant IR
- 50 000 €
- Frais annuels simulés
- 6 000 €
- Statut de calcul
- Micro-BNC (hypothèse)
Lecture du scénario
À l’ancre confirmée de 550 €, le chiffre d’affaires simulé atteint 88 000 €. Les cotisations pédagogiques représentent 22 528 € et les frais saisis 6 000 €.
Disponible avant impôt sur le revenu : 59 472 €. Formule du plancher : (objectif + frais) ÷ (1 − taux de charges) ÷ jours facturés.
Congés, prospection, administration, formation et imprévus sont inclus dans les 60 jours non facturés. La CFE et les particularités individuelles restent à ajouter.
Frais professionnels et risques à provisionner
Dépenses propres à l’activité
- Mac et appareils de test
- comptes développeur
- services de test
- assurance RC Pro
Le scénario retient 6 000 € de frais annuels à remplacer par des devis et factures réels de Mac et appareils de test et comptes développeur. Les achats refacturés restent séparés.
Risques à traiter dans le devis
- refus du store
- fragmentation des appareils
- régression sur ancienne version
La demande dépend davantage des budgets produit et des cycles de livraison que des saisons. Les clôtures budgétaires peuvent toutefois accélérer ou différer un démarrage.
Avant le devis : 5 questions qui évitent un faux forfait
- Quel résultat concret doit produire écran natif ou multiplateforme et qui l’accepte ?
- Quelles informations, accès ou matières seront disponibles avant le démarrage ?
- Comment seront traités refus du store et les changements de périmètre ?
- Combien de validations, variantes ou reprises sont incluses ?
- Les frais liés à comptes développeur sont-ils inclus, plafonnés ou refacturés ?
Erreurs de tarification fréquentes
- chiffrer migration d’un module mobile obsolète sans réserver le temps de préparation et de validation
- absorber le coût de Mac et appareils de test dans la marge sans l’annualiser
- accepter fragmentation des appareils sans exclusion, plafond de retours ou procédure d’escalade
- comparer son prix à un salaire sans retirer prospection, administration, formation et congés
Contrôler refus du store avant l’engagement
Le devis doit indiquer comment refus du store sera détecté, documenté et arbitré. Cette précaution protège la production de écran natif ou multiplateforme et évite que le prestataire supporte seul une inconnue fournie par le client.
- preuve attendue pour écran natif ou multiplateforme
- responsable de la décision en cas de refus du store
- limite des reprises liées à fragmentation des appareils
Régie, forfait ou mission longue : choisir le bon risque
Temps passé / régie
adaptée aux produits évolutifs, aux dépendances techniques et aux priorités qui changent. Pour migration d’un module mobile obsolète, le relevé du temps doit isoler préparation, production et traitement de refus du store.
Forfait
pertinent pour un audit ou un lot borné avec critères d’acceptation testables. Le forfait borne écran natif ou multiplateforme, les informations d’entrée et les reprises liées à fragmentation des appareils.
Mission longue
réduit le temps commercial mais doit préserver les revues de tarif et le périmètre de responsabilité. Une mission récurrente doit encore financer Mac et appareils de test et préserver une revue du tarif.
Durée à tester dans le devis : de 2 semaines à 6 mois. Il s’agit d’un ordre de grandeur de scénario et non d’une durée moyenne observée.
Négocier et savoir quand augmenter son TJM
- Relier le tarif à la réduction de refus du store plutôt qu’au seul nombre d’années d’expérience.
- Présenter une option de base centrée sur écran natif ou multiplateforme et une option étendue incluant build signé.
- Séparer honoraires, frais liés à Mac et appareils de test et achats ou droits tiers.
Une hausse devient crédible lorsque les demandes mobilisent Swift ou Kotlin, que le périmètre expose à refus du store ou que le client attend build signé avec davantage d’autonomie.
Différences géographiques
Paris et les grands pôles numériques peuvent soutenir des budgets plus élevés, mais le télétravail élargit la concurrence. La langue de travail, les astreintes et la présence sur site comptent davantage que le seul code postal.
Les pages developpeur web, developpeur logiciel, product designer, devops permettent de comparer des contraintes voisines sans les présenter comme un même marché.
Méthode, sources et limites
Les trois montants sont les repères éditoriaux déjà publiés par TJMCalc. Ils ne proviennent pas d’un échantillon de factures de Développeur mobile. Les actes réglementés, conventions collectives, droits, matières, budgets média ou prix imposés ne sont pas convertis artificiellement en TJM.
- TJMCalc — IGdev — Repères éditoriaux TJMCalcrepères junior, confirmé et senior déjà publiés, simulations dérivées des hypothèses visibles
- Urssaf — Vous souhaitez devenir auto-entrepreneur — barèmes 2026taux micro-social 2026, taux ACRE applicables depuis le 1er juillet 2026, validation des trimestres
- Direction générale des Finances publiques — BOFiP — Barème de l’impôt 2026 sur les revenus 2025tranches 0 %, 11 %, 30 %, 41 % et 45 %, quotient familial
- Urssaf — Mon-entreprise — Simulateur de revenus des auto-entrepreneurs — 2026contrôle de cohérence des simulations micro, limites et avertissements
Responsabilité éditoriale
Contenu maintenu par TJMCalc — IGdev. Dernière revue : .
Validation humaine requise : les repères de marché doivent être confrontés à des devis et données sectorielles réelles.
Signaler une erreur ou proposer une sourceFAQ métier
5 questions propres au tarif d’un Développeur mobile
Que doit couvrir le TJM d’un Développeur mobile ?
Il doit couvrir la production de écran natif ou multiplateforme, mais aussi la préparation, les validations, les outils comme Xcode ou Android Studio, la prospection, l’administration, la formation et les périodes sans mission.
Le forfait est-il adapté à migration d’un module mobile obsolète ?
Oui si le résultat, les informations d’entrée, les retours et le traitement de refus du store sont écrits. Sinon, la régie ou une phase de cadrage facturée protège mieux les deux parties.
Quel signal justifie une hausse de tarif pour ce métier ?
Une demande supérieure à la capacité, une maîtrise reconnue de Swift ou Kotlin, une responsabilité accrue sur build signé ou la prévention démontrée de fragmentation des appareils sont des signaux plus solides qu’une hausse automatique.
Les repères de 350 €, 550 € et 800 € sont-ils des moyennes de Développeur mobile ?
Non. Ce sont des ancres éditoriales conservées pour construire des simulations. Elles doivent être confrontées aux devis réellement gagnés, aux coûts et au marché accessible.
Comment traiter Mac et appareils de test dans le devis ?
Annualisez le coût pour calculer votre plancher, puis indiquez si Mac et appareils de test reste dans les honoraires, fait l’objet d’un forfait de frais ou doit être fourni directement par le client.
Simulation personnalisée
Remplacer les hypothèses par vos chiffres
Avant d’accepter un prix, remplacez le repère par vos jours vendables et le coût de Mac et appareils de test, puis vérifiez que le devis borne refus du store et la remise de build signé. Les résultats restent informatifs et ne constituent pas une simulation comptable exacte.