IA et open source : en attendant la jurisprudence

L’essor de l’intelligence artificielle soulève de nouveaux défis juridiques, notamment dans le domaine du développement logiciel. La question devient primordiale : en cas de litige lié au code généré ou assisté par l’IA, qui devra répondre devant la jurisprudence ?

Résumé exécutif

• Les interdictions (QEMU, Gentoo, NetBSD) traduisent une défiance grandissante : sans traçabilité, impossible de respecter le DCO et d’éviter la « pollution » de licences.
• La Linux Foundation opte pour un transfert de risque : elle accepte le code IA mais en fait porter la responsabilité totale au contributeur.
• Le danger clé n’est pas seulement la copie involontaire : c’est le chantage potentiel où l’adversaire brandit l’argument « c’est de l’IA, prouvez l’originalité ».
• Les bénéfices restent réels (revue de code, documentation, prototypage rapide) mais exigent des garde-fous humains et des outils de similarité.
• En l’absence de jurisprudence IA claire (Doe v. GitHub, AI Act, etc.), la prudence domine ; l’avenir passera par des standards de provenance et/ou l’adaptation du DCO.

Glossaire express

• DCO (Developer’s Certificate of Origin) : attestation sur l’honneur de l’auteur indiquant qu’il a le droit de contribuer au code.
• SPDX : format standard d’identification des licences dans le code source.
• AI Act : règlement européen (2024-2026) fixant des obligations de transparence et de gestion des risques pour les systèmes d’IA.
• Chantage à la preuve : stratégie consistant à discréditer une contribution en pointant l’usage d’IA et l’absence de traçabilité.
• LLM : Large Language Model, modèle de langage génératif de grande taille.

Cet article propose un tour d’horizon des positions extrêmes (interdiction) et pragmatiques (acceptation conditionnelle), puis identifie les défis techniques, juridiques et culturels à relever.

Introduction : du workflow par e-mail au choc de l’IA

En tant qu’utilisateur régulier de Proxmox, j’ai récemment souhaité contribuer à ce projet d’infrastructure fondamental. C’est en explorant les modalités de contribution que j’ai découvert, avec surprise, que Proxmox et son écosystème s’appuient encore sur un processus par patchs et e-mails – un monde à part pour quelqu’un habitué au bouton Merge de GitHub. Cette apparente bizarrerie technique m’a poussé à me demander pourquoi ils persistent avec ces méthodes “à l’ancienne”. En creusant, j’ai réalisé que cela reflète une culture de la rigueur, une obsession pour la provenance du code qui s’avère être aujourd’hui la ligne de défense la plus critique face à l’un des plus grands défis de notre temps : l’intelligence artificielle générative.

En tant qu’utilisateur intensif d’outils d’IA — parfois même trop, j’en conviens ! — j’ai été le premier séduit par la facilité avec laquelle ces modèles transforment une idée floue en texte ou en code exploitable. Mais la lecture de la décision de QEMU m’a forcé à réaliser que, dans notre enthousiasme, nous avons souvent négligé la question cruciale : qui portera la responsabilité juridique en cas de litige ?

La position conservatrice de QEMU face à l’IA

Le débat a été cristallisé par la décision radicale de projets comme QEMU, d’interdire purement et simplement les contributions contenant du code généré par IA. Comme le montrent les discussions au sein de la communauté des développeurs, par exemple sur des plateformes comme Lobste.rs, cette position n’est pas un jugement sur la qualité technique de l’IA. C’est une mesure de protection juridique, une décision conservatrice face à un abîme d’incertitudes. La crainte fondamentale étant que le code généré par IA ne puisse satisfaire aux exigences du Developer’s Certificate of Origin (DCO), ce pacte de confiance sur lequel repose une grande partie de l’open source.

Le DCO et les défis posés par l’IA

Pour comprendre le blocage, il faut revenir sur le DCO. Né des cendres des batailles juridiques des années 2000 (comme SCO vs. IBM), le DCO est une simple ligne (Signed-off-by: …) où un développeur certifie sur l’honneur avoir lui-même créé le code et avoir le droit de le soumettre.

