Sommaire
  1. Le piège silencieux du fondateur non technique
  2. 3 histoires vraies qui se finissent mal
  3. Les 6 clauses à exiger dans le contrat
  4. Comptes Apple et Google : qui en est propriétaire
  5. À quoi ressemble une vraie livraison clé en main

Vous payez 8 000€, 25 000€ ou 80 000€ pour faire développer votre application mobile. Six mois plus tard, l'app tourne, elle est publiée, des utilisateurs l'utilisent. Vous voulez ajouter une fonctionnalité, ou changer de prestataire pour passer à autre chose. Vous demandez le code source. Et là, surprise : « Le code est sur notre repository privé. Il faudra signer un avenant pour le récupérer. »

Cette situation est plus fréquente qu'on ne l'imagine. Pas par malveillance des prestataires — par flou contractuel. Quand le contrat n'a pas explicitement réglé la question de la propriété intellectuelle, du code source, des comptes stores et des accès, le prestataire conserve par défaut une partie des actifs. Et vous vous retrouvez dépendant, parfois sans le savoir.

Voici les 6 clauses qu'il faut absolument lire (ou faire ajouter) dans tout contrat de développement d'application mobile. Que vous travailliez avec un freelance, une agence ou un studio, ces points sont non négociables. C'est votre app. C'est votre business. Vous devez en avoir le contrôle complet.

Le piège silencieux du fondateur non technique

Quand on n'est pas développeur, on a tendance à se concentrer sur ce qu'on voit : les écrans, les fonctionnalités, le design. Tout ce qui est « derrière » — le repository de code, les comptes Apple Developer, les certificats de signature, les variables d'environnement, l'infrastructure backend — reste opaque. Et c'est exactement là que les pièges se logent.

La logique du piège est simple : tant que l'app fonctionne, vous ne posez pas de questions. Le jour où vous voulez quelque chose (changer de dev, ajouter une fonctionnalité urgente, vendre votre entreprise, transférer l'app à un investisseur), vous découvrez que le prestataire détient des éléments critiques. Vous n'êtes pas piégé par malveillance. Vous êtes piégé par asymétrie d'information.

Selon une recommandation de la CNIL et l'article L113-9 du Code de la propriété intellectuelle, en France, sans clause explicite de cession dans le contrat, c'est l'auteur du code (donc votre prestataire) qui en conserve les droits patrimoniaux. Payer le développement ne suffit pas légalement. Il faut une cession écrite, datée, exhaustive.

3 histoires vraies qui se finissent mal

Voici trois cas que j'ai vu se produire chez des fondateurs venus me voir pour reprendre leur projet. J'ai changé les noms et les détails, mais les situations sont réelles.

Cas n°1 : l'app publiée au nom du freelance

Un fondateur me contacte parce que son app, publiée sur l'App Store depuis 8 mois, génère du chiffre d'affaires. Il veut la vendre à un fonds. Premier problème : sur la fiche App Store, le nom de l'éditeur n'est pas le sien. C'est celui du freelance qui a développé l'app, parce qu'il avait « déjà un compte Apple Developer et que ça allait plus vite ». Pour transférer l'app à l'acheteur, il faut le consentement du freelance. Le freelance demande 15% du montant de la vente pour signer le transfert. Le deal capote.

Cas n°2 : le repository privé que personne ne donne

Une agence livre une app à 45 000€ à une startup. Le code tourne, l'app est en ligne. La startup veut ajouter une fonctionnalité 6 mois plus tard mais l'agence est devenue trop chère. Elle change de prestataire. Le nouveau dev demande l'accès au repository GitHub. L'agence répond qu'elle accorde un accès en lecture seule pour 2 500€. Pas de cession définitive sans avenant. Et l'avenant coûte 8 000€. La startup paie. Elle n'a juridiquement pas le choix : sa cession initiale ne couvre pas la transmission du repo.

Cas n°3 : les certificats Apple perdus

Un fondateur veut publier une mise à jour 14 mois après le lancement. Le freelance qui a publié la première version a disparu : changement de société, plus de mail, plus de réponse. Les certificats de signature iOS étaient sur sa machine, jamais transmis. Pour signer une nouvelle version, il faut révoquer l'ancien certificat (ce qui peut bloquer temporairement l'app pour les utilisateurs existants), créer de nouveaux profils, et republier en attendant la review. 6 semaines de blocage, dans une période où la concurrence avait déjà sorti une fonctionnalité similaire.

