Comment protéger l’idée d’une app : ce qui marche et ce qui est du théâtre

Le guide du fondateur non technique sur les trois choses qui protègent vraiment l'idée d'un logiciel, et pourquoi le brevet que tout le monde évoque n'en fait presque jamais partie.

Une fondatrice que nous appellerons Renata a fait signer un NDA de deux pages à trois prestataires avant même de décrire son app, un outil de réservation pour salons de tatouage. Ce qu’elle n’a jamais fait, c’est lire le contrat signé avec le studio qui a réellement livré le produit. Ce contrat ne disait rien sur le propriétaire du code. Un an plus tard la relation a tourné, le studio a gardé le dépôt, et Renata avait soigneusement protégé la seule chose qu’elle ne risquait jamais de perdre.

C’est le schéma classique, et c’est pourquoi presque tous les conseils sur comment protéger l’idée d’une app visent la mauvaise cible. Vous ne pouvez pas protéger l’idée d’une app comme vous l’imaginez : une idée, à elle seule, ne peut être ni protégée par le droit d’auteur ni brevetée. Ce que la loi protège, c’est le travail que l’idée produit, à savoir le code, la marque et le design précis. En pratique, trois choses protègent l’idée d’un logiciel, dans l’ordre qui compte vraiment. La vitesse et la qualité avec lesquelles vous exécutez. Un contrat qui vous transfère la propriété de tout ce qui est construit. Et, seulement dans des cas restreints, un NDA ou un brevet. La plupart des fondateurs inversent cet ordre : ils gardent le concept et oublient de sécuriser la propriété du code qu’ils ont payé pour construire.

L’idée n’est pas l’actif

Voici la partie qui pique. L’idée de votre app vaut moins que vous ne le pensez, et c’est une bonne nouvelle.

Presque tout produit à succès que vous pouvez citer était une idée évidente que d’autres ont eue aussi. Le transport via app, la livraison de repas, la gestion de projet pour les équipes d’ingénierie, la comptabilité pour indépendants. Des dizaines d’équipes ont couru après chacune. Les gagnants n’ont pas gagné parce que l’idée était secrète. Ils ont gagné parce qu’ils ont bien construit, appris plus vite que les autres et continué à livrer après que les autres se soient lassés ou aient manqué d’argent. Paul Graham défend ce point depuis vingt ans : l’idée n’est pas la partie difficile, et la traiter comme précieuse trahit un fondateur qui a encore peu construit.

Pour un fondateur non technique, c’est libérateur, pas effrayant. Cela veut dire que l’actif que vous cherchez à protéger n’est pas la phrase que vous prononcez au café. Ce sont les mois de décisions, le produit qui tourne, les clients qui lui font confiance et le code qui tourne en dessous. Rien de tout cela ne peut être emporté par quelqu’un qui entend votre pitch. Et tout cela peut être perdu si vous ne structurez pas le build correctement.

Donc la vraie question n’est pas « comment empêcher qu’on me vole mon idée ». C’est « comment m’assurer d’être propriétaire et de garder le contrôle de ce que je paie pour créer ». Ce sont deux problèmes différents, et un seul empêche les fondateurs de dormir pour les bonnes raisons.

Le vrai risque : ne pas posséder ce que vous avez payé pour construire

Dans la plupart des pays, celui qui écrit le code en détient le droit d’auteur par défaut, sauf si un contrat dit le contraire. Relisez, parce que cela prend les fondateurs au dépourvu en permanence. Si vous engagez un freelance ou un studio et que votre accord ne vous cède pas explicitement la propriété intellectuelle, le développeur peut être, légalement, le propriétaire du logiciel que vous avez commandé. Vous l’avez payé. Vous pouvez l’utiliser. Mais vous n’en êtes peut-être pas propriétaire, et vous n’êtes peut-être pas libre de l’emporter ailleurs.

C’est la défaillance qui arrive vraiment, bien plus souvent que le vol d’idée. Nous avons vu des fondateurs découvrir, en pleine levée, que le code n’avait jamais été cédé à la société. L’avocat de l’investisseur réclame les documents de cession de PI pendant la due diligence, et ils n’existent pas. L’opération se bloque pendant que tout le monde court après un ancien prestataire à São Paulo ou à Lisbonne pour qu’il signe un document qu’il n’a aucun intérêt à signer vite.

