Les modérateurs ont dû poser la question
Il y a en ce moment un post épinglé sur r/opensource qui se lit comme une communauté qui se prépare à une inondation. Les modérateurs demandent au subreddit de définir une politique sur les contributions assistées par IA — précisément ce que tout le monde appelle désormais le « vibe-coding » — et le fil a coupé la salle en deux : 87 % d’upvotes, mais des commentaires en véritable bagarre générale.
Je lis ces commentaires depuis une semaine, et je n’arrête pas de me dire : ce n’est pas vraiment une bagarre sur l’IA. C’est une bagarre sur ce que « open source » veut dire quand la personne qui écrit le code n’est pas une personne.
Soyons clair sur ce qui est réellement proposé, parce que c’est facile à caricaturer. Personne ne défend sérieusement l’interdiction pure et simple des outils d’IA — pas au niveau de la politique. Le débat porte sur les contributions : un projet peut-il raisonnablement accepter un patch dont l’auteur ne peut ni l’expliquer, ni le défendre, ni en être tenu responsable ? Un mainteneur doit-il merger un diff généré par un modèle que le contributeur n’a pas lu ?
Cette question a l’air philosophique. Elle ne l’est pas. C’est la question la plus concrète de l’open source en ce moment, et il nous reste environ dix-huit mois pour y répondre avant qu’elle ne se réponde toute seule.
Le problème du vibe-coding est réel, et ce n’est pas une question de fainéantise
Laissez-moi défendre honnêtement le camp du « ban », parce qu’il est facile à caricaturer en luddites, et ce n’est pas ça.
L’objection centrale n’est pas « le code IA est mauvais ». C’est que la responsabilité est tout le contrat social de l’open source. Quand vous soumettez un patch, vous vous engagez à quelque chose : vous comprenez le changement, vous pouvez en expliquer le raisonnement, et vous en assumerez les conséquences. C’est pour ça que « ça marche sur ma machine » est une blague récurrente et que « je ne sais pas pourquoi ça marche » est une lettre de démission. La revue de code n’est pas qu’un contrôle qualité — c’est la façon dont la communauté vérifie que vous comprenez ce que vous avez fait.
Le vibe-coding brise ce contrat. Un contributeur colle un message d’erreur dans un modèle, récupère un diff, ne teste rien, ne lit rien, et ouvre une PR. Le diff est peut-être même correct — mais le contributeur ne peut pas expliquer pourquoi, ne peut pas le défendre en revue, et disparaît à l’instant où un bug subtil se révèle en production. Le mainteneur a hérité d’un code dont aucun auteur ne le comprend. Ce n’est pas une contribution ; c’est un passif avec une coche verte.
L’inondation est la seconde moitié de la peur. Les LLM rendent gratuit la production de code plausible à un rythme qu’aucun humain ne peut relire. Si un projet devient connu pour accepter des patchs générés par IA sans examen, il en attire davantage. Le rapport signal/bruit s’effondre. Les mainteneurs — déjà la ressource la plus rare de l’open source, déjà en burn-out — se noient dans des ordures plausibles qu’ils doivent désormais lire attentivement parce qu’elles sont plausibles.
C’est un problème réel, urgent et concret. Une politique n’est pas déraisonnable.
Mais c’est là que ça devient juridiquement étrange
Maintenant, laissez-moi introduire la chose qui rend ce débat différent de tous les autres débats « faut-il utiliser l’IA » de l’histoire : la question du copyright.
Les règles qui gouvernent l’open source sont, au fond, des règles de copyright. Une licence permissive comme MIT fonctionne parce que l’auteur cède des droits sur du code qu’il possède. Tout l’édifice — le copyleft, l’attribution, les clauses virales de la GPL — suppose qu’il existe un détenteur de copyright avec des droits à céder.
Le code généré par une machine se situe dans une zone grise, et les tribunaux ne l’ont pas résolue. Le Copyright Office américain a été clair sur le fait qu’une œuvre produite sans paternité humaine n’est pas protégeable — un singe ne peut pas détenir de copyright, et un modèle opérant sans contribution créative humaine significative non plus, du moins selon les directives actuelles. La question ouverte est de savoir où commence la « contribution humaine significative » : éditer le prompt suffit-il ? Sélectionner parmi les sorties ? Relire et refactoriser le résultat ? Personne ne le sait, parce que la loi est en train de s’écrire en temps réel au gré de quelques affaires de tribunaux de district.
Voici donc le scénario cauchemar pour un projet open source : vous mergez un patch vibe-codé, et six mois plus tard un tribunal (ou le Copyright Office) précise que ce patch n’est pas protégeable, ou que son copyright est trouble. Qu’arrive-t-il à la licence de votre projet ? Une chaîne n’est aussi solide que son maillon le plus faible — si un fichier d’un projet GPL n’a pas de détenteur de copyright valide, que veut même dire « copyleft » pour ce fichier ? Le projet a-t-il encore qualité à agir pour faire respecter la GPL ? Vos contributeurs ont-ils encore les droits qu’ils pensaient vous avoir cédés ?
Personne n’a de réponse propre. C’est la vraie raison pour laquelle r/opensource ne peut pas simplement balayer la question d’un « du bon code est du bon code ». Un projet ne peut pas évaluer la propreté juridique d’un patch en lisant le diff — la provenance du code fait désormais partie de ses métadonnées, et la provenance est exactement ce que le vibe-coding efface.
Les trois camps, tels que je les vois
À la lecture du fil, la communauté s’est triée en trois positions, et j’ai de la sympathie pour les trois.
Le camp du « non à l’IA » veut des règles de divulgation ou des interdictions pures : marquer les patchs assistés, ou les rejeter. Leur logique, c’est l’argument de responsabilité ci-dessus, plus une forte dose de grief culturel — le code IA est un raccourci, l’open source a toujours été une culture du métier, et ils ne veulent pas voir le métier noyé par des gens qui ne peuvent pas s’en donner la peine.
Le camp du « ce n’est qu’un outil » fait remarquer, à juste titre, qu’on a déjà eu ce débat. Le copier-coller de Stack Overflow, c’était du vibe-coding avant les LLM. Chaque autocomplétion aussi. La frontière entre « généré par IA » et « assisté par IA » est de toute façon inapplicable — si j’utilise Copilot pour compléter une fonction, est-ce une catégorie différente de la complétion d’une boucle ? Tracer la ligne est une quête perdue d’avance, et l’effet pratique d’une interdiction, c’est simplement… de mentir à son sujet.
Le camp de la « provenance » — dans lequel je me retrouve — pense que le vrai correctif n’est pas d’interdire l’outil, mais de restaurer la responsabilité que l’outil efface. Exiger des contributeurs qu’ils assument leurs patchs d’une façon qui ne dépend pas de la façon dont ils les ont produits : vous pouvez utiliser n’importe quel modèle, mais vous devez pouvoir expliquer le changement, le défendre et en prendre la responsabilité. À l’instant où vous ne pouvez pas expliquer votre propre patch, peu importe qu’un humain ou une machine l’ait écrit — il échoue à la revue.
L’argument du camp de la provenance, c’est que la zone grise juridique est réelle, mais qu’une politique ne peut pas la réparer — seule la transparence le peut. Une norme de divulgation (« ce patch est assisté par IA, voici comment ») est plus durable et plus applicable qu’une interdiction, et c’est la seule chose qui permette aux projets d’évaluer réellement leur propre risque.
La convergence silencieuse avec tout le reste du mois
Voici ce que je trouve frappant : ce débat converge avec une douzaine d’autres fils de la même semaine.
Rust vient de formaliser une politique sur les contributions assistées par LLM — pas une interdiction, mais un cadre de gouvernance, exactement le manuel du camp de la provenance. Claude a commencé à tatouer sa sortie par stéganographie, et la réaction de la communauté open source a été de hurler et d’appeler à abandonner les modèles fermés — le grief du camp du « non à l’IA » qui trouve sa cible. Et un Open Source Endowment vient de se lancer pour financer les mainteneurs, ce qui est le vrai problème racine sous tout ça : il n’y a pas assez d’humains pour relire le code qui existe déjà, encore moins l’inondation qu’un million de LLM s’apprête à générer.
Le fil commun, c’est que l’open source découvre, d’un coup, que son hypothèse fondatrice — le code a un auteur, et l’auteur peut être tenu responsable — est attaquée par une technologie qui produit du code sans auteur. Chaque débat de ce mois-ci est un angle différent sur cette même fissure dans les fondations.
Ce que j’en pense vraiment
Je vais être direct, parce que c’est la mission.
Je ne pense pas que r/opensource devrait bannir l’IA. Je pense qu’une interdiction est inapplicable, culturellement aliénante, et — pire — qu’elle nous laisse croire qu’on a résolu un problème qu’on n’a fait que nommer. Le problème n’est pas le modèle. Le problème, c’est que l’open source n’a jamais eu à vérifier la paternité, et que maintenant il le doit.
Ce que je veux sortir de ce débat, c’est quelque chose de moins excitant qu’une interdiction et de beaucoup plus difficile : une norme de provenance et de responsabilité qui survive au contact du réel. Divulguez quand un patch est assisté par IA. Assumez chaque patch que vous soumettez, quelle que soit la façon dont vous l’avez fait. Et — c’est la partie que personne ne veut entendre — acceptez que la question juridique du copyright généré par machine sera tranchée par des tribunaux, pas par des subreddits, et que d’ici là, chaque projet qui merge du code sans provenance porte un risque qu’il ne peut pas pleinement mesurer.
Ce qui m’inquiète, ce n’est pas que le camp du « non à l’IA » gagne. C’est que le débat devienne ennuyeux — qu’on rejoue « l’IA c’est bien ou c’est mal » pour la centième fois sans jamais arriver au vrai travail, qui est de comprendre comment une communauté qui fonctionne sur la confiance et l’attribution peut continuer quand l’attribution cesse d’être automatique.
Je reviens sans cesse à une image : un mainteneur à 2 h du matin, qui fixe un diff techniquement correct mais clairement généré, soumis par quelqu’un qui est allé se coucher, et qui se demande si le merger relève de l’artisanat ou de la faute professionnelle. Ce mainteneur n’a pas besoin d’une interdiction. Il a besoin d’un moyen de dire non — ou oui, mais voici ce dont j’ai besoin de toi d’abord — sans se faire traiter de luddite ni de vendu.
C’est la politique que r/opensource essaie vraiment d’écrire. J’espère qu’ils l’écriront bien, parce que le reste d’entre nous va la copier.
La discussion de politique de r/opensource est un post épinglé par les modérateurs sur le subreddit. Ça vaut la peine de lire les commentaires — pas pour les prises de position, qui sont les habituelles, mais pour la façon dont une communauté qui a passé trente ans à faire confiance à l’attribution essaie de comprendre quoi faire quand l’attribution cesse d’être automatique.