Vibe coding : Comment protéger une application codée avec l'IA ?
Décrire une application à une IA et la voir se coder sous ses yeux : voilà la promesse du vibe coding. Mais une application créée en quelques prompts appartient-elle vraiment à celui qui l’a demandée ? Le code généré par une IA n’est protégé par le droit d’auteur que s’il porte la trace de choix humains. Et lorsque ce droit fait défaut, le parasitisme et le secret des affaires peuvent prendre le relais, à condition d’avoir anticipé la preuve. Dans les trois cas, une même réponse : documenter.
Vibe coding : de quoi parle-t-on ?
L’expression a été lancée en février 2025 par Andrej Karpathy, cofondateur d’OpenAI, dans un message publié sur X. Neuf mois plus tard, le dictionnaire Collins en faisait son expression de l’année 2025, et la définissait comme l’usage d’une intelligence artificielle, sollicitée en langage naturel, pour écrire du code informatique.1
Concrètement, le développeur ne tape plus forcément les lignes de code : il décrit ce qu’il veut, l’outil propose, puis il accepte, corrige et relance. Dans sa version la plus radicale, on accepte le code sans même le lire. Dans un usage professionnel, on pilote plutôt l’IA comme une équipe : architecture, choix techniques, revue et tests.
Cette différence ne relève pas seulement de la méthode. Elle détermine directement ce que le droit acceptera de protéger. Car le droit d’auteur ne protège ni un résultat ni un effort en tant que tels : il protège une création humaine. Or, en vibe coding, la question « qui a créé ? » n’a plus de réponse évidente.
I. LE CODE GÉNÉRÉ PAR IA EST-IL PROTÉGÉ PAR LE DROIT D’AUTEUR ?
Le logiciel est une œuvre, à condition d’être original
Le logiciel, y compris son matériel de conception préparatoire, figure parmi les œuvres de l’esprit.2 Son auteur est protégé du seul fait de la création, sans dépôt ni formalité.3
Encore faut-il que le programme soit original, c’est-à-dire qu’il soit « la création intellectuelle propre à son auteur », selon la directive 2009/24/CE. La même directive désigne comme auteur la personne physique, ou le groupe de personnes physiques, ayant créé le programme, la loi nationale pouvant toutefois attribuer cette qualité à une personne morale.4 Dès 1986, l’assemblée plénière de la Cour de cassation exigeait un « effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignante ».5 Autrement dit, il faut pouvoir identifier des choix propres à celui qui programme.
Idées, fonctionnalités et langage restent libres
La directive écarte expressément les idées et principes à la base d’un programme.4 La Cour de justice en a tiré que ni la fonctionnalité d’un programme, ni son langage de programmation, ni le format de ses fichiers de données ne sont protégés à ce titre.6
C’est précisément à cet endroit que le vibe coding se heurte au droit. Ce que l’utilisateur apporte par ses prompts relève souvent de l’idée ou de la fonctionnalité : « une appli de réservation avec paiement et rappels par SMS ». Et la forme, c’est-à-dire les lignes de code, a été écrite par la machine.
Une ligne qui se dessine déjà hors de France
À notre connaissance, aucune juridiction française ne s’est encore prononcée sur un logiciel entièrement généré par IA. Mais les signaux convergent.
Aux États-Unis, le Copyright Office a conclu en janvier 2025 que, avec les technologies actuelles, les seuls prompts ne donnent pas un contrôle suffisant pour faire de l’utilisateur l’auteur du résultat.7 La Cour suprême a refusé, le 2 mars 2026, d’examiner l’affaire Thaler v. Perlmutter, laissant en place la règle selon laquelle une œuvre doit avoir un auteur humain.8
En Europe, le tribunal de Munich a refusé le 13 février 2026 toute protection à trois logos générés par IA, faute d’influence créatrice humaine prépondérante sur la forme finale. Il a jugé indifférents le temps passé, le soin apporté au prompt, sa longueur ou le recours à une version payante. Il admet en revanche que l’apport humain puisse intervenir au fil de prompts successifs ou par la modification ultérieure du résultat.9 Le Parlement européen a, de son côté, affirmé le 10 mars 2026 qu’un contenu intégralement généré par IA ne devrait pas être protégé par le droit d’auteur.10
Ce qui reste protégeable
Tout n’est donc pas perdu, mais la protection devient plus ciblée. Restent protégeables les parties que le développeur a écrites ou substantiellement réécrites, l’architecture qu’il a conçue et imposée à l’outil, et le matériel de conception préparatoire qu’il a produit. Le code accepté tel quel, lui, risque fort de rester sans titulaire.
Entre le « je décris, j’accepte » et le « je conçois l’architecture, j’impose les structures, je réécris », le curseur se déplace. C’est donc à celui qui revendique des droits de montrer concrètement où se situe son apport.
II. DOCUMENTER : LA PREUVE DE L’APPORT HUMAIN
La charge de la preuve pèse sur celui qui revendique
La jurisprudence est constante : c’est à celui qui invoque un droit d’auteur sur un logiciel d’en démontrer l’originalité. Dans une affaire qui opposait deux concepteurs à Microsoft, la Cour de cassation a approuvé les juges qui leur reprochaient de n’avoir rien produit sur l’originalité des composantes du logiciel : lignes de programmation, codes, organigramme ou matériel de conception préparatoire. Les algorithmes et fonctionnalités décrits n’étaient pas protégeables, et le caractère innovant du programme ne suffisait pas.11
Avec l’IA, cette exigence prend une autre dimension. Il ne suffit plus de montrer que le code existe et qu’il est le vôtre. Il faut montrer quelle part de ce code reflète des choix humains, et lesquels.
Que conserver, concrètement ?
Le réflexe est simple : garder la trace de ce que l’humain a décidé, et pas seulement de ce que la machine a produit.
• La conception : cahier des charges, schémas d’architecture, modèles de données, maquettes. Ce matériel de conception préparatoire est protégeable en lui-même lorsqu’il est original.
• Le dialogue avec l’outil : l’historique des sessions et des prompts, horodaté, en particulier ceux qui imposent une structure, refusent une proposition ou arbitrent entre plusieurs solutions.
• L’historique Git : des commits qui distinguent ce qui a été généré de ce qui a été écrit ou réécrit par un développeur, avec des messages explicites. C’est souvent la pièce la plus parlante devant un expert.
• La revue de code : les choix d’implémentation retenus, les alternatives écartées et pourquoi.
• L’outil utilisé : son nom, sa version et ses conditions d’utilisation au jour du développement, qui règlent notamment le sort des contenus générés et des données transmises.
Donner une date certaine
Documenter est utile, mais encore faut-il pouvoir dater les éléments conservés. Le dépôt du code source auprès de l’Agence pour la protection des programmes (APP), l’enveloppe Soleau ou un horodatage qualifié permettent de figer une version à une date donnée. Ils ne créent aucun droit, mais ils fournissent une référence opposable.
Une affaire parisienne l’illustre. Dans un litige portant sur une suite logicielle, le juge de la mise en état du tribunal judiciaire de Paris a chargé un expert de comparer le code saisi chez un ancien salarié à la version déposée à l’APP quelques mois plus tôt.12 Sans ce dépôt, le point de comparaison aurait lui-même été discuté.
Titularité : ne pas céder ce que l’on n’a pas
Lorsque le logiciel est développé par des salariés dans l’exercice de leurs fonctions, les droits patrimoniaux reviennent à l’employeur.13 Avec un prestataire ou un freelance, il faut une cession écrite et précise.
Mais le vibe coding ajoute une difficulté : on ne peut pas céder un droit qui n’existe pas. Un prestataire qui garantit à son client la « pleine propriété » d’un code largement généré s’engage au-delà de ce qu’il peut juridiquement transmettre. Les contrats de développement doivent désormais dire quelle part du livrable est générée, avec quel outil, ainsi que ce qui est réellement garanti.
III. PARASITISME : UN FILET DE SÉCURITÉ, SOUS CONDITIONS
Une action ouverte à ceux qui n’ont pas de droit privatif
Si le code n’est pas protégé par le droit d’auteur, cela ne signifie pas pour autant que tout est permis. La responsabilité délictuelle de droit commun permet d’agir en concurrence déloyale ou en parasitisme, précisément lorsqu’on ne peut se prévaloir d’aucun droit privatif.14
La Cour de cassation définit le parasitisme comme une forme de déloyauté, constitutive d’une faute, qui consiste pour un opérateur économique à se placer dans le sillage d’un autre afin de tirer indûment profit de ses efforts, de son savoir-faire, de sa notoriété ou de ses investissements.15
Deux précisions récentes renforcent l’intérêt de cette voie. Le parasitisme peut être invoqué en dehors de tout rapport de concurrence. Et celui dont l’action en contrefaçon a été rejetée faute de droit privatif peut former, pour la première fois en appel, une demande en parasitisme fondée sur les mêmes faits.16
Encore faut-il démontrer une valeur économique
C’est souvent là que la difficulté apparaît pour les projets vibecodés. Il appartient à la victime d’identifier la valeur économique individualisée qu’elle invoque, ainsi que la volonté du tiers de se placer dans son sillage. Cette valeur ne se déduit pas de la seule longévité ou du succès commercial du produit. Et les idées étant de libre parcours, reprendre un concept ne constitue pas, en soi, un acte de parasitisme.15
La chambre commerciale veille à ce que cette charge ne soit pas inversée : elle a censuré une cour d’appel qui avait reproché au défendeur de ne pas prouver que l’avantage invoqué par la victime, un certificat sanitaire, pouvait être aisément obtenu.17
À l’inverse, le parasitisme a été retenu lorsque le demandeur prouvait la réalité du travail de conception et de développement, le caractère innovant de sa démarche et ses investissements, face à un concurrent incapable de justifier du moindre travail de mise au point.18
Le paradoxe du vibe coding
Le vibe coding réduit précisément le coût du développement. Plus une application a été produite vite et à peu de frais, plus il sera difficile de démontrer des investissements dont un concurrent aurait indûment profité. Et le concurrent qui reproduit vos fonctionnalités en les décrivant à son tour à une IA pourra soutenir qu’il n’a repris que des idées.
La valeur à protéger ne se trouve donc pas nécessairement dans le code lui-même. Elle est dans ce qui l’entoure : la recherche utilisateur, les itérations de design, la structuration des données, les contenus, les tests et la stratégie de lancement. Encore faut-il que ces efforts soient chiffrés et datés.
L’absence de preuve peut même bloquer une action avant le procès. Une enseigne qui soupçonnait un parasitisme a vu rétracter la mesure d’instruction qu’elle avait obtenue sur requête : elle n’avait ni défini ni précisé les efforts humains et financiers qu’elle entendait protéger. La Cour de cassation a approuvé cette rétractation.19
IV. SECRET DES AFFAIRES : PROTÉGER CE QUI NE SE VOIT PAS
Trois conditions cumulatives
Le secret des affaires offre une protection qui ne dépend ni de l’originalité ni d’un investissement particulier. L’information doit n’être pas généralement connue ou aisément accessible, revêtir une valeur commerciale du fait de son caractère secret, et faire l’objet de mesures de protection raisonnables.20 L’obtention par accès ou copie non autorisés est illicite et engage la responsabilité civile de son auteur.21
Ce qui est visible n’est pas, en principe, secret
La loi admet expressément l’obtention d’un secret par création indépendante ou par l’observation et le test d’un produit mis à la disposition du public, sauf stipulation contractuelle contraire.22 Le droit d’auteur va dans le même sens : l’utilisateur légitime d’un logiciel peut en observer et tester le fonctionnement pour en déterminer les idées et principes.23
Un concurrent qui observe votre application et demande à une IA d’en produire un équivalent agit donc, en principe, dans son droit. Le secret protège autre chose : le code côté serveur, les données, les paramétrages, et surtout ce qui fait la valeur d’un projet vibecodé, à savoir la chaîne de prompts, les instructions système, les configurations d’agents et les jeux de tests. Ces éléments, rarement protégeables par le droit d’auteur, peuvent l’être au titre du secret.
L’angle mort : ce que l’on confie à l’outil
La troisième condition, celle des mesures de protection raisonnables, mérite une attention particulière en vibe coding. Coller du code propriétaire ou des instructions sensibles dans un outil d’IA grand public, dont les conditions autorisent la réutilisation des données, pourrait être opposé à l’entreprise pour contester le caractère raisonnable de ses mesures.
Les mesures attendues restent classiques, mais doivent être adaptées : dépôts de code privés et accès nominatifs, clauses de confidentialité dans les contrats de travail et de prestation, politique interne d’usage de l’IA, choix d’offres professionnelles qui excluent l’entraînement sur les données transmises. Et, là encore, une trace écrite de ces mesures.
V. EN PRATIQUE : CE QU’IL FAUT POUVOIR PROUVER
Chaque fondement appelle une preuve différente, même si les pièces utiles se recoupent largement. Mieux vaut les constituer au fil du développement qu’au moment du litige.
| Fondement | Ce qu'il faut démontrer | Pièces utiles |
|---|---|---|
| Droit d'auteur | Des choix humains libres et créatifs dans la forme du code ou sa conception | Spécifications, schémas d'architecture, historique Git distinguant code généré et code réécrit, prompts structurants, dépôt APP daté |
| Parasitisme | Une valeur économique individualisée et la volonté du tiers de s'inscrire dans son sillage | Temps passé et budget, itérations de design, recherche utilisateur, dépenses marketing, preuves de la copie et de sa chronologie |
| Secret des affaires | Une information non accessible, ayant une valeur du fait du secret, protégée par des mesures raisonnables | Politique d'accès, clauses de confidentialité, politique d'usage de l'IA, conditions des outils utilisés, journaux d'accès |
| Titularité | Que les droits vous appartiennent effectivement | Contrats de travail, cessions écrites avec les prestataires, conditions d'utilisation des outils d'IA |
Conclusion : coder vite, prouver longtemps
Le vibe coding ne crée pas un vide juridique. Il déplace surtout la question. La valeur d’une application ne se trouve d’ailleurs plus toujours dans ses lignes de code, et le droit ne protège que ce qui peut être rattaché à un choix humain, à un investissement identifiable ou à une information réellement gardée secrète.
Dans les trois cas, la protection se joue en amont, pendant le développement, et non au moment du litige. Une architecture documentée, un historique de commits lisible, des investissements chiffrés et une politique d’usage de l’IA sont les meilleurs actifs d’un projet vibecodé.
Notes et références
1. Collins Dictionary, « vibe coding », expression de l’année 2025 ; expression employée pour la première fois par Andrej Karpathy sur X en février 2025 — franceinfo.fr ; fr.euronews.com.
2. CPI, art. L. 112-2, 13° — legifrance.gouv.fr.
3. CPI, art. L. 111-1 — legifrance.gouv.fr.
4. Directive 2009/24/CE du 23 avril 2009 concernant la protection juridique des programmes d’ordinateur, art. 1er, § 2 (exclusion des idées et principes) et § 3 (originalité), et art. 2, § 1 (qualité d’auteur) — eur-lex.europa.eu.
5. Cass. ass. plén., 7 mars 1986, n° 83-10.477, publié au bulletin, dit arrêt Pachot — legifrance.gouv.fr.
6. CJUE, gr. ch., 2 mai 2012, C-406/10, SAS Institute Inc. c/ World Programming Ltd (ni la fonctionnalité, ni le langage de programmation, ni le format de fichiers de données ne constituent une forme d’expression protégée) — eur-lex.europa.eu.
7. U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability, janv. 2025 — copyright.gov.
8. Cour suprême des États-Unis, 2 mars 2026, refus de certiorari, Thaler v. Perlmutter, n° 25-449, laissant en place l’arrêt de la Cour d’appel du circuit de Washington (D.C. Cir.) du 18 mars 2025. Voir le commentaire — hklaw.com.
9. Amtsgericht München (tribunal de Munich), 13 févr. 2026, 142 C 9786/25 (logos générés par IA ; absence d’influence créatrice humaine prépondérante), tel que rapporté par la mission APIE, « Quel droit d’auteur à l’ère de l’intelligence artificielle générative ? », 4 juin 2026 — economie.gouv.fr.
10. Parlement européen, résolution du 10 mars 2026 sur le droit d’auteur et l’intelligence artificielle générative – opportunités et défis, 2025/2058(INI), P10_TA(2026)0066 — europarl.europa.eu.
11. Cass. 1re civ., 14 nov. 2013, n° 12-20.687 (preuve de l’originalité à la charge de celui qui revendique des droits ; algorithmes et fonctionnalités non protégés) — legifrance.gouv.fr.
12. TJ Paris, 3e ch. 1re sect., ord. JME, 20 avr. 2023, n° 21/14626 (expertise comparant le code saisi à la version déposée à l’APP) — legifrance.gouv.fr.
13. CPI, art. L. 113-9 — legifrance.gouv.fr.
14. C. civ., art. 1240 — legifrance.gouv.fr.
15. Cass. com., 26 juin 2024, n° 23-13.535, publié au Bulletin et au Rapport (définition du parasitisme ; charge de la preuve de la valeur économique individualisée et de la volonté de se placer dans le sillage d’autrui ; idées de libre parcours) — legifrance.gouv.fr.
16. Cass. com., 18 mars 2026, n° 24-17.016, publié au bulletin (parasitisme invocable hors de tout rapport de concurrence ; demande recevable pour la première fois en appel après rejet de l’action en contrefaçon faute de droit privatif) — legifrance.gouv.fr.
17. Cass. com., 24 sept. 2025, n° 24-13.002 (censure de l’inversion de la charge de la preuve) — legifrance.gouv.fr.
18. Cass. com., 26 juin 2024, n° 22-17.647 et 22-21.497, publié au Bulletin et au Rapport (parasitisme retenu au vu du travail de conception, du caractère innovant et des investissements) — legifrance.gouv.fr.
19. Cass. 2e civ., 16 avr. 2026, n° 25-14.297 (rétractation d’une mesure d’instruction in futurum, faute d’efforts humains et financiers définis) — legifrance.gouv.fr.
20. C. com., art. L. 151-1 — legifrance.gouv.fr.
21. C. com., art. L. 151-4 — legifrance.gouv.fr ; art. L. 152-1 — legifrance.gouv.fr.
22. C. com., art. L. 151-3 — legifrance.gouv.fr.
23. CPI, art. L. 122-6-1, III — legifrance.gouv.fr.