Développeur d’application mobile, agence ou no-code : comment choisir ?

1. Développeur, agence ou no-code : la réponse courte

Choisis une agence ou un studio si tu veux un seul interlocuteur responsable de tout, du design jusqu’à l’envoi à Apple. Choisis un développeur freelance si tu as le temps de piloter le projet toi-même, et un outil no-code si ton app reste simple et que tu acceptes de la construire. Dans tous les cas, garde à ton nom le compte développeur Apple, la fiche App Store et l’accès au code ou au projet.

Aucune option n’est la meilleure pour tout le monde : tout dépend du temps que tu peux y consacrer, de la complexité de l’app (comptes, paiement, données, IA) et de qui s’en occupera après la publication. Pour la vue d’ensemble, lis notre guide pour créer une application mobile, de l’idée à l’App Store.

2. Les cinq façons de faire construire ton app

Derrière « trouver quelqu’un pour faire mon app », il y a cinq organisations, parfois combinées : un freelance peut utiliser un outil no-code, une agence peut s’appuyer sur l’IA.

• Une agence ou un studio. Une entreprise de création d’application mobile réunit cadrage, design, développement, tests et publication, avec un interlocuteur et un contrat. Un studio est souvent plus petit et plus spécialisé, par exemple sur l’iPhone.
• Un développeur freelance. Une personne indépendante, spécialisée sur iOS, sur Android ou sur une technologie qui sert les deux. Le design, la fiche App Store ou les tests peuvent rester à ta charge.
• Un outil no-code que tu utilises toi-même. Tu assembles l’app avec des blocs visuels, sans écrire de code. L’outil fournit la technique et souvent la publication ; tu dépends de ses offres et de ses limites.
• Un associé technique ou une équipe interne. Un associé qui code reçoit une part de la société ; un salarié, un salaire. La compétence reste dans l’entreprise, mais il faut trouver la bonne personne.
• Les outils d’IA. Ils produisent des écrans ou du code à partir de consignes. Xcode, le logiciel de développement d’Apple, fonctionne par exemple avec les modèles d’Anthropic, de Google ou d’OpenAI (page Xcode d’Apple, octobre 2026). Quelqu’un doit quand même décider quoi construire, relire, tester et publier : vois notre guide pour créer une application avec l’IA.

3. Le comparatif : qui fait quoi et ce qui reste à ta charge

Ce tableau décrit des situations typiques : un prestataire précis peut faire plus ou moins, et c’est son devis qui fait foi.

Pars de ta contrainte la plus forte. Peu de temps : une équipe qui prend tout en charge te soulage. Budget serré et app simple : le no-code ou un freelance sont des pistes sérieuses. App au cœur de ton entreprise, qui évolue chaque mois : un associé ou une équipe interne mérite d’être étudié. Pour la technologie, vois notre comparatif application native, hybride ou web.

4. Ce qu’il faut vérifier chez une agence ou un freelance

Des apps publiées que tu peux télécharger

Demande des liens vers l’App Store, pas seulement des visuels. Télécharge deux ou trois apps, utilise-les et regarde la date de leur dernière mise à jour. Une maquette montre un talent de design ; une app publiée montre un projet mené jusqu’à la validation d’Apple.

Sur la fiche App Store, le champ « Fournisseur » indique le compte qui a publié l’app : pour l’app d’un client, c’est normalement le nom du client. Demande donc ce que le prestataire a fait : design, code, publication, ou une partie seulement.

Qui dessine et qui code

Demande qui fera le design, qui écrira le code et qui sera ton interlocuteur. Une partie du travail peut être sous-traitée : ce n’est pas un problème si tu le sais et si le contrat la couvre. Avec un freelance, demande qui s’occupe du design et des tests.

Des livrables à chaque étape

Un bon découpage te permet de vérifier avant de payer la suite : cadrage, écrans, version installée sur ton téléphone, soumission au store. TestFlight, l’outil de test d’Apple, sert à installer une version avant sa publication. Méfie-toi d’un projet où tu ne vois rien de concret avant la fin.

Chez Yodavio, par exemple, chaque étape de notre méthode de développement en 4 étapes a son livrable : le brief et la liste des écrans ; tous les écrans dessinés sur Figma, validés avant la première ligne de code ; l’app construite à l’identique et testée sur ton téléphone ; la fiche de l’app, les tests et la soumission à Apple ou à Google Play, prévue au jour 21. La validation dépend ensuite d’Apple. Le studio crée des applications iPhone et Android : le détail est sur la page de notre offre de création d’applications mobiles.

Les réalisations du studio donnent des faits vérifiables : BOOXS, AudiCheck, FixScan, Klaps et Talkana ont chacune leur fiche App Store et leur date de sortie. Ce sont des projets du studio, pas des missions de clients. Demande la même précision à chaque prestataire : un lien vers l’app publiée, ou une version à installer sur ton téléphone.

