Recruter un freelance application mobile sans se tromper de profil
Confier son projet à un freelance application mobile est une décision qui engage pour des mois, parfois des années. Une application Android ou multiplateforme se développe, se publie, puis se maintient : le profil choisi au départ pèsera sur la qualité du code, la facilité à faire évoluer le produit et le coût total. Or les erreurs de recrutement se ressemblent souvent : un portfolio flatteur mais invérifiable, une estimation trop belle pour être vraie, un contrat muet sur la propriété du code. Voici une méthode concrète pour réduire ces risques, de la définition du besoin jusqu’à la signature.
Clarifier le besoin avant de chercher un freelance application mobile
Le meilleur entretien du monde ne compense pas un besoin flou. Avant de publier une annonce ou de solliciter des profils, quelques points doivent être tranchés, au moins dans les grandes lignes.
- Les plateformes visées : Android seul, Android et iOS, ou d’abord Android puis iOS plus tard. Ce choix oriente vers un développeur natif Kotlin ou vers un profil multiplateforme.
- Le périmètre fonctionnel : les écrans principaux, les parcours utilisateurs, les fonctions du téléphone sollicitées (caméra, géolocalisation, notifications, paiement).
- L’existant : une application à créer de zéro, une refonte, ou une base de code à reprendre. Reprendre un projet existant demande un profil plus expérimenté.
- Le back-end : une API déjà disponible, un service à construire, ou une solution prête à l’emploi.
- Budget et calendrier : même approximatifs, ils évitent de perdre du temps avec des profils hors de portée.
Ce travail débouche sur un cahier des charges, qui n’a pas besoin d’être exhaustif mais doit être lisible. Il sert de base commune à tous les échanges et permet de comparer les propositions sur des bases identiques.
Le choix technique mérite une attention particulière. Un projet purement Android avec un usage intensif du matériel penche vers le natif ; un projet qui doit sortir rapidement sur les deux systèmes avec une seule équipe peut pencher vers Flutter ou React Native. Le comparatif Flutter ou natif détaille ces arbitrages.
Lire un portfolio : les signaux qui ne trompent pas
Un portfolio de développeur mobile se juge d’abord sur des éléments vérifiables. Les maquettes et captures d’écran sont agréables à regarder, mais elles ne prouvent ni la qualité du code ni la capacité à livrer.
Les applications publiées sont la preuve la plus solide. Il suffit de les installer depuis le Google Play Store pour juger de la fluidité, de la stabilité et du soin apporté à l’interface. La fiche de l’application donne aussi des indices : date de dernière mise à jour, réponses aux avis des utilisateurs, cohérence de la description.
Le rôle exact du candidat sur chaque projet doit être précisé. Une application d’envergure est rarement l’œuvre d’une seule personne : avoir participé à une équipe de dix développeurs n’a pas la même valeur qu’avoir conçu seul une application de bout en bout. Les deux expériences ont leur intérêt, encore faut-il savoir laquelle correspond au besoin.
Le code consultable sur un dépôt public, lorsqu’il existe, en dit long. Même sans être développeur, un client peut demander à un tiers de confiance d’y jeter un œil, ou observer des indices simples : présence de tests, documentation, régularité des contributions, clarté de l’organisation des fichiers.
Les recommandations vérifiables complètent l’ensemble. Un ancien client joignable qui confirme les délais tenus et la qualité de la collaboration vaut mieux que dix témoignages anonymes.
| Signal | Ce qu’il prouve | Comment le vérifier |
|---|---|---|
| Application publiée sur le Play Store | Capacité à livrer un produit fini | Installer et tester l’application |
| Mises à jour régulières | Suivi dans la durée | Date de dernière version sur la fiche |
| Code source public | Qualité et organisation du code | Relecture par un tiers technique |
| Rôle précis décrit | Niveau de responsabilité réel | Questions en entretien, références |
| Références clients joignables | Fiabilité et respect des délais | Appel ou échange écrit avec l’ancien client |
| Connaissance des règles Google Play | Autonomie sur la publication | Questions sur la Play Console et les refus |
Les questions à poser en entretien
L’entretien sert à vérifier trois choses : la compétence technique, la compréhension du besoin et la façon de travailler. Quelques questions ouvertes en disent plus long qu’un questionnaire de culture générale.
Sur la technique, demander au candidat de raconter un problème difficile rencontré sur un projet passé et la manière dont il l’a résolu. Les réponses vagues ou trop théoriques sont un signal faible. Interroger aussi sur ses choix habituels : architecture, gestion des données hors ligne, tests, outils de suivi des plantages. Un développeur Android expérimenté parle naturellement de Kotlin, de Jetpack Compose, de la gestion du cycle de vie et de la publication sur la console Google Play. Pour situer les débats sur le langage, l’article Kotlin ou Java pour Android donne les repères utiles.
Sur le besoin, lui présenter le cahier des charges et écouter ses questions. Un bon profil identifie rapidement les zones floues, les risques et les fonctionnalités coûteuses. Il propose parfois de simplifier une première version pour sortir plus vite. À l’inverse, un candidat qui accepte tout sans poser de questions et annonce un délai très court doit inquiéter.
Sur l’organisation, aborder concrètement :
- la fréquence des points d’avancement et le format des comptes rendus ;
- la livraison de versions intermédiaires testables ;
- la disponibilité réelle (temps plein, temps partiel, autres missions en parallèle) ;
- la gestion des imprévus et des demandes hors périmètre ;
- la suite après la mise en ligne, notamment la maintenance.
Le petit test rémunéré : un investissement plutôt qu’une dépense
Quand l’enjeu est important ou que deux profils semblent équivalents, un test rémunéré court permet de trancher sur des faits. Il s’agit de confier une tâche réelle et limitée, quelques jours tout au plus : un écran, un module isolé, la correction d’un bug identifié sur l’existant.
Rémunérer ce travail est une question de respect et d’efficacité. Les profils les plus demandés refusent souvent les exercices gratuits, et un test payé est traité avec le même sérieux qu’une vraie mission. Le coût reste modeste au regard du risque d’un mauvais recrutement sur un projet de plusieurs mois.
Le test révèle des éléments impossibles à percevoir en entretien : la qualité réelle du code livré, le respect du délai annoncé, la clarté des explications, la façon de poser des questions quand une consigne est ambiguë. Faire relire le résultat par une personne technique indépendante, si le client n’en a pas en interne, rend l’exercice beaucoup plus probant.
Le contrat : propriété du code et livraison des sources
C’est la partie la plus souvent négligée, et celle qui provoque les conflits les plus coûteux. En droit français, un développeur indépendant reste en principe titulaire des droits d’auteur sur le logiciel qu’il crée, sauf cession expresse prévue au contrat. La situation diffère de celle d’un salarié, dont les droits sur les logiciels créés dans l’exercice de ses fonctions sont dévolus à l’employeur. D’où l’importance d’une clause de cession rédigée avec soin, idéalement relue par un juriste.
Plusieurs points doivent figurer noir sur blanc :
- la cession des droits sur le code produit, avec son étendue (droits cédés, durée, territoire) et le moment où elle intervient, souvent au paiement complet ;
- la livraison des sources : dépôt de code complet, historique, documentation, scripts de compilation, et pas seulement le fichier de l’application ;
- l’accès aux comptes : l’application doit être publiée sur le compte développeur Google Play du client, jamais sur celui du prestataire, et les clés de signature doivent être sous le contrôle du client ;
- les composants tiers : bibliothèques open source, licences et éventuels services payants utilisés ;
- la garantie et la maintenance : durée pendant laquelle les bugs sont corrigés sans surcoût, et conditions d’une maintenance au-delà.
Le point des comptes est capital. Une application publiée sous le compte d’un développeur qui disparaît devient très difficile à récupérer. Mieux vaut créer soi-même le compte développeur Google Play et y inviter le prestataire avec les droits nécessaires. L’article sur la façon de publier une application sur le Play Store explique comment fonctionne cette console.
Comparer les propositions sur des bases équivalentes
À l’issue de ces étapes, il reste souvent deux ou trois candidats. La comparaison ne doit pas se limiter au prix. Un taux journalier élevé associé à une estimation réaliste coûte parfois moins cher, au final, qu’un taux bas assorti d’un délai irréaliste qui finira par déraper. Les fourchettes de marché présentées dans l’article sur le TJM d’un développeur mobile aident à repérer une offre anormalement basse ou haute.
Les critères à pondérer sont la pertinence de l’expérience pour le projet, la qualité démontrée lors du test, la clarté de la proposition, la disponibilité et la vision de la suite. Un freelance qui évoque spontanément les tests, la maintenance et les mises à jour imposées par les évolutions d’Android montre qu’il pense au-delà de la livraison. Il est aussi utile de demander à chaque candidat comment il découperait le projet en étapes livrables : la réponse révèle sa compréhension du besoin, sa méthode et sa capacité à hiérarchiser ce qui doit sortir en premier.
Recruter un freelance pour une application mobile n’a rien d’un pari si l’on procède par étapes : besoin clarifié, portfolio vérifié, entretien centré sur le concret, test rémunéré et contrat qui protège le code. Le temps passé à ces vérifications est presque toujours inférieur au temps perdu à rattraper un mauvais choix.