C’est ici que l’analyse de Shuji Sado est la plus éclairante. Il identifie deux raisons pour lesquelles l’IA brise ce contrat de confiance :

1. Le problème de l’auteur humain : Dans de nombreuses juridictions, une œuvre générée par une IA n’est pas protégeable par le droit d’auteur car elle n’a pas d’auteur humain. Comment un contributeur peut-il alors certifier avoir “créé” le code ?

2. L’incertitude de la “propreté” du code : Les IA ont été entraînées sur un corpus de données mondial, incluant du code sous des licences variées et incompatibles, voire du code propriétaire. Rien ne garantit alors, que l’IA ne régurgite pas un extrait de ce code, contaminant ainsi le projet receveur.

Les défis posés par l’IA au DCO sont également analysés dans des travaux académiques, comme celui de Ioannidis et al, qui suggèrent de modifier les licences pour clarifier les responsabilités.

L’approche pragmatique de la Linux Foundation

Face à cette impasse, tout le monde ne choisit pas la voie de l’interdiction. La Linux Foundation, qui est pourtant à l’origine du DCO, a publié une directive qui tente de trouver un équilibre. En substance, elle autorise les contributions issues de l’IA, mais elle opère un transfert complet du risque sur le développeur. Ce dernier doit personnellement garantir deux choses :

1. Que les conditions d’utilisation de l’outil d’IA lui permettent d’utiliser le résultat sous une licence open source.

2. Que le code généré ne contienne pas de matériel tiers protégé, ou si tel est le cas, qu’il ait la permission de l’utiliser et qu’il fournisse l’attribution nécessaire.

Cette politique, bien que se voulant progressiste, est un pari. Elle demande à un développeur de certifier la propreté d’un code dont il ne maîtrise pas le processus de création, généré par une boîte noire dont le contenu est un secret commercial.

Les avantages potentiels de l’IA dans l’open source

Malgré ces risques, l’IA générative offre des opportunités significatives pour l’open source. Mon expérience personnelle montre que des outils comme GitHub Copilot peuvent accélérer le développement en suggérant du code réutilisable, aidant les contributeurs à prototyper rapidement des idées tout en respectant les licences compatibles. Par exemple, une étude de GitHub indique que Copilot peut augmenter la productivité des développeurs jusqu’à 55% dans certaines tâches. De plus, l’IA peut assister dans la revue de code, la détection de bugs ou la génération de documentation, boostant ainsi la productivité sans compromettre la qualité, si celle-ci est utilisée avec discernement.

Cependant, pour maximiser ces bénéfices, il est important de combiner l’IA avec des vérifications humaines rigoureuses, comme le soulignent des études récentes sur l’intégration de l’IA dans les workflows open source. Cette perspective positive contraste avec les défis précédents, soulignant la nécessité d’un équilibre entre innovation et prudence.

Les risques juridiques et le chantage à la preuve

Cette situation crée un terrain de jeu idéal pour les acteurs malveillants. Le risque le plus sophistiqué n’est plus l’accident, mais le chantage à la preuve par l’IA. Imaginons un scénario : une entreprise peu scrupuleuse voit un projet innovant, fabrique de fausses preuves d’antériorité pour l’idée, et attaque l’auteur. Son argument ? “L’auteur a admis utiliser l’IA. Il ne peut donc pas prouver que son ‘invention’ ne vient pas de notre code, auquel l’IA a eu accès via une obscure fuite de données.”

Le fardeau de la preuve est inversé de manière diabolique. L’IA devient un levier pour rendre une attaque crédible et une défense quasiment impossible, forçant l’innovateur à un règlement à l’amiable coûteux. Ce phénomène rappelle étrangement les craintes des acteurs et scénaristes d’Hollywood : comment prouver qu’une performance ou un script n’est pas une variation subtile de leur travail original, modifiée juste assez par l’IA pour échapper aux protections légales ?