La maintenance et les mises à jour d’iOS

Une app publiée n’est jamais terminée : Apple fait évoluer iOS et ses outils chaque année. Depuis le 28 avril 2026, toute app envoyée sur App Store Connect doit être compilée avec Xcode 26 ou plus récent et le SDK d’iOS 26 (exigences publiées par Apple, vérifiées en octobre 2026). Même pour corriger une faute de frappe, il faut donc un projet à jour.

Demande qui fera ces mises à jour, dans quel délai et à quelles conditions (corrections, compatibilité avec la nouvelle version d’iOS, nouvelles fonctions), puis fais-le écrire dans le devis.

5. Comptes, code et contrat : ce qui doit rester à ton nom

Le compte développeur Apple

Pour publier sur l’App Store, il faut un compte Apple Developer. Apple l’annonce à 99 USD par année d’adhésion, un prix qui peut varier selon la région (conditions d’inscription d’Apple, octobre 2026). En compte individuel, ton nom apparaît comme vendeur sur l’App Store ; en compte d’organisation, c’est celui de ta société, qui doit être une entité juridique avec un numéro D-U-N-S.

Ce compte devrait être à ton nom, ou à celui de ta société, dès le départ. Seul son titulaire, l’« Account Holder », peut signer les accords juridiques avec Apple et renouveler l’adhésion. Les règles de validation de l’App Store vont dans le même sens : une app devrait être soumise par la personne ou l’entité qui en détient les droits (règle 5.2.1) et, dans les domaines très réglementés comme la santé ou la finance, par l’entité qui fournit le service (règle 5.1.1 ix).

Donner accès au prestataire sans lui confier tes clés

Inutile de partager ton mot de passe. Dans App Store Connect, le titulaire, un Admin ou un App Manager invite d’autres personnes avec un rôle : App Manager gère tous les aspects d’une app, Developer son développement et sa livraison. Pour ces rôles, l’accès peut être limité aux seules apps concernées, si tu ne leur ouvres pas les rapports (aide Apple sur l’ajout d’utilisateurs).

Si l’app est déjà sur le compte du prestataire

Apple prévoit un transfert d’app entre comptes : le titulaire du compte qui cède l’app le lance, celui du compte qui la reçoit l’accepte. L’app doit avoir au moins une version publiée sur l’App Store, et elle garde ses notes et ses avis (présentation du transfert et critères à remplir). Avant la première publication, c’est donc impossible : crée ton compte avant le développement. Google Play permet aussi de transférer une app vers un autre compte développeur.

Le code source, les fichiers de design et les droits

Payer une app ne suffit pas à en posséder le code. Bpifrance Création le rappelle : pour un logiciel commandé à un prestataire extérieur, « le donneur d’ordre ne devient pas automatiquement titulaire des droits ». Il faut un contrat de cession, en annexe ou en clause du contrat de développement (fiche publiée en juin 2026). Demande aussi l’accès au dépôt du code pendant le projet et les fichiers Figma à la fin. Si l’enjeu est important, fais relire la clause par un juriste.

Avec le no-code, vérifie si le projet est exportable : cela dépend de l’outil et de l’offre. Chez FlutterFlow, par exemple, le téléchargement du code et la publication sur l’App Store font partie des offres payantes, pas de l’offre gratuite (page des tarifs, octobre 2026). Bubble et Adalo précisent que tu publies avec tes propres comptes Apple et Google.

Le contrat et le devis

Un devis détaillé liste les écrans et fonctions inclus, les livrables par étape, ce que tu fournis, les exclusions, le calendrier et l’échéancier, en séparant la production du délai de validation d’Apple. Le contrat précise la cession des droits, la remise du code et des accès, la confidentialité et la maintenance. Pour comparer des devis sur la même base, sers-toi de notre guide sur le prix d’une application mobile, poste par poste.

6. Les signaux d’alerte avant de signer

Aucun de ces signaux ne prouve à lui seul une mauvaise intention. Chacun justifie une question de plus, et une réponse écrite.

• Aucune app publiée à montrer, seulement des maquettes, sans explication sur ce qui a été livré.
• La proposition de publier l’app sur le compte du prestataire « pour aller plus vite », sans plan pour te la transférer.
• Un devis d’une ligne, du type « application complète », sans liste d’écrans ni de livrables.
• Une date de validation par Apple garantie. C’est Apple qui décide, selon sa procédure d’App Review.
• Le paiement de la totalité avant le moindre livrable.
• Le flou sur la personne qui code, ou sur la propriété du code et des fichiers.
• Un outil no-code choisi sans savoir si le projet pourra en sortir un jour.
• Une technologie imposée sans explication liée à ton projet.

7. Dix questions à poser au premier appel

