{"componentChunkName":"component---src-templates-blog-template-js","path":"/fr/blog/ai-open-source-and-intellectual-property","result":{"data":{"markdownRemark":{"html":"<h1>IA, Open Source et Propriété Intellectuelle</h1>\n<p>L’open source a toujours reposé sur un échange simple mais puissant : vous pouvez utiliser, étudier, modifier et partager le code, mais vous devez respecter la licence. Cet accord a permis la création de Linux, Kubernetes, PostgreSQL, Python, d’innombrables bibliothèques de sécurité et de toute l’infrastructure derrière une grande partie de l’internet moderne.</p>\n<p>L’IA générative exerce une pression sur cet équilibre.</p>\n<p>Les grands modèles d’IA sont entraînés sur d’énormes quantités de textes, d’images, d’audio, de vidéo et de code source. Une part significative de ce matériel a été rendue publique par des personnes désireuses de partager, collaborer, documenter, enseigner ou publier. Mais le fait d’être accessible au public ne signifie pas qu’une utilisation commerciale sans limite soit permise. Le simple fait qu’un dépôt soit hébergé sur internet n’est pas une renonciation automatique au droit d’auteur. Une licence open source n’est pas une invitation à ignorer l’attribution, le copyleft, les mentions légales, les obligations de partage du code source ou les restrictions prévues dans les licences de dépendance.</p>\n<p>Voilà le dilemme central : les entreprises d’IA plaident souvent que l’entraînement relève de l’analyse, de l’apprentissage ou de l’usage équitable (fair use). Beaucoup de créatrices, créateurs et mainteneurs open source considèrent au contraire que l’entraînement de modèles implique la copie industrielle d’œuvres protégées, souvent sans autorisation, compensation, attribution ni moyen pratique de s’y opposer.</p>\n<h2>Pourquoi l’open source est particulièrement exposé</h2>\n<p>Le code open source est facile à collecter. Il est structuré, interrogeable, versionné et hébergé dans des dépôts publics. Il contient aussi des commentaires, des tests, des discussions d’issues, des exemples, des historiques de commits, de la documentation et des fichiers de configuration.</p>\n<p>Pour les constructeurs de modèles d’IA, c’est un matériel d’entraînement extrêmement précieux. Pour les mainteneurs, cela crée plusieurs risques.</p>\n<ul>\n<li>Les obligations de licence peuvent disparaître entre l’entrée d’entraînement et la sortie générée.</li>\n<li>L’attribution n’est généralement pas préservée lorsqu’un modèle suggère du code.</li>\n<li>Le code sous copyleft peut influencer les extraits générés sans que l’utilisateur connaisse la licence source ou les obligations qui y sont attachées.</li>\n<li>Les mainteneurs peuvent voir leur travail utilisé pour créer des outils commerciaux qui concurrencent leurs services de conseil, de support ou d’hébergement.</li>\n<li>Des schémas de code sensibles à la sécurité peuvent être reproduits sans contexte.</li>\n<li>Du code vulnérable ou obsolète peut être plus facilement copié à grande échelle.</li>\n</ul>\n<p>La question ne porte pas seulement sur la capacité d’un modèle à produire une copie parfaite d’une fonction. Cela s’est vu plus ouvertement dans les premiers outils d’IA pour le code, où les requêtes pouvaient parfois reproduire du code reconnaissable. Avec la maturité des produits, les fournisseurs sont devenus plus prudents concernant les filtres, les contrôles de similitude et de sorties. Mais éviter la reproduction verbatim évidente ne règle pas le problème de fond. Le processus d’entraînement a pu dépendre de code dont les conditions de licence n’ont jamais été transmises.</p>\n<p>En d’autres termes, le problème du droit d’auteur ne disparaît pas simplement parce que la preuve est plus difficile à détecter dans la sortie.</p>\n<p>C’est particulièrement le cas pour les licences réciproques comme la GPL et l’AGPL. Ces licences ne sont pas de simples autorisations. Elles accordent de larges libertés, mais elles exigent aussi que les œuvres dérivées, ou les logiciels distribués dans certaines conditions, conservent ces libertés. Si un modèle est entraîné sur du code GPL et qu’il génère ensuite du code substantiellement basé sur cette entrée GPL, l’utilisateur peut, à son insu, introduire des obligations GPL dans son propre projet. Si ce projet est propriétaire, à source fermée, ou distribué sous une licence incompatible, cela aboutit à une violation de licence.</p>\n<p>Le problème pratique est que l’utilisateur n’a généralement aucun moyen de le savoir. L’assistant IA ne dit pas : « Cette suggestion provient de code sous licence GPL », « Ce schéma est issu d’un projet AGPL » ou « Cette sortie ressemble à un code sous licence Apache et nécessite le maintien des mentions ». Le contexte de licence était présent dans les données d’entraînement, mais il manque dans la réponse. Cela rompt la chaîne de conformité dont dépend le licensing open source.</p>\n<h2>La différence inconfortable entre lire et entraîner</h2>\n<p>Les développeurs apprennent tout le temps grâce à l’open source. On lit du code, on comprend des modèles, puis on écrit sa propre implémentation. C’est normal et sain. L’open source dépend de ce type d’apprentissage.</p>\n<p>L’entraînement d’IA diffère par son ampleur, son automatisation et ses effets de marché. Un développeur humain lisant un projet ne copie généralement pas des millions de dépôts dans un pipeline d’entraînement, n’en compresse pas les schémas statistiques dans un modèle commercial, et ne vend pas la génération de code comme un produit. Le modèle peut ne pas stocker les fichiers comme une base de données, mais la valeur commerciale provient toujours de l’extraction de schémas depuis le travail d’autrui.</p>\n<p>C’est pourquoi le débat est si difficile. Si chaque acte d’apprentissage machine sur du code public exige une autorisation individuelle, nombre de systèmes d’IA deviennent impossibles à entraîner. Si aucune autorisation n’est requise, les droits économiques et moraux des créatrices et créateurs s’affaiblissent nettement. Les deux extrêmes posent problème.</p>\n<h2>UE vs États-Unis : deux instincts juridiques très différents</h2>\n<p>Le paysage juridique n’est pas homogène. Les pays tentent encore d’adapter le droit d’auteur à l’IA, alors que ce droit n’a pas été pensé pour l’entraînement massif de modèles.</p>\n<h3>Union Européenne</h3>\n<p>L’UE dispose d’un cadre plus explicite. La <a href=\"https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32019L0790\" rel=\"nofollow\">Directive sur le droit d’auteur dans le marché unique numérique</a> contient des exceptions pour la fouille de textes et de données (text and data mining – TDM). L’Article 3 couvre les organismes de recherche et les institutions du patrimoine culturel. L’Article 4 autorise la TDM de façon plus large, y compris à des fins commerciales, mais permet aux titulaires de droits de réserver leurs droits, par exemple via des moyens lisibles par machine.</p>\n<p>La <a href=\"https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai\" rel=\"nofollow\">Loi sur l’IA de l’UE</a> ajoute une couche pour les modèles d’IA à vocation générale. Les fournisseurs ont des obligations de transparence et liées au droit d’auteur, notamment l’obligation de se conformer au droit d’auteur européen et de fournir des résumés des contenus utilisés pour l’entraînement. Cela ne répond pas totalement à la question de la légalité d’un entraînement particulier, mais pousse l’UE vers un modèle où les fournisseurs d’IA doivent documenter davantage, et les titulaires de droits disposent d’outils plus clairs pour s’opposer.</p>\n<p>Le point faible est celui de l’application pratique. Les mécanismes de retrait (opt-out) sont fragmentés. <code>robots.txt</code> a été conçu pour les robots d’indexation du web, pas pour une gestion raffinée des droits d’auteur sur l’ensemble des dépôts de code, registres de paquets, miroirs, jeux de données et forks. Un petit mainteneur open source peut avoir légalement le droit de réserver l’usage, mais n’a aucune possibilité réaliste d’auditer si un modèle frontalier l’a respecté.</p>\n<h3>États-Unis</h3>\n<p>Aux États-Unis, il n’existe pas d’exception spécifique au droit d’auteur pour l’entraînement des IA. Le débat porte largement sur l’usage équitable (fair use), les contentieux, les accords de licence et les préjudices au marché. L’<a href=\"https://www.copyright.gov/ai/\" rel=\"nofollow\">Office du copyright américain</a> a étudié IA et copyright dans plusieurs rapports, incluant les répliques numériques, la protection des sorties d’IA, et l’entraînement des IA génératives. Leur <a href=\"https://www.copyright.gov/fair-use/\" rel=\"nofollow\">guide du fair use</a> rappelle que l’usage équitable s’apprécie cas par cas, selon des critères comme le but, la quantité utilisée et l’effet sur le marché.</p>\n<p>Cela rend la situation plus flexible mais moins prévisible. Les entreprises d’IA peuvent avancer que l’entraînement est transformateur. Les titulaires de droits rétorquent que la copie massive relève d’un usage commercial et concurrence le marché de la licence, portant ainsi atteinte à la valeur de leur travail. Les tribunaux dessinent encore les frontières.</p>\n<p>Pour l’open source, cette approche crée une incertitude. Une entreprise peut penser que l’entraînement de modèles à partir de dépôts publics relève du fair use, tandis que les mainteneurs peuvent estimer que les conditions de licence sont bafouées. Tant que tribunaux et législateurs n’apportent pas de précisions, il en résulte un déséquilibre pratique : seules les grandes entreprises peuvent absorber le risque juridique, alors que les mainteneurs individuels n’en ont pas les moyens.</p>\n<h3>Royaume-Uni</h3>\n<p>Le Royaume-Uni se situe entre ces positions. Le gouvernement a lancé une consultation sur un cadre pour le droit d’auteur et l’IA qui combinerait une exception pour la TDM, le droit de réserve, des licences et une transparence renforcée. La consultation officielle reconnaît que le droit britannique actuel fait débat et que créateurs et développeurs d’IA manquent de certitudes.</p>\n<p>C’est une tentative de voie médiane : autoriser l’entraînement massif sauf opposition, mais offrir plus de contrôle et de visibilité aux titulaires de droits. L’applicabilité dépend des détails techniques. Un opt-out réservé aux gros éditeurs ne serait pas équitable pour les développeurs indépendants, les musiciennes, écrivains et petits projets open source.</p>\n<h3>Japon et Singapour</h3>\n<p>Le Japon est souvent décrit comme plus permissif concernant l’analyse de l’information et l’apprentissage machine, même si les détails restent sujets à interprétation et à recommandations. L’Agence pour les affaires culturelles a publié une vue d’ensemble sur IA et droit d’auteur, tout en rappelant la complexité juridique du sujet.</p>\n<p>Singapour dispose également d’une large exception pour l’analyse computationnelle de données. L’objectif politique est de soutenir l’innovation et le développement de l’IA, mais la contrepartie est connue : des permissions d’entraînement étendues peuvent affaiblir la position de négociation des titulaires de droits, sauf si des garde-fous sont apportés en matière de transparence, de marchés de licences ou autres protections.</p>\n<h2>La question dépasse le code source</h2>\n<p>Le débat open source s’inscrit dans un conflit plus vaste autour de l’identité numérique et du travail créatif.</p>\n<p>Les acteurs combattent contre les systèmes d’IA qui copient visages, mouvements corporels et performances. Les comédiens de doublage et chanteuses luttent contre les voix clonées qui peuvent générer de nouvelles créations sans consentement. Les écrivains et journalistes contestent l’entraînement de modèles sur des livres, articles et archives. Les artistes visuels s’opposent aux générateurs d’images capables d’imiter leur style ou d’inonder le marché de travaux dérivés.</p>\n<p>Le schéma est presque toujours le même :</p>\n<ul>\n<li>Une œuvre créative est collectée à grande échelle.</li>\n<li>Le modèle apprend à partir d’elle sans lien direct avec l’auteur.</li>\n<li>Un produit est vendu, utilisant cette nouvelle capacité.</li>\n<li>Le créateur n’a que peu de transparence, peu de pouvoir de négociation, et des moyens très limités de prouver ce qui s’est passé.</li>\n</ul>\n<p>Pour les actrices et chanteuses, la question n’est pas seulement le droit d’auteur, c’est aussi le droit à la personnalité, le droit à l’image, le droit du travail, le droit des contrats, la protection du consommateur et le consentement. Une voix est à la fois une performance, un identifiant biométrique, une marque et une part de l’identité personnelle. Un visage est un atout artistique, mais c’est aussi la personne elle-même.</p>\n<p>Les développeurs open source ne se considèrent peut-être pas comme des performeurs, mais l’économie de la situation est comparable. Leur travail devient un matériau de base pour un système susceptible de les concurrencer, de réduire l’attribution et de déplacer la valeur de nombreux petits créateurs vers quelques grands fournisseurs de modèles.</p>\n<h2>Le problème du « c’était public »</h2>\n<p>Un des arguments les plus faibles dans le débat sur l’IA est que l’accès public équivaut à un usage sans restriction. Le web n’a jamais fonctionné ainsi. Un article de blog est public, mais n’est pas librement réutilisable dans un livre. Une photo est publique, mais n’est pas librement utilisable dans une publicité. Un dépôt GitHub est public, mais reste soumis au droit d’auteur et aux conditions de licence.</p>\n<p>Les licences open source sont fondées sur cette distinction. Elles accordent de larges permissions, mais ces permissions s’accompagnent de conditions. MIT, Apache, BSD, GPL, AGPL, MPL et d’autres licences fixent chacune des règles différentes sur l’attribution, les brevets, la distribution du code source, l’usage réseau et les œuvres dérivées. Traiter tout code public comme une simple matière première efface ces choix.</p>\n<p>C’est dangereux, car la diversité des licences n’est pas un hasard. C’est ainsi que les mainteneurs expriment leurs intentions.</p>\n<h2>À quoi ressemblerait un système plus équitable ?</h2>\n<p>Il n’existe pas de solution simple, mais plusieurs principes pourraient assainir l’écosystème.</p>\n<h3>1. Transparence par défaut</h3>\n<p>Les fournisseurs d’IA devraient publier des résumés significatifs des sources de données utilisées pour l’entraînement. Il n’est pas forcément nécessaire que chaque fichier individuel soit listé publiquement, mais déclarer seulement « entraîné sur des données publiques » ne suffit pas. Développeuses, artistes, éditeurs et utilisatrices ont besoin de savoir quels types de contenus ont été utilisés, et sous quelle base légale.</p>\n<h3>2. Respect des droits lisibles par machine</h3>\n<p>Si la loi dépend de mécanismes d’exclusion (opt-out), ceux-ci doivent être standardisés, accessibles et opposables. Un petit projet ne devrait pas avoir besoin d’un service juridique pour dire « n’entraînez pas d’IA avec ceci ». Les dépôts, registres de paquets, sites web et plateformes de contenu doivent disposer de mécanismes clairs, effectivement respectés par les crawlers IA.</p>\n<h3>3. Outils d’IA sensibles aux licences</h3>\n<p>Les assistants de code devraient aider les utilisateurs à comprendre le risque de licensing. Si le code généré ressemble à un code open source connu, l’outil doit avertir l’utilisateur et afficher la licence correspondante. Dissimuler ces problèmes de similitude diminue peut-être les procès à court terme, mais augmente le risque de non-conformité pour les développeurs et entreprises utilisant l’outil.</p>\n<h3>4. De meilleurs modèles de rémunération</h3>\n<p>Certains usages d’entraînement devraient être soumis à licence. Cela peut prendre la forme de licences directes, de licences collectives, de places de marché de jeux de données ou de modèles de partage de revenus. Les détails varieront entre le code source, la musique, le cinéma, le journalisme ou l’art visuel, mais le principe reste le même : si un produit d’IA commercial dépend d’un travail humain de qualité, ses auteurs ne devraient pas être invisibles.</p>\n<h3>5. Une protection forte contre l’usurpation</h3>\n<p>Les répliques numériques de voix, de visages et de performances devraient exiger le consentement. L’étiquetage seul ne suffit pas si une fausse voix ou un faux visage peut être utilisé pour tromper, harceler, frauder ou remplacer quelqu’un commercialement. Ici, le droit d’auteur n’est qu’une partie de la réponse.</p>\n<h2>Que peuvent faire les mainteneurs open source aujourd’hui ?</h2>\n<p>La situation juridique est incertaine, mais les mainteneurs disposent tout de même d’options concrètes.</p>\n<ul>\n<li>Choisir une licence de façon réfléchie et documenter la raison.</li>\n<li>Ajouter dans le dépôt des mentions claires sur la préférence ou non pour l’entraînement d’IA, si le projet le juge pertinent.</li>\n<li>Soutenir les fondations et organismes qui défendent les droits open source dans les débats sur la politique de l’IA.</li>\n</ul>\n<p>Aucune de ces actions ne résout totalement le problème. Elles réduisent simplement les risques en attendant que la loi et la pratique industrielle évoluent.</p>\n<h2>Le vrai danger pour l’open source</h2>\n<p>Le plus grand danger n’est pas que l’IA apprenne de l’open source. Apprendre de l’open source est une clef du succès du monde logiciel.</p>\n<p>Le danger, c’est que l’IA transforme la collaboration ouverte en extraction à sens unique. Si les mainteneurs contribuent code, documentation, rapports de bugs, exemples et savoir communautaire, mais que la valeur commerciale est captée ailleurs sans attribution, respect des licences ni soutien aux communs, le contrat social s’affaiblit.</p>\n<p>L’open source dépend de la confiance. Les acteurs de l’IA ont besoin de l’open source, mais risquent aussi d’endommager l’écosystème dont ils dépendent eux-mêmes. Respecter les licences, publier des informations transparentes sur les données, soutenir les mainteneurs, et mettre en place des mécanismes d’exclusion et de licence ne sont pas des positions anti-IA. Ce sont des positions pro-durabilité.</p>\n<p>L’IA peut être un outil utile pour les développeurs, artistes, écrivains, chanteurs, acteurs et entreprises. Mais l’utilité ne fait pas disparaître les droits de propriété, le consentement ou le crédit. Si la société désire que les systèmes d’IA soient entraînés sur le travail de millions de personnes, elle doit aussi décider comment ces personnes gardent un droit de regard sur ce qu’elles ont créé.</p>\n<p>Cette décision ne peut être laissée aux seules entreprises qui ont déjà copié les données.</p>","frontmatter":{"date":"July 06, 2026","slug":"ai-open-source-and-intellectual-property","title":"IA, Open Source et Propriété Intellectuelle","description":"Comment l'entraînement de l'IA met au défi l'open source, le droit d'auteur, les licences, et la lutte plus large autour du travail créatif, des voix, des visages et de l'identité numérique.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"ai-open-source-and-intellectual-property","lang":"fr","langPathPrefix":"/fr"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}