Connexion Premium

Le vibe coding met en danger l’open-source selon des économistes

Aux sources de la vibe

Le vibe coding met en danger l’open-source selon des économistes

En générant du code à partir de multiples sources des logiciels libres, le vibe coding détourne en même temps nombre d'utilisateurs des personnes qui ont créé ces logiciels. Les financements, les rapports de bugs et les discussions s'amenuisent en parallèle à la destruction des communautés d'utilisateurs, constatent des chercheurs en économie.

Le 04 février à 13h58

« Dans le modèle commercial traditionnel [de l'open source], où les revenus des développeurs dépendent entièrement de l'engagement direct des utilisateurs, l'écosystème open source ne peut survivre à l'adoption généralisée de l'IA », affirment quatre chercheurs en économie.

Dans une étude mise en ligne sur la plateforme de preprint arXiv et non relue par leurs pairs, Miklós Koren, Gábor Békés, Julian Hinz et Aaron Lohmann, constatent que l'arrivée du vibe coding sur le marché du logiciel a eu des conséquences importantes sur les logiciels libres.

Les deux premiers sont chercheurs en économie à l'Université de Centre Europe (située à Budapest, cofondée et financée par George Soros). Julian Hinz est pour sa part à l'université allemande de Bielefeld et comme Aaron Lohmann, il travaille aussi pour le think tank allemand Kiel Institute.

En suivant le déclin de Stack Overflow ?

Les plateformes de discussions autour du code sur lesquelles les IA génératives ont aussi été entrainées, ont été touchées avant, à l'image de Stack Overflow. Si les volte-face de Stack Overflow à propos de l'IA ont sans doute eu des effets, en 2024, des chercheurs montraient les liens entre l'arrivée massive des LLM dans les outils de développement et la baisse de partage de connaissance sur la plateforme.

Pour illustrer un effet similaire sur les projets open-source, ces quatre chercheurs citent un message récent d'Adam Wathan, responsable de l'entreprise Tailwind Labs qui édite le projet Tailwindcss. Ce dernier explique que son entreprise a licencié 75 % de son équipe en raison de « l'impact brutal » de l'IA.

« Le trafic vers notre documentation a baissé d'environ 40 % depuis début 2023, malgré la popularité croissante de Tailwind », explique-t-il suite à une pull request qui demandait l'ajout d'une fonctionnalité permettant l'optimisation de l'utilisation de cette documentation par les modèles de langage. « Cette documentation est le seul moyen pour les gens de découvrir nos produits commerciaux, et sans clients, nous ne pouvons pas nous permettre de maintenir le framework ».

La monétisation sur la découverte du projet menacée

Les économistes expliquent dans leur étude que tous les projets open-source qui veulent monétiser leur logiciel ne s'appuient pas sur la même stratégie : « Une grande partie des activités monétisées liées aux logiciels libres concerne les services aux entreprises : le segment des grandes entreprises représentait plus de 69,0 % du marché des services open source en 2022 ».

Mais ils ajoutent qu' « en revanche, une grande partie de l'utilisation des logiciels libres concerne la production en petites équipes et individuelle, où l'adoption peut être élevée, mais où la monétisation repose sur la découverte par le biais des canaux communautaires plutôt que sur des achats formels ». Et ce sont notamment ces projets, comme Tailwind, qui selon eux se trouvent menacés par le vibe coding.

Un détournement des utilisateurs par l'IA

Dans cet article, les économistes modélisent mathématiquement cet écosystème de l'open source reliant l'adoption des logiciels par les utilisateurs aux gains des développeurs. Puis ils ajoutent à leur modélisation l'arrivée du vibe coding. Ils regardent ensuite comment le marché évolue au sein de cette modélisation, et si les développeurs ne monétisent leur travail que via l'engagement direct et non via des alternatives s'appuyant sur l'IA (par exemple en faisant payer l'accès à des API), des dons ou autres.

De cette modélisation, les quatre chercheurs concluent qu' avec le vibe coding, « les utilisateurs peuvent adopter plus facilement les paquets, et les développeurs peuvent s'appuyer plus efficacement sur le code existant » et la productivité augmente.

Mais « le canal de détournement de la demande fait passer les utilisateurs d'une interaction directe (lecture de la documentation, dépôt de rapports de bogues, collaboration avec les responsables de la maintenance) à une utilisation médiatisée par l'IA ». Dans les modèles commerciaux open source traditionnels basés sur la visibilité et l'engagement, ce détournement érode la base de revenus qui soutient la contribution.

Un changement de modèle économique plutôt qu'un ralentissement de l'adoption de l'IA ?

Dans leurs remarques, ces quatre chercheurs se positionnent contre un ralentissement de l'adoption de l'IA, car « les avantages sont trop importants et la technologie trop utile », mais ils plaident plutôt pour une adaptation des modèles économiques des petites entreprises d'open-source qui ne s'appuient actuellement que sur les interactions directes. Transferts directs, modes de monétisation alternatifs mais aussi et surtout « la redistribution au niveau des plateformes » sous forme de « Spotify de l'open source », seraient, selon eux, des solutions viables.

Encore faut-il, pour cette dernière solution évoquée, que la communauté de l'open-source accepte de lier directement une grande partie de ses revenus à un ou des acteurs centraux qui dirigeraient ces plateformes.

Commentaires (23)

votre avatar
« la redistribution au niveau des plateformes » sous forme de « Spotify de l'open source », seraient, selon eux, des solutions viables
Parler de libre (enfin, pas sûr, vu que l'on parle uniquement de l'OS de FLOSS) et recommander une centralisation : comment perdre toute crédibilité en une phrase.
Ces personnes sont-elles au courant de l'histoire & des valeurs du libre & ouvert ?
votre avatar
Mon avis est que tous ce qui sort d'une IA, devrait être sous CC-by-SA ou GPL car on ne peut distinguer dans les sources d'entraînement de l'IA le contenu sous ces licences du reste. Et comme ces licences sont contaminantes, elles contaminent tous le reste.
Ma position est sûrement bancale juridiquement, mais je pense que les boîtes d'IA se sont tellement assis la propriété intellectuelle, le domaine publique & Co que cela fait bizarre à tous les opposants à la HADOPI. Et donc les positions bancales juridiques n'interdisent pas le développement des entreprises.
Selon que vous serez puissant ou misérable,
les jugements de cour vous rendront blanc ou noir.
votre avatar
Ma position est sûrement bancale juridiquement
Oui, c'est très bancal. On ne peut pas changer la licence d'un code comme ça. Seul l'auteur peut le faire, ou alors il faut que cela soit permis par la licence à la base.

Et il ne faut pas croire, il n'y a pas que des projets libres sur lesquels se sont entrainés les LLM, et encore moins que des projets sous GPL.

Qui plus est, si le code produit par un LLM était soumis à une licence comme la GPL, cela sous-entendrait que le "propriétaire" du code, c'est l'éditeur du LLM, pas celui qui vibe-code.

Par contre, il pourrait y avoir des licences qui considèrent que le code issu d'un LLM comme pouvant être considéré comme une oeuvre dérivée (et donc couverte, comme la GPL). Mais dans ce cas, ce serait à l'auteur d'un logiciel ou d'une bibliothèque de :
1) prouver que le LLM a été entrainé avec son programme dans le jeu d'entrainement
2) prouver qu'il y a un véritable lien entre son projet et le projet "vibe-codé".

