Si je paie pour l'application, le code est-il à moi ?

Pas forcément, si le contrat ne le dit pas. Payer pour un travail n'implique pas toujours la cession automatique des droits sur le code ; dans de nombreux systèmes juridiques, cela doit être écrit explicitement. C'est pourquoi la clause de cession est essentielle. Assurez-vous toujours, avant de commencer, que le contrat vous transfère la propriété du code après paiement, et pas seulement un droit d'usage.

Que dois-je posséder en plus du code ?

En plus du code source, vous devez posséder le compte Apple Developer, le dépôt où vit le code, ainsi que tous les identifiants et accès. Le code seul, sans le compte Apple ni l'accès au dépôt, vous laisse encore dépendant du prestataire. Le contrôle total signifie posséder l'ensemble du projet, afin qu'aucun fournisseur ne puisse vous couper l'accès à votre propre application.

Comment éviter qu'une agence retienne mon code en otage ?

Fixez la propriété par écrit avant de commencer. Le contrat doit vous transférer les droits sur le code après paiement, et le code doit vivre dans un dépôt que vous contrôlez, avec un compte Apple à votre nom. Ainsi, aucun prestataire ne peut bloquer votre application pour imposer des frais. Un partenaire sérieux accepte cela sans réserve ; celui qui hésite est un signal d'alerte.

Une agence sérieuse me remettra-t-elle tout le code ?

Oui. Un partenaire sérieux vous transfère la pleine propriété du code qu'il a écrit et maintient votre accès au dépôt et au compte Apple en permanence, car il n'a rien à cacher. Retenir le code comme moyen de pression est une pratique à éviter. Posez la question de la propriété avant même de commencer : la réponse vous montrera vite à quel type de partenaire vous avez affaire.

Qui est propriétaire du code source d'une application ?

Q: Qui est propriétaire du code source d'une application ?

Cela dépend du contrat, ce n'est pas automatique. Sans clause explicite de cession des droits d'auteur, le prestataire qui a écrit le code peut en conserver les droits, même si vous l'avez payé. Le contrat doit donc stipuler clairement qu'après paiement, votre entreprise devient propriétaire du code. Ceci est une information générale et non un avis juridique, alors consultez un avocat pour votre cas.

Réponse courte

Savoir qui possède le code source d’une application dépend du contrat, ce n’est pas automatique. Sans clause de cession des droits, le prestataire peut conserver les droits sur le code qu’il a écrit. Vous devez vous assurer que votre entreprise possède le code, le compte Apple et le dépôt, par écrit, avant de commencer. C’est votre meilleure protection contre une agence qui retiendrait votre code en otage. Ceci est une information générale, pas un avis juridique. Si vous cherchez aussi un bon prestataire, voyez notre guide sur combien coûte le développement d’une application.

Qui possède le code par défaut

La première chose qui surprend beaucoup de fondateurs, c’est que payer pour la création d’une application ne signifie pas toujours en posséder le code. L’intuition dit que si vous payez, le code est à vous, mais le droit fonctionne souvent autrement : les droits d’auteur sur le code appartiennent par défaut à celui qui l’a écrit, sauf si le contrat vous les transfère explicitement.

Cela veut dire que sans la clause adéquate, vous pouvez vous retrouver dans une situation étrange : vous avez payé l’application, mais le prestataire conserve les droits sur le code, et vous n’avez qu’un droit de l’utiliser. Ce n’est pas théorique, c’est la source de nombreux problèmes qui arrivent aux entreprises n’ayant pas veillé à ce détail. La bonne nouvelle est que la solution est simple : le contrat doit stipuler clairement qu’après paiement, la propriété du code passe à votre entreprise. C’est une seule clause, mais l’une des plus importantes de tout le projet, et il faut la régler avant que quoi que ce soit ne commence, pas découvrir son absence plus tard. Des organismes comme l’OMPI rappellent que la propriété intellectuelle se gère par le contrat.

Pourquoi vous devez posséder le code

Posséder le code source n’est pas une formalité ni un détail juridique ; c’est le contrôle de votre propre application et de votre avenir. Quand vous possédez le code, vous pouvez faire de l’application ce que vous voulez : la faire évoluer, changer de prestataire, engager quelqu’un d’autre pour la maintenir, ou simplement savoir que votre produit vous appartient vraiment.

Quand vous ne le possédez pas, chacune de ces choses dépend de quelqu’un d’autre. Vous voulez modifier quelque chose ? Vous devez revenir vers ce seul prestataire. Vous voulez en changer parce que la collaboration se passe mal ? Vous pourriez découvrir que vous ne pouvez pas emporter votre propre application. Ce renversement de pouvoir est exactement ce qu’il faut éviter, car il transforme un partenaire en unique issue et vous prive de choix. Posséder le code, développé nativement en Swift, signifie que l’application est un actif de votre entreprise, pas une chose empruntée à un fournisseur qui peut changer d’avis. Pour quiconque prend son application au sérieux, ce contrôle est inestimable.

Ce que posséder votre application comprend

Élément	Pourquoi vous en avez besoin
Le code source	C’est l’application elle-même ; sans lui, vous n’avez rien
Le dépôt	L’endroit où vit le code ; vous devez y avoir accès
Le compte Apple Developer	Votre présence sur l’App Store et l’application
Les identifiants et accès	Tout se connecte à travers eux