Jurisprudence IA : l’attente d’un cadre juridique clair

En l’absence de solution technique miracle — comme un “tampon bio” qui certifierait la provenance du code, une idée séduisante mais commercialement et juridiquement irréaliste pour les fournisseurs d’IA — tous les regards sont tournés vers les tribunaux.

Le monde de la technologie attend fébrilement que la jurisprudence (les décisions des tribunaux qui créent des précédents légaux) commence à dessiner des lignes claires. Le cas le plus suivi est le recours collectif Doe v. GitHub, où des développeurs attaquent GitHub pour avoir entraîné son IA Copilot sur leur code sans permission. Selon des rapports récents, le cas est en appel depuis novembre 2023, avec un focus sur la question de l’« identicality » – si le code généré doit être exactement identique pour constituer une violation de copyright.

Depuis avril 2025, l’appel de cette affaire se concentre sur une question cruciale : le code généré par l’IA doit-il être identique au code original pour constituer une violation ? C’est le cœur du débat sur l’« identicality ». Pour simplifier : si l’IA génère du code qui fait la même chose que votre code mais avec une syntaxe légèrement différente, est-ce du vol ou non ?

Cette question fait écho aux grèves d’Hollywood de 2023, où acteurs et scénaristes luttaient contre le même problème. Les juges estiment pour l’instant que seule une copie exacte, caractère par caractère, constitue une violation. Cette interprétation très restrictive crée un précédent dangereux : elle laisse un boulevard aux IA pour “paraphraser” – que ce soit le code d’un développeur, le style de jeu d’un acteur, ou la plume d’un scénariste. Qui empêchera l’IA de prendre un modèle humain, de le modifier subtilement, et de contourner ainsi toute protection ? C’est précisément ce mécanisme de contournement qui rend la législation urgente et nécessaire. Ces décisions devront trancher : quelle est la nature juridique d’une œuvre générée par IA ? Quelle est la responsabilité des plateformes ?

L’impact de l’AI Act européen

Cette incertitude juridique se complexifie davantage avec l’entrée en vigueur progressive de l’AI Act européen. Cette réglementation, première du genre au monde, impose des obligations de transparence et de traçabilité (le registre public des modèles à haut risque n’ouvrira qu’au début 2026). Elle classe les systèmes d’IA selon des niveaux de risque – inacceptable, haut risque, limité et minimal – avec des règles plus strictes pour les plus risqués. Adoptée en juin 2024, elle entre en vigueur par phases à partir d’août 2024, avec une application complète d’ici 2027. Le Parlement européen a mis en place un groupe de travail pour superviser son implémentation et s’assurer qu’elle favorise l’innovation numérique en Europe. Elle pourrait indirectement favoriser les approches restrictives comme celle de QEMU. Si les systèmes d’IA doivent documenter leurs données d’entraînement et leurs processus de développement, comment concilier cette exigence avec l’utilisation d’outils génératifs dont la “boîte noire” échappe précisément à cette traçabilité ? L’Europe pourrait ainsi devenir un catalyseur involontaire de la prudence juridique dans l’open source mondial.

Les limites des modèles d’IA ‘open source’

Parallèlement, l’émergence de modèles comme DeepSeek, présentés comme “open source” tout en gardant secrètes leurs données d’entraînement, illustre une nouvelle forme de ce schisme. (Le code est bien publié sous licence MIT, mais le communiqué du 18 février 2025 confirme que le corpus d’entraînement demeure confidentiel.) Ces projets relancent le débat fondamental : peut-on vraiment parler d’open source quand les éléments cruciaux restent opaques ? Cette question, qui semblait théorique il y a encore quelques mois, devient centrale alors que l’industrie tente de surfer sur la légitimité de l’open source sans en accepter pleinement les contraintes de transparence.

Un déjà-vu historique : l’humanité face aux révolutions technologiques