Et ça, c'est loin d'être facile, à moins que le LLM ne "reponde" directement un fichier entier sans le modifier par exemple.
votre avatar
Qui plus est, si le code produit par un LLM était soumis à une licence comme la GPL, cela sous-entendrait que le "propriétaire" du code, c'est l'éditeur du LLM, pas celui qui vibe-code.
Pour qu'il y ait une licence, il faut qu'il y ait propriété intellectuelle et pour qu'il y ait propriété intellectuelle, il faut que ça soit un ou plusieurs humains qui produise l'œuvre.

L'exemple le plus connu est celui de la macaque qui s'était prise en photo. fr.wikipedia.org Wikipedia
Le 22 décembre 2014, le bureau du droit d'auteur des États-Unis a clarifié ses pratiques en indiquant explicitement que les œuvres créées par des non-humains ne sont pas soumises aux règles du droit d'auteur.
D'accord avec le reste.

Et reste le problème du code co-produit par des LLM et des humains, ça risque d'être compliqué à gérer, ce point.
votre avatar
"Contaminant" est un terme péjoratif, utilisé par les adversaires des modèles libres. "Diffusif" est neutre.
votre avatar
Tout comme "privateur", qui est utilisé par les libristes (et ça ne leur pose en général pas de problème), alors qu'il existe pourtant tout un tas d'alternative, à la fois plus précises et plus neutres...
votre avatar
La rapacité du capitalisme : profiter du travail des autres pour maximiser son propre profit, sans avoir de considération pour ceux qui ont contribué à faire émerger et vivre le-dit projet.