Le correctif est sans éclat et quasi gratuit. Votre contrat de build doit contenir une clause claire de cession de propriété intellectuelle qui transfère la propriété de tout le code, des designs et des actifs à votre société, à la création ou au paiement. Elle doit couvrir tous ceux qui touchent au projet, y compris les sous-traitants. Nous détaillons ce que ce contrat doit contenir dans notre guide sur le contrat de développement logiciel, et c’est la page de protection juridique la plus précieuse qu’un fondateur signera de sa vie. Rien de tout cela n’est un conseil juridique ; pour ce qui compte vraiment, faites relire le texte par un avocat en PI. Mais sachez réclamer la clause dès le départ, car aucun NDA ne vous sauvera si vous sautez cette étape.

Ce que vous pouvez et ne pouvez pas protéger légalement

Il est utile de séparer l’idée de son expression, parce que la loi le fait.

L’idée elle-même (« une app qui fait X pour Y ») n’est pas protégeable. N’importe qui peut construire une app qui fait la même chose, et la plupart de vos futurs concurrents le feront.

Le code est protégé par le droit d’auteur à l’instant où il est écrit. Cette protection est automatique, et c’est précisément pourquoi la clause de cession compte : le droit d’auteur appartient à l’auteur jusqu’à ce qu’il soit transféré.

Le nom, le logo et la marque peuvent être protégés par une marque déposée, généralement le dépôt le plus utile que fera une app à ses débuts et bien moins cher qu’un brevet.

La manière précise dont vous avez résolu un problème technique véritablement nouveau peut, dans de rares cas, être protégée par un brevet. La plupart des apps n’y sont pas éligibles, et nous y venons.

Donc quand on demande s’il est possible de protéger légalement une idée sans brevet, la réponse honnête est oui, presque entièrement, par les contrats, le dépôt de marque et une bonne hygiène opérationnelle. La question du brevet est souvent une distraction face aux protections qui font le vrai travail.

Faut-il breveter l’idée de votre app ?

Probablement pas, et ceux qui disent le contraire vendent souvent des brevets.

On ne brevète pas une idée. On peut parfois breveter une méthode précise, nouvelle et non évidente, et les méthodes logicielles sont notoirement difficiles à faire passer. L’office américain des brevets n’accorde pas de brevet pour « une marketplace de promeneurs de chiens ». Il peut en accorder un pour un procédé technique réellement nouveau, mais c’est une barre haute que la plupart des apps grand public et B2B n’atteignent jamais.

Et il y a le coût et l’horloge. Aux États-Unis, un brevet logiciel coûte couramment de 10 000 à 20 000 dollars ou plus en honoraires et frais de dépôt, et met deux à quatre ans à être délivré. Pendant ces années, votre produit changera tellement que ce que vous avez breveté pourrait ne plus ressembler à ce que vous vendez. Pour une société en pre-seed ou seed, cet argent achète bien plus de protection sous forme de runway : une meilleure première version, une itération plus rapide, une vraie avance sur le marché. La vitesse est un fossé qu’un concurrent ne peut pas vous retirer en remplissant un formulaire.

Les brevets méritent leur place dans des situations précises. Les sociétés de deep tech et de hardware, les entreprises dont toute la valeur est un algorithme inédit, ou les fondateurs dont les investisseurs veulent explicitement une PI défendable. Si c’est votre cas, parlez tôt à un avocat en brevets. Si vous construisez une app bien faite dans une catégorie connue, votre temps et votre argent vous protègent mieux qu’un dépôt.

Une liste en quatre étapes pour vraiment protéger l’idée de votre app

Voici l’ordre des opérations que nous donnerions à tout fondateur non technique, classé selon ce qui vous protège réellement.

1. Exécutez, et exécutez en public. Sortez une vraie première version, gagnez des utilisateurs payants et prenez de l’avance. Un produit vivant, avec des clients, est la protection qu’aucun concurrent ne copie. La peur du vol s’évapore généralement à l’instant où vous avez quelque chose de réel sur le marché.