L’histoire nous enseigne que chaque révolution technologique majeure s’accompagne invariablement d’abus et de résistances. De l’imprimerie de Gutenberg qui menaçait les copistes médiévaux, à la photographie qui terrorisait les peintres portraitistes, en passant par l’enregistrement sonore qui devait “tuer” la musique live, nous avons toujours oscillé entre exploitation créative et détournement malveillant des nouveaux outils.

Mais alors, qui empêchera l’IA de prendre un modèle humain, de le modifier subtilement, et de contourner ainsi toute protection ? C’est exactement le même dilemme avec le code : une IA peut “paraphraser” syntaxiquement du code protégé, créant une œuvre techniquement différente mais fonctionnellement identique.

Cette capacité de contournement souligne l’urgence de légiférer. Sans cadre juridique clair établi maintenant, l’IA risque d’être perçue soit comme un outil de pillage légalisé, soit comme une menace existentielle à la création humaine. L’absence de régulation favorise les acteurs malveillants qui exploiteront ce vide juridique, tandis que les créateurs légitimes – qu’ils soient acteurs, scénaristes ou développeurs – se retrouvent sans protection.

Conclusion : quelles pistes pour sortir de l’impasse ?

En attendant, nous sommes dans une ère de schisme qui rappelle d’autres moments charnières de l’histoire technologique. D’un côté, des projets qui acceptent le risque pour ne pas freiner l’innovation, pariant sur les bénéfices à long terme. De l’autre, des projets d’infrastructure comme QEMU qui, par leur culture de la rigueur, choisissent de se barricader. Leur position, loin d’être un rejet de la technologie, est un acte de sagesse préventive : face à un jeu dont les règles sont inconnues et potentiellement truquées, la seule stratégie gagnante est de refuser de jouer.

Face à cette incertitude, plusieurs voies pourraient être explorées. Sur le plan technique, le développement d’outils de traçabilité et d’analyse de similarité pour le code généré par IA pourrait rassurer les communautés open source. Par exemple, des modèles d’apprentissage automatique disponibles sur Hugging Face permettent de détecter du code généré par IA avec une précision croissante. Juridiquement, une évolution du DCO ou l’apparition de clauses spécifiques à l’IA dans les processus de contribution pourraient clarifier les responsabilités. L’Open Source Initiative (OSI) mène une initiative sur la définition de l’IA open source, proposant des standards pour les modèles d’IA, y compris des checklists et FAQs pour guider les projets. Enfin, la coopération entre juristes, développeurs et institutions (comme l’OSI ou la Linux Foundation) sera essentielle pour définir des standards adaptés à l’ère de l’IA.

Tant que la réponse restera floue sur qui portera la responsabilité juridique en cas de litige, aucun tribunal ne voudra trancher un sujet dont les répercussions (humaines et surtout financières) seraient gigantesques. En attendant, la vigilance et la transparence restent les meilleurs alliés des projets open source.

Questions fréquentes (FAQ)

Puis-je utiliser GitHub Copilot dans mon side-project ?
Oui, si le projet reste purement personnel ou interne. Dès que vous visez une diffusion open source, assurez-vous de pouvoir justifier la provenance de chaque morceau de code généré – ou tenez-vous prêt à le réécrire.

Qu’est-ce qu’un patch « Signed-off-by » ?
C’est la signature exigée par le DCO : l’auteur atteste avoir créé le contenu ou être habilité à le publier et à choisir la licence.

Existe-t-il une exception pour la simple documentation générée par IA ?
Certains projets l’acceptent, mais QEMU, Gentoo ou NetBSD l’interdisent par principe de précaution. La Linux Foundation l’autorise si vous assumez l’entière responsabilité.

Où lire exactement la clause anti-IA de QEMU ?
Sur le dépôt officiel : https://github.com/qemu/qemu/blob/master/docs/devel/code-provenance.rst#use-of-ai-content-generators.

Comment vérifier si mon code IA respecte les licences ?
Utilisez des outils comme ScanCode pour analyser les licences et détecter les similarités avec du code existant, en vérifiant manuellement les sorties pour assurer la conformité.