Traduction de Why Open Source Doesn’t Embrace AI par Justin sur From The Architect, 27 mai 2026 · 10 min
Il y a une semaine, je vous aurais dit que la communauté open source rejetait l’IA pour quatre raisons évidentes. Puis j’ai essayé de défendre chacune d’elles de manière rigoureuse. La plupart s’effondrent à l’examen — et ce qui reste, c’est un débat bien plus constructif.
La réponse habituelle
Tous les responsables de projets que je connais ont à peu près les trois ou quatre mêmes critiques à l’égard des outils d’IA.
Premièrement, personne ne peut dire d’où proviennent les données d’entraînement, ce qui ne passe pas bien dans une culture obsédée par la provenance. Deuxièmement, les responsables de projets croulent sous les PR et les rapports CVE générés par l’IA — les articles de Daniel Stenberg sur le côté curl de cette question en sont désormais l’exemple par excellence. Troisièmement, l’IA court-circuite l’ancien cycle d’apprentissage où les contributeurs apprenaient une base de code en gagnant la confiance des réviseurs au fil des mois. Et quatrièmement, l’asymétrie des pouvoirs : les modèles de pointe nécessitent des capitaux d’hyperscalers, ce qui s’inscrit mal dans un mouvement fondé sur le principe « vous pouvez lire, modifier et redistribuer le code ».
C’est l’argumentaire standard. Présentez-le à n’importe quel contributeur au FOSDEM et vous obtiendrez des hochements de tête approbateurs de la part de tout le monde. C’est aussi la position que je vous aurais donnée il y a une semaine, avant d’essayer de la défendre en détail et de réaliser que la plupart de ses arguments ne tiennent pas vraiment la route.
L’argument gagnant-gagnant
La critique la plus courante que j’entends de la part des développeurs est simple. Si l’IA est entraînée sur de l’open source, puis utilisée pour écrire davantage d’open source, c’est sûrement une victoire pour tout le monde. L’argument, en gros, est que l’open source a formé le modèle, et que le modèle aide désormais les gens à produire davantage d’open source.
La réponse immédiate est que la valeur ne circule pas. Le code est introduit gratuitement dans le modèle, est « blanchi » par l’entraînement, puis ressort derrière un mur payant loué à une entreprise privée. Le contributeur dont le code a façonné GPT-5, Claude ou Copilot ne touche aucune part, n’est pas crédité et paie les mêmes frais d’abonnement que tout le monde. Comparez cela à la façon dont l’open source fonctionne habituellement : je corrige un bogue dans libcurl, la correction reste dans libcurl, tous les utilisateurs en aval en bénéficient, le projet s’en trouve amélioré de façon permanente. Avec les LLM, le projet en amont n’obtient rien.
Cette réponse est satisfaisante. C’est aussi là que l’argument commence à vaciller.
Le problème RHEL
L’argument de la communauté contre l’extraction de l’IA doit tenir compte du fait qu’elle a joyeusement toléré l’extraction à une échelle bien plus grande pendant des décennies.
Red Hat fournit des correctifs du noyau en amont, mais Satellite, Insights et Ansible Automation Platform sont propriétaires. Ils ont gagné des milliards grâce à un noyau qu’ils n’ont pas écrit, ont restreint la distribution du code source aux clients payants en 2023, et restent systématiquement parmi les principaux contributeurs d’entreprise à Linux. La communauté a râlé, mais a continué à utiliser RHEL (Red Hat Enterprise Linux). L’extraction par les fournisseurs de cloud a frappé Elasticsearch et MongoDB si fort que les deux ont modifié leur licence par mesure d’autodéfense — Elastic visant directement AWS, MongoDB de manière préventive contre l’ensemble du secteur du cloud — et nous utilisons toujours tous AWS. Amazon Linux 2023 est un dérivé de Fedora. Ils gardent le plan d’orchestration fermé. Personne n’organise de boycott.
Si RHEL s’en tire avec Satellite, un logiciel à code source fermé, tout en gagnant des milliards grâce à un noyau qu’il n’a pas écrit, la critique de l’IA ne peut pas se limiter à « ils ont tiré profit des biens communs ». Cela va trop loin. Cela exclut tout le secteur des services gérés dont l’open source est désormais dépendant.
Ce que Valve montre réellement
Valve est probablement le contre-exemple le plus solide dont dispose la position anti-IA. La Steam Deck est livrée avec KDE Plasma en mode bureau, donc le travail de Valve sur la Steam Deck finance une société de conseil — Techpaladin depuis 2025, Blue Systems avant cela — qui emploie à son tour une part importante de l’équipe de développement de KDE Plasma, y compris Nate Graham et David Edmundson. Valve finance également les travaux sur Mesa, les graphiques du noyau, Wine, Gamescope et PipeWire par le biais d’arrangements similaires. KDE Plasma sur Wayland en 2026 est nettement meilleur qu’il ne l’était en 2022, et une part non négligeable de cette amélioration est due à l’argent de Valve.
Mais la raison pour laquelle cela fonctionne est importante, car cela ne se généralise pas comme la communauté le souhaiterait parfois.
Valve redistribue des binaires sous licence GPL sur chaque Deck qu’elle commercialise. La licence impose tout ce qui en découle. Elle doit fournir le code source, elle doit se conformer au copyleft, et le financement en amont relève en partie d’un intérêt personnel éclairé, car l’alternative serait de créer un fork et de le maintenir indéfiniment. Ce n’est pas de la générosité morale, c’est la logique des licences. Le noyau Linux l’a contrainte à respecter les règles de Linux.
Les fournisseurs d’IA ne redistribuent pas le code. Ils l’utilisent pour l’entraînement. La question juridique centrale est de savoir si cela déclenche une licence quelconque — et jusqu’à présent, les tribunaux ont penché vers « non, ce n’est pas le cas ». Ce qui signifie que la comparaison avec Valve ne nous dit pas réellement ce que nous voulons qu’elle nous dise. Elle nous dit que lorsque la distribution déclenche le copyleft, le copyleft fonctionne. Elle ne dit rien sur ce qui se passe lorsque la distribution n’entre pas en ligne de compte.
L’inspiration n’est pas de la copie
C’est la partie de l’argumentation sur laquelle j’ai le plus évolué, et celle qui pose le plus de problèmes à la position farouchement anti-IA.
Si le droit d’auteur considérait « l’apprentissage à partir du code » comme une infraction, l’industrie du logiciel s’effondrerait sous son propre poids. Tous les ingénieurs chevronnés que je connais ont passé des années à lire le code d’autres personnes et à en reprendre inconsciemment les modèles. J’ai appris à structurer une application GTK en lisant le code du plugin de Builder. La moitié de ce que je sais sur le C de production vient de la lecture de curl. Rien de tout cela n’a donné à libcurl ou à Builder un droit sur ce que j’écris ensuite. Ce qui est gênant, c’est que les LLM industrialisent ce processus à une échelle que les humains ne pourraient jamais atteindre — et une grande partie de la réaction instinctive de la communauté porte sur ce changement d’échelle, et non sur la question juridique qui le sous-tend.
La véritable question juridique n’est pas de savoir si « l’entraînement constitue une infraction ». Jusqu’à présent, les tribunaux américains semblent favorables aux arguments d’utilisation transformative concernant l’entraînement lorsque les données d’entraînement ont été acquises légalement — le règlement de 1,5 milliard de dollars conclu par Anthropic dans l’affaire Bartz c. Anthropic l’année dernière, concernant des livres obtenus sur des sites de piratage, en est le contre-exemple concret, et cela scinde la question en deux parties. L’entraînement sur des textes sous licence légale semble défendable ; la manière dont le corpus a été constitué est un autre sujet. Et l’UE s’engage à nouveau dans une direction différente. La question intéressante qui reste est de savoir si le résultat constitue une contrefaçon lorsqu’il reproduit mot pour mot les données d’entraînement. C’est au moins un problème sur lequel les tribunaux peuvent se prononcer.
Et une fois que l’on sépare le fait que « l’entraînement a eu lieu » du fait qu’« une expression spécifique a été reproduite », le logiciel commence à paraître étrangement différent de la plupart des médias créatifs pour lesquels le droit d’auteur a été conçu. Il n’y a qu’un nombre limité de façons d’écrire du code.
Le droit d’auteur dispose déjà d’un concept pour cela : il s’agit de la fusion. S’il n’existe qu’une poignée de façons sensées d’exprimer quelque chose, la protection du droit d’auteur devient très fragile. Personne ne détient la propriété de la boucle canonique for. Personne ne détient la propriété de la forme standard d’un tri rapide ou d’une recherche binaire. Il existe une doctrine connexe appelée scènes à faire pour les éléments de base inévitables dans un genre. L’affaire Google c. Oracle (2021) a abordé un domaine connexe : la Cour a considéré le code de déclaration de Java comme hautement fonctionnel et a finalement jugé l’utilisation de Google équitable, la contrainte fonctionnelle étant l’un des facteurs qui a fait pencher l’analyse en faveur de Google.
Appliquez cela au débat sur l’IA et bon nombre des affirmations du type « regardez, le modèle a généré du code GPL ! » s’affaiblissent à l’examen. Entraînez-vous sur suffisamment de code et les correspondances exactes à elles seules ne vous apprendront plus grand-chose — la plupart des bases de code non triviales partagent suffisamment de motifs de surface pour qu’il y ait forcément des chevauchements. Le véritable critère juridique n’est pas « la sortie correspond-elle ? », mais « la sortie correspond-elle d’une manière qui n’a aucune justification fonctionnelle ? ».
Preuves solides de copie : noms de variables idiosyncrasiques, style de commentaire distinctif, choix algorithmiques inhabituels, bogues reproduits, en-têtes de droits d’auteur reproduits mot pour mot, tics spécifiques à un auteur. Les célèbres exemples de Copilot — la racine carrée inverse rapide de Quake III avec le commentaire // what the fuck? intact, les en-têtes de licence GPL complets — sont réels et accablants. Ils ne peuvent invoquer la défense de la fusion.
Preuves faibles de copie : un tri rapide qui ressemble à n’importe quel autre tri rapide, une fonction de hachage qui correspond parce qu’il existe six façons raisonnables de l’écrire, du code standard qui converge parce que le code standard converge. Un tribunal appliquant la doctrine de la fusion rejetterait la plupart de ces cas sans sourciller.
Ainsi, la véritable préoccupation restante en matière de contrefaçon n’est pas que « la régurgitation existe ». C’est la régurgitation ciblée d’expressions idiosyncrasiques, non contraintes sur le plan fonctionnel. La suppression des correspondances exactes est gérable, et certains fournisseurs le font déjà. Détecter des résultats transformés ou partiellement mémorisés est beaucoup plus difficile en pratique, et c’est là que réside le véritable travail d’ingénierie. Mais il s’agit toujours de travail d’ingénierie, pas d’une impasse philosophique.
Ce qui reste réellement
Une fois les slogans mis de côté, les objections se réduisent assez rapidement. Rien de ce qui reste n’est faux. Rien de tout cela ne correspond à ce à quoi ressemble habituellement le discours.
Le premier point est l’auditabilité. La culture open source repose sur des traces — git blame, archives de listes de diffusion, bases de données CVE, lignes de signature — tout l’appareil est construit autour de la possibilité de retracer la valeur jusqu’à sa source. La contribution de RHEL au domaine public est vérifiable jusqu’au niveau du correctif. Celle de Valve est vérifiable jusqu’au développeur. Les fournisseurs d’IA n’offrent rien d’équivalent. Le corpus d’entraînement n’est pas divulgué, les poids sont fermés, et il n’y a aucun moyen de calculer quelle fraction de la capacité d’un modèle provient de votre projet par rapport à celui de quelqu’un d’autre. L’objection n’est pas vraiment « vous avez pris notre code ». C’est « vous avez pris notre code et nous n’avons aucun moyen de vérifier ce qui s’est passé ensuite ». C’est une critique du processus, mais elle est légitime, et on pourrait en principe y répondre.
La deuxième concerne la régurgitation ciblée — le cas où les modèles restituent mot pour mot des morceaux idiosyncrasiques de données d’entraînement, non pas une convergence statistique sur des modèles standard, mais une reproduction réelle d’expressions distinctives. Il s’agit d’un véritable problème de violation, mais d’ordre technique. La détection des correspondances exactes est résolue. La mémorisation sémantiquement équivalente ne l’est pas. Le travail est réel, mais le problème est circonscrit.
Le troisième cas est plus difficile, car il n’existe aucune réponse en matière de droit d’auteur. Un humain inspiré par la lecture de Linux bénéficie d’un modeste gain de productivité sur son prochain projet — il doit tout de même l’écrire lui-même. Un LLM formé sur Linux offre à chaque développeur qui l’utilise un gain de productivité substantiel, vendu par abonnement à des millions d’utilisateurs. Le statut juridique est le même que celui de l’humain inspiré. Le transfert économique est radicalement différent. Le droit d’auteur n’a jamais été conçu pour réguler cet écart, car jusqu’à présent, cet écart n’existait pas — l’inspiration était limitée par la capacité cognitive humaine. C’est une préoccupation réelle, mais c’est une question de politique : voulons-nous un nouveau régime fiscal ou de licence pour l’inspiration à l’échelle industrielle ? L’amalgamer avec le droit d’auteur, comme le fait la plupart de la rhétorique communautaire, est négligent — le droit d’auteur ne couvre pas ce qui nous dérange réellement.
Trois choses, donc. Publier les corpus d’entraînement. Lutter contre la régurgitation idiosyncrasique. Avoir une conversation sérieuse pour déterminer si les transferts de productivité à cette échelle nécessitent une réponse politique. Rien de tout cela n’implique de rejeter l’IA.
Le recadrage
Ce qui m’amène à la position sur laquelle j’ai finalement atterri, à savoir que la communauté a jugé les fournisseurs d’IA selon de mauvais critères.
Dans les communautés open source dont je fais partie — GNOME, l’écosystème des crates Rust, le monde Linux de bureau — le développement assisté par l’IA alimente déjà les bases de code publiques à une échelle considérable. Chaque crate Rust, chaque widget GTK, chaque correctif du noyau livré plus rapidement parce que quelqu’un avait un partenaire de programmation compétent dans son éditeur est une contribution au bien commun. Cela n’apparaît tout simplement pas dans les comptes des fournisseurs d’IA. Si l’on mesure la contribution en fonction de ce qui aboutit dans le domaine public plutôt que de ce que le fournisseur de modèles met en open source, le bilan pourrait déjà être positif. Nous mesurons la mauvaise colonne.
La position actuelle de la communauté est, je pense, en partie une erreur de catégorie. Elle juge les fournisseurs d’IA selon les critères que nous appliquons aux forges — GitHub, GitLab, SourceHut — alors que l’analogie la plus proche concerne les compilateurs et les IDE. Personne n’a exigé que les heuristiques d’optimisation de GCC soient reproductibles à partir de données publiques, ni que JetBrains open-source IntelliJ avant de vous autoriser à y écrire des correctifs Linux. L’analogie n’est pas parfaite — les compilateurs n’ingèrent pas de corpus protégés par le droit d’auteur comme le font les modèles de base — mais culturellement, nous avons traité ces outils comme des outils de productivité plutôt que comme des fournisseurs d’infrastructure. Nous les avons jugés en fonction de ce que leurs utilisateurs produisaient.
Il existe une version cohérente de l’argument en faveur de l’IA qui dit : les fournisseurs d’IA sont des fabricants d’outils, pas des propriétaires de plateformes. Jugez-les à l’aune de ce que leurs utilisateurs produisent. Et ce qu’ils produisent ici est massivement plus open source, plus rapide.
La plupart des contributeurs que je connais utilisent déjà ces outils. La vraie question est de savoir ce qui permettrait aux responsables de maintenance de l’admettre publiquement sans avoir l’impression de céder sur l’ensemble du débat — et la réponse, quand on y réfléchit, s’avère être une liste assez courte. Des justificatifs, la suppression de la régurgitation, et une conversation politique honnête sur le transfert de productivité. C’est tout.
Comparé à l’état habituel du débat, c’est une liste bien plus courte que ne le laisse entendre la rhétorique.
Liste évolutive des traductions par Gilles en vrac
Les caractères gras dans le texte sont de Gilles.