Ces trois cas ont un point commun : ils étaient évitables avec quelques clauses contractuelles claires et une livraison structurée. Voici la liste exacte de ce qu'il faut exiger.

Vous avez un doute sur ce que vous possédez vraiment ?

30 minutes pour passer en revue votre contrat actuel, ce que vous détenez, ce qui manque, et ce qu'il faut récupérer avant qu'il ne soit trop tard. Diagnostic clair, sans engagement.

Réserver mon appel

Les 6 clauses à exiger dans le contrat de développement de votre app mobile

Clause 1 : cession exclusive et irrévocable des droits patrimoniaux

Le contrat doit explicitement indiquer que le prestataire vous cède, à titre exclusif et irrévocable, l'intégralité des droits patrimoniaux sur le code source, les designs, les assets graphiques, les algorithmes spécifiques, et tout livrable du projet. La cession doit couvrir : reproduction, représentation, adaptation, modification, traduction, distribution. Pour le monde entier. Pour la durée légale maximale (vie de l'auteur + 70 ans en France).

Cette clause doit lister précisément les éléments cédés. Une formulation vague (« le prestataire cède le résultat des prestations ») laisse la place à interprétation. Une formulation précise (« code source iOS, code source Android, code backend, fichiers Figma, certificats, documentation technique, scripts de déploiement ») ne laisse pas de marge.

Clause 2 : livraison effective du code source en fin de projet

Avoir les droits, c'est bien. Avoir le code, c'est mieux. La clause doit prévoir une livraison technique formelle : transfert du repository sous votre contrôle (GitHub, GitLab ou Bitbucket à votre nom), accès admin à votre nom, suppression des accès du prestataire à votre demande. Idéalement, cette livraison conditionne le paiement du dernier jalon. Pas de livraison technique = pas de solde versé.

Clause 3 : documentation technique minimale

Le code seul ne suffit pas. Il faut un README technique qui explique comment lancer le projet en local, où sont les clés et secrets, quelles sont les dépendances tierces, comment se passe le déploiement, et quelles sont les variables d'environnement. Sans ça, votre nouveau dev passera 3 à 5 jours à reconstruire le contexte. Vous payez ces 3 à 5 jours.

Clause 4 : transfert des comptes stores et tiers

Apple Developer, Google Play Console, Firebase, services backend (Supabase, Vercel, AWS), services tiers (Stripe, OneSignal, Mailjet) : tous ces comptes doivent être à votre nom ou transférés à votre nom à la livraison. La clause doit prévoir : (a) la création initiale au bon nom, ou (b) le transfert formel à votre nom au moment de la livraison, avec mots de passe transmis et 2FA basculé sur vos appareils.

Clause 5 : aucune dépendance à des outils propriétaires du prestataire

Certains prestataires utilisent des frameworks maison, des SDK propriétaires, des outils internes qui ne sont pas livrés avec le code. Le jour où vous changez de dev, plus rien ne fonctionne en local. La clause doit interdire ce type de dépendance, ou exiger qu'elle soit explicitement listée et licenciée à votre nom (avec un coût marginal et transparent, pas un abonnement à 500€/mois pour conserver l'accès).

Clause 6 : période de garantie et de support post-livraison

La livraison ne s'arrête pas le jour de la signature finale. Sur tout projet sérieux, il faut une période de garantie de 30 à 60 jours minimum pendant laquelle le prestataire corrige gratuitement tout bug imputable à son code. Ce n'est pas une faveur : c'est le standard. Cette période est aussi celle où vous découvrez les bugs en production que les tests internes n'avaient pas attrapés. Sur les projets ZUHD, j'offre 2 mois de maintenance MVP Care pour cette raison précise — un MVP qui sort en prod sans filet est un MVP qui crash en prod.

