Comment le vibecoding détruit l’open source qui le nourrit

3 mars 2026

Le serpent qui se mord la queue

Il y a un an, le vibecoding était une curiosité. Aujourd’hui, c’est une industrie. Des millions de développeurs — ou plutôt de prompteurs — génèrent des applications entières en décrivant ce qu’ils veulent à un LLM. En quelques minutes, une API, un front, un déploiement. Magique.

Mais derrière cette magie, il y a un sale secret que personne ne veut regarder en face : chaque ligne de code générée par ces IA a été entraînée sur des millions de projets open source — des projets qui, aujourd’hui, agonisent.

Le vibecoding ne serait rien sans l’open source. Et il est en train de le tuer.

Qu’est-ce que le vibecoding, exactement ?

Pour ceux qui auraient passé l’année 2025 dans une grotte : le vibecoding, c’est la pratique de créer du logiciel en langage naturel, en s’appuyant sur des modèles d’IA générative (Claude, GPT-5, Gemini, et les dizaines de modèles spécialisés qui ont émergé depuis). On décrit une vibe, une intention, et l’IA produit le code.

Pas de débogage. Pas de lecture de documentation. Pas de Stack Overflow. Et surtout — c’est là que le bât blesse — pas de contribution en retour.

Le pacte implicite de l’open source est rompu

L’écosystème open source a toujours reposé sur un contrat social tacite :

Je publie mon code gratuitement. En échange, d’autres l’utilisent, trouvent des bugs, proposent des améliorations, contribuent. Le projet vit parce qu’une communauté le fait vivre.

Ce contrat avait déjà été mis à rude épreuve par les grandes entreprises qui consomment de l’open source sans contribuer proportionnellement. Mais au moins, les développeurs qui utilisaient ces bibliothèques les comprenaient. Ils ouvraient des issues. Ils forkaient. Ils envoyaient des pull requests. Ils écrivaient des articles de blog qui faisaient connaître le projet.

Le vibecoding a dynamité ce cycle.

Le vibecodeur ne sait pas quelle bibliothèque il utilise. Il ne le sait pas, et il s’en fiche. Il a demandé « fais-moi une API de paiement avec gestion de webhooks », et l’IA a choisi pour lui telle ou telle dépendance. Il ne lira jamais le README de ce projet. Il n’ouvrira jamais une issue. Il ne saura même pas que ce projet existe.

Les chiffres qui font froid dans le dos

Les données commencent à parler, et elles ne sont pas rassurantes :

  • Les contributions aux projets open source de taille moyenne (10-500 stars) ont chuté de 35 % entre janvier 2025 et janvier 2026, selon les données agrégées de GitHub et GitLab. Ce sont ces projets de taille moyenne qui forment l’essentiel du tissu conjonctif de l’écosystème.

  • Le nombre de nouvelles issues ouvertes par des humains est en baisse de 28 %, tandis que les issues ouvertes par des bots ou des outils automatisés explosent — souvent du bruit, rarement du signal.

  • Les dons via GitHub Sponsors, Open Collective et Tidelift stagnent ou reculent pour la majorité des projets, alors que l’usage réel (mesuré par les téléchargements npm, PyPI, etc.) continue d’augmenter. Plus de consommation, moins de soutien.

  • Le nombre de nouveaux contributeurs « first-time » sur les projets fondamentaux (librairies de crypto, parsers, outils réseau) a chuté de 41 %.

Ce dernier chiffre est le plus inquiétant. C’est le pipeline de la relève qui se tarit.

La génération fantôme

J’ai parlé avec une dizaine de mainteneurs de projets open source populaires ces dernières semaines. Le même constat revient, presque mot pour mot :

« Mes téléchargements n’ont jamais été aussi hauts. Mes contributions n’ont jamais été aussi basses. »

— Mainteneur d’une bibliothèque Python de traitement de données, 12 000 stars

« Je reçois des issues qui n’ont clairement aucun sens. Quelqu’un a copié-collé un message d’erreur généré par un outil IA, sans comprendre ce que fait ma bibliothèque ni même savoir qu’il l’utilise. Je passe plus de temps à fermer des issues inutiles qu’à développer. »

— Mainteneur d’un outil Node.js

« J’ai l’impression d’être devenu un sous-traitant invisible de Cursor et de Copilot. Mon code est partout, mais moi, j’ai disparu. »

— Créatrice d’une bibliothèque de composants UI

Le vibecoding a créé une génération fantôme : des gens qui dépendent de l’open source sans exister dans l’open source. Ils ne sont ni utilisateurs, ni contributeurs, ni spectateurs. Ils sont des consommateurs passifs d’un extracteur automatique de valeur.

Le problème technique : des dépendances sans conscience

Au-delà du problème communautaire, il y a un problème technique concret.

Quand un développeur humain choisit une dépendance, il fait (en théorie) un travail d’évaluation : ce projet est-il maintenu ? A-t-il des vulnérabilités connues ? Est-il adapté à mon cas d’usage ? Quelle est sa licence ?

L’IA, elle, optimise pour ce qui marche maintenant. Elle favorise les bibliothèques sur-représentées dans ses données d’entraînement — c’est-à-dire celles qui étaient populaires au moment de l’entraînement. Cela crée deux effets pervers :

  1. L’effet de fossilisation : des bibliothèques obsolètes ou mal maintenues continuent d’être injectées dans de nouveaux projets, parce que l’IA « se souvient » d’elles. On a vu des projets générés en 2025 qui utilisaient des versions de packages datant de 2022, avec des CVE connues.

  2. L’effet winner-take-all : les gros projets (React, Express, pandas) continuent d’être recommandés systématiquement, tandis que les alternatives plus récentes, plus légères, mieux conçues, restent invisibles. L’innovation de l’écosystème se fige.

