Votre IA a écrit la moitié du dépôt. Avant de livrer, ou de lever des fonds dessus, la question tombe : détenez-vous réellement ce code, et êtes-vous autorisé à l’utiliser comme vous l’utilisez ? La réponse honnête est que « qui le détient » recouvre trois questions différentes, et la plus risquée est celle que presque personne ne vérifie. Ceci est une orientation pratique, pas un conseil juridique. Le droit de la propriété intellectuelle est propre à chaque juridiction : traitez ce texte comme une carte, pas comme une décision. Ce n’est pas non plus une classification au titre du règlement sur l’IA : droit d’auteur et licences portent sur le code ; le règlement sur l’IA, s’il s’applique, porte sur le système d’IA que vous mettez devant des personnes.
Trois questions cachées dans « qui le détient »
1. Le code généré par une IA peut-il même être protégé ?
Dans plusieurs juridictions majeures, la protection par le droit d’auteur (ou le copyright aux États-Unis) exige une paternité humaine. L’U.S. Copyright Office a répété que la sortie purement générée par une IA, sans contribution créative humaine significative, n’est pas protégeable au titre du copyright américain. L’Union et d’autres juridictions varient, et le droit bouge encore. Ce texte ne transpose pas la position américaine sur le droit d’auteur français ou sur la directive 2001/29/CE.
La conséquence, contre-intuitive : pour les parties qu’une IA a générées avec peu de façonnage humain, vous pouvez ne pas détenir un droit exclusif dans les juridictions qui exigent une paternité humaine, ce qui veut dire que vous pouvez ne pas pouvoir empêcher d’autres d’utiliser ce même code. Pour la plupart des équipes produit, c’est tenable (votre fossé est rarement une seule fonction), mais cela compte si la valeur est le code lui-même, et il vaut mieux le savoir avant de dire à un investisseur que vous « détenez » tout.
2. Êtes-vous autorisé à l’exploiter commercialement ?
C’est en général la question facile. Les grands outils de code par IA (Copilot, Cursor, Claude, et d’autres) vous cèdent les droits sur la sortie dans leurs conditions et autorisent en général l’usage commercial ; certains offrent même une indemnisation PI sur les paliers payants / entreprise. Mais « en général » n’est pas « toujours », et les conditions diffèrent selon le palier. Lisez les conditions de l’outil et du palier que vous utilisez réellement, et gardez-en une note. Les paliers gratuits et grand public portent parfois des conditions différentes de celles des offres professionnelles.
3. Pourrait-il porter la licence de quelqu’un d’autre ? (le piège)
Voici celle qui blesse. Les modèles d’IA sont entraînés sur d’énormes volumes de code public sous de nombreuses licences différentes, y compris des licences copyleft comme la GPL et l’AGPL. Un modèle peut, et le fait parfois, reproduire des extraits de données d’entraînement quasi verbatim. Si un morceau de code généré est substantiellement une copie de code sous GPL, alors les obligations de la GPL s’y attachent, du moins selon la lecture contractuelle habituelle de la licence, que le code ait été produit par une IA et que vous n’en ayez rien su. Savoir si un juge qualifierait le morceau de copie substantielle est une question de faits, pas une conclusion que ce texte tranche.
Le piège copyleft, concrètement
Les licences copyleft sont « virales » : incorporez du code GPL dans votre produit et la licence peut vous obliger à publier votre source aux mêmes conditions. C’est acceptable pour un projet open source et un problème sérieux pour un logiciel propriétaire. Le danger du code généré par IA est que la contamination est invisible : pas de ligne import, pas de dépendance dans votre manifeste, pas de signal évident. Ce n’est que du code qui a l’air d’être le vôtre.
Des équipes ont découvert du code généré par IA entaché de copyleft tard dans un cycle de livraison et se sont trouvées face aux pires options : réécrire le module contaminé, ou changer la façon dont elles licencient leur produit. Le coût n’est pas un droit de licence, c’est la réécriture d’urgence et le risque sur le produit déjà livré.
Votre système d’IA est-il à haut risque ?
Découvrez-le en 2 minutes, gratuitement, sans inscription.
Faire l’évaluation gratuiteQue faire avant de livrer du code généré par IA
- Connaître les conditions de votre outil. Confirmez que l’IDE / le modèle que vous utilisez vous accorde des droits commerciaux sur la sortie, sur le palier où vous êtes réellement.
- Surveiller la reproduction verbatim. Soyez particulièrement prudent lorsque l’IA produit un bloc large, complet, reconnaissable (un algorithme connu, un analyseur, un utilitaire distinctif) : c’est là que la régurgitation de code sous licence est la plus probable.
- Suivre la provenance. Gardez une trace des parties du dépôt générées par IA, afin que si une question de licence se pose un jour, vous puissiez y répondre au lieu d’auditer tout dans la panique.
- Repérer le copyleft tôt. Attrapez les schémas de type GPL / AGPL au moment du commit, pas à la livraison.
- Tenir un dossier daté. « Nous avons vérifié, voici ce que nous avons trouvé, à cette date » est ce qui transforme une inquiétude vague en quelque chose que vous pouvez défendre devant un client, un acquéreur ou un conseil.
Provenance : la couche qui manque encore
On ne gère pas ce qu’on ne voit pas. La raison pour laquelle la contamination de licence fait peur, c’est que le code généré par IA arrive sans provenance, sans piste d’où il vient ni de ce qu’il pourrait porter. C’est exactement l’écart que la génération suivante de garde-fous de développement est bâtie pour fermer : provenance et sûreté de livraison pour le code généré par IA, au moment du commit, dans la boucle où vous travaillez réellement.
Nous intégrons cela ensuite dans Legalithm : savoir ce que votre IA a écrit, signaler les extraits contaminés par une licence ou non attribués, et prouver qu’il est sûr de livrer. Si c’est une douleur que vous ressentez, demandez un accès anticipé, cela nous dit de le construire plus tôt pour vous.
Et l’autre obligation : le règlement sur l’IA
Le droit d’auteur et les licences portent sur le code. Si votre application place aussi une fonction d’IA devant des personnes, un agent conversationnel, du contenu généré, un classifieur, vous pouvez séparément devoir des obligations au titre du règlement sur l’IA, indépendamment de qui détient le code. C’est une autre question, avec sa propre réponse ; voir le règlement sur l’IA s’applique-t-il aux applis nées du « vibe coding » ? et lancez l’évaluation gratuite du règlement sur l’IA pour trouver votre palier.
Limites honnêtes
Ceci est une information générale, pas un conseil juridique. Les issues en droit d’auteur et en licences dépendent de votre juridiction et de vos faits, et c’est un domaine où faire intervenir un avocat PI qualifié pour tout enjeu élevé est le bon réflexe. Le travail de Legalithm est de faire apparaître les questions tôt et de tenir un dossier cité, daté, pour que vous ne le découvriez pas au pire moment.
En résumé : vous pouvez presque toujours utiliser le code que votre IA a écrit, mais « l’utiliser » et « le détenir proprement » ne sont pas la même chose, et le piège copyleft est invisible jusqu’à ce qu’il soit cher. La provenance, attrapée dans la boucle, est ce qui garde le code généré par IA livrable.