2. Obtenez la cession de PI par écrit avant le premier commit. Faites de la cession de propriété intellectuelle une condition du contrat avec tout développeur, studio ou freelance. Vérifiez qu’elle couvre les sous-traitants. C’est l’étape qui évite la défaillance qui arrive vraiment. Si vous choisissez un partenaire de build, évaluez-le sérieusement d’abord, car un bon partenaire rend cette paperasse routinière et un mauvais en fait un combat.

3. Soyez propriétaire de vos comptes et de votre code. Le dépôt, les comptes cloud, le domaine et les fiches sur les stores doivent être enregistrés au nom de votre société, pas sur l’e-mail personnel d’un prestataire. Pour les builds à plus fort enjeu, un accord de séquestre du code source vous donne un filet si la relation se termine mal. Quand un investisseur mène la due diligence technique, la propriété propre de ces comptes est l’une des premières choses qu’il vérifie.

4. N’ajoutez un NDA ou un brevet que lorsque la situation l’exige. Utilisez un NDA quand vous partagez quelque chose de réellement sensible avec une partie qui aurait une raison de le compromettre, comme un pilote avec un grand compte ou un partenaire d’échange de données. Déposez un brevet seulement si vous avez une méthode vraiment inédite et le budget pour la défendre. Traitez les deux comme des outils ponctuels, pas comme la fondation.

Faites les trois premiers et vous aurez protégé l’idée de votre app mieux que tout fondateur qui a commencé par le brevet et le NDA en oubliant de céder le code.

Quand un NDA vaut la peine d’être demandé

Les NDA ne sont pas inutiles. Ils sont juste trop utilisés au mauvais moment.

Demander à un studio de développement sérieux de signer un NDA avant la première conversation vous marque comme inexpérimenté, et les bons refuseront souvent, parce qu’ils parlent à des dizaines de fondateurs aux idées proches. Le NDA qui compte vient plus tard : quand vous remettez de vraies données clients, une base propriétaire ou des métriques internes détaillées à un partenaire qui pourrait, de façon plausible, en abuser. Là, un NDA mutuel est normal et raisonnable, et toute société crédible le signe sans friction.

Le test est simple. Si ce que vous protégez est un concept, un NDA achète peu. Si ce que vous protégez est un matériel précis et sensible, qui a une valeur propre, un NDA est approprié. Dépensez votre prudence là où l’actif vit vraiment.

Foire aux questions

Comment empêcher qu’on vole l’idée de votre app ?
La plupart du temps, vous ne le pouvez pas, et la plupart du temps, vous n’en avez pas besoin. Les idées sont communes ; l’exécution est rare. Protégez le travail : cédez le code à votre société dans le contrat, déposez la marque, gardez les comptes et les dépôts sous votre contrôle et livrez plus vite que quiconque entendant votre pitch ne pourrait rattraper.

Dois-je breveter l’idée de mon app ?
Presque certainement pas. On ne brevète pas une idée, seulement une méthode précise et inédite, et la plupart des apps n’y sont pas éligibles. L’argent et les années que coûte un brevet protègent généralement une jeune société bien moins que ces mêmes ressources investies à construire et livrer.

Peut-on protéger légalement une idée sans brevet ?
Oui. L’essentiel de la vraie protection vient des contrats (cession de PI), du dépôt de marque pour votre nom et du contrôle opérationnel de base de votre code et de vos comptes. Cela couvre les choses qui peuvent réellement être emportées, ce qu’un brevet sur une idée vague ne couvrirait pas.

Combien coûte le dépôt d’un brevet pour l’idée d’une app ?
Aux États-Unis, un brevet logiciel coûte couramment de 10 000 à 20 000 dollars ou plus en honoraires et frais, et met deux à quatre ans à être délivré. Pour la plupart des fondateurs en phase précoce, ce budget offre plus de protection sous forme de produit et de runway que sous forme de dépôt.

Le dépôt d’un brevet pour une app en vaut-il la peine ?
Rarement, pour une app classique dans une catégorie connue. Cela vaut la peine quand votre valeur centrale est une méthode technique vraiment inédite, quand vous êtes en deep tech ou en hardware, ou quand les investisseurs exigent explicitement une PI défendable. Sinon, la vitesse et la propriété vous protègent mieux.