La propriété, c’est plus que le seul code, et le tableau montre l’image complète. Le code source seul, sans accès au dépôt où il vit, vous laisse encore dépendant. De même, le compte Apple Developer Program doit être à votre nom, car c’est lui qui détient votre application sur l’App Store ; s’il appartient au prestataire, il contrôle votre présence dans la boutique. La règle est simple : vous devez posséder et contrôler l’ensemble du projet, le code, le dépôt, le compte Apple et tous les accès. Alors seulement vous avez le contrôle total, et aucun fournisseur ne peut vous couper de votre propre application ni la bloquer pour vous imposer quelque chose.

Le problème du code pris en otage

Voici le scénario concret qui amène tant de fondateurs à cette question, et qui arrive plus souvent qu’il ne le devrait. Une entreprise paie une agence pour construire une application, mais le code vit dans le dépôt de l’agence et le compte Apple appartient à l’agence. Tout va bien jusqu’à ce que ça se gâte : un désaccord sur les frais de maintenance, l’envie de changer de prestataire, ou simplement une collaboration qui se détériore. Et soudain, l’entreprise découvre qu’elle ne peut pas emporter son application, parce qu’en réalité elle ne la contrôle pas.

Si vous êtes déjà dans cette situation, une issue formelle existe: App Store Connect prend en charge le transfert d’une application vers votre propre compte, en conservant ses utilisateurs, ses notes et ses avis. Faites-en la demande explicite dans toute négociation de sortie, car une application transférée garde tout ce qu’elle a gagné, contrairement à une application republiée de zéro.

C’est le code pris en otage, et c’est un risque réel dont circulent des histoires. Une agence qui détient votre code et votre compte a un moyen de pression sur vous : vous pourriez vous sentir obligé de payer plus que ce qui est juste, ou de rester avec un fournisseur dont vous vous sépareriez, parce que l’alternative est de perdre l’application. La protection n’est pas d’espérer que cela n’arrive jamais, mais d’éviter cette possibilité même, en possédant le code, le dépôt et le compte dès le départ. Quand c’est vous le propriétaire, personne ne peut prendre votre application en otage, parce qu’elle est simplement à vous, quelle que soit la tournure de la collaboration.

Comment garantir votre propriété, et les signaux d’alerte

La protection contre tout cela est simple, à condition de s’en occuper en amont, avant de commencer. Quelques étapes suffisent : inscrire la cession des droits dans le contrat, garder le code dans un dépôt que vous contrôlez, ouvrir le compte Apple à votre nom, et rassembler tous les accès.

Signal d’alerte	Ce que cela signifie
Réticence à écrire la cession des droits	Il veut peut-être garder le contrôle de votre code
Code uniquement dans le dépôt du prestataire	Vous n’avez pas plein accès à votre application
Compte Apple au nom de l’agence	Elle contrôle votre présence sur la boutique
Réponses évasives sur la propriété	Il évite un sujet qui devrait être clair
Code conditionné à des frais futurs	L’annonce classique du code otage

Le fil conducteur est le même : vous garantissez le contrôle en le fixant par écrit avant que le travail ne commence. Un partenaire sérieux accepte cela sans réserve, car c’est normal pour lui, et inscrit volontiers la propriété au contrat. La façon dont un prestataire réagit à la question de la propriété en dit déjà long, et c’est une question à poser tôt. L’évasion, le flou ou la pression pour signer vite sans clarifier la propriété sont eux-mêmes la réponse, et ce n’est pas celle que vous voulez.

Propriété et maintenance ne sont pas la même chose

Une confusion fréquente mérite d’être dissipée : posséder le code et savoir qui maintient l’application sont deux choses différentes, et l’une n’exclut pas l’autre. Vous pouvez être pleinement propriétaire du code tout en confiant, par choix, sa maintenance à l’agence qui l’a construit, parce qu’elle le connaît le mieux. La propriété ne signifie pas perdre votre partenaire ; elle signifie rester avec lui parce que vous le voulez, non parce que vous y êtes contraint.

C’est là toute la différence entre une relation saine et une relation malsaine. Dans la première, l’agence maintient votre application parce qu’elle le fait bien, et vous restez propriétaire du code et pourriez partir si les choses se gâtaient. Dans la seconde, l’agence maintient votre application parce qu’elle détient le code et que vous n’avez nulle part où aller. Le même service, un rapport de force tout autre. Quand vous possédez le code, les frais de maintenance deviennent un échange équitable que vous jugez à sa valeur, et non une rançon que vous payez par contrainte, ce qui rend d’ailleurs la collaboration meilleure plutôt que pire.

Quand la question est plus complexe

Sachez que ceci est une information générale, pas un avis juridique, et que dans certains cas la question de la propriété est plus complexe. Les applications utilisent souvent des composants éprouvés et des bibliothèques open source ; vous n’en êtes pas propriétaire, mais vous les utilisez sous leur licence, ce qui est normal. Un partenaire sérieux vous dira ce qui est votre code exclusif et ce qui provient de tels composants, afin que vous compreniez précisément ce que vous possédez. Pour un projet important ou complexe, il vaut la peine de faire relire le contrat par un avocat, car les détails du droit d’auteur et de la cession peuvent être subtils et varient selon la juridiction.

Pour la plupart des applications, cependant, la règle est simple et atteignable : vous devez posséder le code écrit pour vous, ainsi que le compte et le dépôt, et un partenaire sérieux vous le garantira volontiers par écrit. Une équipe qui conçoit et construit sous un même toit, comme nous, transfère la pleine propriété du code que nous écrivons et maintient votre accès au dépôt et au compte Apple Developer Program en permanence, car votre application doit vous appartenir. Voyez des exemples dans notre travail et parlez-nous de votre projet, et de la propriété du code, lors d’un court appel.