Tout le monde appelle un ralentissement de l'IA (pour diverses raisons), mais tout le monde continue de l'utiliser, "parce que c'est utile / rigolo" et "je veux ma part du butin".
votre avatar
Je dois être un extra-terrestre, pour ma part je joue avec l'IA pour produire... Du code libre.
Je bosse sur un gros projet que j'ai toujours rêvé de voir émerger et jamais vu apparaître. Et pour combler mes éventuelles lacunes en sécurité, en Rust.
L'IA n'est qu'un amplificateur. Je peux t'assurer que sans elle, porter le moteur interne de Kodi vers Rust tout en conservant la compatibilité des skins, et en visant d'autres usages que l'aspect media center, m'aurait été impossible, tant la charge de travail que ça représente est folle...
votre avatar
Et pour combler mes éventuelles lacunes en sécurité, en Rust.
Voilà ce que je craignais à lire partout "rust = sécurité" :craint:
votre avatar
Personne n'a dit que c'était le graal. Mais au niveau des risques liés à l'allocation mémoire, ça limite déjà pas mal de soucis...
votre avatar
Le problème est que tu ne combles aucune lacune avec ça, car la sécurité IT n'est pas une techno mais un référentiel de bonnes pratiques et de contrôles.

Par exemple, les patterns de type supply chain sont aussi possibles avec Rust.
votre avatar
Mais... Personne ici ne t'a affirmé le contraire !
votre avatar
Non, mais le raccourci que j'ai cité m'a convaincu qu'il était nécessaire de préciser ces éléments.
votre avatar
ça limite déjà pas mal de soucis
Pas plus que n'importe quel langage "managé" comme Python, Java, C# (je ne parle pas des performances, juste de la sécurité) dont l'usage n'est en aucune façon un gage de sécurité.
votre avatar
les avantages sont trop importants et la technologie trop utile

J'espère que dans la source il y a un peu plus de contexte pour étayer cela. Parce que pour le moment, je ne vois rien de transcendant. Cela fait plus de mal que de bien et je suis dans le développement depuis un paquet d'année. J'attends toujours la déferlante promis de logiciel vibe codé de "qualité".
votre avatar
Force est de constater que plus les llm s'améliorent, meilleur devient le code produit. Hier ce n'était clairement pas au point, aujourd'hui pas encore mais c'est mieux, et demain ? Demain n'est pas écrit.
votre avatar
Dans l'essai que j'ai fait de Antigravity au travail c'était très moyen. L'agent tape plus vite que toi mais réfléchis super longtemps pour certaines choses basique (et malgré le fait de lui faire auto documenter comment faire les PR ils pinaillait à chaque fois à recréer les commandes). Au final pour refactor des tests ou des tâches précises à porté limité c'était bien. Dès que l'humain au commande ne savait pas ce qu'il faut faire (techniquement) ça part dans les choux super vite... Donc peut être en mode d'analyse de code pour combler les trous dans les tests et/ou d'aide à la rédaction de test répétitifs je ne dirais pas non.

Voire la chaîne de pensé pendant qu'il débug c'était intéressant par contre. Les solutions qu'il trouve pas toujours par contre 🤣
votre avatar
Gemini 3 sur Antigravity est très loin d'être représentatif de ce qu'il se fait de mieux actuellement. Ce n'est pas le pire, mais il est clairement à la ramasse et en retard comparé à d'autres même si les progrès sont flagrants comparé à la 2.5. On va dire que pour quelque chose de gratuit avec plusieurs comptes google, ça dépanne, mais il faut souvent reprendre ce qui est développé pour aboutir au résultat souhaité.

Dans l'ordre si tu veux te faire une idée, teste :

-Codex 5.2 Very High sur Visual Studio et ses forks - très lent mais le plus doué pour résoudre les problèmes complexes, mais tend à pondre du code monolithique si on ne l'accompagne pas.
-Claude Opus 4.5 via son propre IDE - le plus tout terrain, très bon mais très cher, se débrouille bien sur beaucoup de chose, probablement le meilleur à l'usage et en raisonnement classique à ce jour.
-Kimi K2.5 via Kilocode sur Visual Studio & cie - extrêmement convaincant, manque encore un peu de compétences en raisonnement, mais c'est le premier modèle open-source multimodal qui se démarque vraiment et faire presque aussi bien que Claude Opus. Mais c'est aussi le plus cher d'entre-eux.
-GLM 4.7 sur Kilocode - presque aussi bon que Kimi K2.5, mais plus lent, et bien moins cher.

Le reste, c'est clairement largué à côté, même Qwen ou Deepseek-R1 sont en retard, mais ce qui est gratuit dépanne bien pour un peu d'analyse et des choses basiques.