Comptes Apple et Google : qui en est propriétaire (et pourquoi c'est non négociable)

C'est le point le plus souvent négligé. Une app publiée sur les stores est rattachée à un compte développeur. Ce compte a un propriétaire légal. Si ce propriétaire n'est pas vous, vous ne contrôlez pas l'app.

Apple Developer Program (99€/an)

Vous avez deux options : compte Individual (à votre nom personnel) ou compte Organization (au nom de votre entreprise, exige un D-U-N-S Number). Pour une app de business, choisissez Organization. C'est légèrement plus long à créer (10 à 15 jours pour obtenir le D-U-N-S et la validation Apple), mais c'est ce qui sécurise la propriété au nom de la société, pas d'une personne physique.

Apple permet le transfert d'app entre comptes développeurs, mais avec des conditions strictes : pas d'in-app purchase actif, pas de version bêta en cours, certificats à régénérer côté nouveau compte. Le transfert prend 1 à 2 semaines. À planifier avant de signer un deal de revente.

Google Play Console (25€une seule fois, à vie)

Même logique : compte Personnel ou Compte d'Organisation. Pour un business, organisation. Le compte doit être à votre nom dès le début. Google permet aussi le transfert d'app, avec des conditions similaires. Anticipez.

Le bon réflexe : créer les comptes en J0, pas en J60

Sur chaque projet ZUHD, je crée (ou j'aide à créer) les comptes Apple et Google au nom du client dès la première semaine. Pas à la fin. Pourquoi ? Parce que la validation D-U-N-S et l'enrôlement Apple peuvent prendre 2 semaines. Si vous attendez la fin du projet pour créer les comptes, vous découvrez le délai au pire moment et la publication est repoussée d'autant.

Cette discipline est rattachée au process de validation continue que j'applique sur chaque projet : on ne se réveille pas en J55 pour s'occuper de l'administratif. Tout est fait en parallèle du dev, par briques anticipées.

Sécurisez votre projet avant de signer un devis

30 minutes pour passer votre contrat (ou votre future signature) au crible des 6 clauses essentielles, plus la check des comptes stores. Si une clause manque, on l'identifie ensemble.

Réserver mon appel

À quoi ressemble une vraie livraison clé en main

Pour vous donner un repère concret, voici tout ce que je remets à un client le jour de la livraison finale d'un MVP ZUHD. Cette liste n'est pas exhaustive, mais elle couvre 95% des actifs critiques.

Côté code et documentation

Côté comptes et accès

Côté assets stores

Côté contractuel

Quand cette liste est complète, vous êtes propriétaire à 100% de votre app. Vous pouvez changer de prestataire demain matin, vendre votre entreprise après-demain, ou simplement dormir tranquille en sachant que personne ne peut vous bloquer. C'est la définition de la livraison clé en main — et c'est ce que devrait être le standard du marché.

Une dernière vérification avant de signer

Si vous êtes sur le point de signer un devis avec un freelance, une agence ou un autre studio, prenez 10 minutes pour faire ce test simple. Demandez explicitement, par écrit (mail), la confirmation des 6 points suivants :

  1. Le contrat prévoit-il une cession exclusive et irrévocable de tous les droits patrimoniaux sur le code, le design et les livrables ?
  2. Le repository de code sera-t-il transféré à mon nom (organisation ou personne) à la livraison ?
  3. Une documentation technique me sera-t-elle remise (README, architecture, secrets) ?
  4. Les comptes Apple Developer et Google Play seront-ils à mon nom dès le départ ou transférés en fin de projet ?
  5. Y a-t-il des dépendances à des outils propriétaires de votre studio que je dois connaître ?
  6. Quelle est la période de garantie post-livraison incluse, et qu'est-ce qu'elle couvre ?

Si la réponse à l'une des questions est ambiguë, vous savez où renégocier. Si plusieurs réponses sont vagues ou esquivées, changez de prestataire. Pour comparer les modèles freelance, agence et studio sur d'autres critères (qualité, risque, délai), j'ai écrit un comparatif honnête ici.

Votre app est un actif. Un actif que vous avez payé, qui va générer du chiffre d'affaires, et que vous transmettrez peut-être un jour. Sa propriété complète n'est pas une option de luxe. C'est la base.

Vous voulez un projet d'app où vous êtes propriétaire de tout, dès J0 ?

30 minutes pour regarder votre projet ensemble, vous expliquer comment ZUHD structure la propriété et la livraison clé en main, et vous donner un devis si pertinent. Sans engagement.

Réserver mon appel