Prépare un court brief avant l’appel (public, action principale, écrans indispensables, date, enveloppe) avec notre modèle de cahier des charges d’application mobile. Pose ensuite ces questions à chaque prestataire, dans le même ordre.

1. Quelles apps avez-vous publiées, que puis-je télécharger aujourd’hui, et qu’avez-vous fait sur chacune ?
2. Qui fera le design, qui écrira le code, et qui sera mon interlocuteur ?
3. Quel livrable vais-je recevoir à chaque étape, et quand pourrai-je tester l’app sur mon téléphone ?
4. Quelle technologie proposez-vous pour mon projet, et pourquoi celle-là ?
5. Le compte développeur Apple et la fiche App Store seront-ils à mon nom ? Comment accéderez-vous à mon compte ?
6. Aurai-je accès au code pendant le projet ? Le contrat prévoit-il la cession des droits sur le code et le design ?
7. Que comprend exactement le devis, et qu’est-ce qui en est exclu ?
8. Comment gérez-vous une demande de changement en cours de route ?
9. Qui s’occupe d’un éventuel refus d’Apple, des corrections après la publication et des mises à jour d’iOS, et à quelles conditions ?
10. Quels services faudra-t-il payer chaque mois (hébergement, API, IA), et à quel nom seront ces comptes ?

Note les réponses par écrit. Un prestataire sérieux accepte de les reprendre dans son devis.

8. Où trouver une agence ou un développeur freelance

Plusieurs canaux existent, cités ici sans ordre de préférence.

• Les plateformes de freelances, comme Malt, Codeur.com ou Upwork, où tu publies ton projet ou contactes des profils.
• Les annuaires d’agences de développement d’application mobile, comme La Fabrique du Net, Sortlist ou Clutch. Certaines places y sont payées : l’annuaire Clutch marque par exemple des fiches « Sponsored » et indique pouvoir être rémunéré pour certains placements (octobre 2026). Le rang ne dit donc rien de la qualité.
• L’App Store lui-même : repère des apps proches de ce que tu veux, puis cherche qui les a conçues, sur le site de l’éditeur ou en lui écrivant.
• Le bouche-à-oreille : des entrepreneurs qui ont déjà fait construire une app, un incubateur, une communauté de développeurs locale. C’est aussi là que l’on rencontre souvent un associé technique.

Contacte ensuite deux ou trois prestataires avec le même brief et compare leurs réponses aux dix questions : ce qui sera livré d’abord, le prix ensuite.

9. Questions fréquentes

Faut-il choisir un développeur, une agence ou un associé ?

La question revient sur les forums, par exemple sur r/developpeurs. Un associé partage le risque sur la durée, contre une part de ta société ; une agence prend tout en charge contre une facture ; un développeur seul te laisse piloter le reste. Décide d’abord si tu cherches un prestataire pour un projet ou un partenaire pour une entreprise.

Mon développeur a publié l’app sur son compte Apple : puis-je la récupérer ?

Ce cas réel est discuté sur les forums développeurs d’Apple : une app créée pour une cliente sur le compte personnel du développeur ne pouvait pas être transférée, faute de version publiée. Un ingénieur d’Apple y explique comment recréer l’identifiant de l’app dans le compte de la cliente, sans pouvoir déplacer les certificats. Après une première publication, le transfert suit les critères d’Apple.

Un client qui a payé l’application peut-il exiger le code source ?

La question a été posée, côté développeur, sur le forum Droit de CommentCaMarche. Tout dépend du contrat. Sans cession prévue, le client ne devient pas automatiquement titulaire des droits sur le code. Écris dans le contrat ce qui te sera remis : code, fichiers de design et accès.

Peut-on récupérer le code d’une app depuis l’App Store ?

Non. Sur les forums d’Apple, un développeur qui avait perdu son code et ses sauvegardes s’est vu répondre qu’il faudrait reconstruire l’app : l’App Store distribue l’app, pas ses fichiers sources. Garde ton propre accès au dépôt du code.

J’ai commencé mon app avec une IA : un professionnel peut-il la reprendre ?

Des demandes de ce type existent, comme cette annonce publiée sur Codeur.com en juin 2026 pour finaliser des projets commencés avec Codex. C’est possible, mais le prestataire examinera d’abord l’existant pour décider s’il continue ou repart de tes écrans. Donne-lui le code, les consignes utilisées et les accès.

Peut-on créer une application mobile sans coder et la publier sur l’App Store ?

Oui, plusieurs outils no-code publient des apps natives avec ton propre compte développeur. Les règles d’Apple s’appliquent comme ailleurs : une app issue d’un modèle ou d’un service de génération doit être soumise par le fournisseur de son contenu, c’est-à-dire toi, et non par l’outil au nom de ses clients (règle 4.2.6).