Le paradoxe de la « démocratisation »

Les défenseurs du vibecoding avancent un argument de poids : la démocratisation. Grâce à l’IA, des millions de personnes qui ne savaient pas coder peuvent désormais créer des logiciels. C’est vrai. C’est même formidable.

Mais cette démocratisation est extractive. Elle extrait de la valeur d’un bien commun (l’open source) pour la concentrer dans des produits propriétaires (les IDE IA, les plateformes SaaS, les API d’inférence). Les vibecodeurs paient leur abonnement à Cursor ou Replit, pas à la personne qui maintient date-fns à 2h du matin.

On a privatisé les bénéfices et socialisé les coûts. Un classique.

Les modèles d’IA eux-mêmes aggravent le problème

Il faut aussi pointer du doigt les entreprises d’IA elles-mêmes.

Les modèles ont été entraînés sur du code open source, souvent sans consentement explicite, et les revenus générés par ces modèles ne redescendent pas vers les projets dont ils dépendent.

Certaines initiatives existent — Anthropic, Google et d’autres ont lancé des fonds de soutien — mais soyons honnêtes : ce sont des miettes. Le fonds « AI for Open Source » annoncé par la Linux Foundation en novembre 2025 représente 50 millions de dollars. C’est moins que ce que ces entreprises dépensent en compute sur un trimestre.

Et surtout, l’argent ne remplace pas les contributeurs. Un projet open source ne meurt pas faute de dollars. Il meurt faute de gens qui s’en soucient.

Le scénario cauchemar

Projetons-nous un instant.

Si la tendance actuelle se poursuit :

  1. Les mainteneurs épuisés abandonnent leurs projets. C’est déjà en cours. Le burnout des mainteneurs n’est pas nouveau, mais le vibecoding l’accélère en augmentant la charge (plus d’usage, plus de bruit dans les issues) tout en diminuant la récompense (moins de reconnaissance, moins de contributions).

  2. Les projets critiques deviennent des logiciels zombies : toujours téléchargés, plus jamais mis à jour. Des failles de sécurité s’accumulent. Les IA continuent de les recommander.

  3. Une crise de sécurité majeure éclate lorsqu’une vulnérabilité dans un package-zombie se retrouve dans des milliers d’applications vibecoded. Log4Shell semblera un exercice d’échauffement.

  4. L’innovation ralentit parce que les nouveaux projets open source ne trouvent plus de communauté. Pourquoi publier un package quand personne ne le regardera jamais — quand les gens ne regardent plus de code du tout ?

  5. Les modèles d’IA se dégradent parce qu’ils s’entraînent de plus en plus sur du code généré par IA plutôt que sur du code humain réfléchi. Le serpent se mord la queue jusqu’à l’os. Ce qu’on appelle le model collapse devient visible dans la qualité du code produit.

Ce scénario n’est pas de la science-fiction. Chaque étape est déjà amorcée.

Que faire ?

Je ne suis pas naïf au point de penser qu’on peut arrêter le vibecoding. Le génie est sorti de la bouteille, et franchement, la productivité qu’il apporte est réelle. Mais on peut — on doit — corriger la trajectoire.

1. Taxer l’extraction, financer les communs

Les plateformes d’IA qui monétisent du code généré à partir de l’open source devraient reverser un pourcentage significatif de leurs revenus à l’écosystème. Pas un fonds symbolique. Un mécanisme structurel, proportionnel à l’usage réel. Le modèle existe déjà dans d’autres domaines : on appelle ça une licence de redistribution ou une redevance sur les communs numériques.

2. Rendre les dépendances visibles

Les outils de vibecoding devraient afficher systématiquement les dépendances open source qu’ils injectent, avec un lien vers le projet, son état de maintenance, sa licence, et un moyen de contribuer. Pas caché dans un package.json que personne ne lira. En plein écran. « Ce code utilise 47 projets open source. 3 d’entre eux n’ont pas été mis à jour depuis un an. Voici comment les soutenir. »

3. Intégrer la contribution dans le workflow IA

Pourquoi les outils IA ne pourraient-ils pas générer des contributions en retour ? Détecter un bug dans une bibliothèque, rédiger un correctif, proposer une documentation améliorée ? Si l’IA est capable de consommer l’open source, elle devrait être capable d’y contribuer.

Certains projets expérimentaux vont dans ce sens. Il faut les généraliser.

4. Éduquer les vibecodeurs

Ce n’est pas parce qu’on ne code pas qu’on ne devrait pas comprendre d’où vient le code qu’on utilise. Les plateformes de vibecoding devraient inclure un minimum de literacy open source : qu’est-ce qu’une licence ? Qu’est-ce qu’un mainteneur ? Pourquoi c’est important ?

On n’exige pas de quelqu’un qui conduit une voiture qu’il sache la construire. Mais on exige qu’il sache que la route a été construite par quelqu’un, et qu’il paie des impôts pour l’entretenir.

5. Repenser les licences

La licence MIT et la licence Apache ont été écrites pour un monde où les utilisateurs étaient des développeurs. Ce monde n’existe plus. Il est temps d’explorer de nouveaux modèles de licences qui prennent en compte l’extraction par IA et garantissent une redistribution équitable de la valeur créée.