Enfin, de façon général, sans accompagnement, sans directives claires, TOUS les llm feront de la m... ou presque. L'idéal c'est de croiser et faire converser ces derniers, car comme lorsque l'on croise les sources, croiser les LLM pour confronter leurs raisonnement jusqu'à alignement améliore drastiquement le résultat.

Il faut également leur rappeler d'être factuels pour limiter les soucis.
votre avatar
Claude a beaucoup d’avance depuis longtemps maintenant. Même Sonnet 4.5 continue de se défendre toujours aussi bien.

J’ai cru à un moment que Gemini était meilleur mais en fait non, Gemini blablate beaucoup trop, et, probablement à cause de ça, a tendance à tourner en rond.

Si t’as aucun problème de budget par exemple parce que ta boîte paie, y a juste toujours rien de mieux que Claude. Pas toujours parfait mais facile à surveiller et à encadrer, ne refait pas 20 fois les mêmes erreurs quand tu lui fais remarquer.

GLM 4.7 j’ai testé vite fait et ça a l’air pas mal si t’as pas les moyens de payer Claude mais il fait plus d’erreurs.

Claude Sonnet/Haiku c’est vraiment la seule IA qui me donne l’impression d’avoir un junior à mes côtés : elle fait des erreurs mais c’est très rare qu’elle fasse des trucs stupides ou s’obstine sur des mauvaises pistes. Avec le bon tooling genre opencode, je n’ai plus trop peur de la faire travailler sur des sujets un peu complexe.

Je met un point d’honneur à toujours relire tout ce qui est produit et j’ai rarement besoin d’y revenir, surtout si je l’encadre en la forçant à faire du BDD ou du TDD.
votre avatar
Clairement Opus 4.5 est vraiment en avance.
Après c'est un outil qui demande beaucoup de temps et d'expérimentation pour comprendre comment lui faire faire des choses convenables (gestion des contextes/sessions, les différents fichiers de mémoire, les conventions de code etc...).
votre avatar
C'est bien cela le problème, j'ai pas que cela à faire de baby-sitter une flotte de llm en espérant arriver à un point ou le code généré serait acceptable.

Autre point, basculer d'un monde ou développer un logiciel était accessible à n'importe quelle personne avec un ordinateur, à un monde où il faudra payer pour développer..., je suis pas fan.

Sans parler de l'empreinte énergétique pour arriver à un résultat aussi médiocre.

Peut-être que cela s'améliorera... ou pas. La techno est basée sur des probabilités, donc on ne pourra jamais en faire quelque chose qu'on peux croire les yeux fermés.

La seul chose de sûr poir le moment ce sont les problématiques monstres que cela crées ( emploi, environnment, perte de compétence, bulle financière, lavage de cervaux) pour un avantage hypothétique.
votre avatar
Il y a plusieurs autres aspects qui "fragilisent" l'opensource en IA:
* la mort des petites bibliothèque : là où avant n allait peut-être utiliser une petite bibliothèque ou un petit bout, on peut générer le code "équivalent" en IA
* la vampirisation: on peut injecter le code d'un bibliothèque et la "forker" en interne par IA, l'IA étant un très bon éléments pour améliorer/customiser une librairie existante. Et elle est capable de réinjecter les mises à jours en se débrouillant bien
votre avatar
Pour ma part, j'ai toujours eu la flemme de peaufiner mes programmes, donc l'IA est un apport appréciable, d'autant que la qualité du code produit s'est nettement amélioré avec le temps. Donc les usages changent, reste à savoir si globalement ça va être profitable ou pas.

Côté licence, chatGPT (Codex) que j'ai interrogé m'a indiqué que la propriété de code était inchangée : l'IA est considérée comme un outil et n'applique aucune licence au travail effectué. La difficulté se déplace vers le modèle d'entrainement, mais c'est un problème pour le fournisseur, pas pour le codeur. En effet, les données utilisées pour l'entraînement peuvent être soumises à licence(s), et à des licences de natures très différentes. Mais tant qu'on n'utilise pas une portion de code significative dans le code produit, il n'y a pas de problématique nouvelle à celle d'un développeur dans son coin. Une précaution, tout de même : il faut être sûr que le code produit n'est pas directement tiré d'un code sous licence. Ca reste la même chose, encore une fois, qu'un développeur isolé, à la grosse différence qu'un LLM explique rarement (et difficilement) comment il a abouti au code généré. D'autres avis ?

Le vibe coding met en danger l’open-source selon des économistes

  • En suivant le déclin de Stack Overflow ?

  • La monétisation sur la découverte du projet menacée

  • Un détournement des utilisateurs par l'IA

  • Un changement de modèle économique plutôt qu'un ralentissement de l'adoption de l'IA ?

Fermer